Tag: apt

在 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-Priority 是 1001，而其他的都掛到 -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 升級上去了。

用 reprepro 建立 APT repository

在「用 fpm 這個工具包 .deb 安裝」這篇題到了 fpm，另外在同一篇文章裡面 (「Using Cloudflare R2 as an apt/yum repository」這篇) 也有提到要怎麼生出一個有簽名過的 APT repository，裡面就提到了 reprepro 這個工具。

在 Debian Wiki 上面的「SetupWithReprepro」就有一步一步告訴你設定的方式，另外 Wikimedia 的技術 wiki 上也有提到常用的操作：「Reprepro」。

然後可以丟到很多不同的地方，最常見的 apache 或是 nginx 外，S3 或是其他可以吐 HTTP/HTTPS 的 object storage 服務都可以。

也是先記錄起來，等要用的時候可以回來 blog 上翻到...

用 fpm 這個工具包 .deb 安裝

先前在「Using Cloudflare R2 as an apt/yum repository」這邊看到的工具，其中一個是 fpm，可以快速包裝成各種套件格式 (符不符合 community standard 就是另外一回事晴了)。

在「deb - Debian package format」這邊就有提到像是之前 HashiCorp 都只有丟 binary 出來時，要怎麼打包。

先抓 binary zip 檔下來，然後直接用 fpm 指定版號與要丟的 prefix，他就幫你包起來：

$ wget https://releases.hashicorp.com/terraform/1.0.10/terraform_1.0.10_linux_amd64.zip
$ fpm -s zip -t deb --prefix /usr/bin -n terraform -v 1.0.10 terraform_1.0.10_linux_amd64.zip

生出來的 terraform_1.0.10_amd64.deb 就可以直接 apt install 或是 dpkg -i 裝進去。

看起來可以是個快速先解決問題的工具，之後遇到沒有提供 apt repository 的套件可以用這個方式先打包起來裝，後續移除也比較簡單，不用靠文件來記錄一堆細節...

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出 Lockdown Mode

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出了 Lockdown Mode：「Apple expands industry-leading commitment to protect users from highly targeted mercenary spyware」。

Lockdown Mode 主要是透過降低被攻擊的面積以提昇安全性，依照 Apple 的預想，主要是針對被政府單位盯上的族群：

Apple is previewing a groundbreaking security capability that offers specialized additional protection to users who may be at risk of highly targeted cyberattacks from private companies developing state-sponsored mercenary spyware.

在 Lockdown Mode 下目前列出來的限制：

  • Messages: Most message attachment types other than images are blocked. Some features, like link previews, are disabled.
  • Web browsing: Certain complex web technologies, like just-in-time (JIT) JavaScript compilation, are disabled unless the user excludes a trusted site from Lockdown Mode.
  • Apple services: Incoming invitations and service requests, including FaceTime calls, are blocked if the user has not previously sent the initiator a call or request.
  • Wired connections with a computer or accessory are blocked when iPhone is locked.
  • Configuration profiles cannot be installed, and the device cannot enroll into mobile device management (MDM), while Lockdown Mode is turned on.

列出來的這些的確都是之前 0-day 常被拿來打的東西，把攻擊面積縮小的確會有不少幫助。

這應該是業界第一個大咖跳進來做這個 (也就兩個大咖？)，第一次搞未必會完美，但算是個開始，後面應該會有更多的面積被考慮進去...

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構，從錯誤訊息觀察，看起來後面是 Amazon S3，前面是 Fastly 的 CDN。

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量)，就把 blog 搬到 AWS 的 t4g.small (ARM) 上，理論上頁面的速度應該會快不少，過幾天等穩定性沒問題後就來買 RI...

從 x86-64 轉到 ARM 上面，主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository，所以就改用 MariaDB 了。

其他的倒是都差不多，目前的 Ubuntu + nginx + PHP 沒什麼問題，跑一陣子看看...

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞，但沒讀完就一直放著沒寫：「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題，對於 HTTP 重導的程式碼沒有處理好外部字串，在還沒修正的機器上用這個指令關閉 redirect，避免在修正的過程反而被 RCE 打進去：

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題，因為 HTTPS 連線用的程式碼又是另外一份，裡面不知道有沒有問題 (像是之前經典的 Heartbleed)，所以應該還是會繼續爭吵吧...

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明：「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護，但會使得維護的複雜度變高很多。

首先是被竄改的問題，APT 本身就有簽名機制 (參考「SecureApt」)，即使 mirror site 被打下來也無法成功竄改內容，反而比起單純的 HTTPS 保護還好。

而對於隱私問題，由於內容是可以公開取得的，這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法)，加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高)，所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack)，APT 降低風險的解法是把時間簽進去，當用戶端發現太久沒更新時，就當作過期失效而提出警告。

就以上來看，把所有的 APT 伺服器都加上 HTTPS 的工程太浩大，而得到的效益太小。所以願意提供 HTTPS 的站台就提供，但主要的保護還是從本來的 SecureApt 機制上提供。

在飯店裡攻擊企業的高階主管

算是為什麼企業要提供 Full Routing VPN 的一個攻擊管道的說明...

這篇介紹了在飯店裡透過 WiFi 攻擊企業的高階主管，想辦法塞木馬取得資訊，或是滲透進企業內部的網路：「Hackers are using hotel Wi-Fi to spy on guests, steal data」。

Those behind the campaign have continually evolved their tactics and malware payloads, blending phishing and social engineering with a complex Trojan, in order to conduct espionage on corporate research and development personnel, CEOs, and other high-ranking corporate officials.

有點介於 APT 與一般性的攻擊中間...

保護 macOS 的方法

在「drduh/macOS-Security-and-Privacy-Guide」這邊列出了許多保護方式，如果考慮到 APT 的話應該是個不錯的指南...

不過考慮到相當硬，服用前請小心，有些步驟甚至需要拆機：

雖然整篇文章還頗硬的，但裡面講軟體的部份還是很不錯的指南，可以保護自己...