幹壞事是進步最大的原動力
自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目：「Ask HN: Why can't I host my own email?」。
收信只要有固定 IP，加上 ISP 沒有擋 TCP port 25 就倒不是問題，整個最難的點在於怎麼送信，因為會常常被標成 spam...
最基本要設定的東西大概是 SPF，但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。
然後依照經驗，Gmail 擋信的機率低不少，微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...
目前一般建議是自用就過 Amazon SES，沒有低消所以個人用起來不貴...
OpenSSH 在連到新的 host 時會跳出 key fingerprint 的資訊讓使用者確認，有時候為了自動化會用 StrictHostKeyChecking=no 避開，在 Lobsters Daily 上則看到了新的選項可以用，StrictHostKeyChecking=accept-new：
Reading manuals is extremely helpful.
I discovered the "accept-new" option for ssh strict host key checking and now I can delete my buggy code for manually populating known_hosts. 😅
Does exactly what it says. If the host key not in known_hosts, add it. Fail otherwise. pic.twitter.com/9xsbsMcpur
— Anton Medvedev (@antonmedv) January 11, 2022
就如同選項的名字所描述的，查了一下 OpenSSH Release Notes 可以看到這是在 OpenSSH 7.5 導入的參數，是在 March 20, 2017 引入的：
* ssh(1): expand the StrictHostKeyChecking option with two new settings. The first "accept-new" will automatically accept hitherto-unseen keys but will refuse connections for changed or invalid hostkeys. This is a safer subset of the current behaviour of StrictHostKeyChecking=no. The second setting "off", is a synonym for the current behaviour of StrictHostKeyChecking=no: accept new host keys, and continue connection for hosts with incorrect hostkeys. A future release will change the meaning of StrictHostKeyChecking=no to the behaviour of "accept-new". bz#2400
對於一些自動化的流程應該夠用了，不需要到用 no 完全關掉。
翻了「Ubuntu – Package Search Results -- openssh-client」可以看到 18.04 之後都是 7.5 之後的版本了，支援度應該是沒什麼太大問題...
如同在「升級跳板機」這邊提到的，這台跳板機是跑 Ubuntu 20.04，加上需要跑 PPPoE，我就遇到透過 PPPoE 拿到的 DNS 無法套用的系統內。
這點在「add pppoe support to systemd-networkd」這邊有被提到，而且看起來 Debian 那邊已經套用 patch 上去了，但 Ubuntu 這邊似乎還沒...
我看了看還是決定先暫時先回頭用 resolvconf，可以只用指令解決：
sudo apt install -y resolvconf sudo systemctl disable systemd-resolved
然後重開確認後就可以收工...
算是做個記錄...
差不多是 2014 年的時候，因為 xDSL 網路的頻寬拉起來比較夠用了，加上當時發生一些事情，而且 HiNet 的 PPPoE 可以申請發一個固定 IP (即「非固固 IP」)，所以就用這個功能架了一台小的 server，這樣一來就有一台小的 server 可以用，另外很多 firewall 之類的操作就方便很多。
當時買的機子是 Gigabyte 的 GB-XM12-3227，Intel i3-3227 + 4GB RAM + 128GB mSATA SSD：
幾年前 CPU 風扇掛過一次，去淘寶上挖了一顆回來後又可以繼續用。
不過後來在上面跑的東西愈來愈多，加上現在的軟體開發愈來愈吃各種資源 (就算只是 command line 環境)，i3-3227 的 CPU Benchmarks 跑分也才 1274，記憶體也只裝了 4GB，跑起來還是愈來愈吃力... 大概在年初的時候就有打算要換，直到看到了這個機殼的影片：
我買了一個機殼回來 (還找到 $350 含運的店家)，在客廳裝了一台 Intel J1900 + 8GB RAM 的機器接電視用 (不過這又是另外一個故事了)，對這款機殼還算滿意，就再去下了一顆回來...
接下來就是湊其他的零件了，既然這次要拿來當半個開發機用，上面的等級要好一點，但又不希望太吃電 (畢竟是一直開著的機器)，所以就找了一顆二手的 Intel i3-8100T (35W，CPU Benchmarks 分數 5319)，然後在 PChome 24h 上面找了張 H310 的主機板，一個全新的 350W 電源供應器，以及 2*16GB RAM + 500GB SATA SSD。風扇的話是之前 Intel E3-1230 v3 留下來的風扇 (現在上面是掛水冷)，扣具的位置是相同的 (LGA115x)，就直接拿來用了。
弄好後裝個 Ubuntu 20.04，然後在只有兩顆風扇的環境下 (電源供應器的風扇與 CPU 風扇)，CPU idle 只有 35 度上下，壓測也只有 55 度上下，本來還在糾結後方要不要還是裝個 8cm 系統風扇，後來決定還是放一顆上去好了，用負壓的方式把熱帶出來。
如果之後真的遇到灰塵太多的問題，再考慮用先前在「無風扇系統的 CPU 散熱片」提到的方案來換：
接下來就是搭車把機器帶老家裝，就順便被老人家餵食：
換完後當然如同預期的速度快不少，接下來應該會考慮把線路升級到 300M/100M (現在只有 100M/40M)，不過看起來 IP 一定會變，就比較麻煩了，之後再看看機會...
在「How to SSH Properly」這篇裡面講了三個 OpenSSH 的進階用法：CA 架構、透過 Jump Server 連線，以及 2FA 的設定。
之前蠻常看到使用 -o StrictHostKeyChecking=off 關閉檢查，但 OpenSSH 有支援 CA 架構，可以先產生出 Root CA，然後對 Host 的 Public Key 簽名，在連線的時候就可以確保連線沒有被調包 (通常是 MITM)，但得設計一套機制，自動化機器生出來後的步驟。
另外一個可能的方式是 SSHFP，搭配 DNSSEC 也可以確認連線沒有被調包，不過這又牽扯到 DNS 的部份...
第二個提到的是 Jump Server (Bastion host)，之前的作法是用 -A 把 authentication agent 帶過去再連進去，這邊則是教你怎麼下指令直接連線，而不需要先連到 Jump Server (但實際上底層是透過 Jump Server)。
第三個是 2FA，對於還是使用密碼登入的系統可以多一層保護。文章裡面講的是 TOTP 的方式 (就是現在還蠻常見的 app + 六碼動態數字)。
先知道有這些東西，之後真的有用到的場景時再回來看...
這邊講的是透過 css (以及 js) 使用的 Google Fonts，作者想要改善這塊，加速網頁的速度：「Should you self-host Google Fonts?」。
作者第一個提到的技巧是個懶人技巧，只要加上 preconnect 預先把 HTTPS 連線建好，就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異：
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin> <link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">
作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect，但從前後比較可以看出，整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的)：
另外一個技巧是增加 swap，讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖，然後突然字都冒出來的情況，也就是把一般在用的：
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin> <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
加上 &display=swap：
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin> <link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">
最後一招就是把字型放在自己家，差異就更大了：
另外一個好處是改善 privacy，不過好像沒特別提到...
先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫，經過幾天後有改變了。
Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」，裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30，被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style：
In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:
Original Plan – Support for the path-style model ends on September 30, 2020.
Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.
這樣大幅降低本來會預期的衝擊，但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來？
在 Hacker News 上翻的時候翻到的公告：「Announcement: Amazon S3 will no longer support path-style API requests starting September 30th, 2020」。
現有的兩種方法，一種是把 bucket name 放在 path (V1)，另外一種是把 bucket name 放在 hostname (V2)：
Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com/<bucketname>/key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //<bucketname>.s3.amazonaws.com/key).
這次要淘汰的是 V1 的方式，預定在 2020 年十月停止服務 (服務到九月底)：
Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.
Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.
在 Hacker News Daily 上看到「VirtualBox E1000 Guest-to-Host Escape」這篇，講 VirtualBox 5.2 的機器上 E1000 + NAT 模式的爆破... 另外在 Hacker News 上的討論也提到了很多這樣做的背景：「VirtualBox E1000 Guest-to-Host Escape | Hacker News」。
Oracle 對社群的態度 (無論是 open source community 或是 security community) 都一直是社群很不爽的事情。
這次爆破的發現人之前找到一個 VirtualBox 的 security bug (參考「SSD Advisory – VirtualBox VRDP Guest-to-Host Escape」)，回報後先是回應他們在處理中，然後被發現 VirtualBox 在 5.2.18 修掉了，但是完全沒有提到安全性問題的事情。所以這次作者也懶得囉唆了，找到就 full disclosure 出來。
作者給的 workaround 有兩個，優先建議暫時先用 PCnet 系列的界面，如果不行的話，至少不要用 NAT。
作者發表後沒多久馬上就有 5.2.22 推出，不過看 changelog 應該是沒有修正這個問題？(或是修掉又沒提...)
原文是講滲透測試的前置作業，需要將某個特定 domain 下的主機名稱掃出來：「A penetration tester’s guide to sub-domain enumeration」。
最直接的還是 DNS zone transfer (AXFR)，如果管理者沒設好 DNS server 的話，這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。
看了一下有幾種方式：
site: 指令過濾；用 VirusTotal 列；翻 Certificate Transparency 記錄；透過 ASN 資訊；透過 Forward DNS。應該有人可以提到所有的東西再寫成程式 XD