Назад | Перейти на главную страницу

Отброшены пакеты ACK FIN, ACK RST, RST на веб-сервере с iptables

Я запускаю веб-сервер (Apache) на машине Debian 7 с iptables на той же машине. Правила iptables генерируются сценарием ConfigServer Firewall (CSF). Веб-сайты, размещенные там, хороши с моей стороны, однако Я вижу, что входящий трафик на порт 80 сильно упал.

Вот выдержка из логов (IP-адрес веб-сервера: 11.22.33.44):

Jan 27 15:21:36 [hostname] kernel: [1229124.817624] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3144 DF PROTO=TCP SPT=36879 DPT=80 WINDOW=510 RES=0x00 ACK FIN URGP=0
Jan 27 15:21:36 [hostname] kernel: [1229124.872795] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3183 DF PROTO=TCP SPT=36684 DPT=80 WINDOW=513 RES=0x00 ACK FIN URGP=0
Jan 27 16:03:36 [hostname] kernel: [1231642.223513] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=19101 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK FIN URGP=0
Jan 27 16:03:41 [hostname] kernel: [1231647.015463] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=26215 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK RST URGP=0
Jan 27 16:03:51 [hostname] kernel: [1231656.677627] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=10630 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0
Jan 27 16:04:42 [hostname] kernel: [1231707.911962] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3513 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Jan 27 16:04:42 [hostname] kernel: [1231707.911976] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3514 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

Сотни строк такого материала. Нет определенного шаблона синхронизации, и падение происходит для случайных клиентов.

Но эти отброшенные пакеты всегда помечаются флажками ACK FIN, RST, ACK RST и гораздо реже SYN. Я понимаю, что это пакеты «подтверждения передачи и завершения соединения».

Соответствующие правила iptables:

Chain INPUT (policy DROP)
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:80
LOGDROPIN  all  --  anywhere             anywhere

Chain LOGDROPIN (1 references)
LOG        tcp  --  anywhere             anywhere             limit: avg 30/min burst 5 LOG level warning prefix "Firewall: *TCP_IN Blocked* "
DROP       all  --  anywhere             anywhere

Итак, судя по всему, эти пакеты отбрасываются, потому что их соответствующее соединение больше не открыто, то есть RELATED или ESTABLISHED. Это означает, что передача прошла успешно и что сервер закрывает соединение до того, как клиент успевает подтвердить полученные данные, оставляя соединение (и, возможно, HTTP-запрос?) На стороне клиента.

Мне действительно любопытно, что могло быть причиной этого. А также интересно, затронуты ли клиенты, поскольку я не могу воспроизвести проблему. Я надеюсь, что вы, ребята, поможете мне понять!

Спасибо за чтение =)

РЕДАКТИРОВАТЬ: OK Я пошел на рыбалку и сделал трассировку пакетов для одного из этих случаев, когда пакеты [ACK, FIN] отбрасываются (следуя методу, описанному в моем комментарии ниже). Брандмауэр отбросил три последних пакета:

Source                Destination           Protocol Length Info                                                                            Time
[CLIENT COMP]         [WEBSERVER]           TCP      68     55478 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1400 WS=4 SACK_PERM=1               2014-01-29 20:44:36.044009
[WEBSERVER]           [CLIENT COMP]         TCP      68     http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:36.044052
[WEBSERVER]           [CLIENT COMP]         TCP      68     http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:37.243948
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=1 Ack=1 Win=16800 Len=0                                  2014-01-29 20:44:37.421123
[CLIENT COMP]         [WEBSERVER]           HTTP     464    GET /sites/default/files/js/js_R9UbiVw2xuTUI0GZoaqMDOdX0lrZt....js HTTP/1.1     2014-01-29 20:44:37.432097
[WEBSERVER]           [CLIENT COMP]         TCP      56     http > 55478 [ACK] Seq=1 Ack=409 Win=15872 Len=0                                2014-01-29 20:44:37.432122
[WEBSERVER]           [CLIENT COMP]         HTTP     963    HTTP/1.1 200 OK  (text/javascript)                                              2014-01-29 20:44:37.432703
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=409 Ack=908 Win=15892 Len=0                              2014-01-29 20:44:37.769928
[WEBSERVER]           [CLIENT COMP]         TCP      56     http > 55478 [FIN, ACK] Seq=908 Ack=409 Win=15872 Len=0                         2014-01-29 20:44:42.437129
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=409 Ack=909 Win=15892 Len=0                              2014-01-29 20:44:42.580378
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:44.668730
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:49.194316
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:58.869659

Согласно этому:

  1. Сервер отправляет ответ HTTP 200 OK
  2. Желающих закрыть соединение. Он отправляет клиенту пакет [FIN, ACK], поскольку я предполагаю, что он пытается закрыть одновременное соединение.
  3. Клиент отвечает [ACK] на [FIN, ACK] сервера (номера Seq / Ack указаны в правильном порядке), но не [FIN], что, согласно спецификации, означает, что соединение только наполовину закрыто.
  4. Но потом, 5 минут спустя, клиент отправляет [FIN, ACK], что необычно, потому что он уже отправил ACK на «конец соединения» сервера. Я предполагаю, что задействован какой-то тайм-аут TCP, и что клиент только пытается закрыть соединение, которое осталось открытым.

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

Я заметил 3 вещи:

Интересный материал. Если есть что, стреляйте!

Согласно почтовая цепочка в netfilter это обычная функция iptables. Если вы не хотите, чтобы эти сообщения появлялись в журнале, вы можете попробовать добавить INVALID в список состояний, принимаемых на 80-м порту, и посмотрите, исчезнет ли эта проблема.

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