はじめに
スキャナーを使う前に、アドレス、名前、ネットワーク経路、サービスポートを区別する必要があります。これらは別々の観測であり、一つの層の成功は別の層の成功を証明しません。
この実習では、Kali 環境内にローカル DNS サーバーと Web サービスを提供します。ゲートウェイをスキャンしたり、公開ターゲットに依存したりせず、ネットワークを調べ、演習用の名前を解決し、TCP の待ち受けを確認します。
アドレス、経路、ループバックの到達性を調べる
このステップでは、Kali コンテナのネットワークを調べ、範囲を限定したローカルの接続経路をテストします。
準備済みのシェルに入り、ワークスペースを選びます。
kali
cd /home/labex/project
IP アドレスはネットワークのエンドポイントを識別します。インターフェースはシステムとネットワークの接続で、経路はアドレス宛てのトラフィックの行き先を示します。コンテナは独自のネットワーク環境を持つので、ホストの設定を想定せず、この環境を調べてください。
ip は Linux のネットワークを調べます。-brief はインターフェースのアドレスを簡潔に表示します。
ip -brief address
ループバックインターフェースの lo と、127.0.0.1 を探します。ループバックの通信は、このネットワーク環境内にとどまります。他のインターフェースやアドレスは異なる場合があります。/8 や /16 のようなプレフィックスはアドレスのネットワーク範囲を表し、サービスポートではありません。
経路を調べます。
ip route
default 項目があれば、より具体的な経路に一致しない場合に使われます。ゲートウェイのスキャンや経路の変更は不要です。
ping は到達性のプローブを送ります。-c 3 はプローブを 3 回に制限し、自動的に終了させます。
ping -c 3 127.0.0.1
応答と最後のパケット概要が表示されるはずです。正確な時間は変わります。ping の応答は、そのプローブに応答があったことを示し、特定の TCP サービスの待ち受けを確認するものではありません。
学習済みの出力のリダイレクトで、インターフェースの観測を保存します。
ip -brief address > interfaces.txt
cat interfaces.txt
保存した表示には、ループバックインターフェースとそのアドレスが含まれるはずです。
演習用 DNS サーバーで名前を解決する
このステップでは、ローカル DNS サーバーを使い、名前解決とサービスへの接続を区別します。
DNS は名前をレコードに変換します。A レコードは IPv4 アドレスを保持します。この実習では、127.0.0.1 のポート 5353 に DNS サーバーと、ローカル名 training-web.test を提供します。公開 DNS サービスは不要です。
dig は DNS に問い合わせます。@127.0.0.1 はサーバー、-p 5353 は既定とは異なる DNS ポート、次の引数は名前を選び、A は IPv4 アドレスレコードを要求します。
dig @127.0.0.1 -p 5353 training-web.test A
応答欄には名前とアドレス 127.0.0.1 が示されるはずです。DNS もポートを使います。ここでのポート 5353 は演習用 DNS サーバーのもので、応答の名前が示す Web サービスのポートではありません。
表示オプション +short は応答データだけを表示します。この小さな結果を保存します。
dig @127.0.0.1 -p 5353 +short training-web.test A > dns-answer.txt
cat dns-answer.txt
想定される出力：
127.0.0.1
システムの名前検索では、直接 DNS に問い合わせる代わりにローカルファイルを使うこともあります。getent hosts は、システムに設定されたホスト名検索に名前を問い合わせます。
getent hosts localhost
出力は localhost とループバックアドレスを関連付けます。IPv6 の ::1 の場合もあります。これは、dig で提供された DNS サーバーを明示的に問い合わせることとは異なります。名前解決に成功すればアドレスは得られますが、必要なサービスがそこで利用できるか、さらに調べる必要があります。
待ち受けを調べ、TCP ポートをテストする
このステップでは、アドレスと、特定のトランスポートプロトコルおよびサービスポートを結び付けます。
ポートは、アドレス上のトランスポートのエンドポイントを識別します。TCP は接続を確立し、UDP は同じ接続ハンドシェイクなしでデータグラムを送ります。ポート番号だけでは、どのアプリケーションや脆弱性があるかは証明できません。
ss はソケット情報を表示します。-l は待ち受けソケット、-t は TCP を選び、-n はアドレスとポート番号を数値のまま表示します。
ss -ltn
ローカルエンドポイント 127.0.0.1:8080 を探します。提供された演習用 Web サービスのものです。このアドレスはコンテナ内のループバックに限定します。-t の代わりに -u で UDP ソケットを別に調べます。
ss -lun
演習用 DNS エンドポイントはポート 5353 を使います。TCP と UDP は別のポート空間を持ち、同じ番号を両方のプロトコルで使えます。
演習サービスの TCP 待ち受け行だけを保存します。パターンにはポートの前のコロンと、長い番号と区別する末尾の空白を含めます。
ss -ltn | grep ':8080 ' > service-listener.txt
cat service-listener.txt
行には LISTEN と 127.0.0.1:8080 があるはずです。間隔やキューの値は異なる場合があります。
Ncat は、アプリケーションデータを送らずに TCP 接続をテストできます。-v は状態を表示し、-z は対話型のデータセッションの代わりに接続確認を要求します。
ncat -vz 127.0.0.1 8080
状態には接続成功が表示されるはずです。これは選んだ TCP ポートが今接続を受け付ける証拠で、まだ HTTP 応答は検証しません。HTTP 自体は後の実習で調べます。
まとめ
インターフェースと経路を調べ、回数を限定した到達性テストを送り、ローカル DNS に問い合わせ、TCP と UDP の待ち受けを調べ、一つの TCP 接続をテストしました。名前解決やネットワーク到達性の成功と、アプリケーションレベルの動作を区別しました。
