Проблема детектирования вторжения и/или атаки рано или поздно встает перед любым админом.
Существует много разных IDS, базирующихся на разных принципах. От простых анализаторов логов до сложных аппаратно-программных комплексов.
Передо мной, собственно, поставили достаточно четкую задачу. Нужно пройти PCI DSS, в частности, решить проблему с широко известными в узких кругах пп.10.5 и 11.5 :)
Серверов много. Поэтому очень желательно решение с централизованным управлением и отчетами. Есть, конечно, коммерческие решения. Но они весьма и весьма недешевы. С другой стороны, меня заверили, что было немало прецедентов прохождения PCI с использованием OSSEC - Open Source Host-based Intrusion Detection System. Поэтому, закатав рукава, беремся за работу.
За основу была взята версия 2.7-beta. Выбор, может конечно, показаться несколько странным, но версия 2.6 имела ряд недостатков конкретно для существующего окружения и показала себя местами весьма нестабильной.
Собрал rpm, установил на тестовый сервер и тестовый клиент. И сразу грабли. При попытке мониторинга audit.log компонента-сборщик логов ossec-logcollector начала падать в segfault. С выдачей в лог незадолго до смерти сообщения о недоступности audit.log.
Поиски информации по инету ничего внятного не дали, в новой версии добавлен специальный обработчик именно логов auditd (logformat linux-auditd). Хотя оно падало и в классической схеме. Дальнейшие исследования показали, что логколлектор падает всегда, если лог становится недоступен (например, залочен программой в момент обращения)
Делать нечего, пришлось взять дебагер и вспомнить молодость :)
В общем, оказалось, что имеем серьезный баг. При недоступности лога к нему идет несколько попыток обращения (количество определяется переменной в конфигурации), после чего значение logff[ i ].fp (если я правильно понял, это дескриптор файла, но могу и ошибаться) устанавливается в NULL.
А на следующем цикле идет проверка. И, оказывается, по этой переменной. И, какое совпадение, именно такое значение имеет logformat command ! Т.е. на следующем цикле объект, описывающий файл, пытается интерпретироваться, как описывающий команду!
Но и это еще не все. Ссылку на функцию чтения (в переменной read) никто, понятно, не чистит. Ну и вполне логично, что, когда вызывается read, пытаемся читать файл по позиции "текущее время в секундах" (это устанавливается обработчиком формата command), и fgetpos радостно падает в segfault.
Собственно, подробности админам на самом деле не нужны. А нужен им ПАТЧ, который решит проблему! :)
Вот это счастье: logcollector.sl.patch
После его применения у меня стабильно заработал logcollector.
Разработчикам о проблеме, разумеется, сообщил.
Немає коментарів:
Дописати коментар