Защита SSH от подбора пароля
Чтение лог-файлов, для любого вменяемого системного администратора, является довольно повседневным занятием, делать это можно по разному, речь сейчас пойдет не об этом. Вряд-ли найдется человек, занимающийся удаленным администрированием и ни разу не сталкивавшийся с логом авторизации в системе, буквально заваленным тысячами сообщений о неудачных попыток входа в систему по протоколу SSH.
Напомню, что SSH является стандартом для подключения и администрирования удаленных систем, кстати, не только в мире UNIX, и входит в стандартный набор установленных пакетов, многих UNIX дистрибутивов, FreeBSD в частности.
Причиной такого количества неудачных подключений, являются попытки подбора пары логин:пароль, так называемые атаки по словарю, осуществляемые с помощью специальных программ. Бороться с данным видом атак вручную, абсолютно бесполезное занятие, наличие IP адреса атакующего ничего не дает, так как, в подавляющем большинстве случаев, являются "левыми" и периодически меняются.
Если копнуть соответствующие материалы по безопасности серверных операционных систем, можно найти целый ряд простых правил, придерживаясь которых, можно обеспечить достаточно высокий уровень безопасности SSH. Приведу краткий список того, что необходимо знать и помнить:
- Конечно-же устанавливать нормальные пароли. Безопасный пароль должен состоять как минимум из 10-16 знаков, содержать, буквы в нижнем и вернем регистрах, цифры, и символы( !"№;%:?-_ и т.д. ). Подобрать такой пароль, за сколь-нибудь приемлемый промежуток времени, практически не реально.
- Запретить удаленный вход в систему под учетной записью root.
- Для нужд удаленного администрирования, завести отдельного пользователя с минимальными правами, разрешив ему подключаться по протоколу SSH. Для повышения привилегий в системе, использовать программы типа su.
- Если есть возможность, ограничить удаленные подключения по IP адресам. ( средствами демона SSH или фаерволом ).
freebsd8 /# cd /usr/ports/security/sshguard-ipfw freebsd8 /usr/ports/security/sshguard-ipfw# make install cleanКак видим, все очень просто, ставится sshguard без каких либо дополнительных параметров. Принцип работы программы программы следующий: sshguard парсит лог файл регистраций в системе, если обнаруживает аномальное количество неудачных подключений с определенного IP, помечает адрес как нарушителя и добавляет в IPFW блокирующее правило на определенный промежуток времени, по умолчанию, время блокировки, 7 минут. Если в дальнейшем, данный IP вновь обратит на себя внимание sshguard своим неадекватным поведением, снова будет создано блокирующее правило в IPFW, но срок будет 2*7. Схема расчета времени блокировки следующая: 7 минут, 2*7 минут, 2*2*7 минут ..... 2^(n-1)*7 минут. В дальнейшем, после определенного количества рецидивов, указанного в опции -b, IP может будет помещен с черный список на постоянной основе. Настройка sshguard, так-же проста как и установка. Для использования sshguard, будем использовать syslog, соответственно в конфиг данного демона ( /etc/syslog.conf ), пропишем следующую строку:
auth.info;authpriv.info |exec /usr/local/sbin/sshguard -a 3 -b 10:/var/db/sshguard/blacklist -w /var/db/sshguard/whitelistпосле чего нужно перезапустить демон syslogd.
freebsd8 /# /etc/rc.d/syslogd restartЕсли быть точным, sshguard сама пропишет необходимый минимум в этот файл, нужно только раскомментировать строку и поправить под свои нужды. Итак, основные опции
- -a
- Количество неудачных попыток ввода пароля, после которых адрес блокируется, в нашем случае 3.
- -b номер:/path/to/blacklist
- Задает файл черного списка адресов и количество блокировок, после которого IP адрес будет помещен в этот список.
- -w адрес/хост/блок/файл
- Данная опция определяет белый список адресов. Может принимать IP адрес IP4 или IP6, доменное имя хоста или блок IP адресов в формате 10.20.30.0/24. Кроме того можно прописать путь до файла, содержащего все вышеперечисленное в виде списка. Что-бы указать несколько адресов, хостов или блоков, данную нужно использовать повторно, то есть -w 1.2.3.4 -w 5.6.7.8 -w microsoft.com. Мы прописали путь до файла.
- -p секунды
- Время блокировки адреса атакующего. По умолчанию 420 секунд ( 7 минут )
- -s секунд
- Реабилитировать адрес после указанного количества секунд. По умолчанию 20*60 ( 20 минут). Грубо говоря, если попытки атаки с одного IP предпринимаются раз в 20 минут, в черный список он не попадет никогда.
- syslig
- syslog-ng
- metalog
- multilog
- raw messages
- IBM AIX firewall
- PF
- netfilter/iptables
- IPFW
- IP Filter
- /etc/hosts.allow
- null firewall
Комментарии
Спасибо за статью. Ответьте, пожалуйста, на глупый вопрос: файлы /var/db/sshguard/blacklist и /var/db/sshguard/whitelist создадуться автоматически?
Судя по всему нет ибо в логах при отсутствие данных файлов получаем ошибку:
если не создать блеклист - то он создаться автоматом
белый лист сам не создается ))
да мне /etc/rc.d/syslogd restart не помог
только ./syslogd start
и stop соовественно
Забыли еще в список "что нужно обязательно знать" добавить изменение порта и создание "непонятных" и "непопулярных" имен пользователей - ко мне постоянно пытаются (если смотреть по тем логам, когда стоял стандартный порт по определенным причинам) подключиться либо по словарю, либо по именам, схожим с DNS, либо по "стандартным" логинам вроде www, ftp, и так далее.
В итоге апач настроен на пользователя wwwwww, и так далее. Ну а после того как исчезла необходиомсть использовать стандартный порт, количество атак уменьшилось в разы - а если еще поставить блокировку сканирования портов с помощью ipfw, то sshguard можно даже не использовать
ну порт я меняю вообще в первую очередь, даже если для этого пока нет причин :)
а как сделать что бы он блокировал только 22 порт а не весь трафик ??? у меня freebsd 9 ...
Маленькое замечание.
Если в фаерволе используется открытый тип доступа по ssh (в конце запрещающих правил стоит правило allow tcp from any to me dst-port 22), то нужно одно небольшое шаманство. Скорее всего это правило будет располагаться выше запрещающих правил sshguard, соответственно его правила становятся полностью бесполезными.
Лечится принудительным указанием номера правила, например 56000 allow tcp from any to me dst-port 22.
тогда автоматические правила sshguard будут располагаться до финального разрешения.
Так правило allow any from all to all находится в самом низу, 65535-ым. Ниже него ничего уже не встанет.
О, извиняюсь, думал, что речь о завершающем правиле ipfw идёт для всех. Насчет разрешающего правила только для ssh, о котором вы говорите, есть нюанс. По умолчанию, действительно, анализ будет идти до первого удовлетворяющего правила, далее - выход из ipfw либо в дроп либо в доступ. Тогда нужно заранее зарезервировать секцию номеров до этого правила. Вообще, строго придерживаться сегментации, писать все правила с определенными диапазонами номеров, оставляя запасы. Пригодится для отладки и тестирования
Добавляет IP в черный список, но не блокирует ничего. В ipfw никаких правил не добавляет. Пишите полные статьи, а не куски непонятно откуда. Файлы черного и белого списка тоже нужно руками создавать, иначе не заработает ничего.
Та же беда. У меня ни каких действий с фаерволом не делает. Процесс сам запускается. Пробовал и через syslog.conf и через rc.conf добавлять. Ни каких динамических и статических правил не появляется, ни как не чего не блокиркуется. Понятия не имею в чём беда. 1 раз в чёрном списке появился и в таблице 22, на доступ это не как не повлияло, хотя это могло быть правилом более высоким моим вызвано, я всё это дело почистил для проб дальше и это было всё что он смог для меня сделать.
Отправить комментарий