Это меня немного беспокоит: я используючертдля мониторинга сервера CentOS 6 на предмет изменений в файлах и каталогах. Я хочу обнаружить изменения в двоичных файлах, PHP-скриптах, которые тайно проносятся на сервер, файлах конфигурации, которые изменяются и т. д. Это выполняется ежедневно, и я получаю электронное письмо с обнаруженными изменениями. Обычно оно содержит только файлы журналов и изменения после того, как я обновил свой веб-код или установил новое программное обеспечение. Сегодня я, кажется, сорвал джекпот, но я не уверен.
Я получил письмо, в котором контрольная сумма MD5 сотен файлов изменилась, но не их временная метка или размер. Это касается исполняемых файлов, таких как , /bin/gawkно также и библиотек, таких как /lib/libasound.so.2.0.0. Все это произошло между 4:00 1 января и 4:00 2 января (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)
Конечно, моей первой мыслью было хакерство, но вид diff заставляет меня задуматься. Похоже, что реальный код не изменился; я не эксперт по двоичным файлам ELF, но я думаю, что это всего лишь таблицы смещения перемещения для общих библиотек.
Так что, по-вашему, произошло на самом деле? Помимо взлома, единственная другая возможность, которая приходит мне в голову, это мера «безопасности», при которой смещения общих библиотек рандомизированы, а связанные с ними двоичные файлы также должны быть обновлены. Но почему сейчас? В последний раз я устанавливал какое-то программное обеспечение 23 декабря, и ничего странного не появлялось между этими событиями. Единственное задание cron, которое может быть связано, это /etc/cron.daily/prelink, но если так, то почему сейчас?
решение1
Разница в бинарных контрольных суммах, которую вы описали, вероятно, вызвана предварительной компоновкой. В дистрибутивах Linux на основе RHEL, таких как CentOS и Fedora, предварительная компоновка включена по умолчанию. Вот как 2009Статья LWN.netобъясняет концепцию предварительной ссылки:
Программы Linux обычно состоят из двоичного исполняемого файла, который ссылается на несколько общих библиотек. Эти библиотеки загружаются в память один раз и используются несколькими исполняемыми файлами. Чтобы это произошло, динамическому компоновщику (то есть ld.so) необходимо изменить двоичный файл в памяти таким образом, чтобы все адреса объектов библиотеки указывали на правильное место в памяти. Для приложений со многими общими библиотеками — например, программ с графическим интерфейсом — этот процесс может занять некоторое время.
Идея предварительной компоновки довольно проста: сократить время, которое динамический компоновщик должен потратить на выполнение этих перемещений адресов, сделав это заранее и сохранив результаты. Программа предварительной компоновки обрабатывает двоичные файлы ELF и общие библиотеки примерно так же, как это делает ld.so, а затем добавляет специальные разделы ELF в файлы, описывающие перемещения. Когда ld.so загружает предварительно связанный двоичный файл или библиотеку, он проверяет эти разделы и, если библиотеки загружены в ожидаемом месте и библиотека не изменилась, он может выполнить свою работу гораздо быстрее.
Однако если библиотеки всегда загружаются в одно и то же место памяти, злоумышленники могут попытаться нацелить эти места с помощью вредоносного кода, поэтому дистрибутивы Redhat prelinkрегулярно запускаются с -Rопцией (для достижения рандомизации адресного пространства). Одним из последствий изменения мест памяти является изменение контрольной суммы исполняемых двоичных файлов. Поэтому, если вы используете средство проверки целостности файлов, такое как AIDE, вы получите уведомление об «измененном» двоичном файле, когда на самом деле единственным изменением, которое произошло, является ASLR через prelink -R.
Использованная литература: https://en.wikipedia.org/wiki/Prelink#Linux