FreeBSD 5.X、6.X 常見問答集
Prev |  | Next

# Chapter 13 系統安全篇

Biing Jong Lin

13.1. 什麼是 sandbox？
13.2. 什麼是 securelevel?
13.3. BIND (`named`) 除了在通訊埠 53 以外也在 其他高編號通訊埠 (high-numbered port) 聆聽 (Listen)。 這是怎麼回事？
13.4. Sendmail 除了在標準的通訊埠 25 外也在通訊埠 587 聆聽！這是怎 麼回事？
13.5. 我發現了這個 UID 0 `toor` 帳號，這是什麼 碗糕？我被黑掉了嗎？
13.6. 為什麼 `suidperl` 無法正常運作？

13.1. 什麼是 sandbox？

“Sandbox” 是系統安全用的術語，有兩個意義：

- 放在某些虛擬防護牆裡的執行程序，這些防護牆是用來阻止 某些人侵入這道程序，進而出入於更大的系統中。

  這道程序可以完全在防護牆裡 “動作”。也就 是說，它所執行的任何程式不可能會滲透到牆的外面。所以如果 您對它有安全上的顧慮，並不需要特別去監聽它的一舉一動，反 正它只能在牆內活動。

  舉例來說，可以用 userid 來做這道防護牆，這正是 security 和 named 說明文件中的定義。

  現在就用 `ntalk` 這個服務作說明（見 /etc/inetd.conf）。這個服務以前的 userid 是 `root`，現在執行時則是用 `tty`。`tty` 這個使用者就是一個 sandbox，如果有人能夠順利用 ntalk 侵入系統，現在他就算進得來也只能用這個 userid。

- 放在某個模擬機器裡的程式，這比上述來得更嚴密。基本上 這表示能侵入該程式的人相信他能再進入所屬的機器，但事實上 只會進入模擬出來的機器，無法進一步修改任何真實的資料。

  達到這個目的最常用的方法，就是在某個子目錄下做出模擬的 環境，然後用 chroot 執行該程式，這樣該程式的根目錄便是這個 子目錄，而非系統真正的根目錄。

  另一個常見作法是將某個檔案系統 mount 成唯讀，但在它 上面另外製造出程式以為可以寫入的檔案系統。這個程式會相信 它可以對其他檔案讀寫，但只有它看不到這個唯讀效應 - 系統 執行的一般程式都看得到。

  我們試圖將這類 sandbox 盡量透明化，讓使用者或侵入者 無法看到他是否在某個 sandbox 裡面。

UNIX 實作兩種 sandbox，一個在程式層面，另一個則是由 userid 來達成。

每個 UNIX 執行程序會用防火牆將它和所有其他程序隔開，某個程序 不可以隨意修改其他程序位址的資料。這和 Windows 中，程式可以輕易 修改其他位址資料，結果導致當機的情形大不相同。

每個 UNIX 程序都屬於某個特定的 userid。如果該 userid 不是 `root`，就會將它和其他使用者的程序隔開。 Userid 同時也用於硬碟資料的存取權上。

13.2. 什麼是 securelevel?

securelevel 是核心中所實作的一個安全機制。基本上當 securelevel 是正值時，核心會限制某些工作；即使是 superuser (也就是 `root`) 也無法完成那些工作。在撰寫 本文時，securelevel 機制在一般的限制外，還能夠限制以下的功能：

- 清除某些特定的檔案旗標，例如 `schg` (系統唯讀標旗, the system immutable flag)

- 經由 `/dev/mem` 與 `/dev/kmem`， 將資料寫入至核心記憶體中

- 載入核心模組

- 更動 ipfirewall(4) 規則。

想要檢查在某個運作中的系統的 securelevel 狀態，只要執行以下 命令即可：

    # sysctl kern.securelevel

輸出的結果會包含一個 sysctl(8) 變數名稱 (在這個例子中， 它是 `kern.securelevel`) 以及一個數字。後者即是 目前的 securelevel 值。如果它是一個正值 (也就是大於 0)，表示至少 有一些 securelevel 的保護機制已經開啟了。

你沒有辦法降低一個運作中的系統的 securelevel；如果可以的話， 就失去了這個機制的意義了。如果你要作一些需要 securelevel 為 非正值才可以的動作的話 (例如 `installworld` 或更動日期)，你需要修改 `/etc/rc.conf` 內的 securelevel 設定 (找找 `kern_securelevel` 和 `kern_securelevel_enable` 變數)，然後重新開機。

想要知道更多有關於 securelevel 與各個不同等級影響的細節， 請參考 init(8) 說明文件。

> Warning: securelevel 可不是萬靈丹；它有許多已知的缺陷，往往造成 一種安全的假象。

> 它一個最大的問題，就是要讓這個功能完全有效的話，在 securelevel 發揮作用前的啟動過程中，所有使用到的檔案都 必須被保護起來。如果一個攻擊者在 securelevel 有效前 (由於 有些系統在啟動中所作的事情，無法在較高的 securelevel 中 正常運作，所以這會在啟動過程中後期才會運作)，能讓他們的程式 被執行的話，securelevel 的保護就完全無效了。保護啟動程序 中所有的檔案在技術上是可行的，但是如果真的這樣作的話，系統 維護將會變成一場夢魘。即使只是修改一個設定檔，也必須將整個 系統關閉，至少也得到單人模式。

> 除了這點，還有許多其它的東西都在通信論壇上討論，尤其是 freebsd-security。請到 這裡 搜尋以前的 討論。有些人希望 securelevel 能夠儘快消失，由另一個更優秀的 機制取代，不過機會有點渺茫。

> 風險自行承擔。

13.3. BIND (`named`) 除了在通訊埠 53 以外也在 其他高編號通訊埠 (high-numbered port) 聆聽 (Listen)。 這是怎麼回事？

FreeBSD 3.0 後的版本使用一個特殊的 BIND 版本，這個版本會使 用隨機的高編號通訊埠來回應外部的查詢。如果你因為要適合防火牆的 設定或是單純的想讓自己看來舒服一點而想用 53 通訊埠回應外部查詢， 那麼你可以嘗試更改以下檔案相關內容 `/etc/namedb/named.conf`：

    options {
            query-source address * port 53;
    };

你也可以將 `*` 更改為特定 IP address， 藉以加強控制條件。

順便恭喜你。能夠讀取你系統上的 sockstat(1) 報告並且注意 不正常狀況是一件好事！

13.4. Sendmail 除了在標準的通訊埠 25 外也在通訊埠 587 聆聽！這是怎 麼回事？

較新版本的 Sendmail 支援 mail submission 這項功能，並且使 用通訊埠 587。這項功能還沒有被廣泛支援但是支援的數目正在增長 中。

13.5. 我發現了這個 UID 0 `toor` 帳號，這是什麼 碗糕？我被黑掉了嗎？

放心。`toor` 是一個 “alternative” 管理者帳號 (toor 是 root 的轉向拼法)。 以往是跟隨 bash(1) 安裝而建制的，後來則成為系統內定建制的一 個帳號。這個帳號將伴隨一個非標準的 shell 測試使用， 讓你不需要去 更改到 `root` 的內建 shell。因為這些其他的 shell 並沒有跟隨系統預設值安裝 (舉例來說，某些由 ports 安裝的 shell package)，而被內定安裝在 `/usr/local/bin` 目錄下，有可能存在不同的檔案系統中。 倘若 `root` 的 shell 被放在 `/usr/local/bin`，且 `/usr` (或是其他包含著 `/usr/local/bin` 這個子目錄的檔案系統) 因為某些原因並沒有被正常的 mount 起來的話，`root` 將無法正常的登入系統進行維修 (雖然說你重開機成單人模式就會問你要 載入哪個 shell)。

有些人使用 `toor` 帳號進行每日的 `root` 維護工作，如此可以使用非標準的 shell，而 `root` 可以保留標準 shell， 以因應單一使用者模式 (single user mode) 或緊急狀況處理。 依照系統內定值，你將無法使用 `toor` 登入， 因為這個帳號尚未更改密碼設定。因此你如果你想啟動這個帳號，你需要 使用 `root` 登入系統並且修改 `toor` 的密碼。

13.6. 為什麼 `suidperl` 無法正常運作？

因為某些安全的考，`suidperl` 內定的安裝 並沒有設定 suid bit。系統管理者可以依照以下命令啟動 suid 設定。

    # chmod u+s /usr/bin/suidperl

如果你想要在由 source 升級時 `suidperl` 內定 啟動 suid 功能的話，編輯 `/etc/make.conf` 加入 `ENABLE_SUIDPERL=true` 然後執行 `make buildworld`。

Prev | Home | Next
Networking |  | PPP

本文及其他文件，可由此下載：ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/。

若有 FreeBSD 方面疑問，請先閱讀 FreeBSD 相關文件，如不能解決的話，再洽詢 <questions@FreeBSD.org>。
關於本文件的問題，請洽詢 <doc@FreeBSD.org>。