Почему iptables не блокирует IP-адрес?

9

Я настроил fail2ban для отслеживания определенного типа получаемого вредоносного трафика и запрета связанных IP-адресов.

Кажется, все работает отлично - регулярное выражение соответствует шаблону соответствующим образом, и проблемный IP-адрес добавляется в iptables.

Однако, когда я проверяю логи Apache, я все равно получаю хиты с IP-адреса, который забанен. Как будто iptables не работает вообще.

Итак, позвольте мне поделиться некоторыми особенностями, чтобы убедиться, что все настроено правильно.

Сначала я очищу и перезагрузлю правила iptables:

$ sudo iptables -F
$ cat /etc/iptables.firewall.rules 
*filter

#  Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

#  Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allow SSH connections
#
#  The -dport number should be the same port number you set in sshd_config
#
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

#  Allow ping
-A INPUT -p icmp -j ACCEPT

#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT
$ sudo iptables-restore < /etc/iptables.firewall.rules
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8          reject-with icmp-port-unreachable
   14  1432 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   11  1638 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Теперь вот как выглядит конфигурация fail2ban:

$ cat /etc/fail2ban/filter.d/apache-xmlrpc.conf 
[Definition]
failregex = .*:80 <HOST> .*POST .*xmlrpc\.php.*
ignoreregex =
$ cat /etc/fail2ban/jail.local 
[apache-xmlrpc]

enabled  = true
port     = http,https
filter   = apache-xmlrpc
logpath  = /var/log/apache2/other_vhosts_access.log
maxretry = 6
$ fail2ban-regex /var/log/apache2/other_vhosts_access.log /etc/fail2ban/filter.d/apache-xmlrpc.conf 

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/apache-xmlrpc.conf
Use log file   : /var/log/apache2/other_vhosts_access.log


Results
=======

Failregex
|- Regular expressions:
|  [1] .*:80 <HOST> .*POST .*xmlrpc\.php.*
|
`- Number of matches:
   [1] 29 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    80.82.70.239 (Sat Jul 13 02:41:52 2013)
    80.82.70.239 (Sat Jul 13 02:41:53 2013)
    80.82.70.239 (Sat Jul 13 02:41:55 2013)
    80.82.70.239 (Sat Jul 13 02:41:56 2013)
    80.82.70.239 (Sat Jul 13 02:41:57 2013)
    80.82.70.239 (Sat Jul 13 02:41:58 2013)
    80.82.70.239 (Sat Jul 13 02:41:59 2013)
    80.82.70.239 (Sat Jul 13 02:42:00 2013)
    80.82.70.239 (Sat Jul 13 02:42:02 2013)
    80.82.70.239 (Sat Jul 13 02:42:03 2013)
    80.82.70.239 (Sat Jul 13 02:42:04 2013)
    80.82.70.239 (Sat Jul 13 02:42:05 2013)
    80.82.70.239 (Sat Jul 13 02:42:06 2013)
    80.82.70.239 (Sat Jul 13 02:42:07 2013)
    80.82.70.239 (Sat Jul 13 02:42:09 2013)
    80.82.70.239 (Sat Jul 13 02:42:10 2013)
    80.82.70.239 (Sat Jul 13 02:42:11 2013)
    80.82.70.239 (Sat Jul 13 02:42:12 2013)
    80.82.70.239 (Sat Jul 13 02:42:13 2013)
    80.82.70.239 (Sat Jul 13 02:42:15 2013)
    80.82.70.239 (Sat Jul 13 02:42:16 2013)
    80.82.70.239 (Sat Jul 13 02:42:17 2013)
    80.82.70.239 (Sat Jul 13 02:42:18 2013)
    80.82.70.239 (Sat Jul 13 02:42:19 2013)
    80.82.70.239 (Sat Jul 13 02:42:20 2013)
    80.82.70.239 (Sat Jul 13 02:42:22 2013)
    80.82.70.239 (Sat Jul 13 02:42:23 2013)
    80.82.70.239 (Sat Jul 13 02:42:24 2013)
    80.82.70.239 (Sat Jul 13 02:42:25 2013)

Date template hits:
0 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
70 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Year.Month.Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 29

However, look at the above section 'Running tests' which could contain important
information.

Как вы можете видеть, у меня есть failregex, настроенный в фильтре, и фильтр включен. Используя fail2ban-regex, фильтр находит совпадение в файле журнала, который я отслеживаю. (Сейчас я активно сталкиваюсь с проблемным IP-адресом, что делает тестирование довольно простым.)

Поэтому теперь я перезагружаю fail2ban и наблюдаю, как правила вступают в силу:

$ sudo service fail2ban restart
 * Restarting authentication failure monitor fail2ban                                                                                                                         [ OK ] 
$ tail /var/log/fail2ban.log -n 50
2013-07-13 02:42:58,014 fail2ban.server : INFO   Stopping all jails
2013-07-13 02:42:58,745 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' stopped
2013-07-13 02:42:59,439 fail2ban.jail   : INFO   Jail 'ssh' stopped
2013-07-13 02:42:59,440 fail2ban.server : INFO   Exiting Fail2ban
2013-07-13 02:43:08,055 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.6
2013-07-13 02:43:08,057 fail2ban.jail   : INFO   Creating new jail 'ssh'
2013-07-13 02:43:08,111 fail2ban.jail   : INFO   Jail 'ssh' uses Gamin
2013-07-13 02:43:08,397 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2013-07-13 02:43:08,404 fail2ban.filter : INFO   Set maxRetry = 6
2013-07-13 02:43:08,414 fail2ban.filter : INFO   Set findtime = 600
2013-07-13 02:43:08,435 fail2ban.actions: INFO   Set banTime = 600
2013-07-13 02:43:09,277 fail2ban.jail   : INFO   Creating new jail 'apache-xmlrpc'
2013-07-13 02:43:09,277 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' uses Gamin
2013-07-13 02:43:09,283 fail2ban.filter : INFO   Added logfile = /var/log/apache2/other_vhosts_access.log
2013-07-13 02:43:09,286 fail2ban.filter : INFO   Set maxRetry = 6
2013-07-13 02:43:09,289 fail2ban.filter : INFO   Set findtime = 600
2013-07-13 02:43:09,292 fail2ban.actions: INFO   Set banTime = 600
2013-07-13 02:43:09,458 fail2ban.jail   : INFO   Jail 'ssh' started
2013-07-13 02:43:09,792 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' started
2013-07-13 02:43:11,361 fail2ban.actions: WARNING [apache-xmlrpc] Ban 80.82.70.239
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  244 39277 fail2ban-apache-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
  101  7716 fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8          reject-with icmp-port-unreachable
 3404  582K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  349 20900 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   12   720 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    2    80 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    2    80 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3331 4393K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-apache-xmlrpc (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       80.82.70.239         0.0.0.0/0           
  244 39277 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       223.4.147.8          0.0.0.0/0           
  101  7716 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Как показывает журнал fail2ban, набор правил, кажется, настроен правильно. Вы уже можете видеть, что проблемный IP-адрес сразу же перехватывается и блокируется. Вывод iptables показывает, что он фактически отбрасывается.

Однако уже сейчас я наблюдаю, что для этого IP-адреса нет пропущенных пакетов, соответствующих цепочке fail2ban-apache-xmlrpc. Конечно же, я проверяю логи apache:

$ tail /var/log/apache2/other_vhosts_access.log
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:53 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:54 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:56 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:57 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:58 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:59 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:44:00 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:44:02 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"

Нет, это не блокируется! Я также могу подтвердить это в журнале fail2ban:

$ tail /var/log/fail2ban.log
2013-07-13 02:52:30,757 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:37,767 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:44,783 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:51,814 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:58,830 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:05,842 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:11,858 fail2ban.actions: WARNING [apache-xmlrpc] Unban 80.82.70.239
2013-07-13 02:53:12,910 fail2ban.actions: WARNING [apache-xmlrpc] Ban 80.82.70.239
2013-07-13 02:53:20,118 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:27,129 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned

Он снова появляется в журнале apache и, таким образом, fail2ban пытается запретить его!

Я, честно говоря, не могу понять, почему iptables не сбрасывает трафик с этого IP-адреса. Порядок правил мне кажется правильным, поскольку DROP стоит на первом месте.

У меня в Google куча результатов, где люди сталкиваются с подобной проблемой, но всегда кажется, что они возвращаются к проблеме с запретом трафика SSH, когда они находятся на нестандартном порту. В моем случае я просто пытаюсь забанить IP-адрес на стандартном http-порте 80.

Я надеюсь, что я просто пропускаю что-то безумно простое. Это VPS под управлением Ubuntu 12.04 на Линоде. Если у кого-то есть идеи, пожалуйста, дайте мне знать. Большое спасибо...

РЕДАКТИРОВАТЬ : Вот выводiptables -S

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-apache-xmlrpc
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-xmlrpc
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
-A fail2ban-apache-xmlrpc -s 80.82.70.239/32 -j DROP
-A fail2ban-apache-xmlrpc -j RETURN
-A fail2ban-ssh -s 223.4.147.8/32 -j DROP
-A fail2ban-ssh -j RETURN
ubuntu  iptables  fail2ban 
— jsdalton
источник
Вывод iptables -sможет быть более полезным для нас, чем форматiptables -L
— Даниэль Видрик
@ lVlint67 - я отредактировал свой вопрос, чтобы показать результат iptables -Sдля вас. Дайте мне знать, если это даст вам дальнейшее понимание.
— Jsdalton
Последняя запись в журнале Apache находится в 02:44:02, а первое сообщение fail2ban о том, что IP-адрес заблокирован, - в 02:52:30, поэтому я не вижу никаких доказательств того, что он не работает. Пожалуйста, предоставьте полный файл fail2ban.log за период.
— Мгорвен
Первый бан, который я вижу из журнала fail2ban, был в 2:43, но я также заметил расхождения во времени. ПРИМЕЧАНИЕ: бан происходит в So now I restart fail2ban and observe the rules taking effect:блоке
— Даниэль Видрик

Ответы:

10

В iptables -sвыходные выглядит правильно , и я не знаю , как 80.82.70.239/32это становится для any:80вашего сервера через брандмауэр. Мое первое предположение состоит в том, что у вас есть прокси / балансировщик нагрузки перед сервером, и Apache регистрирует HTTP_X_FORWARDED_FORзаголовок или как это называется. Если это так, вам придется переместить логику брандмауэра на балансировщик прокси / нагрузки или на уровень приложения (Apache устанавливает FORWARDED_FORзаголовок и запрещает доступ.

Так или иначе:

Следующее действие, которое я предприму, - это запечатлеть результаты iptables -s, опубликованные вами выше. Отключите fail2ban и загрузите конфигурацию с цепочкой fail2ban и заблокированным IP-адресом в iptables.

Но сделайте это со следующим -Aправилом:

-A INPUT -p tcp --dport 80 -j LOG --log-prefix "HTTP: "

Если бы вы чувствовали себя лучше, поймав 80 и 443, сделайте это. Мысль заключается в том, что журналы от FIREWALL могут показать что-то, чего нам не хватает, если мы обратим внимание на пакеты из подозрительных источников.

— Дэниел Видрик
источник
3
Ты сделал это. Я не знаю, почему я не думал об этом раньше. Apache работает за Cloudflare, и у меня есть Apache, настроенный на запись IP-адреса HTTP_FORWARDED_FOR. Фактический трафик поступает через сервер Cloudflare - поэтому попытка заблокировать его с помощью fail2ban / iptables не сработает. Спасибо!
— Jsdalton
Мы используем балансировщики нагрузки haproxy в кампусе для обработки LB и HA, поэтому я ознакомился с небольшими «причудами», которые приносит установка. Я не знаю, что такое Cloudflare, но если у вас есть надлежащий доступ, перенос бана на балансировщик нагрузки может быть возможным. ... Если это невозможно, Apache может справиться с блокировкой каким-либо способом, но я не знаком с ним по уши.
— Даниэль Видрик
@jsdalton Каким было решение, которое вы получили в итоге. Прямо сейчас в похожей лодке.
— Джей
@jay Поскольку вам нужно изучить заголовки http, вы смотрите на что-то, что называется «Уровень 7» или брандмауэр. В противном случае вы можете попытаться заблокировать попытки балансировки нагрузки или прокси-сервера, если это находится под вашим контролем.
— Даниэль Видрик
1

Вывод iptables фактически показывает, что, хотя существует правило для IP-адреса, fail2ban считает, что его следует отфильтровать и отбросить, ни один пакет не прошел через цепочку fail2ban xmlrpc и фактически был отброшен этим правилом. Вместо этого были приняты все 224 пакета, прошедших через эту цепочку.

Тем не менее, правила действительно верны. Однако, по-видимому, по правилу принятия TCP-порта 80 было принято больше трафика, чем через цепочку фильтров fail2ban. Наиболее вероятная причина заключается в том, что трафик, который вы хотели заблокировать, пришел, когда цепочка fail2ban еще не была вставлена ​​во входные данные (я заметил, что у вас нет этого в ваших правилах по умолчанию, что, вероятно, нормально, но это означает, что если вы перезагрузите iptables цепочка fail2ban вступит в силу не сразу).

Попробуйте запустить, iptables -zчтобы обнулить количество пакетов и iptables -nvLснова посмотреть результат . Вывод не должен быть одинаковым. Кроме того, рассмотрите возможность сохранения правил для цепочек fail2ban в исходных правилах для iptables ( /etc/iptables.firewall.rules). Сохраните правила делегирования, как это:

fail2ban-apache-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443

Также сохраните существование цепочек (например fail2ban-apache-xmlrpc), но не сохраняйте фактические заблокированные IP-адреса.

— Сокол Момот
источник
Спасибо Сокол. Это вероятно потому, что я сбросил правила iptables, а затем прошло несколько секунд, прежде чем я перезапустил fail2ban и были добавлены правила fail2ban-apache-xmlrpc. Тем не менее, я попытался обнулить количество пакетов и перепроверить. Результат был почти таким же. Все пакеты, входящие в правила fail2ban-apache-xmlrpc, возвращаются, и ни один не удаляется. Я подтвердил, что в моих журналах Apache трафик поступает на тот IP-адрес, который он должен отбрасывать.
— Jsdalton
1

У меня была точно такая же проблема, как и у вас на моем собственном веб-сайте. Очень похожая настройка, стек LAMP, пара функциональных jail-серверов fail2ban, но я все еще видел эти якобы забаненные IP-адреса, отображаемые в файле журнала доступа. У меня нет никакого прокси / балансировщика нагрузки перед Apache.

Решение моей проблемы было на удивление простым: переместите утверждения о запретах прямо поверх файла конфигурации iptables!

— Хайдун
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.