Почему некоторые пакеты сброса TCP отображаются в моем журнале iptables?

Я начал добавлять некоторые основные правила iptables на моем сервере Debian Jessie. Моя цель – фильтровать и регистрировать сетевой трафик (для целей безопасности и обучения). Без учета ICMP-пакетов это правила, которые я использую:

# INPUT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -j REJECT --reject-with tcp-reset # OUTPUT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT -A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5 

Политика установлена ​​как ACCEPT для INPUT и OUTPUT.

Теперь в журнале часто перечисляются исходящие пакеты RST , как правило, на порт 80. IP-адрес SRC принадлежит моему серверу, IP-адрес получателя частично отредактирован, чтобы не разглашать действия других людей.

 Aug 14 11:48:37 reynholm kernel: [81795.100496] UNKNOWN_OUTGOING: IN= OUT=ifext SRC=89.238.65.123 DST=108.162.[edited] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=3594 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 

Я не понимаю, что вызывает это, нет приложений, отличных от SSH и MTA. Это из-за моего правила ввода REJECT ? Но не должны ли эти пакеты обрабатываться по правилу выходного состояния ?

Ниже приведена захват одного из этих пакетов вместе с попыткой подключения, по-видимому, инициирующей его. Пакет не был отправлен между моим сервером и 108.162.[edited] до этого.

 11:48:37.860337 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 44) 108.162.[edited].80 > 89.238.65.123.3594: Flags [S.], cksum 0x79bb (correct), seq 79911989, ack 235561828, win 29200, options [mss 1460], length 0 0x0000: 4500 002c 0000 4000 3c06 7342 6ca2 0000 E..,..@.<.sBl... 0x0010: 59ee 417b 0050 0e0a 04c3 5c35 0e0a 6364 YA{.P....\5..cd 0x0020: 6012 7210 79bb 0000 0204 05b4 0000 `.ry........ 11:48:37.860408 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 89.238.65.123.3594 > 108.162.[edited].80: Flags [R], cksum 0x648e (correct), seq 235561828, win 0, length 0 0x0000: 4500 0028 0000 4000 4006 6f46 59ee 417b E..(..@.@.oFY.A{ 0x0010: 6ca2 0000 0e0a 0050 0e0a 6364 0000 0000 l......P..cd.... 0x0020: 5004 0000 648e 0000 P...d... 

3 Solutions collect form web for “Почему некоторые пакеты сброса TCP отображаются в моем журнале iptables?”

Создание пакета TCP RST происходит из вашего правила

 -A INPUT -p tcp -j REJECT --reject-with tcp-reset 

Политика по умолчанию (ACCEPT в вашем случае) применяется только к пакетам, которые не соответствуют ни одному из правил в вашей цепочке. Если пакет соответствует указанному выше правилу с целью REJECT, он не будет подвергаться политике по умолчанию и будет ОТКЛЮЧЕН (и генерировать TCP RST), а не ACCEPTed.

Этот TCP RST не будет соответствовать вашему правилу:

 -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

потому что он не относится к другому установленному соединению и не является частью соединения ESTABLISHED. Он будет продолжаться с помощью ваших правил и соответствия

 -A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5 

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


Что-то еще, что я заметил, это то, что первый пакет, который вы регистрируете, представляет собой пакет SYN / ACK с удаленного веб-сервера, который выглядит как пакет ответов с удаленного веб-сервера в пакет SYN, который вы ранее отправили, чтобы начать соединение с удаленный хост на порту 80. Если вы не отправили начальный SYN, я не думаю, что соединение будет соответствовать «ESTABLISHED», но если вы отправили SYN, я думаю, что соединение должно быть «ESTABLISHED». Это может быть беспорядок, с каким правилом ваш RST заканчивается совпадением.

Расширение большого ответа на @casey: причина этого в том, что пакет с удаленного имеет установленные флаги SYN и ACK. Это INVALID для первого пакета. iptables не рассматривает пакет сброса как относящийся к исходному пакету, поскольку он явно не имеет смысла.

Эффект можно воспроизвести с помощью инструмента, такого как hping3 : пакет SYN / ACK отправляется с помощью hping3 -c 1 --syn --ack 89.238.65.123 . Ответ сервера на этот пакет не будет иметь установленный флаг ACK и не будет соответствовать правилу состояния (т.е. не связан с отправкой ping). В результате запускается запись в журнале.

Такой эффект не возникает, если флаг ACK не задан в первоначальном запросе.

Я избавился от сообщений журнала, отфильтровывая и удаляя входящие пакеты INVALID tcp.

 -I INPUT 3 -m state --state INVALID -j DROP 

Похоже, что это может быть часть сканирования порта, инициированного с tcp / 80 на удаленном хосте. Удаленный хост проверяет вашу службу tcp / 3594, и ваша система правильно говорит «Нет. Теперь уходите (RST)». К сожалению, довольно нормальный материал для интернет-подключений.

Вам может fail2ban установить fail2ban , который может быть очень хорош в блокировании хостов, пытающихся подключиться к вашей системе неприемлемым образом. Предупреждение, однако: настройка его за пределы включенных примеров не является тривиальной.

  • открыть порт 8080 для прослушивания
  • как проверить rx ring, max_backlog и max_syn_backlog размер
  • Маршрутизация входящих сетевых запросов для данного порта в разные приложения
  • Linux медленное исходящее соединение
  • Как узнать, какой файл Apache работает, когда порт попал?
  • Параметры TCP SACK и масштабирование окна не изменяются на Ubuntu 16.04
  • Как я могу узнать, открыт ли порт TCP или нет?
  • Анализ сетевого трафика
  • Port netcat запрашивает информацию для скрипта bash
  • Включен ли TCP PACING по умолчанию в linux?
  • Почему TCP-соединения IPv4 отображаются как tcp6?
  • Linux и Unix - лучшая ОС в мире.