2/2 IDSとIPSの遮断の違い(実験編)その3

■実験3
では、準備編で書いていた内容
・IDSの遮断方法は検知後にクライアントとサーバの両方にRSTパケットを送ることで
　TCP接続を遮断すると書いてあった
　てことは接続初めのパケットはサーバに届いている？

これがyesかnoかを確かめる

リクエストの送り方は、実験その2でもやったようにBurp Suiteで改ざんしたリクエストを送る

は、途中からめんどくさくなったので
pythonであらかじめUser-AgentをセットしたHTTPリクエストを
送ることにした

import urllib2
url = "http://192.168.179.10"
agent = "Nmap Scanner"
req = urllib2.Request(url)
req.add_header("User-Agent", agent)
try:
    res = urllib2.urlopen(req)
except:
    pirint("request failed")

これで簡単に送れる
これでSnortを有効にした場合、"request failed"が返ってくる

そしてWebサーバ側のtcpumpで
・ポート80宛てのリクエスト
・RSTパケット
の2つをキャプチャするように絞る
かつ「-A」オプションでASCII表示する
つまりリクエストとレスポンスの中身も見えるようにする

# tcpdump -A 'tcp[13] & tcp-rst != 0' or 'port 80'

すると出力結果流れとしてはこんな感じだった

kaliから80宛てにsynを受信
↓
kaliからNmap Scannerを含むリクエストを受信
(予想通り)
↓
kaliのIPからRSTパケットを受信
(予想通り)
↓
Webサーバがhtmlページをkaliに送信
(想定外)
↓
kaliがRSTパケットを送信

■考察
「接続初めのパケットはサーバに届いている？」の答えはyesでした

なのでDoS系のリクエストを受信した場合は
IDSで遮断設定してても影響が発生する可能性があると思う
そしてこれは別の機会に確かめてみたい
(コンピュターハイジャッキングのBOFの手法が使えるかな)

そして想定外の部分について
RSTパケットを受信していてもWebサーバは一旦レスポンスを返そうとしているのがわかる
これはRSTパケットが追いつかなかったからなのか

試しにKali側でもtcpdumpで同じフィルタ条件で確かめてみた

ブラウザやpythonでリクエストを送った時はレスポンスが受信できていないが
tcpdumpで出力してみると

なんとしっかりレスポンスのパケットが返ってきているではありませんか！！！！

これは意外、驚き

攻撃側はtcpdump等のキャプチャツールでパケットを見ていれば
例えばSQLインジェクションを狙った攻撃でも
ブラウザやスクリプトではレスポンスを確認でいなくても
パケットキャプチャレベルであれば確認できると考えられる

これにより、いかにIDSの遮断機能というのは
あくまで補助的な機能でしかない
ということが分かった

その4につづく
2/2 IDSとIPSの遮断の違い(実験編)その4 - akkietech’s diary