Повышаем безопасность FreeBSD с помощью PortSentry

Хакер потерял доступ

Я искал демон, который способен жестко пресекать все попытки сканирования портов и заносить источники угроз в черный список. Особенно, если учитывать тот факт, что стандартные порты демонов (например SSH) я не использую, повесив служебные сервисы на другие порты.

Такая утилита была найдена, ей оказалась PortSentry.

Вообще, защищать системы нужно обязательно, особенно если это продакшн сервер или какая-нибудь система хранения данных вроде HP EVA P6500. Пресекать злоумышленников нужно на корню, сразу. Если это в инете – банить по IP, если это в корп.сети – с бумагой начальнику, мол “нарушитель”. Ну да ладно.

Итак, инсталлировать будем на нашу любимую FreeBSD 8.2 из портов:

# cd /usr/ports/security/portsentry
# make install clean

Установка portsentry
Установка portsentry

Исполняемый файл лежит в /usr/local/bin, а конфиг залез в /usr/local/etc/portsentry.conf (есть конфиг .default)

Увидим там подобные строки:

Список защищаемых портов
Список защищаемых портов

По умолчанию раскомментирована вторая группа. Мы можем сформировать свой список защищаемых портов, либо воспользоваться готовым.

Так же внизу будут варианты действий с нарушителем (который фигурирует как $TARGET$, в роли чего выступает IP адрес.

Используем ipfw правило
Используем ipfw правило

Можно разделываться с нарушителем по-разному. Добавить маршрут в черную дыру. Создать запрет в файрволле. Вывести предупреждение. Вообще ничего не делать. Поскольку у меня ipfw, я раскомментирую соответствующую строчку (и немного её подправлю).

add 1 deny all from $TARGET$/32 to any – добавляет запрещающее правило для всех протоколов с этого IP адреса.

Запускаем нашего сторожа:

# /usr/local/etc/rc.d/portsentry.sh start

и смотрим, слушает ли он порты:

Слушает порты
Слушает порты

С проверкой нужно быть осторожным. Поскольку даже простая попытка telnet на 1-ый порт вызвала добавление запрещающего правила:

Хакер потерял доступ
Хакер потерял доступ

Помимо этого создаются записи в файле /var/log/messages, который вообще стоит анализировать регулярно. Возможно есть смысл добавить очистку запрещающих правил в cron с интервалом в 10 минут, дабы случайно не остаться без удаленного доступа (я вот иногда забываю, что перевесил ssh в другое место).

Интересно? Поделись с другом
Litl-Admin.ru

Comments:

Leave a Reply