Skip to content


Противодействие автоматическому подбору паролей

В лог-файлах почти любого публично доступного FTP-сервера в Интернет сисадмин почти всегда видит попытки множественных безуспешных попыток авторизации. Например:

Thu Sep 3 04:39:50 2009 FTP command: Client "221.232.131.51", "USER Admin"
Thu Sep 3 04:39:51 2009 [Admin] FTP response: Client "221.232.131.51", "530 Permission denied."
Thu Sep 3 04:39:53 2009 CONNECT: Client "221.232.131.51"
Thu Sep 3 04:39:53 2009 FTP response: Client "221.232.131.51", "220 Welcome to our FTP-server."
Thu Sep 3 04:39:53 2009 FTP command: Client "221.232.131.51", "USER Admin"
Thu Sep 3 04:39:54 2009 [Admin] FTP response: Client "221.232.131.51", "530 Permission denied."
Thu Sep 3 04:39:55 2009 FTP command: Client "221.232.131.51", "USER Admin"
Thu Sep 3 04:39:56 2009 [Admin] FTP response: Client "221.232.131.51", "530 Permission denied."
Thu Sep 3 04:39:57 2009 CONNECT: Client "221.232.131.51"
Thu Sep 3 04:39:57 2009 FTP response: Client "221.232.131.51", "220 Welcome to our FTP-server."
Thu Sep 3 04:39:57 2009 FTP command: Client "221.232.131.51", "USER Admin"
Thu Sep 3 04:39:58 2009 [Admin] FTP response: Client "221.232.131.51", "530 Permission denied."
Thu Sep 3 04:39:59 2009 FTP command: Client "221.232.131.51", "USER Admin"
Thu Sep 3 04:40:00 2009 [Admin] FTP response: Client "221.232.131.51", "530 Permission denied."

Как-правило, цель взломщиков проста – угадать пароль и использовать FTP-аккаунт для размещения скриптов рассылки спама, сбора персональных данных с фишинговых сайтов и прочих тёмных делишек. Поэтому всегда стоит по возможности закрывать доступ на TCP-порт 21 в firewall-е для всех, кроме блоков IP-адресов, с которых ходят доверенные пользователи. Но что делать, если мы не знаем откуда будут ходить легитимные пользователи нашего FTP-сервера? В таких случаях, конечно, доступ закрывать нельзя, но можно существенно понизить эффективность подбора паролей путем следующих двух простых правил для стандартного в linux firewall-а iptables:

  1. iptables -A INPUT -m recent --name ftpbruteforce --update --seconds 60 --hitcount 2 -j DROP
  2. iptables -A INPUT -p tcp --syn --dport 21 -m recent --name ftpbruteforce --set -j ACCEPT

Второе правило означает, что если встретится TCP-сегмент, в котором порт получателя 21 и установлен флаг SYN (что соответствует 1-ой фазе установки соединения при подключении к FTP-серверу), то iptables "запомнит" этот факт вместе с моментом появления такого TCP-сегмента и установит для этого события заданное нами имя ftpbruteforce. А первое правило означает, что если события с именем ftpbruteforce будут наступать чаще, чем 2 раза в течение 60-ти секунд, то такие TCP-сегменты будут блокироваться (-j DROP). Параметр −−update означает, что таймер блокировки обнуляется каждый раз, когда событие ftpbruteforce наступает в следующий раз. То есть легитимный пользователь, который правильно указывает логин и пароль при подключении к серверу, без проблем подключиться, потому что для него сработает только 2-ое правило и не сработает 1-ое правило. Он даже один раз может ошибиться при указании атрибутов доступа – вторая попытка с уже правильными атрибутами тоже будет успешной. А вот уже начиная с третей попытки установить соединение в течение 60-ти секунд начнет срабатывать 1-ое правило и трафик будет блокироваться, что как раз и соответствует случаю подбора паролей (bruteforcing).

Данную методику можно применять, конечно же, не только для FTP-серверов, но и для многих других случаев (например, SSH). Другие примеры использования модуля recent можно посмотреть на странице его автора и в странице руководства ('man iptables').

Размещено в категории *nix. Теги: , .

Комментариев: 1

Чтобы быть всегда в курсе здесь происходящего, Вы можете подписаться на RSS feed для комментариев на эту заметку.

  1. Интересно! Хотелось бы побольше точно таких же интересных постов

Some HTML is OK

(required)

(required, but never shared)

, или ответить через trackback.

Страница 1 из 11