Linux の Traceroute について
Linux の Traceroute では、ポートを指定して、ネットワーク経路上で該当ポートを使用する通信が許可されているかどうかを確認することができます。
Traceroute とは
IP パケットの TTL*1を活用し、最初に TTL を 1 に設定して ICMP パケットを送信する。
1番目のルータが受け取った時点で TTL は1減算されるため、ルータは TTL の生存時間が過ぎたことを通知する”ICMP Time Exceeded (TYPE=11)"を自身の情報と共に返す。これを受けて、ホストは TTL を 2 にして送信、2台目のルータの情報を入手。これを繰り返すことで、目的のホストまでの経路情報を取得する。
参考:@IT
Traceroute の使い方
TCP 389番を使用して Traceroute をする場合
traceroute -T -p 389 100.64.1.90
UDP 53番を使用して Traceroute をする場合
traceroute -U -p 53 100.64.1.90
Traceroute の実行例
以下の環境で実際に試してみます。
NW 装置で TCP389 をブロックし、UDP53 を許可している場合、Traceroute の実行結果は以下となります。
Traceroute(TCP389)の結果
NW 装置でブロックしているため通信不可
[root@hostname ~]# traceroute -T -p 389 100.64.1.90 gateway (10.1.1.254) 0.910 ms 0.841 ms * * * *6 * gateway (10.1.1.254) 0.789 ms !X
Traceroute(UDP53)の結果
NW装置で許可しているため通信可
[root@hostname ~]# traceroute -U -p 53 100.64.1.90 traceroute to 100.64.1.90 (100.64.1.90), 30 hops max, 60 byte packets 1 gateway (10.1.1.254) 0.917 ms 1.570 ms 1.531 ms 2 100.64.1.90 (100.64.1.90) 2.856 ms * *
Tracerouteの留意事項
Traceroute(ポート指定)では、IP到達性があれば、応答を得ることができます。
例として、サーバが該当ポートを使用するサービスをリッスンしていなくても、応答を得ることができることから、Traceroute では、ネットワーク経路上や、宛先サーバで、該当ポートを使用した通信がブロックされていないことを確認できるだけで、サービスレベルの確認はできない点に留意が必要です。
Traceroute(TCP389)の結果
サーバで LDAP をリッスンしていないが、 NW 装置とサーバで ALL 許可しているため通信可
[root@hostname ~]# traceroute -T -p 389 100.64.1.90 traceroute to 100.64.1.90 (100.64.1.90), 30 hops max, 60 byte packets 1 gateway (10.1.1.254) 1.328 ms 1.744 ms * 6 * 100.64.1.90 (100.64.1.90) 1.445 ms 3.007 ms
サービスのアクティブ性確認
サービスのアクティブ性を確認するため、実際のサービス通信以外で確認する方法として、Telnet があります。Telnet でサービスポートを指定することで、サービスが該当ポートで、待ち受けているかの確認することが可能です。
Telnet(TCP389)の結果
サーバで LDAP をリッスンしている場合は、以下のとおりとなる。
telnet 100.64.1.90 389 Trying 100.64.1.90... Connected to 100.64.1.90. Escape character is '^]'.
サーバで LDAP をリッスンしていない場合は、以下のとおりとなる。
telnet 100.64.1.90 389 Trying 10.1.1.254... telnet: connect to address 100.64.1.90 : Connection refused
tcpdump によるパケットキャプチャ
サービスをリッスンしている場合
[root@hostname ~]# tcpdump port 389 -i ens34 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens34, link-type EN10MB (Ethernet), capture size 262144 bytes IP localhost.localdomain.57498 [root@hostname ~]# 100.64.1.90.ldap: Flags [S], seq 2076959109, win 29200, options [mss 1460,sackOK,TS val 1279295 ecr 0,nop,wscale 7], length 0 IP 100.64.1.90.ldap [root@hostname ~]# localhost.localdomain.57498: Flags [S.], seq 2434335086, ack 2076959110, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 1711531 ecr 1279295], length 0 IP localhost.localdomain.57498 [root@hostname ~]# 100.64.1.90.ldap: Flags [.], ack 1, win 229, options [nop,nop,TS val 1279296 ecr 1711531], length 0
サービスをリッスンしていない場合*2
[root@hostname ~]# tcpdump port 389 -i ens34 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens34, link-type EN10MB (Ethernet), capture size 262144 bytes IP localhost.localdomain.57502 [root@hostname ~]# 100.64.1.90.ldap: Flags [S], seq 3028605199, win 29200, options [mss 1460,sackOK,TS val 1695981 ecr 0,nop,wscale 7], length 0 IP 100.64.1.90.ldap [root@hostname ~]# localhost.localdomain.57502: Flags [R.], seq 0, ack 3028605200, win 0, length 0
RST について
前述のとおり、通常、サーバはリッスンしていないサービスに対するリクエストに応じてRSTを送信します。[RFC793, RFC1122, Ste94]
また、一部のファイアウォール等では不正と判断したパケットに対して、RSTを送信します。*3
RST をサーバが送信しているのか、経路上の NW が送信しているのかを見極める方法として、パケットキャプチャで送信元 IP や TTL を確認する方法が考えられます。
TTL が同じ値の場合はサーバ、TTL に差異がある場合は、NW 装置が RST を送信している可能性が高くなります。
以上