iptables блокирует часть трафика на портах 80 и 443, когда это не должно?

Веб-сервер, которым я управляю, показывает странные отказы iptables от адресов IPv4 на порту назначения 443, несмотря на то, что HTTPS-трафик явно разрешен. Порт 80 также разрешен в том же правиле, но сайт только для HTTPS, и 80 немедленно перенаправляется на 443 с помощью nginx.

Дело в том, что просмотр сайта работает. Вы можете загрузить все страницы, все ресурсы в порядке и т. Д. Но что-то здесь явно не так, и это может снизить производительность при загрузке страницы.

Вот несколько примеров ошибок, которые зарегистрированы /var/log/iptables_deny.log для порта 443 и 80 соответственно. Они могут прийти по отдельности или в очередях, судя по моим tail -f в файле журнала. Подавляющее большинство для порта 443:

iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x08 PREC=0x00 TTL=53 ID=61266 DF PROTO=TCP SPT=49264 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=11186 DF PROTO=TCP SPT=58445 DPT=443 WINDOW=254 RES=0x00 ACK FIN URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=16941 DF PROTO=TCP SPT=16278 DPT=80 WINDOW=255 RES=0x00 ACK FIN URGP=0

Быстрая подсказка говорит, что типы пакетов в отказах могут быть по крайней мере ACK, ACK FIN, ACK RST, ACK PSH и RST. Возможно, другие, но они не привлекли мое внимание.

Ниже вывод из iptables -nvL. Базовая схема (сначала разрешите все связанные и установленные, затем разрешите весь новый трафик на 80 и 443) должна основываться на всем, что я прочитал. Правила LOG & DROP являются последними в цепочке INPUT, как и должно быть.

Chain INPUT (policy ACCEPT 1 packets, 391 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     
 8893  770K ACCEPT     all  --  *      *       0.0.0.0/0       0.0.0.0/0      ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0       0.0.0.0/0      icmptype 8
   63  3840 ACCEPT     tcp  --  *      *       0.0.0.0/0       0.0.0.0/0      ctstate NEW multiport dports 80,443
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:137
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:138
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:139
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:445
    1    40 LOG        all  --  *      *       0.0.0.0/0       0.0.0.0/0      limit: avg 15/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    1    40 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 1 packets, 65 bytes)
 pkts bytes target     prot opt in     out     source          destination   
 7311   19M ACCEPT     all  --  *      *       0.0.0.0/0       0.0.0.0/0

Актуальные соответствующие правила, если они пригодятся после этого вывода:

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 80,443 -j ACCEPT

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

Есть идеи, что может быть за этим?

Источник

1 ответ

Решение

Пакеты RST и ACK,FIN являются частью самого конца TCP-соединения.

Я понимаю, что iptablesМеханизм отслеживания соединений использует довольно надежный подход к удалению записей таблицы состояний по соображениям безопасности: как только он увидит, что один конец соединения пытается закрыть его, тогда (зная, что такой запрос сигнализирует об окончании соединения, потому что один конец этого теперь думает, что соединение разорвано), он удаляет записи таблицы состояний, которые разрешали трафик этого соединения.

Возможно, было бы небезопасно для него ждать дольше, чтобы сделать это, в случае, если какой-то другой аналогичный межсетевой экран также находился в пути, блокируя оставшиеся пакеты очистки, которые указаны RFC; отсрочка получения записи в таблице состояний до тех пор, пока они не будут замечены, может привести к тому, что в течение некоторого периода времени в таблице останутся недопустимые записи, что может привести к потенциальной уязвимости.

Но в RFC указывается, что еще нужно привести в порядок, и именно эти пакеты, как вы видите, отклоняются. Да, это означает, что конечные точки в соединении будут использовать больше памяти, ожидая, пока соединения устареют, вместо того, чтобы видеть полное закрытие и иметь возможность намного быстрее освободить память соединения; но повышение безопасности часто требует ресурсов, и это один из тех компромиссов.

В этих пакетах нет никакого вреда, поэтому вы можете спокойно игнорировать записи журнала.

Изменить: если вы не хотите видеть их в журналах, разберитесь с ними перед строкой регистрации, например

iptables -I INPUT 13 -p tcp -m conntrack --ctstate INVALID --tcp-flags ACK,FIN ACK,FIN -j DROP
Источник
Другие вопросы по тегам