web-dev-qa-db-ja.com

iptablesを使用してWebサーバーにACKFIN、ACK RST、RSTパケットをドロップしました

私はDebian7マシンでWebサーバー（Apache）を実行し、同じマシンでiptablesを実行しています。 iptablesルールは、ConfigServer Firewall（CSF）スクリプトによって生成されます。そこでホストされているWebサイトは、私の側では問題ありませんが、ポート80で多くのインバウンドトラフィックがドロップされています。

ログからの抜粋は次のとおりです（Webサーバー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要求？）がクライアント側でハングしたままになることを意味します。

何がこれを引き起こしているのか、私は本当に興味があります。また、問題を再現できないようであるため、クライアントが影響を受けているかどうかも疑問に思っています。皆さんが私を理解するのを手伝ってくれることを願っています！

読んでくれてありがとう=）

[〜＃〜] edit [〜＃〜]：OK釣りに行って、[ACK、FIN]パケットがドロップされるこれらのケースの1つについてパケットトレースを作成しました（コメントに記載されている方法に従います）未満）。最後の3つのパケットは、ファイアウォールによってドロップされたパケットです。

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. サーバーはHTTP200OK応答を送信します
  2. 接続を閉じたい。 [FIN、ACK]パケットをクライアントに送信します。これは、同時接続を閉じようとしていると推測されるためです。
  3. クライアントはサーバーの[FIN、ACK]に[ACK]で応答しますが（Seq/Ack番号は正しい順序です）、[FIN]は応答しません。これは、仕様によれば、接続が半分しか閉じられていないことを意味します。
  4. しかし、5分後、クライアントは[FIN、ACK]を送信します。これは、サーバーの「接続の終わり」にすでにACKを送信しているため、異常です。何らかの形式の=を推測しています。 TCPタイムアウトが関係しており、クライアントは開いたままの接続を閉じようとしているだけです。

したがって、接続終了ハンドシェイクが正しい順序で発生していないことは明らかです。そして、問題はクライアント側にあるようです。クライアント側は、5分のタイムアウトまで接続を閉じません。

私は3つのことに気づきました：

  • この特定のクライアントは最新のブラウザを実行していたため、ブラウザは問題ではありません。
  • 彼/彼女は多くのTCP再送信を送受信しており、接続が失われていることを示唆しています。この男は3Gでモロッコから接続されていることが判明したので、合計します^^。
  • 最後に、Apacheログは、彼が正しいHTTP応答を取得したことを示しているため、サイトトラフィックは「問題」の影響を受けません。

面白いもの。何かあったら撃て！

apache-2.2iptablesfirewalltcp
3
Moufle McMitten

Netfilterの メールチェーン によると、iptablesの正常な機能のようです。これらのメッセージをログに記録したくない場合は、ポート80で受け入れる状態のリストにINVALIDを追加して、その問題が解決するかどうかを確認できます。

そうでなければ、迷惑でログがいっぱいになることを除けば、それは無害なトラフィックであり、クライアントは何の問題も経験しません。

0
Nathan C