はじめに
Linux におけるネットワークトラフィック分析とセキュアなリモートアクセスに関するこの実験へようこそ。ネットワークアクティビティの監視方法と通信の保護方法を理解することは、システム管理者、開発者、またはセキュリティ愛好家にとって不可欠なスキルです。
この実験では、強力なコマンドラインツールのスイートを実際に体験します。以下の方法を習得します。
netstatおよびその後継であるssを使用して、アクティブなネットワーク接続とリスニングサービスを検査する。tcpdumpを使用して、ライブネットワークパケットをキャプチャおよび分析する。sshを使用して、自身のマシンへのセキュアなリモート接続を確立する。digおよび DNSSEC を使用して、DNS レスポンスの整合性を検証する。
この実験の終わりには、これらの不可欠なネットワーキングユーティリティと、Linux システムの管理および保護におけるそれらの役割についての実践的な理解が得られるでしょう。
Netstat/SS によるアクティブなネットワーク接続の検査
このステップでは、システム上のアクティブなネットワーク接続とリスニングポートを表示する方法を学びます。これは、どのサービスが実行されており、ネットワーク経由でアクセス可能かを理解するために不可欠です。ここでは、一般的に使用される 2 つのツール、netstat と ss を使用します。
まず、古典的で広く知られているユーティリティである netstat を使用しましょう。netstat を含む net-tools パッケージは、実験のセットアップ中にインストールされています。
以下のコマンドを実行して、リスニング中の TCP (-t) および UDP (-u) ポートをすべて、名前解決を行わずに数値形式 (-n) で表示し、リスニングソケット (-l) のみに焦点を当てます。
netstat -tuln
以下のような出力が表示されるはずです。実験のために起動された SSH サーバー（ポート 22）と Python Web サーバー（ポート 8000）、およびポート 3001 と 3002 の追加サービスのエントリに注目してください。
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.11:37199 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
udp 0 0 127.0.0.11:60120 0.0.0.0:*
udp 0 0 0.0.0.0:3001 0.0.0.0:*
次に、netstat のモダンな代替である ss を使用しましょう。一般的に ss の方が高速で、より詳細な情報を提供します。コマンドとフラグは非常に似ています。
ss -tuln
出力の形式は若干異なりますが、ポート 22、3001、3002、8000 でリッスンしているサービスと、いくつかの内部 Docker サービスに関する同じ重要な情報が表示されます。
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.11:60120 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:3002 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:8000 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.11:37199 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
これらのコマンドを使用することで、システムのネットワークに面したサービスのスナップショットを迅速に取得できます。
Tcpdump によるローカルネットワークトラフィックのキャプチャ
このステップでは、強力なコマンドラインパケットアナライザーである tcpdump を使用して、ネットワークトラフィックをリアルタイムでキャプチャおよび検査します。これは、ネットワークの問題のデバッグやプロトコルの動作を理解する上で非常に役立ちます。
まず、トラフィックキャプチャに使用できるネットワークインターフェイスを確認しましょう。
sudo tcpdump -D
出力には、利用可能なインターフェイスがリストされます。lo は「ループバック」インターフェイスで、同じマシン内でのネットワーク通信（例：localhost への接続）に使用されます。プライマリネットワークインターフェイス eth1 を含むさまざまなインターフェイスが表示されます。
1.eth1 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]
ローカル Web サーバーへのリクエストを確認するために、ループバックインターフェイス (lo) でトラフィックをキャプチャします。これを行うには、2 つのターミナルが必要です。
現在のターミナルで、以下の tcpdump コマンドを実行します。これは lo インターフェイスをリッスンし (-i lo)、5 パケットをキャプチャしたら停止します (-c 5)。
sudo tcpdump -i lo -c 5
次に、ターミナルタブバーの + アイコンをクリックして新しいターミナルを開きます。この新しいターミナルで、curl を使用してローカル Web サーバーにリクエストを送信し、ネットワークトラフィックを生成します。
curl http://localhost:8000
最初のターミナルに戻ります。tcpdump が curl リクエストに関連するパケットをキャプチャしたことがわかります。出力は以下のようになり、TCP ハンドシェイクとデータ転送が表示されます。
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:57:14.158058 IP localhost.57272 > localhost.8000: Flags [S], seq 2025143228, win 65495, options [mss 65495,sackOK,TS val 1006286113 ecr 0,nop,wscale 7], length 0
14:57:14.158072 IP localhost.8000 > localhost.57272: Flags [S.], seq 403368374, ack 2025143229, win 65483, options [mss 65495,sackOK,TS val 1006286113 ecr 1006286113,nop,wscale 7], length 0
14:57:14.158083 IP localhost.57272 > localhost.8000: Flags [.], ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
14:57:14.158129 IP localhost.57272 > localhost.8000: Flags [P.], seq 1:79, ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 78
14:57:14.158133 IP localhost.8000 > localhost.57272: Flags [.], ack 79, win 511, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
5 packets captured
24 packets received by filter
0 packets dropped by kernel
ログに表示されるように、特定のトラフィックを生成せずに tcpdump を実行した場合、バックグラウンドの DNS クエリやその他のシステム通信が表示される可能性があることに注意してください。これは通常のシステム動作であり、積極的にブラウジングしていない場合でも、システムがさまざまなネットワーク通信を維持していることを示しています。
ライブネットワークトラフィックのキャプチャと表示に成功しました。
SSH を使用したセキュアなリモートアクセスを実証
このステップでは、セキュアなリモートアクセスに SSH (Secure Shell) を使用する方法を学びます。この実験では、パスワードを使用するよりも安全なキーベース認証を設定し、自身のマシン (localhost) にログインします。openssh-server は既に起動されています。
まず、SSH キーペア（秘密鍵と公開鍵）を生成する必要があります。ここでは、ビット長 2048 の RSA キーを作成します。-f フラグはキーを保存するファイルを指定し、-N "" はこの実験での利便性のためにパスフレーズを空に設定します。
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
このコマンドは、~/.ssh ディレクトリ内に id_rsa（秘密鍵）と id_rsa.pub（公開鍵）を作成します。
次に、自身のユーザーがこのキーを使用してログインできるようにするには、公開鍵を authorized_keys ファイルに追加する必要があります。このファイルには、ログインが許可されているすべての公開鍵がリストされます。
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
セキュリティのため、SSH は .ssh ディレクトリとそのファイルに対して厳格なパーミッションを要求します。それらが正しく設定されていることを確認しましょう。セットアップスクリプトは既にこれらのファイルを適切なパーミッションで作成していますが、これらのコマンドを知っておくことは良い習慣です。
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
これで全ての設定が完了しました。localhost へのセキュアな接続をテストできます。コマンドはリモートエンド（つまり、あなた自身のマシン）で echo "Hello from SSH" を実行し、その結果を表示します。
ssh labex@localhost 'echo "Hello from SSH"'
初めて接続する際には、ホストのフィンガープリントを確認するように求められる場合があります。yes と入力して Enter キーを押してください。その後、echo コマンドからの出力が表示されるはずです。
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Hello from SSH
SSH を使用して、セキュアなキーベース認証を設定し、正常に使用することができました。
Dig を使用した DNSSEC の名前解決を確認
このステップでは、dig (Domain Information Groper) を使用して DNS クエリを実行し、DNSSEC (DNS Security Extensions) について学びます。DNSSEC は、DNS データに暗号署名を追加することで、DNS スプーフィングから保護するのに役立ちます。
まず、labex.io に対して標準的な DNS クエリを実行し、その IP アドレスを確認しましょう。
dig labex.io
出力には、クエリの詳細と、最も重要な ANSWER SECTION に A レコード（IP アドレス）が表示されます。labex.io はロードバランシングのために複数の IP アドレスを持っていることに注意してください。
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9789
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 10 IN A 104.26.10.219
labex.io. 10 IN A 104.26.11.219
labex.io. 10 IN A 172.67.72.162
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:16 CST 2025
;; MSG SIZE rcvd: 85
次に、同じクエリを実行しますが、+dnssec オプションを追加して、DNS リゾルバに DNSSEC 関連のデータを提供するように要求します。
dig labex.io +dnssec
出力には、OPT PSEUDOSECTION に追加の DNSSEC 関連情報が含まれており、DNSSEC が要求されたこと（do フラグは「DNSSEC OK」を意味します）を示しています。ただし、flags セクションに ad（Authenticated Data）フラグが含まれていないことに注意してください。
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1042
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 5 IN A 172.67.72.162
labex.io. 5 IN A 104.26.11.219
labex.io. 5 IN A 104.26.10.219
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:21 CST 2025
;; MSG SIZE rcvd: 108
ad フラグが存在しないことは、DNSSEC 情報が要求されたものの、リゾルバが署名を検証できなかったか、またはドメインで DNSSEC が有効になっていないことを示しています。
DNSSEC を使用する別の有名なドメインである icann.org で試してみましょう。
dig icann.org +dnssec
ここでも、出力のヘッダーを確認します。
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> icann.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;icann.org. IN A
;; ANSWER SECTION:
icann.org. 10 IN A 192.0.43.7
;; Query time: 72 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:26 CST 2025
;; MSG SIZE rcvd: 77
前のクエリと同様に、応答には ad フラグがありません。これは、この環境の DNS リゾルバが DNSSEC 検証を実行していないことを示しています。これは、コンテナ化または仮想化された環境では一般的であり、DNS リゾルバが標準のシステムリゾルバとは異なる設定になっている場合があります。
まとめ
この実験を完了された皆さん、おめでとうございます！いくつかの必須の Linux ネットワークおよびセキュリティツールに関する実践的な経験を積むことができました。
この実験では、以下のことを学びました。
netstatおよびssを使用して、実行中のネットワークサービスや接続をリッスンしているサービスを調査する方法。tcpdumpを使用して特定のインターフェースでライブネットワークパケットをキャプチャし、トラフィックを分析する方法。- キーベース認証を使用して
sshを設定し、セキュアなリモートアクセスを実現する方法。 digを使用してドメインネームシステム（DNS）をクエリし、DNSSEC の概念を理解する方法。これには、DNSSEC 情報を要求する方法や結果の解釈方法が含まれます。
これらは、あらゆる Linux 環境の管理、トラブルシューティング、およびセキュリティ確保に不可欠な基本的なスキルです。これらの強力なツールが提供する多くのオプションを引き続き探求することをお勧めします。
