玩了一下 OpenSnitch,Linux 下的 Application Firewall

這是在 Hacker News 上的討論「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」這篇看到的,裡面一開始是提到 Mac 上面的 Little Snitch,可以針對特定應用程式設定防火牆規則,而在 Linux 上對應的解決方案則是 OpenSnitch,但一直沒有嘗試,所以就試著用看看...

套件分成兩個部分,一個是 OpenSnitch 的主程式,另外一個是 GUI 的部分。

而在 Ubuntu 22.04 上裝有點麻煩,因為 Ubuntu 22.04 上預設的 grpc package 似乎是有 bug,需要裝新版解決。

不過我在找 PPA 的時候發現有人包了輔助套件:「OpenSnitch - application firewall (Xenial & newer)」。

這個套件本身是沒有包 OpenSnitch 主程式與 GUI 套件的,他只是要「補充」官方套件安裝的問題,所以需要照他的說明安裝:(我把下面指令提到的 1.5.2 換成目前新版的 1.6.0 裝,目前看起來是會動的)

sudo add-apt-repository ppa:savoury1/opensnitch
sudo apt-get update && sudo apt-get upgrade
sudo dpkg -i opensnitch_1.5.2-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.5.2-1_all.deb
sudo apt-get -f install

這邊用 dpkg -i 裝,而不是用 apt install 的原因是故意讓他不裝 dependency,等到後面的 apt-get -f install 時再裝 PPA 裡面提供的 dependency。

裝好後把跑 opensnitch-gui 起來後就會陸陸續續收到系統內不同的應用程式嘗試的連線,像是官網提供的 screenshot 這樣 (會跳出像左邊這樣的視窗):

這樣可以控的比較細,不過剛開始用會需要花時間把系統內常態性的 request 先設定過一次,還蠻煩的 XD

在 PPA 裡面只安裝特定軟體的方式

Ubuntu 20.04 的 rsync 內建只有 3.1.3 (參考「Ubuntu – Package Search Results -- rsync」這邊),但 --mkpath 這個參數需要 3.2.3+ 才能跑:「How can I configure rsync to create target directory on remote server?」,所以就要找 PPA 看看有沒有人有包新版的可以用。

在「Utilities - various (Xenial & newer)」這邊可以看到 Rob Savoury 有包,但發現這包有一堆軟體,我不想要裝這麼多,所以就用 Pinning 限制。

apt-cache policy 可以看到 o= 的值,然後就可以在 /etc/apt/preferences.d/savoury1-utilities 裡設定 rsync 的 Pin-Priority1001,而其他的都掛到 -1

Package: *
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: -1

Package: rsync
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: 1001

但跑 apt upgrade 沒看到可以升級,而直接 apt install rsync 的時候可以看到是因為 libxxhash0 跟不上新版而產生錯誤訊息:

The following packages have unmet dependencies:
 rsync : Depends: libxxhash0 (>= 0.8.0) but 0.7.3-1 is to be installed
E: Unable to correct problems, you have held broken packages.

所以一起加進去變成:

Package: *
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: -1

Package: libxxhash0 rsync
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: 1001

然後就可以 apt upgrade 升級上去了。

jless:檢視 JSON 的工具

前幾天在「Show HN: Jless, a command-line JSON viewer (pauljuliusmartinez.github.io)」這邊看到用 Rust 寫的 jless 這個工具,官網有個動圖可以參考:

這樣方便不少,就不需要自己在對半天...

另外也剛好拿來練手,把 Rust 寫的套件包成 Ubuntu PPA:「PPA for jless」。

主要是 cargo vendor 這個指令可以把相依套件都抓下來放到 vendor/ 下面,然後設定 .cargo/config.toml 後就可以在本地端處理了,這對於 build farm 限制 internet 連線的情況會好用很多...

Ondřej Surý 的 PPA 將會繼續支援 PHP 5.6 與 PHP 7.0 的安全性更新

Twitter 上看到 Ondřej Surý 因為得到協助 (包括 Microsoft),所以會繼續支援 PHP 5.6 與 PHP 7.0 的 PPA 更新:

在「PHP 5.6 and PHP 7.0 will stay (for now)」裡面有提到這是 best effort,沒有保證會維持多久:

Please note that this is based on best effort and without any warranty.

對於還在這兩個版本掙扎的人再多了一些時間...

用 Stubby 在 Ubuntu 上跑 DNS over TLS

透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試,大約是從 10ms 變成 40ms),但可以讓 ISP 看不到你查詢什麼,對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS),但一直沒看到,結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。

Stubby 在 Ubuntu 18.04 上可以直接裝,但在 Ubuntu 16.04 上需要透過 PPA 裝,我是透過「DNS Utils : James Newell」這個安裝的,裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

就可以走 port 853 的 DNS over TLS 了,而 Stubby 預設會聽 127.0.0.1::1 的 port 53,所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。

目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate),Stubby 看起來只能用 tls_pubkey_pinset 鎖住,但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate),之後看看有沒有可以吃 Root CA 架構的認證再來調整...

nginx 推出了 1.14.0 的 PPA

nginxPPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。

這個版本使用了 OpenSSL 1.1.0,對 cipher 這塊最大的差異主要是包括了 CHACHA20AESCCM 演算法。後者的 CCM 指的是 CCM mode,這是當時 OCB mode 因為專利問題而發展出來的演算法,就目前的效能測試沒有 GCM 好,而且普及率也沒有 GCM 高,放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選):

The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.

真正的重點在於 CHACHA20 的引入,讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。

不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明),目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息,但暫時還不會有效果...

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydratedPPA (在「PPA for dehydrated : Gea-Suan Lin」這邊),後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」),為了避免名稱相同但是內容物差很多,我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正,這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1),這點需要注意一下:

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated,也許會照著現在 APT 內的架構來做...

Let's Encrypt 的 Wildcard Certificate 開放使用!

Twitter 上看到這則 tweet,Let's Encrypt 正式開放 Wildcard Certificate 了:

參考「ACME v2 and Wildcard Certificate Support is Live」這邊的說明,裡面有提到 Wildcard Certificate 需要有 ACMEv2 的 client:

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv2. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

翻了一下「ACME Client Implementations」,我常用的 dehydrated 也支援 ACMEv2 了,而且剛好前幾天我更新了 PPA (參考「PPA for dehydrated : Gea-Suan Lin」),把最新版 (0.5.0 後的 6e802dd) 包進去了,等下來測試看看要怎麼玩 XDDD

然後我之後打算把 letsencrypt.tw 的資料改丟到我的 Wiki 上,這樣改起來比較簡單...

dehydrated 0.4.0 的新要求

dehydrated 出 0.4.0 了,剛剛把 PPA for dehydrated 更新了,已經安裝過的使用者可以直接升級使用。

這次主要的改變在於建立帳號時必須先同意 Let's Encrypt 的使用條款:

dehydrated now asks you to read and accept the CAs terms of service before creating an account

這邊可以用 dehydrated --register --accept-terms 表示同意並且建立帳號。

nginx 1.10.2

之前在「谈谈 Nginx 的 HTTP/2 POST Bug」這邊提到了 nginx 的一個 bug:「當 HTTP/2 的第一個 request 是 POST 時連線會失敗」的問題,這個問題在 mainline 版本的 1.11.0 解決了,但 stable 版一直沒有出新版 back-porting 回來。

而剛剛看到 1.10.2 將 http2_body_preread_size 從 mainline 版本弄回來解決了:「[nginx-announce] nginx-1.10.2」。

*) Change: HTTP/2 clients can now start sending request body
   immediately; the "http2_body_preread_size" directive controls size of
   the buffer used before nginx will start reading client request body.

然後剛剛發現 Ondřej Surý 老大分別弄出了 nginx (stable 版本) 與 nginx-mainline (mainline 版本) 的 PPA,所以也可以考慮可以直接換到 mainline 上?這樣也是個方法...