メモ > サーバ > 構築: 攻撃からの防御 > iptableのログ
iptableのログ
iptablesの設定
http://www.nina.jp/server/redhat/iptables/iptables.html
iptablesのログフォーマットと内容について
http://tech.sayama-yuki.net/archives/422
/etc/sysconfig/iptables を編集する。
#以上のチェックにかからなかったパケットは、ICMPパケット host-prohibited を返して接続を拒否
-A MY-FIREWALL -j REJECT --reject-with icmp-host-prohibited
この直前に以下を追加し、iptableを再起動。
#以上のチェックにかからなかったパケットを /var/log/messages に記録。ただし記録は1秒間に1回まで
-A MY-FIREWALL -j LOG --log-level info --log-prefix "[IPTABLES REJECT]: " -m limit --limit 1/s
/var/log/messages に以下のようなログが記録されるようになった。
Mar 21 16:02:05 refirio kernel: [IPTABLES REJECT]: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:52:54:0d:00:23:01:08:00 SRC=153.121.33.75 DST=153.121.33.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=15869 PROTO=UDP SPT=138 DPT=138 LEN=209
Mar 21 16:03:03 refirio kernel: [IPTABLES REJECT]: IN=eth0 OUT= MAC=01:00:5e:00:00:01:b8:ca:3a:62:cc:e0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
Mar 21 16:03:32 refirio kernel: [IPTABLES REJECT]: IN=eth0 OUT= MAC=52:54:0d:00:23:10:00:24:38:2d:06:00:08:00 SRC=89.248.166.153 DST=153.121.33.84 LEN=40 TOS=0x00 PREC=0x00 TTL=19 ID=26437 PROTO=TCP SPT=3389 DPT=3389 WINDOW=50723 RES=0x00 SYN URGP=50723
「SRC=89.248.166.153」の部分で送信元IPアドレスが判る。
「DST=153.121.33.84」の部分で送信先IPアドレスが判る。
この場合、オランダからrefirio.netにアクセスがあり、そのアクセスを遮断したと判る。
送信元IPアドレスがプライベートIPアドレスの場合、送信元が偽装されている可能性が高い。
これらは接続は拒否しておくといい。
プライベートIPアドレスの範囲は以下のとおり。
10.0.0.0/8（10.0.0.0 〜 10.255.255.255）
172.16.0.0/12（172.16.0.0 〜 172.31.255.255）
192.168.0.0/16（192.168.0.0 〜 192.168.255.255）
以下の送信元も偽装されている可能性が高い。
これらも接続は拒否しておくといい。
127.0.0.0/8
169.254.0.0/12
192.0.2.0/24
224.0.0.0/4
224.0.0.0/5
「SPT=138」の部分でソースポート番号（送信元のポート番号）が判る。
「DPT=138」の部分でデスティネーションポート番号（送信先のポート番号）が判る。
同じIPアドレスから色々なポートに対してアクセスがあれば、ポートスキャンの可能性がある。
以下のログは基本的なファイヤーウォールのログなので無視していい？
May 7 18:21:49 refirio kernel: [IPTABLES REJECT]: IN=eth0 OUT= MAC=01:00:5e:00:00:01:b8:ca:3a:62:cc:e0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
止まらない SRC 0.0.0.0 DST 224.0.0.1
http://luluya.mydns.jp/d_pukiwiki/index.php?%E3%81%82%E3%81%9F%E3%81%BE%E3%81%AE%E3%81%AA%E3%81%8B%2...
strange kernel log message appeared
http://www.linuxquestions.org/questions/linux-server-73/strange-kernel-log-message-appeared-41754352...
AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a time
https://www.abuseipdb.com/
■CentOS7のfirewallでの具体例
以下はCentOS7のfirewallで、中国からのアクセスを拒否した際のログ。（説明用に若干改変してある。）
ログ形式はCentOS6のiptableと同じみたい。
Apr 21 15:20:47 refirio kernel: FINAL_REJECT: IN=eth0 OUT= MAC=52:54:0d:00:23:10:00:1b:ed:b0:c1:00:08:00 SRC=122.4.199.68 DST=153.121.33.84 LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=60580 DF PROTO=TCP SPT=21667 DPT=2222 WINDOW=39862 RES=0x00 ACK RST URGP=0
ログの意味は以下のとおり。
先頭領域：
Apr 21 15:20:47 ... 4月21日15時20分47秒に記録された。
refirio kernel ... refirioサーバ。
FINAL_REJECT ... firewallコマンドによるデフォルトのラベル。（？）
MACレイヤ（L2）：
IN=eth0 ... NIC eth0へのアクセス。（？）
OUT= ... 例えば eth1 とあればNIC eth1からのアクセス。（？）
MAC=52:54:0d:00:23:10:00:1b:ed:b0:c1:00:08:00 ... refirioサーバのNICのMacアドレス。（？）
IPレイヤ（L3）：
SRC=122.4.199.68 ... ソースIPアドレス / 送信元アドレスは 122.4.199.68。 （中国。）
DST=153.121.33.84 ... デスティネーションIPアドレス / 送信先アドレスは 153.121.33.84 （refirio.net）
LEN=40 ... パケットの長さ。
TOS=0x00 ... IPヘッダ TOSフィールドの値。
PREC=0x00 ... IPヘッダ TOSフィールド内、PRECEDENCEの値。
TTL=50 ... IPヘッダ TTLの値。
ID=60580 ... IPヘッダ IDの値。
DF ... IPヘッダ Flag の DFビット(Don’t Fragment)が立っている場合。
PROTO=TCP ... プロトコル / TCP。
TCPレイヤ（L4）：
SPT=21667 ... ソースポート番号 / 送信ポート番号は21667。
DPT=2222 ... デスティネーションポート番号 / 送信ポート番号は2222。
WINDOW=39862 ... TCP Window。
RES=0x00 ... Reservedの値。
ACK RST ... Control Bitsのそれぞれに対応（URG、ACK、PSH、RST、SYN、FIN）。
URGP=0 ... Urgent Pointerの値。
■Control Bits（制御ビット）について
TCP/IPでコネクションを確立する時、終了するときに特定の制御ビットを送受信する。
例えば接続確立の際には以下のやりとりが行われる。3ステップによって行われるため、「3ウェイハンドシェイク」と呼ばれる。
1. クライアントからSYNパケットを送る。
2. サーバからACK+SYNパケットが返される。
3. クライアントからACKパケットを送ってコネクションを確立。
ポートが空いていなかった場合、2でサーバからACK+RSTが返されて終了する。
また、接続終了の際には以下のやりとりが行われる。
1. クライアントからFIN+ACKパケットを送る。
2. サーバからACKパケットが返される。
3. その後しばらくしてサーバからもFIN+ACKが送られてくる。
4. クライアントからACKパケットを送ってコネクションを終了。
制御ビットには以下がある。
URG ... urgent
ACK ... acknowledgement
PSH ... push
RST ... reset
SYN ... synchronize
FIN ... finish