這讓我有點擔心：我正在使用阿菲克監視 CentOS 6 伺服器上檔案和目錄的變更。我想檢測二進位檔案的更改、走私到伺服器上的 PHP 腳本、更改的設定檔等。通常它只包含日誌檔案和我更新網頁程式碼或安裝新軟體後的更改。今天我似乎中了大獎，但我不確定。
我收到一封電子郵件，其中數百個文件的 MD5 校驗和已更改，但時間戳或大小未更改。這包括像/bin/gawk這樣的可執行文件，也包括像/lib/libasound.so.2.0.0.這一切都發生在 1 月 1 日 4:00 至 1 月 2 日 4:00 之間（afick 運行時間為 4:00）。
作為測試，我從備份中恢復了 /bin/gawk 並運行了手動 md5 校驗和；確實該文件已更改。但這兩個二進位檔案之間的差異有些不確定：
--- old.gawk.hex 2017-01-02 15:56:06.000000000 +0100
+++ new.gawk.hex 2017-01-02 15:56:14.000000000 +0100
@@ -881,12 +881,12 @@
00003700 a6 03 00 00 00 00 00 00 d1 04 00 00 12 00 0d 00 |................|
00003710 f0 6d 42 00 00 00 00 00 2a 10 00 00 00 00 00 00 |.mB.....*.......|
00003720 01 00 00 00 b0 6b 5a 56 65 fd 1b 6d 00 00 00 00 |.....kZVe..m....|
-00003730 00 00 00 00 44 00 00 00 b0 6b 5a 56 b2 04 c4 e2 |....D....kZV....|
+00003730 00 00 00 00 44 00 00 00 56 e5 5d 58 82 a0 c7 cf |....D...V.]X....|
00003740 00 00 00 00 00 00 00 00 62 00 00 00 b0 6b 5a 56 |........b....kZV|
00003750 58 97 65 11 00 00 00 00 00 00 00 00 97 10 00 00 |X.e.............|
00003760 b0 6b 5a 56 30 fb 60 86 00 00 00 00 00 00 00 00 |.kZV0.`.........|
00003770 b0 2f 40 83 34 00 00 00 01 00 00 00 00 00 00 00 |./@.4...........|
-00003780 e0 08 65 00 00 00 00 00 e0 1f c8 83 34 00 00 00 |..e.........4...|
+00003780 e0 08 65 00 00 00 00 00 e0 1f 88 0a 35 00 00 00 |..e.........5...|
00003790 01 00 00 00 00 00 00 00 08 09 65 00 00 00 00 00 |..........e.....|
000037a0 50 2d 15 83 34 00 00 00 01 00 00 00 00 00 00 00 |P-..4...........|
000037b0 d0 ff ff ff ff ff ff ff 58 2d 15 83 34 00 00 00 |........X-..4...|
@@ -19806,13 +19806,13 @@
*
000501e0 28 00 65 00 00 00 00 00 1e 59 40 00 00 00 00 00 |(.e......Y@.....|
000501f0 00 00 00 00 00 00 00 00 00 b1 e8 82 34 00 00 00 |............4...|
-00050200 10 cd ec 82 34 00 00 00 50 32 a2 83 34 00 00 00 |....4...P2..4...|
-00050210 80 79 e6 82 34 00 00 00 e0 2f a2 83 34 00 00 00 |.y..4..../..4...|
+00050200 10 cd ec 82 34 00 00 00 50 32 62 0a 35 00 00 00 |....4...P2b.5...|
+00050210 80 79 e6 82 34 00 00 00 e0 2f 62 0a 35 00 00 00 |.y..4..../b.5...|
00050220 20 87 e7 82 34 00 00 00 20 bc e8 82 34 00 00 00 | ...4... ...4...|
00050230 20 9f e7 82 34 00 00 00 b0 05 e8 82 34 00 00 00 | ...4.......4...|
00050240 d0 af e9 82 34 00 00 00 20 5e ed 82 34 00 00 00 |....4... ^..4...|
00050250 40 7e ee 82 34 00 00 00 40 71 ec 82 34 00 00 00 |@[email protected]...|
-00050260 10 9d e9 82 34 00 00 00 30 6f a1 83 34 00 00 00 |....4...0o..4...|
+00050260 10 9d e9 82 34 00 00 00 30 6f 61 0a 35 00 00 00 |....4...0oa.5...|
00050270 f0 d7 ec 82 34 00 00 00 60 19 e3 82 34 00 00 00 |....4...`...4...|
00050280 e0 b1 e9 82 34 00 00 00 10 85 ee 82 34 00 00 00 |....4.......4...|
00050290 30 84 ec 82 34 00 00 00 40 20 e6 82 34 00 00 00 |0...4...@ ..4...|
(etc)
當然，我的第一個想法是駭客攻擊，但看到差異讓我感到好奇。真正的代碼似乎沒有改變；我不是 ELF 二進位檔案的專家，但我認為這些只是共享庫的重定位偏移表。
那你認為到底發生了什麼事？除了駭客攻擊之外，我能想到的唯一其他可能性是「安全」措施，其中共享庫偏移量是隨機的，並且連結到的二進位檔案也必須更新。但為什麼現在呢？我最後一次安裝某些軟體是在 12 月 23 日，期間沒有任何奇怪的情況。唯一可能相關的 cronjob 是 /etc/cron.daily/prelink，但如果是這樣，為什麼現在呢？
答案1
您所描述的二進制校驗和的差異可能是由於預連結造成的。基於 RHEL 的 Linux 發行版（例如 CentOS 和 Fedora）預設啟用預連結。這是 2009 年的情況LWN.net文章解釋了 prelink 背後的概念：
Linux 程式通常由引用多個共用程式庫的二進位執行檔組成。這些庫一次載入到記憶體中並由多個可執行檔共用。為了實現這一點，動態連結器（即 ld.so）需要更改記憶體中的二進位文件，以便庫物件的任何位址都指向記憶體中的正確位置。對於具有許多共享庫的應用程式（例如 GUI 程式），該過程可能需要一些時間。
預連結背後的想法相當簡單：透過提前執行並儲存結果來減少動態連結器執行這些位址重定位所需的時間。預先連結程式以與 ld.so 大致相同的方式處理 ELF 二進位檔案和共用程式庫，然後將特殊的 ELF 部分新增至描述重定位的檔案。當 ld.so 載入預先連結的二進位檔案或函式庫時，它會檢查這些部分，如果函式庫載入到預期位置並且函式庫沒有更改，它可以更快地完成其工作。
但是，如果程式庫始終載入在相同記憶體位置，攻擊者可以嘗試使用惡意程式碼瞄準這些位置，這就是 Redhat 發行版prelink定期使用該-R選項運行的原因（以實現位址空間佈局隨機化）。更改記憶體位置的後果之一是二進位可執行檔的校驗和將會發生變化。因此，如果您使用 AIDE 等檔案完整性檢查器，您將收到有關「已更改」二進位檔案的警報，而實際上發生的唯一變更是透過prelink -R.