iptablesの動作を確認する方法と、便利なツールの紹介
ファイアーウォールを設置していても、正しく動作していなければ何の意味もありません。
そこでこのページでは、前回の投稿で設定したパケットフィルタリングが正しく動作しているか、テストする方法を解説します。
目次
ポートスキャンに利用するNmapの導入と使い方
実際にNmapを利用してポートの状態を確認する
Pingに利用するfpingの導入と使い方
Ping Flood対策のlimitモジュールをテスト
Smurf対策のテスト
SYN flood対策の確認
拒否IPからの接続をテスト
ハッシュリミットの動作をテスト
ポートスキャンに使うNmapの導入と使い方
まずポートスキャンで正しいポートが開放されているか調べます。
ポートスキャンにはnmapコマンドを使います。Linux内部でポートスキャンすると外部からの接続についての動作確認ができないので、外部から実行するためにwindows版をダウンロードして実行します。
「nmap公式サイト」の「Microsoft Windows binaries」にある「nmap-6.40-setup.exe（2013年11月現在）」をクリックしてインストールします。
インストール時に選択する項目がありますが全てチェックした状態でインストールしてください。
ちなみにLinuxでは以下のコマンドでインストールできます。 # yum install nmap 処理によっては大量のリソースを消費するため、ポートスキャンを実行する対象は自分の管理するサーバに限定してください。
インストールしたフォルダにある「zenmap.exe」を起動してください。「zenmap.exe」はnmapをGUIで実行できるソフトです。
コマンドを「コマンド」の項目に入力、「スキャン」ボタンをクリックすると実行。というシンプルな作りです。
nmapコマンドには多くのオプションがありますが、よく使うものは以下のものです。
nmapの書式
# nmap [オプション]
最もシンプルなチェック方法は以下のものです。
例）example.comをポートスキャン
# nmap example.com
（解説には何も指定しないと0~1660のTCPポートをスキャン。とありますが実際には1000程度スキャンするようです。）
ターゲットの指定方法
IPもしくはドメインで指定します。スペースを挟めば複数のホストを指定することもできます。
リストから抜き出す方法や、特定のホストを除外することもできます。
例）example.comと192.168.0.0をポートスキャン
# nmap example.com 192.168.0.0
よく使うオプション
nmapには大量のオプションがあるため、ここでは今回の動作確認に利用するオプションを紹介します。
| 指定 | 意味 | 解説 |
|---|---|---|
| -sT | TCPフルコネクトスキャン | 通常のTCP接続でポートスキャン |
| -sS | TCPハーフコネクトスキャン | TCPのスリーハンドシェイクの内、SYNだけ送信してACKを送信しない方法。接続が確立しないため相手のログに痕跡を残さないスキャンが可能（設定によりますが）。 |
| -sU | UDPスキャン | UDP接続でポートスキャン |
| -sP | pingスキャン | pingでサーバが動作しているかチェック |
| -sA | ACKスキャン | TCPのスリーハンドシェイクの内、ACKだけ送信する方法。通常いきなりACKを送信することはないため攻撃の兆候と取られる。
ファイアーウォールで正しくフィルタリングもしくは破棄されるかテストする際に利用する。 |
ポートスキャンの結果として表示される6つの状態
この結果を見てポートが開放されているか、閉じられているかを判断します。
| open | アプリケーションがTCPコネクションやUDPパケットをアクティブに受け入れている。 | |
|---|---|---|
| closed | アクセス可能(Nmapのプローブパケットを受信したり応答したりする)だが、そこで受信待機しているアプリケーションはない。 | |
| filtered | Nmapは、このポートが開いているかどうかを判別できない。 | |
| unfiltered | unfiltered状態とは、ポートにはアクセス可能だが、そのポートが開いているか閉じているかをNmapでは判別できないことを意味する。 | |
| open|filtered | Nmapがポートをこの状態に分類するのは、対象のポートが開いているかフィルタ処理されているかを判別できない場合である。 | |
| closed|filtered | この状態は、ポートが閉じているかフィルタ処理されているかを、Nmapが判断できない場合に用いられる。 | |
実際にNmapを利用してポートの状態を確認する
それでは実際にチェックをしていきます。まずは自分のサーバで以下のコマンドを打ち、どのサービスが、どのポートで待ち受けているかチェックしておきます。
# netstat -tlnp
NmapでTCPポートをスキャン
それぞれのサービスに対応したポートを把握したら、Nmapで外部からアクセスして確認します。
example.comの全ポート（1-65535）をTCPでアクセス可能かポートスキャン
# nmap -p 1-65535 example.com
「ホスト」ボタンを選択して、「ポート/ホスト」タブをクリックすると、応答のあったポートの一覧表示ができます。
緑の表示で状態にOpenと書かれたポートは正常に開放されています。
赤の表示で状態にClosedと書かれたポートはアクセス可能だが待ち受けているサービスがない状態です。
前のページでポート113をメールレスポンス向上のためREJECTとしたのを覚えているでしょうか？
このように実際にサービスを提供していなくてもファイアーウォールで拒否の応答を返すとClosedと表示されます。
NmapでUDPポートをスキャン
同じように全てのポートをUDPでスキャンしたいところですが、仕組み上UDPの検査には時間がかかるため、全ポートはチェックしません。
example.comのポート（1-1024？）をUDPでアクセス可能かポートスキャン
# nmap -sU example.com
もしくは使用しているポートを限定して調べると短時間で結果がわかります。
example.comの10022ポートをUDPでアクセス可能かポートスキャン
# nmap -sU -p 10022 example.com
ACKスキャンでステートフルパケットインスペクションのチェック
「-sA（ACKスキャン）」を使い、ステートフルパケットインスペクションが有効かチェックします。
iptablesのステートフルパケットインスペクションの設定で、新規の接続にも関わらずSYNフラグを持っていない接続は破棄という設定にしました。そのため、新規の接続にも関わらずACKでチェックした場合パケットが破棄されるはずです。
example.comのステートフルパケットインスペクションが有効かチェック
# nmap -sA example.com
結果に何も表示されなければ正常に破棄されています。
fpingを使ったパケットフィルタリングのテスト
ポートが正しくフィルタリングされていることを確認したら、続いてはそれぞれの拡張モジュールが正しく動作しているかテストします。まずはPing of Death攻撃の対策として導入したパケットの大きさで制御するlengthモジュールが正しく動作しているかテストします。
Windowsのコマンドプロンプトで使えるpingコマンドだとサイズを変更することはできません。そこでfpingをインストールして確認します。
fpingのインストール方法
1.「fpingの公式サイト」でダウンロードしてください。ドロップメニューでfpingを選択して「downloadボタン」をクリックします。
2.解凍して「x86フォルダ（OSが32bitの場合）」の中にある「Fping.exe」を「C:\Windows」にドラッグ。
あとはコマンドプロンプトを起動して、以下のようにPingを打ってください。
example.comに56バイトのpingを一回打つ
# fping example.com -n 1 -s 56
…
Reply[1] from 192.168.0.0: bytes=56 time=36.6 ms TTL=55
Ping statistics for 192.168.0.0:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 36.6 ms, Maximum = 36.6 ms, Average = 36.6 ms
「example.com」の部分はIPアドレスでも構いません。
「-n 1」でPingの回数を指定。
「-s 56」でサイズを56バイトに指定。実際にはICMPのヘッダ（8バイト）やTCPのヘッダー（20バイト）が付くので、84バイトになります。
「Packets: Sent = 1, Received = 1, Lost = 0 (0% loss)」となっているので、1つのパケットを送信して、応答が1度あり、応答がなくロスしたPingは無いことがわかります。
fpingの動作確認ができたところで、Pingのサイズを変えてテストします。
lengthモジュールでは85バイト以上のPingを破棄するように設定したので、今度は100バイトのPingを送信してみます。
# fping example.com -n 1 -s 100
…
Pinging 192.168.0.0 with 100 bytes of data every 1000 ms:
192.168.0.0: request timed out
Ping statistics for 192.168.0.0:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss)
Approximate round trip times in milli-seconds:
Minimum = 0.0 ms, Maximum = 0.0 ms, Average = 0.0 ms
「-s 100」で100バイトのPingを指定しています。
「Packets: Sent = 1, Received = 0, Lost = 1 (100% loss)」となっているので、1つのパケットを送信して、応答は0で、応答がないPingが1なのでロス率は100％となります。
これでlengthモジュールが正しく動作していることが確認できました。
Ping Flood対策のlimitモジュールをテスト
Ping Flood攻撃の対策として利用したlimitモジュールは、5回以上アクセスされると発動して、発動後は1秒に1度だけ許可するという設定でした。
windowsの通常のpingだと1秒間に1度の設定になっているため、fpingを利用して50ms秒に5回の高速Pingを送信してテストします。
# fping example.com -t 50 -n 5
Pinging 192.168.0.0 with 32 bytes of data every 50 ms:
Reply[1] from 192.168.0.0: bytes=32 time=7.9 ms TTL=55
Reply[2] from 192.168.0.0: bytes=32 time=9.5 ms TTL=55
Reply[3] from 192.168.0.0: bytes=32 time=7.5 ms TTL=55
Reply[4] from 192.168.0.0: bytes=32 time=9.0 ms TTL=55
192.168.0.0: request timed out
Ping statistics for 192.168.0.0:
Packets: Sent = 5, Received = 4, Lost = 1 (20% loss)
Approximate round trip times in milli-seconds:
Minimum = 7.5 ms, Maximum = 9.5 ms, Average = 8.5 ms
「-t 50」で50ms秒間隔。
「-n 5」で5回テストしています。
「Packets: Sent = 5, Received = 4, Lost = 1 (20% loss)」となっているので、、5つのパケットを送信して、応答は4で、応答がないPingが1なのでロス率は20％となります。
このテストでlimitモジュールが正しく動作していることがわかります。
試しに1秒に1度だとリミットが発動しないことを確認してください。
# fping example.com -t 1000 -n 5
Smurf攻撃と対策
ブロードキャストアドレスにPingを送信して応答がないことを確認します。
# fping 192.168.0.255 -n 1
またカーネルで禁止になっているかどうかを、サーバ側でもPingを打って確かめます。
# ping -b 192.168.0.255
SYN flood攻撃と対策
ツールを使ってSYN flood攻撃をテストすることは可能ですが、レンタルサーバで実行するのは、かなり黒よりのグレーなので、設定が有効か調べる程度にしておきます。
cat /proc/sys/net/ipv4/tcp_syncookies
「1」と表示されていればCookieが有効なのでTCPがハーフ・オープンの状態でもメモリが枯渇することはありません。
拒否IPからの接続をテスト
こればっかりは便利なツールが無いので、プロキシを利用するしかありません。
例えば中国からのアクセスを拒否する設定にしている場合は「プロキシサーバーリスト」で生きているプロキシを探してみてください。
プロキシの利用法は様々ありますが、Internet Explorerを使う方法が手間なしです。IEの設定で「インターネットオプション＞接続＞LANの設定」をクリックして、プロキシサーバの欄に入力して試してください。
他のサイトが正常に表示されるプロキシで、自分のサイトが表示されなければ正しく動作しています。
ハッシュリミットの動作をテスト
SSHのポートは以下の設定になっていました。
iptables -A INPUT -p tcp -m state --state NEW --dport 42424 -m hashlimit --hashlimit-burst 5 --hashlimit 1/h --hashlimit-mode srcip --hashlimit-htable-expire 3600000 --hashlimit-name ssh-limit -j ACCEPT_JP_FILTER
このままだとテストするには面倒な設定なので、以下の設定にします。
「1回アクセスするとリミットが発動。発動後5分間に1度だけ許可。」に変更します。
iptables -A INPUT -p tcp -m state --state NEW --dport 42424 -m hashlimit --hashlimit-burst 1 --hashlimit 5/m --hashlimit-mode srcip --hashlimit-htable-expire 3600000 --hashlimit-name ssh-limit -j ACCEPT_JP_FILTER
設定を変更したらTera Term等で1度ログイン後、すぐにもう1度ログインしなおしてください。すると2度目は接続できないはずです。
5分経つと再びログインできるようになっているので、再度ログインした後に元の設定に直しておいてください。
以上で動作テストは完了です。正しく動作していたでしょうか？動作していない場合は、スペルチェックや記述順序を確認してみてください。
続いてはrsyslogを利用してログファイルの振り分けと、ローテーションについて解説します。
と思いましたが、rsyslogについてまとめたら長くなったので、2つに分けました。
rsyslogの使い方を知りたい方は「障害報告・アラート表示・ログのデータベースへの出力と活躍するrsyslogの使い方」へ。
ログのローテーションについて知りたい方は「rsyslogを利用したログファイル作成と、logrotateを利用したログのローテーション」へアクセスしてください。