2/2 IDSとIPSの遮断の違い(準備編)

かなり長編になるが、得たものは大きい

■背景

セスぺ本いわく

・IDSの遮断方法は検知後にクライアントとサーバの両方にRSTパケットを送ることで

　TCP接続を遮断すると書いてあった

　てことは接続初めのパケットはサーバに届いている？

・IPSのインラインでの遮断方法は、検知初めのパケットそのものを遮断しサーバに届かないようにする

　てことは検知後にクライアントにはRSTも届いていない？

たまにreset-both的なアクションをとるようなIDSもあるがそういうことなのか

ちなみになぜreset-serverがある？クライアントにrstを送らないことのメリットがある？

やりたいこと

snortでrejectとdrop?の2つくらいあったけど、上記のような違いで通信を遮断しているのか確かめたい

■準備

この実験では下記のホストと材料を使用する

Webサーバ側 (192.168.179.10)

・Snort

・iptables

・tcpdump

Kali Linux側 (192.168.179.44)

・Wireshark

・Nmap

・Burp suite

なんか今までやってきたことを存分に活かしている気がする

なんかわくわくする

・Webサーバ側

IDSには以前に導入したSnortを使用する

シグネチャの例としてsnortに、NmapのUser-Agentを含む場合に遮断するルールを追加する

ちなみにNmapのUser-Agentはこれ

User-Agent: Mozilla/5.0 (compatible; Nmap Scripting Engine; hxxps://nmap.org/book/nse.html

ルールは/etc/snort/rules/local.rulesファイルに下記を追加

reject tcp any any -> 192.168.179.10 80 (msg: "Nmap Access to port 80"; content:"Nmap"; sid:1000010; rev:1; )

とりあえずHTTPリクエストに「Nmap」が含まれる場合は遮断することにする

snortを起動 (-A consoleでコンソール出力させる)

# snort -c /etc/snort/snort.conf -A console

そしてポート80宛の通信が通るようにiptablesでポートをあける

# iptables -I INPUT -p tcp --dport 80 -j ACCEPT

さらにWebサーバ側でのパケットを見るためにtcpdumpも起動

# tcpdump port 80

ちなみにRSTパケットのみに絞りたければこう

# tcpdump 'tcp[13] & tcp-rst != 0'

Webサーバ側はこれで準備おk

・Kali Linux側

こちらではWiresharkが使えるので、これでパケットを確認する

キャプチャ開始後に下記フィルタを設定

(http) || (tcp.flags.reset == 1)

これで

１. HTTP通信

２. RSTパケット

のいずれかを確認することができる

NmapとBrup Suiteは実際にリクエストを送る際に使用する

Kali Linux側の準備はこれで終了

準備だけでこれだけ書いてしまったので実験編に続く

2/2 IDSとIPSの遮断の違い(実験編)その1 - akkietech’s diary