オンサイト診断でのネットワーク疎通手順

オンサイト(客先)で、セキュリティ診断を実施する際に、診断対象のサーバまで疎通確認をする際の手順を記す

無線と有線(準備編)

客先作業の場合、ほぼ有線LANであることは私の周りのローカルあるあるではないと思う。

そして、、、最近のノートPCには有線LANアダプタが付いていない場合が多い。

• 有線LANアダプタ付のノートPCを用意する
• USBの有線LANアダプタを用意する

客先のネットワークに接続する

• DHCPであれば、有線LANアダプタのデバイスをDHCPモードにしておく
• 固定のIPアドレスを配布された場合は、それらの設定値を有線LANアダプタのデバイスにセットする

までは、ネットワークケーブルを接続しないこと

(最近のOS(Windows)はいろいろと通信するかもしれないので、なるべく客先に余計なパケットを流さないようにするため)

疎通確認

結線の確認

ハブ、またはノートPC側のLANアダプタ側にランプが付いているかどうか。
付いていなければ、ケーブル内で断線しているかもしれないし、アダプタとケーブルがうまくつながっていないかもしれない。

こんな感じでランプが点灯する。
(この写真では1番と2番につながっているパソコンの電源が入っている状態)

自分のケーブルを挿した番号のランプが付かなければ、ケーブルがどこかで断線しているか、アダプタが壊れている

Windows側もこんな感じで「ケーブルが接続されていないよ」と表示してくれるけどね。

自分自身への確認

簡単なネットワーク図

まずは自分のOSで認識しているか・・・

cmd.exe

c:\>ipconfig /all

• 固定IPアドレスが適切にセットされているかどうか
• DHCPサーバからIPアドレスが配布されているか

cmd.exe

c:\>ping.exe -n 1 127.0.0.1
c:\>ping.exe -n 1 自身のPCのアドレス

これで、自分自身のPCの設定は正常動作しているところまで確認できた

同僚のPCへ

cmd.exe

c:\>ping.exe -n 1 同僚のPCのアドレス
c:\>arp -a

同僚のPCへping可能かどうか

できなかった場合は、arpコマンドで同僚のMACアドレスが取得できているかどうか確認する

同僚のPCがWindowsFireallでICMPをブロックしていても、MACアドレスは取得できているはず

できていなかった場合は、あなたの有線LANアダプタが壊れているか、デバイスドライバが壊れているか、スイッチハブが壊れているか

これで直近のスイッチハブが正常動作しているところまで確認できた

デフォルトゲートウェイへ

cmd.exe

c:\>ping.exe -n 1 デフォルトゲートウェイのアドレス
c:\>arp -a

デフォルトゲートウェイへping可能かどうか

できなかった場合は、arpコマンドでデフォルトゲートウェイのMACアドレスが取得できているかどうか確認する

これで直近のルータ(デフォルトゲートウェイ)まで正常動作しているところまで確認できた

診断対象のサーバへ1(DNS)

診断対象URLとしてIPアドレスではなくて、ホスト名(FQDN)名で指示されていた場合は、DNSサーバへの疎通確認が必要になる

cmd.exe

c:\>nslookup 診断対象のサーバのホスト名

IPアドレスに変換できていれば、DNSサーバまで正常確認できた

診断対象のサーバへ1

cmd.exe

c:\>ping.exe -n 1 診断対象のサーバのアドレス
c:\>arp -a

診断対象のサーバへping可能かどうか

診断対象のサーバがICMPを拒否している可能性があるので、できなくても落ち込まなくてよい

できなかった場合は、tracerouteコマンドで、どの経路までつながっているのか確認してみる

cmd.exe

c:\>tracert.exe -d 診断対象のサーバのアドレス

-d オプションは必ず付けること
リンク : Windows の traceroute の注意点

可能なら TCP Tracerouteがよいが、Windowsには定番がないんですよねー。
リンク : sTcpTraceRoute Manual
リンク : tracetcp.exe
リンク : nmapでもできるらしい

これで診断対象のサーバまでケーブルレベルで正常動作しているところまで確認できた

診断対象のサーバへ2

cmd.exe

c:\>nc.exe -nvv -z -w 2 診断対象のサーバのアドレス ポート番号
c:\>nc.exe -vv -z -w 2 診断対象のサーバのホスト名 ポート番号

(Windowsのnetcatでは-wオプションは効かないけど、なんとなく付けてみた)

これで、ポートの開閉、DNSの名前解決が正常かどうかまで確認できた

診断対象のサーバへ2(つながらない場合)

経路上のルータで、MACアドレス制限をしている場合もある

企業が使うルータには、MACアドレスを登録制にするなど、多機能な場合があるよ

診断対象のサーバへ3(SSL/TLS)

cmd.exe

c:\>openssl.exe s_client -host 診断対象のサーバのアドレス/ホスト名 -port ポート番号

または

cmd.exe

c:\>openssl.exe s_client -host 診断対象のサーバのアドレス/ホスト名 -port ポート番号 -servername 診断対象のサーバのホスト名

これで、SSL/TLSサーバの正常性確認までできた

診断対象のサーバへ4

Webブラウザを使って、画面が表示されれば、すべての確認は終了。ということになる

診断対象のサーバへ3(SSL/TLS)(つながらない場合)

過去の経験1

• HSTS有効
• 接続テストでHSTS有効化された
• プロキシを通したら、プロキシの証明書(診断対象のサーバとは別の証明書)となって、HSTSが発動してWebブラウザが接続拒否

過去の経験2

• SSL/TLSで接続できない
• opensslコマンドのエラーも意味不明
• Wiresharkで覗いてみると、TCP 3way-HandShake後に(SSL/TLSハンドシェイクを無視して)HTTPレスポンスメッセージが返ってきた
• その内容は「MACアドレス〇〇〇はアクセス禁止です」という内容
• 端末のMACアドレスが晒されているのはデフォルトゲートウェイまでなのは、ネットワークの基礎知識です
• つまり、TCPの3way-HandShake後にデフォルトゲートウェイが、診断対象サーバに成り代わって上記のHTTPレスポンスメッセージを返信して、診断対象サーバに成り代わってTCPのクローズ処理を実施していた

という顛末でした。

まとめ

Webアプリケーション脆弱性診断技術者であっても、ネットワークの知識、基礎的なネットワークコマンドの知識、Wiresharkで基礎的な通信プロトコルを読み解く技量は必要

以上