Tag: security

開 S3 bucket 與 IAM 帳號的工具

看到 Simon Willison 的「s3-credentials: a tool for creating credentials for S3 buckets」這篇，裡面講到了幾件事情。

在 AWS 上比較好的安全設計是，不同專案之間都有自己的 S3 bucket，然後建立對應的 IAM user，每個 IAM user 只能存取自己的 S3 bucket。

但這個建立過程很煩：

Creating those credentials is surprisingly difficult!

整個建立的過程包括了四個步驟：

  1. 建立 S3 bucket。
  2. 建立 IAM user。
  3. 將 IAM user 掛上對應的 S3 權限。
  4. 建立 IAM user 的 access key。

讓人煩的主要是第三個，那個 JSON format 每次都要翻資料 XD

所以他寫了 s3-credentials 這個套件讓大家用，可以透過 pip 直接安裝起來用。

不過我是偏好用 awscli 的，直接把指令放在 wiki page 上面：「awscli」，需要的時候就 copy & paste 過來執行就可以了。在公司的 wiki 上還有直接把 EC2 instance 生到對應的 subnet 指令可以用...

這東西大概不會簡化，只能大家自己找出路 XD

用 iptables 擋特定國家的封包

這兩天發現 ubuntu-20.04.3-live-server-amd64.iso 這個 BitTorrent 的 ISO image 有大量來自 CN 的連線在狂抓，導致整個上傳頻寬都被吃滿：

沒想到第一次用 iptables 的 xt_geoip 居然是這個用途... 主要是參考「GeoIP Blocking Ubuntu 20.04LTS」這邊的方法，不過因為我的 rtorrent 是跑在 Docker 裡面的，有另外要注意的地方。

首先是安裝軟體，這邊要裝 xtables-addons-common 與 libtext-csv-xs-perl：

sudo apt install -y libtext-csv-xs-perl xtables-addons-common

再來是建立目錄，並且下載一包 GeoIP 的資料 (從 DBIP 下載) 並且轉成 xt_geoip 可以用的格式：

sudo mkdir /usr/share/xt_geoip
cd /usr/share/xt_geoip
sudo /usr/lib/xtables-addons/xt_geoip_dl
sudo /usr/bin/perl /usr/lib/xtables-addons/xt_geoip_build

然後就是加到 iptables 的條件裡面了，我加到兩個地方，一個是 INPUT chain，另外一個是 DOCKER-USER chain (參考「Docker and iptables」這邊的說明)，假設你是用 port 6991 的話就這樣加：

sudo iptables -I INPUT -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP
sudo iptables -I DOCKER-USER -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP

然後可以考慮每個禮拜更新一次資料庫。

另外在找資料的時候發現「Free updated GeoIP legacy databases」這邊有人放出 MaxMind 的版本，不過免費版的應該都差不多，這邊就用 xtables-addons-common 內預設的。

弄完以後就正常多了...

裝完 Windows 後馬上跑的設定：關掉一堆侵犯隱私的設定

因為 Diablo II: Resurrected 的關係跑回來用 Windows 10，裝完 OS 後可以透過 GUI 關掉一堆隱私設定沒錯，但感覺應該是有人整理出來更方便的方法...

在「Awesome Windows privacy」這邊看到有工具可以做到，目前用的是「Windows-10-Hardening」這組，把 script 抓下來後用管理權限跑一次，接著重開機就好了...

看起來沒什麼大問題，之後應該都會在重灌後拿來用...

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。

在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。

接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。

其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。

概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...

美國聯邦政府 CIO 以資安理由建議安裝 ad block 軟體

Hacker News Daily 上看到的，美國聯邦政府的 CIO Clare Martorana 行文建議行政管理和預算局 (Office of Management and Budget) 安裝 ad block 軟體以確保資訊安全：「The NSA and CIA Use Ad Blockers Because Online Advertising Is So Dangerous」。行文的文件在「Wyden Letter to OMB on Ad-Blocking」這邊可以看到，另外在 Hacker News 上的討論「The NSA and CIA use ad blockers (vice.com)」也可以翻。

有很多惡意軟體 (像是 malware) 會透過合法的 ad network 散布，然後竊取資料，甚至是透過麥克風監聽環境音：

I write to urge the Office of Management and Budget (OMB) to protect federal networks from foreign spies and criminals who misuse online advertising for hacking and surveillance, by setting clear new rules for agencies in its forthcoming “zero trust” cybersecurity policy.

I have pushed successive administrations to respond more appropriately to surveillance threats, including from foreign governments and criminals exploiting online advertisingto hack federal systems. This includes seemingly innocuous online advertisements, which can be used to deliver ‘malware to phones and computers—often without requiring users to click anything. This ‘malware can steal, modify or wipe sensitive government data, or record conversations by remotely enabling a computers built-in microphone.

記得我是從 Firefox 還叫做 Phoenix 的時代就在用 ad blocker 了... 建議大家一定要裝啊，以現在來說應該都是裝 uBlock Origin，在有支援 extension 的瀏覽器都有商店可以直接安裝。

Ubuntu 14.04 與 16.04 的 ESM 從八年延長到十年

本來的舊的 Ubuntu ESM 是額外的三年 (加上本來的 LTS 五年，共八年)，14.04 會支援到 2022 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 14.04 LTS has transitioned to ESM support」)，然後 16.04 會支援到 2024 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 16.04 LTS transitions to Extended Security Maintenance (ESM)」)，而 18.04 與 20.04 以後的 Ubuntu ESM 則是額外五年。

現在則是宣佈 14.04 與 16.04 都切齊額外五年了，所以總共都是十年：「Ubuntu 14.04 and 16.04 lifecycle extended to ten years」。

另外在 Hacker News 上的討論可以看一下：「Ubuntu 14.04 and 16.04 lifecycle extended to ten years (ubuntu.com)」，有人覺得這個政策很糟，但我覺得還好，有些商業環境就是花錢解決懶得升級... (沒有 support 只有 security update 的方案，一台實體機器才 USD$225/year，如果是虛擬機的話就更便宜了)

算是對付 legacy application 還蠻重要的方案...

OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

看到 OpenSSL 的官方居然特地寫一篇與 Let's Encrypt 的相容性問題：「Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2」。

這邊提到的 OpenSSL 1.0.2 很舊了 (在 Ubuntu 16.04 內是 1.0.2g)，理論上大多數的機器應該不太會遇到這個問題。

問題出自 Let's Encrypt 舊的 DST Root CA X3 將在這個月月底過期，這在 Let's Encrypt 的「DST Root CA X3 Expiration (September 2021)」這邊也有提到。

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

理想上只有要任何一條 trust chain 成立，就應該會把這個憑證認為是合法的憑證，但這在 OpenSSL 1.0.2 (以及之前的版本) 不是這樣設計。

舊版的設計是只要有任何一條過期的憑證，就會把憑證認為過期而失效：

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做，另外我還有想到一個惡搞方式，是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

Firefox 支援 HTTPS RR

在「Firefox 92.0, See All New Features, Updates and Fixes」這邊看到支援 HTTPS RR：

More secure connections: Firefox can now automatically upgrade to HTTPS using HTTPS RR as Alt-Svc headers.

在「Enabling HTTPS RR on release」這邊決定啟用的，使用的標準是「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」這個，可以看到目前還是 draft (draft-ietf-dnsop-svcb-https-07)。

HSTS 是 Trust on first use，也就是在第一次連線時 server side 會送出 HSTS header，之後瀏覽器遇到同一個網站時就會都強制使用 HTTPS。

如果要確保第一次也是強制使用 HTTPS，在這之前必須靠瀏覽器內建的清單 HSTS Preload List 才能確保安全性，這次的 HTTPS RR 算是補上這個缺口。

在使用者環境有 DNS over HTTPS (DoH) 或是 DNS over TLS (DoT)，再加上 DNS resolver 會檢查 DNSSEC 的前提下，整條環境就接起來了。

不過實際讀了 spec 會發現 SVCB RR 與 HTTPS RR 想做的事情太多了，話說愈複雜的東西愈容易出包，先放著觀望看看好了...

OpenSSH 的 scp 改用 SFTP 協定

在「By default, scp(1) now uses SFTP protocol」這邊看到的，OpenSSH 的 scp 改用 SFTP 協定了，原因也有附在文章裡：

SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side.

要注意這是 BC-break change，有些之前會動的 case 在改用 SFTP 後會爛掉，但這算是前進了一大步，scp 因為 spec 的關係很難維護安全性。

在「Deprecating scp」這邊也有提到相關的問題，另外也給出了一些範例。