от Lucifer

Малко по занемарих тази поредица. Обещавам да се реванширам, нищо че знам колко малко хора я следват. За днес съм ви приготвил нещо, което надали ще помогне на някого, а хората на които ще помогнем, най-вероятно вече знаят за него и ще ми се изсмеят, че откривам топлата вода, но все пак …

Преди няколко дни, покрай един случай имах нужда от внимателно наблюдение на един от сървърите. И тъй като много мразя да вися по конзоли и да дебна логове, се замислих дали няма някакъв автоматизиран метод да се направи … и се оказа, че не е нужно да откривам топлата вода. Вече има такова нещо и то си е напълно работещо и то се нарича OSSEC. Можете да го намерите тук (макар, че ви препоръчвам да се разтърсите и да си намерите gihub-а и последната master версия).

OSSEC е Open Source Host-based Intrusion Detection System. Какво ще рече това?

OSSEC наблюдава системата и следи за всякакви опити за не оторизиран достъп (най-общо казано), като покрай това следи цялостното състояние на сървъра на който е инсталиран и съобщава за всякакви системни грешки или проблеми.

Какво всъщност може да прави тази програмка и защо съм толкова впечатлен?

Освен анализа на системните логове в реално време, следенето за промяна в системната среда и опита за засичане root kits, OSSEC има така наречения Active response – следвайки поредица от дефиниции, програмата автоматично може да вземе нужните мерки за да защити системата от атака… което в моя случай беше нож с две остриета. Опитвайки се да подкарам някакъв скрипт, успях без да искам да се банна от собствения си сървър за 10 минути. Неприятно, но ефективно. Програмката също така може да ви нотифицира (с email) за всички event-и, които активират някой triger.

OSSEC идва настроена по подразбиране с голямо количество правила и анализиращи модули, но ако няма нещо, което ви трябва – позволява добавяне на собствени аналитични модули и промяна на начина по който се реагира на някои неща. Пример за това е E_ALL нотификацията на PHP 5.4.x – E_ALL флага, кара всички грешки, нотификации и „оплаквания“ за Strict-ни PHP дефиниции да бъдат изплюти в http error log-а. Това е много хубаво за девелопъра в мен, който иска да вижда всички strict забележки, но не желая да получавам 150 mail-а на час, защото да кажем phpBB3 не са си дефинирали стриктно класовете и функциите. Тук с пълна сила идва персонализирането на правилата и за да видите колко е лесно, ще поместя собствените си промени и ще ги обясня:

<group name=“local,syslog,errors“>
<rule id=“100001″ level=“1″>
<if_sid>1002</if_sid>
<match>PHP Strict Standards:</match>
<description>PHP 5.4.3 PHP Strict Standards reporting!</description>
<description> No need to mail</description>
</rule>
<rule id=“100002″ level=“1″>
<if_sid>1002</if_sid>
<match>PHP Warning:</match>
<description>PHP 5.4.3 PHP Wornings reporting!</description>
<description> No need to mail</description>
</rule>
<rule id=“100003″ level=“1″>
<if_sid>1002</if_sid>
<match>PHP Notice:</match>
<description>PHP 5.4.3 PHP Notice reporting!</description>
<description> No need to mail</description>
</rule>
<rule id=“100004″ level=“1″>
<if_sid>31106</if_sid>
<url>/tmp/phpMyAdmin/</url>
<description>phpMyAdmin override!</description>
<description> No need to mail!</description>
</rule>
</group> <!– SYSLOG,LOCAL –>

 

Правилата имат уникални номера, за да не се бъркат. Всички потребителски дефинирани започват от 100001. 100001, 100002, 100003 отговарят за различните PHP нотификации, които всъщност не са грешки, въпреки че в http error log-а присъстват като [:error]. Аз лично не желая да получавам тонове съобщения в пощата си, за strict, notice и warning, за това съм ги предефинирал да ги логва, но да не ги съобщава.

100004 е малко по-интересна предефиниция. Правилото, което предефинира е 31106, което отговаря за разчитането на SQL Injections в GET заявките на адреса. Проблема с това, е че phpMyAdmin използва GET заявки за да комуникира със скриптовете си… което води до десет минутен бан в IPTABLES и /etc/hosts.deny … неприятно, но ефективно както казах.

OSSEC идва за много и различни платформи. Linux, MacOS, Solaris, HP-UX, AIX и дори Windows. Интегрира се без проблем към съществуващата инфраструткура и макар, че е малко труден за точно конфигуриране, всъщност е един много сериозен инструмент. Може да бъде инсталиран на единичен сървър и да наблюдава много OSSEC агенти, превръщайки машината в своеобразен focal point за анализ на грешки и проблеми. За сега съм го инсталирал само на сървъра в София, но тези дни, след подходящ update на операционната система и рекомпилиране на всички други неща смятам да сложа и един клиент във Варна.

Хубавото е че клиентите имат нужда от малко настройка, а всички правила и повечето от опциите се настройват от сървъра. Това ви позволява да разпънете голям брой клиенти и да мониторирате голям брой машини.

Минус, който има, поне според мен, е липсата на свестен dashboard, но тъй като аз съм упорито говедо, смятам да седна да напиша нещо свястно.

Друг съществен пропуск смятам, че е липсата на hardware watchdog, както например SNMP, но предполагам, че двете могат да се обединят.

Лично за мен, само за няколко дни OSSEC се превърна в незаменим помощник. Малко са хората, които успяват да наблюдават множество машини едновременно … аз не съм от тях.

Ваш,

Lucifer

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *

 

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните ви за коментари.

WordPress Appliance - Powered by TurnKey Linux