ARP poisoning (対策編)

セキュリティ

ARP poisoningに対しては現状で「とても効果的」という対策手法が見付からないので， 色々な対策を組み合わせて攻撃のハードルを上げるしかない．

ARP poisoningを防御する

まずはARP poisoning攻撃をさせない方法について考える．

不正なクライアントのネットワークへの参加を拒む

これが基本．

外部のPCをネットワークに接続する場合は VLAN などでセグメントをわける， あるいはネットワークへの接続に認証システムを使う． 無線LANを利用しているなら，ちゃんとAPをWPAで保護する． ローカルネット内のシステムはしっかり守り，侵入させない．

しかしたとえネットワークへの参加者を管理したところで， 正規のネットワーク参加者が攻撃を試みる可能性も残る． よって，この対策は有効ではあるけれども，十分ではない．

静的 ARP テーブルを用いる

ARP poisoningはIPアドレスに対応するイーサネットアドレスを動的に，かつ認証なしに解決するというARPプロトコルの問題であるとも言える． このため，あらかじめ管理者が信頼できる IP・イーサネットアドレスの対応関係を静的ARPテーブルとして与えておくことで，攻撃者がARPテーブルを汚染することを防御できる．

すでに説明したが，静的 ARP テーブルはファイルから読み込める． 例えば，次のようにIPアドレス "192.168.0.1" に対応する MAC アドレスを KURO-BOX に登録しておく．

KURO-BOX:~# cat /etc/ethers
00:30:13:77:D4:3A   192.168.0.1
                   
KURO-BOX:~# arp -f /etc/ethers

KURO-BOX:~# arp
Address         HWtype  HWaddress           Flags Mask       Iface
192.168.0.1     ether   00:30:13:77:D4:3A   CM               eth0

この状態で，KURO-BOX に対してarpspoofを実行し，192.168.0.1 になりすまそうとしてみる．

localhost:~# arpspoof -t kuro-box 192.168.0.1

しかし，KURO-BOX の ARP テーブルは変化せず，攻撃は失敗する．

KURO-BOX:~# arp
Address         HWtype  HWaddress           Flags Mask       Iface
192.168.0.1     ether   00:30:13:77:D4:3A   CM               eth0

ただ，管理の手間を考えると，本当にこの方法が効果的だとは言いにくい．

ARP poisoning を検知する

ARP poisoningを防止するのではなく，APR poisoning，あるいはそれを利用したスニッファを検知する手法について説明する．

arpwatch

arpwatchは正常時にIP <-> Etherアドレスの対応表を作成しておき，それが更新されたときに 管理者にメールを送る or snmp で通知する or ログに吐くなどするツールである． 静的ARPテーブルと違って攻撃を防ぐことはできないが，柔軟に運用できるメリットがある． arpwatchのコマンドラインオプションを紹介する．

  • -f <datafile> : 対応表の場所を指定する (デフォルトは /var/lib/arpwatch/arp.dat)
  • -i <interface> : インターフェースを指定する
  • -n <net>[/<width>] : 監視するネットワーク (+ネットマスク) を指定する
  • -r <savefile> : tcpdump ログからデータを読み込む

Debian版には特有のオプションがあるっぽい．

  • -s <path> : メール送信に使うプログラムを指定 (-odi オプションを取り，かつ stdin から入力を受け取るプログラムであれば代替可能．例えばメールではなくファイルに記録するスクリプトなども指定できる)
  • -m <address> : メール送信先を指定する
  • -u <username> : arpwatch の起動権限を に変更する．
  • -Q : メールによるレポート送信を止める
  • -z <net>/<mask> : 指定されたネットワークを監視しない (DHCP との併用時に便利)

arpwatchをKURO-BOX上で実際に動かしてみる． 最初はarp.datが空のため，通信を行なうたびに少しずつ IP <-> Ether の対応情報を書き込んで行く． この様子もメールや syslog で報告される．

Subject: new station eth0
From: arpwatch@hogehoge.com (Arpwatch KURO-BOX)
                                         
            hostname: <unknown>
          ip address: 192.168.0.1
           interface: eth0
    ethernet address: 0:30:13:77:d4:3a
     ethernet vendor: NEC Corporation
           timestamp: Thursday, March 23, 2006 4:13:02 +0900

上のメールは， 192.168.0.1 に対応するイーサネットアドレスを学習したという報告である． この状態で arpspoof -t Kuro-Box 192.168.0.1 を実行し， 192.168.0.1 を騙ろうとすると，次のようなメールが報告される．

Subject: changed ethernet address eth0
From: arpwatch@hogehoge.com (Arpwatch KURO-BOX)
                         
            hostname: <unknown>
          ip address: 192.168.0.1
           interface: eth0
    ethernet address: 8:0:46:b6:b:87
     ethernet vendor: Sony Corporation Ltd. [Sony]
old ethernet address: 0:30:13:77:d4:3a
 old ethernet vendor: NEC Corporation
           timestamp: Friday, March 24, 2006 23:53:44 +0900
  previous timestamp: Friday, March 24, 2006 23:31:49 +0900
               delta: 21 minutes

192.168.0.1 に対応するイーサネットアドレスが変更されたとの通知である． さらにこの後，本物の 192.168.0.1 と偽物の間で イーサネットアドレスが次々に flip flop する様子が報告される．

Subject: flip flop eth0
From: arpwatch@hogehoge.com (Arpwatch KURO-BOX)
                         
            hostname: <unknown>
          ip address: 192.168.0.1
           interface: eth0
    ethernet address: 0:30:13:77:d4:3a
     ethernet vendor: NEC Corporation
old ethernet address: 8:0:46:b6:b:87
 old ethernet vendor: Sony Corporation Ltd. [Sony]
           timestamp: Friday, March 24, 2006 23:57:57 +0900
  previous timestamp: Friday, March 24, 2006 23:57:56 +0900
               delta: 1 second

Subject: flip flop eth0
From: arpwatch@hogehoge.com (Arpwatch KURO-BOX)
                       
            hostname: <unknown>
          ip address: 192.168.0.1
           interface: eth0
    ethernet address: 8:0:46:b6:b:87
     ethernet vendor: Sony Corporation Ltd. [Sony]
old ethernet address: 0:30:13:77:d4:3a
 old ethernet vendor: NEC Corporation
           timestamp: Saturday, March 25, 2006 21:38:38 +0900
  previous timestamp: Saturday, March 25, 2006 21:31:48 +0900
               delta: 6 minutes

........

これにより，ARP poisoning の試みは露見する．

Snort (arpspoof プリプロセッサ)

ネットワークIDSのSnortにもARP poisoningの発生を検知するarpspoofプリプロセッサが用意されている． ただし今のところExperimentalな機能となっているため，使い勝手は微妙だ． arpspoof プリプロセッサの検知対象に関してはドキュメントに以下のように書かれている．

  1. Unicast ARP request
  2. Etherframe ARP mismatch (src)
  3. Etherframe ARP mismatch (dst)
  4. ARP cache overwrite attack

(1) は本来ブロードキャストされるべき ARP 要求がユニキャストされていることを示すもの， (2) と (3) はよくわからない， (4) が ARP キャッシュの上書き，つまり ARP poisoning の発生を検知するものである． 具体的には，(4) は事前に IP アドレスと MAC アドレスのペアを登録してもらい，その情報と矛盾するような ARP 応答を検知する．

試しにこのプリプロセッサを有効にしてみる． snort.conf に arpspoof プリプロセッサを有効にする設定と，IP <-> MAC アドレスのペアを与えておく．

preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.0.1 0:30:13:77:d4:3a \
    kuro-box 00:0D:0B:69:11:43

この状態で 192.168.0.1 のイーサネットアドレスを上書きするようにARP poisoning を仕掛けてみる． すると，Snortは以下のような検知アラートを生成する．

[**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**]
04/25-22:59:41.906352 
[**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**]
04/25-22:59:43.903969 
....

.... 非常に淡泊だ． Experimental なのだから仕方ないのかもしれない． あるいは僕が Snort の使い方をよくわかっていない所為かもしれない．

Snort の arpspoof プリプロセッサを arpwatch と比較すると， あらかじめ IP と MAC 対応表を静的に与える必要があるなど， 運用の柔軟性に欠ける部分がある． そのうえ検知情報も洗練されてない現状では，arpwatch ではなく あえて Snort を使うことのメリットはあまり無いと思われる．

余談だが，dsniff の arpspoof コマンドは不正な ARP 応答の他に ICMP redirect パケットも送信するため， このパケットを snort で検知することで arpspoof コマンドの使用を知ることが出来る． しかしこれは副作用的な検知であり，ARP poisoningそのものの検知とは関係ない．

スニファ検知ツール

スニファ検知用ツールを使う方法もある． 例えば PromiScan や AntiSniff が有名なようだ．

これらのツール，もともとはプロミスキャスNICの発見を目的として作られている． 一昔前はスニフといえば馬鹿ハブで接続されたネットワーク上で 動作するプロミスキャス NIC，というシナリオだったからだろう． しかし，NIC をプロミスキャスにする必要がないARP poisoningはそれではうまく検知できない． それどころか，PromiScan の手法に関するペーパーを読む限りでは，スイッチングハブ環境下でのプロミスキャス NIC の発見も出来なさそうだ．

ただ，詳しいところはわからないが，これらのツールも現在では色々と改良が加えられているようである． 例えば，MITMによってパケットが無駄に往復することによる遅延を検知する，という記述もあった． なかなか面白い．

他のレイヤでセキュリティを確保する

ネットワークの運用形態によっては，ARP poisoningの脅威が無視できないこともある． また，時としてあまり信頼できないネットワークに PC を繋げて作業せざるをえないこともあるだろう． IPSecを使ったネットワーク層での暗号化，SSL などのアプリケーション層の暗号化など，出来る限り異なるレイヤでの対策を常に心掛ける必要がある．