И снова fail2ban — на этот раз охраняем ProFTP и Dovecot

Собственно, это уже совсем … скучно. И тем не менее…

Просмотр логов показывает, что и в ftp-сервер мой постоянно кто-то пытается попасть «мимо кассы»:

Янв 19 07:54:36 dmitrykhn.homedns.org proftpd[27832] dmitrykhn.homedns.org (82.213.28.12[82.213.28.12]): USER service: no such user found from 82.213.28.12 [82.213.28.12] to 192.168.1.115:21
Янв 19 07:54:37 dmitrykhn.homedns.org proftpd[27832] dmitrykhn.homedns.org (82.213.28.12[82.213.28.12]): USER service: no such user found from 82.213.28.12 [82.213.28.12] to 192.168.1.115:21

…и в почтовый сервер тоже:

Feb  1 00:10:12 dmitrykhn dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=59.124.32.168, lip=192.168.1.115
Feb  1 00:10:19 dmitrykhn dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=210.202.39.205, lip=192.168.1.115

Что же тогда, сидеть и ждать? Решил я воспользоваться все тем же fail2ban — он и так уже трудится, вот пусть теперь и тут еще постарается…

С ProFTP, как мне казалось, все будет просто — соответствующий фильтр в наборе fail2ban имелся. Взял я программу fail2ban-regex и скормил ей файл протокола /var/log/proftpd/proftpd.log в паре с данным фильтром (как пользоваться fail2ban-regex я уже писал тут). Совпадения нашлись, и почти все было бы хорошо, если бы не одно «но». Программа fail2ban-regex сказала, что моя дата не подходит ни под один из известных ей шаблонов. Как я понял, единственное, что могло смутить fail2ban-regex в моей дате, так это тот язык, на котором она была выведена. То есть, «пришла беда, откуда не ждали». То ли авторы дистрибутива Mandriva, используемого мной, то ли авторы ProFTP, решили сделать мне «хорошо» — раз уж выбрал я русский язык, то пусть и протокол будет на русском. В принципе, оно конечно хорошо — понятнее. Даже не смотря на то, что русского того там в протоколе  — аж целых три буквы в имени месяца!..

В принципе, программа ProFTP (как я понял) использует тот язык, который в момент ее запуска указан в системе в качестве системного. Что ж, подумал я, если в момент запуска ProFTP указать, что системный язык английский, то есть шанс, что и сообщения в лог пойдут тоже на нем. Сказано — сделано. Пошел я в папку /etc/init.d и нашел в ней скрипт запуска сервера ProFTP (файл proftpd). Открыл его в редакторе и нашел в нем следующую строку:

         daemon "proftpd >/dev/null 2>&1"

и НАД ней добавил (чтоб долго не угадывать) следующие три:

        export LC_MESSAGES="en_US.UTF-8"
        export LC_ALL="en_US.UTF-8"
        export LANG="en_US.UTF-8"

Должен заметить, что строка daemon «proftpd >/dev/null 2>&1» присутствует в скрипте два раза. Как следствие и свои строки с назначением переменным LC_MESSAGES, LC_ALL и LANG значения en_US.UTF-8 я тоже добавил два раза (в обоих местах). Перезапустил ProFTP, заглянул в лог — красота, сообщения в нем снова на «родном английском»! Что ж, пол дела сделано.

Вторая половина — включить в fail2ban соответствующий фильтр (proftpd). Для этого я открыл в редакторе файл /etc/fail2ban/jail.conf и сделал в нем следующее — нашел в нем секцию про указанный фильтр и изменил ее, после чего она стала выглядеть следующим образом:

[proftpd-iptables]

enabled  = true
filter   = proftpd
action   = iptables[name=ProFTPD, port=ftp, protocol=tcp]
#           sendmail-whois[name=ProFTPD, dest=you@mail.com]
logpath  = /var/log/proftpd/proftpd.log
maxretry = 4

Собственно, изменений было аж три (выделены красным цветом). Смена в поле enabled значения с false на true включила использование фильтра. Диез (#) превратил строку с командой отправки почтового сообщения в комментарий (ну не надо мне эти письма!). Ну и в поле maxretry я поставил 4 — именно после стольких неудачных попыток нарушитель будет забанен.

А с  dovecot вопрос решился с помощью Google. Нашел я в нем ссылку на вот такую чудную страницу:

http://wiki.dovecot.org/HowTo/Fail2Ban

Просто «тупо» повторил описанное на ней, и все.  Для тех, кому английский так и не стал родным, очень кратко:

Создаем файл /etc/fail2ban/filter.d/dovecot-pop3imap.conf вот такого содержания:

[Definition]
failregex = (?: pop3-login|imap-login): (?:Authentication failure|Aborted login \(auth failed|Disconnected \(auth failed).*rip=(?P\S*),.*
ignoreregex =

После чего в файл /etc/fail2ban/jail.conf добавляем новую секцию вот такого вида:

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,imap", protocol=tcp]
logpath = /var/log/maillog
maxretry = 20
findtime = 1200
bantime = 1200

Пару замечаний про «мой случай» (выделено синим):

  • Лог для анализа в моем случае задействован иной — /var/log/mail/info.log (именно в нем я нашел сообщения об ошибочных авторизациях).
  • Строки про findtime и bantime я в секцию dovecot-pop3imap не писал совсем — меня вполне устраивают и значения «глобальных» настроек».
  • Параметр maxretry я у себя поставил поменьше — нечего тут…

После всех этих описанных выше действий, перезапустил я fail2ban и сижу вот теперь, жду…

fail2ban охраняет apache (часть «следующая»)…

В прошлой заметке, посвященной fail2ban, я описал пару фильтров, используемых мной для предотвращения «вражеских» происков, направленных против моего apache. Работало все это отлично, и вопросов не возникало. И дальше бы работало, если бы меня не потянуло на разборки с Chillispot. Дело в том, что в описанных мной конфигурациях fail2ban блокирование нежелательного доступа осуществляется при помощи shorewall. А его-то я как раз и поломал, ковыряясь с Chillispot. Точнее, не поломал, а отключил, так как для работы Chillispot требуется загрузка своего собственного скрипта с правилами для iptables, который «множит на ноль» всю работу shorewallЧитать далее «fail2ban охраняет apache (часть «следующая»)…»

Ну «Secure», так «secure» (часть 3 — fail2ban охраняет apache)

В прошлых моих записях с заголовком «Ну «Secure», так «secure» я защищался от попыток постороннего входа в мой «сервер» по ssh. Но, это ведь не единственный порт моего «сервера», который открыт наружу. Раз уж у меня установлен веб-сайт, то доступ к нему извне, естественно, тоже есть. И вот теперь заглянем-ка в файл протокола ошибок apache (/var/log/httpd/error_log): Читать далее «Ну «Secure», так «secure» (часть 3 — fail2ban охраняет apache)»

Ну «Secure», так «secure» (часть 2)

В прошлой заметке я уже описал, как боролся с «подбирателями паролей» на моем ssh-демоне. В принципе, я считаю, что принятых мер достаточно для защиты моего сервера (да и кому он надо-то?!). Но, с другой стороны, тысячи строк с сообщением об ошибке в логе авторизации просто «напрягают зрение понапрасну». И вот, просматривая сайт с новостями программного обеспечения, я наткнулся на название программы, которое меня заинтересовало — «Fail2Ban«. Открыл у себя «Центр управления Mandriva Linux», в нем выбрал «Управление программами» и ввел имя программы в поле «Поиск». «Есть у нас такая программа» — сказал поиск. Поставил «птичку», установил. Чем заинтересовала-то меня данная программа? Вот что про нее написано;

Fail2Ban scans log files like /var/log/secure and bans IP that makes too many password failures. It updates firewall rules to reject the IP address. These rules can be defined by the user. Fail2Ban can read multiple log files including sshd or Apache web server logs.

А если вкратце и по русски, программа сканирует логи и динамически меняет правила файервола, запрещая доступ тем IP, с которых происходит слишком много НЕУДАЧНЫХ попыток авторизации (читай, «происходит подбор пароля»)!!! Вот и все!

Остается лишь в качестве подтверждения эффективности программы процитировать два лога. Первый — протокол авторизации в системе (файл /var/log/auth.log):

Jul 25 20:12:31 smb-svr sshd[26144]: Invalid user guest from 61.168.222.170
Jul 25 20:12:31 smb-svr sshd[26144]: error: Could not get shadow information for NOUSER
Jul 25 20:12:31 smb-svr sshd[26144]: Failed password for invalid user guest from 61.168.222.170 port 1652 ssh2
Jul 25 20:12:36 smb-svr sshd[26147]: Invalid user guest from 61.168.222.170
Jul 25 20:12:36 smb-svr sshd[26147]: error: Could not get shadow information for NOUSER
Jul 25 20:12:36 smb-svr sshd[26147]: Failed password for invalid user guest from 61.168.222.170 port 2597 ssh2
Jul 25 20:12:42 smb-svr sshd[26149]: Invalid user guest from 61.168.222.170
Jul 25 20:12:42 smb-svr sshd[26149]: error: Could not get shadow information for NOUSER
Jul 25 20:12:42 smb-svr sshd[26149]: Failed password for invalid user guest from 61.168.222.170 port 3700 ssh2

А второй — протокол работы самой программы (файл /var/log/fail2ban.log):

2008-07-25 20:12:43,045 fail2ban.actions: WARNING [ssh-iptables] Ban 61.168.222.170
2008-07-25 20:22:43,414 fail2ban.actions: WARNING [ssh-iptables] Unban 61.168.222.170

Для «полного понимания» добавлю лишь, что по умолчанию программа:

  • запрещает доступ с IP-адреса после трех неверных попыток ввода пароля;
  • блокирует доступ на 600 секунд.

Первое прекрасно видно при сравнении времени третьей попытки из первой «цитаты» со временем включения файервола во второй «цитате». Второе легко заметить, сравнив во второй «цитате» время включения и выключения блокирования адреса. При желании Вы можете изменить те значения настроек, которые Вас не устраивают , самостоятельно отредактировав файлы в папке /etc/fail2ban.

…С тех пор у меня нет в логах авторизации многотысячных записей «Failed password for invalid user...» Чего и вам желаю!,,,

ЗЫ. Балуясь на днях (зкспериментируя) с авторизацией в ssh, заполучил бан самого себя. «Сервер» дома, я на работе, а дела-то не ждут! Пришлось себя срочно «разрешать»… Спас Webmin. У него в разделе «Прочее» есть пункт «Командная оболочка (shell)» (командная строка). Вот в ней-то я и запустил команду:

fail2ban-client status

Сервер fail2ban ответил, что запущен следующий фильтр (Jail): ssh-iptables. Чтобы остановить его, ввел команду:

fail2ban-client stop ssh-iptables

И напоследок, чтобы на будущее меня ни в коем случае не банило, прописал свой рабочий адрес в файл /etc/fail2ban/jail.conf в строке:

ignoreip = 127.0.0.1 XXX.XXX.XXX.XXX

(адреса, когда их несколько, разделяются пробелами)…