iptables/意図せず破棄されたパケットから原因を特定したい

Last-modified: 2011-12-26 (月) 01:24:45

概要
方法
検証時の環境

概要 †

フィルタルールを固くすると、意図せず破棄してしまうパケットも出てくる。ここではログから始めて原因を特定/修正する。実例をもとに説明する。

↑

方法 †

前提条件

-
|
|
!
-
!

# フィルタルールはデフォルト破棄で、必要最低限しか通さない固いルールを使用している。
# INOUTチェイン、OUTPUTチェインの最終行まで到達したパケットはログを出力するようにしている。
# 例. INPUTチェイン最終行
iptables -A INPUT -j LOG --log-prefix "UNDEFIND_INPUT: " -m limit --limit 1/s --limit-burst 10
# 例. OUTPUTチェイン最終行
iptables -A OUTPUT -j LOG --log-prefix "UNDEFIND_OUTPUT: "-m limit --limit 1/s --limit-burst 10

実例①：

iptablesのログ出力先に「UNDEFIND_」が含まれるログが無いか確認(/var/log/syslogにも出力しているとして)

 
 
-
!
 
-
|
|

grep UNDEFIND_ /var/log/syslog
 
# 実行結果の一部(例)
[ 4855.823815] UNDEFIND_INPUT: IN=eth0 OUT= MAC=00:0c:20:b8:14:a7:00:16:01:71:20:94:28:00 SRC=216.34.181.96 DST=192.168.50.100 LEN=64 TOS=0x00 PREC=0x00 TTL=240 ID=43900 DF PROTO=TCP SPT=80 DPT=49839 WINDOW=4242 RES=0x00 ACK SYN URGP=0
 
# UNDEFINED_INPUTが見つかったので、iptablesが何かしらフィルタルールで許可しなかったパケットを破棄しているのがわかる。
# ログを見ていくと、216.34.181.96から自分(192.168.50.100)への入力。
# 80番ポートから49839ポートへのTCPパケットが弾かれているのがわかる。

[SRC=216.34.181.96]から入力元を調査。

 
 
-
!
 
 
-

host 216.34.181.96
 
# 実行結果の一部(例)
Name: projects.sourceforge.net
Address: 216.34.181.96
 
# projects.sourceforge.netからの通信ということが分かる。

[DPT=49839]からプログラムを調査。

netstat -p
 
# 実行結果の一部(例)
稼働中のインターネット接続 (w/oサーバ)
Proto 受信-Q 送信-Q 内部アドレス            外部アドレス            状態        PID/Program name
tcp        0      1 192.168.50.100:49839    216.34.181.96:www       LISTEN      3864/wget: test
tcp        0      1 192.168.50.100:52622    216.34.181.96:www       LISTEN      4222/wget: test
tcp        0      1 192.168.50.100:54245    216.34.181.96:www       LISTEN      4642/wget: test
tcp        0      1 192.168.50.100:46226    216.34.181.96:www       LISTEN      5221/wget: test
 
# projects.sourceforge.netにwgetでwebアクセスしているが、接続が確立されていない。
# しかもいくつも立ち上がっている。
# sourceforge.netへのアクセスで、(おそらく)定期的に行われているということは、なにかしらのプログラムの自動アップデートが怪しそうとあたりを付けれる。

cronの設定を確認。

  1
  2
  3

crontab -e
 
# 定期実行させている中で、rkhunterが実行前にアップデートを確認し、チェックするするというシェルスクリプトを書いたのを見つけた。

rkhunterのアップデート確認が行えるか確認。

 
 
-
|
|
!
 
 
-

rkhunter --checkversion
 
# 失敗。ログを確認してもUNDEFIND_INPUTが追記されている。
# フィルタルールをオフにし全許可で再試行。
# このサイト通りの構成なら以下のパスに停止用スクリプトがあるので実行。
/etc/network/if-post-down.d/iptables
rkhunter --checkversion
 
# 今度は成功。ログを確認してもUNDEFIND_INPUTは追記されていない。

iptablesの見直し。

-
|
!
-
!
 
-
|
!
 
 
-
|

# アップデートを確認するために、こちらから接続を開始したが、状態がESTAVLISHEDではなくLISTENで止まっている。
# ということは、接続済みのものを許可する設定あたりがおかしそうとあたりをつけて確認。
 
# 案の定、これを許可するルールが無かったので、追記する。
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# フィルタをオンにして再確認。
# このサイト通りの構成なら以下のパスに開始用スクリプトがあるので実行。
/etc/network/if-pre-up.d/iptables
rkhunter --versioncheck
 
# 成功。ログを確認してもUNDEFIND_INPUTは追記されていない。
# 終了。

実例②：

iptablesのログ出力先に「UNDEFIND_」が含まれるログが無いか確認(/var/log/syslogにも出力しているとして)

 
 
-
!
 
-
|
|
|
|
|
|

grep UNDEFIND_ /var/log/syslog
 
# 実行結果の一部(例)
[256855.057156] UNDEFIND_INPUT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:15:c5:42:b8:1e:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=338 TOS=0x00 PREC=0x00 TTL=128 ID=1 PROTO=UDP SPT=68 DPT=67 LEN=318 
 
# UNDEFINED_INPUTが見つかったので、iptablesが何かしらフィルタルールで許可しなかったパケットを破棄しているのがわかる。
# ログを見ていくと、ブロードキャストパケットが来たことがわかる。
# UDPで、68番からこちらの67番への入力。UDP 67、68番ポートを使用するのは、DHCP。
# 
# 今回はルーターのDHCP機能は停止したくない、分かりきっている不要なログはノイズになるだけなので出力したくない。とする。
# というわけで、ブロードキャストパケット全てをログを出さずに破棄することにする。
# (もちろんDHCPだけログを出さなくするのも解決策の一つ)

iptablesの見直し。

-
|
!
-
!
 
-
|
!
 
 
-

# ログを出力する前に、ブロードキャストパケットなら破棄するルールを追加する。
# ブロードキャスト宛てパケットはログを出さずに破棄
iptables -A INPUT -d 255.255.255.255 -j DROP
# 上記以外は破棄
iptables -A INPUT -j LOG --log-prefix "UNDEFIND_INPUT: " -m limit --limit 1/s --limit-burst 10
 
# フィルタを再設定する。
# このサイト通りの構成なら以下のパスに停止/開始用スクリプトがあるので実行。
/etc/network/if-post-down.d/iptables
/etc/network/if-pre-up.d/iptables
 
# 終了。

↑

検証時の環境 †

Debian Lenny x86