Мы запускаем брандмауэр с iptables в нашей системе Debian Lenny. Я покажу вам только соответствующие записи нашего файервола.
Chain INPUT (policy DROP 0 packets, 0 bytes)
target prot opt in out source destination
ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
target prot opt in out source destination
ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
LOGDROP all -- * * 0.0.0.0/0 0.0.0.0/0
Некоторые пакеты сбрасываются каждый день с такими сообщениями журнала:
5 февраля, 15:11:02 ядро host1: [104332.409003] сброшено IN = OUT = eth0 SRC = <OWN_IP> DST = <REMOTE_IP> LEN = 1420 TOS = 0x00 PREC = 0x00 TTL = 64 ID = 18576 DF PROTO = TCP SPT = 80 DPT = 59327 WINDOW = 54 RES = 0x00 ACK URGP = 0
из соображений конфиденциальности я заменил IP-адреса на <OWN_IP> и <REMOTE_IP>
Это не повод для беспокойства, просто я хочу понять, что происходит. Веб-сервер пытается отправить пакет клиенту, но брандмауэр каким-то образом пришел к выводу, что этот пакет «НЕ СВЯЗАН» с любым предшествующим трафиком.
Я установил для параметра ядра ip_conntrack_ma достаточно высокое значение, чтобы убедиться, что все соединения отслеживаются модулем состояния iptables:
sysctl -w net.ipv4.netfilter.ip_conntrack_max=524288
Что забавно, каждые 20 минут у меня разрывается соединение:
06:34:54
06:52:10
07:10:48
07:30:55
07:51:29
08:10:47
08:31:00
08:50:52
09:10:50
09:30:52
09:50:49
10:11:00
10:30:50
10:50:56
11:10:53
11:31:00
11:50:49
12:10:49
12:30:50
12:50:51
13:10:49
13:30:57
13:51:01
14:11:12
14:31:32
14:50:59
15:11:02
Это с сегодняшнего дня, но в другие дни тоже выглядит так (иногда ставка меняется).
В чем может быть причина?
Любая помощь приветствуется. С уважением, Яннинг
Я видел очень похожую проблему в своих системах и, возможно, у меня есть ответ относительно того, что происходит.
По-видимому, TCP позволяет клиенту отправлять пакет FIN, а вы подтверждать этот пакет FIN, но при этом держать конец соединения открытым и передавать через него больше данных, отправляя свой собственный пакет FIN в какой-то момент в будущем. Я помню, как читал, что это было реализовано в какой-то момент в ядре 2.6, хотя моя память на этот момент может быть неточной / неуместной.
Многие брандмауэры, включая IPTables, похоже, еще не реализовали это или реализуют его неправильно и считают соединение закрытым, как только они видят FIN, за которым следует ACK. В результате мой сервер время от времени отправляет клиенту пакет, который, по мнению брандмауэра, не является частью установленного соединения и не является новым, и поэтому отбрасывает его.
На практике я не видел каких-либо важных данных в этих последних нескольких отбрасываемых пакетах, поэтому в результате возникает несколько дополнительных пакетов сброса, которые выбрасываются, и некоторые дополнительные соединения остаются в состоянии FIN_WAIT, но не битые или наполовину загруженные страницы .
Я не знаю о 20-минутном тайминге, который вы видите, но я предполагаю, что это какой-то клиент, который регулярно запускается каждые 20 минут и выполняет запрос, который заставляет ваш сервер выполнять последовательность FIN ACK PSH FIN RST.
В этом посте может быть больше информации о том, почему IPTables отбрасывает эти пакеты: http://lists.netfilter.org/pipermail/netfilter/2005-August/062059.html
По словам Криса Брентона, это несоответствие тайм-аутов клиента, сервера и брандмауэра для пакетов в одностороннем закрытом состоянии.
Отображается ли исходный / исходный IP-адрес в этом журнале? Если да, показывает ли этот IP какие-либо действительные запросы в журналах http? Возможно, какая-то система мониторинга проверяет http на вашем сервере, поскольку вы сказали, что это было через определенные промежутки времени. Просто выбрасываю туда вещи.
Если кто-то попытается просканировать вас, отправив ACK-пакеты, а вашему брандмауэру требуется СОСТОЯНИЕ (установленное соединение), он будет отключен.
Межсетевые экраны без сохранения состояния отбрасывают только входящие SYN-пакеты и пропускают ACK. Это означает, что вы можете сканировать за брандмауэром, даже если порт заблокирован. Как? Поскольку ACK не распознается, система будет работать нормально и отправлять пакет RST (RESET), сообщающий вам, что у нас нет соединения. Теперь вы знаете, что что-то прослушивает этот порт.
И если посмотреть на предоставленную вами информацию, это действительно отбрасываемый пакет ACK.
Вы можете подтвердить это, используя Nmap(из внешней системы):
nmap -sA -p80 ваш_ip
Сам никогда не пробовал, но, возможно, использую эти инструкции регистрация всего пакета в pcap может помочь вам найти ответ.
Я не понимаю, почему сообщения журнала iptables показывают пакеты, которые были отброшены при исходящий, в то время как последний журнал показывает отброшенные пакеты входящий?
Я подозреваю, что у вас могут быть две разные проблемы. Возможно, кто-то пытается подделать ваш адрес, поэтому несвязанный ответ на (поддельный адрес) перехватывается iptables и отбрасывается. Это покроет исходящие капли.
Что касается входящих дропов, 20-минутный интервал подозрительно ... возможно, ARP? Какая-то аутентификация DHCP ..? 20 минут - 1200 секунд; возможно, есть 3 отдельные цепочки, каждая из которых добавляет до 3600 (время аренды DHCP по умолчанию), но вы видите только отдельные пакеты. Просто намек.