サーバーではなくファイアウォールによってブロックされたポート
私はインタビューでこの質問をされました、そして私は答えについて確信がありませんでした。質問は、「ファイアウォールの背後にある特定のWebサーバーで開いているポートを確認している場合、Webサーバーで閉じられているポートとファイアウォールでブロックされているポートをどのように確認できるかです。必要なツールを使用できます。 」.
私に与えられたヒントは、tracerouteで使用されている原則です。つまり、変動するTTL=値を使用してパケットを送信し、TTLを超えたメッセージが中間デバイスから返送されるようにするというアイデアです。
そのような目標を達成できるさまざまな方法は何ですか（ヒントの有無にかかわらず）。
この目標を達成するために設計されたFirewalkというツールがあります。それは少し古いですが、ネットワーキングはその時間にあまり変わっていないので、私はそれがまだ機能するはずだと思います。
記事 、 チュートリアル 、 プロジェクトのホームページ 。
この記事からリンクされているホワイトペーパーは http://packetfactory.openwall.net/projects/firewalk/firewalk-final.pdf にあります。
一般的なコンセプトは、ファイアウォールの後にホップがある限り、パケットのTTLを設定して、ファイアウォールを1ホップ超えて期限切れになり、ICMP応答が応答がない場合、ファイアウォールはパケットをブロックしました。応答があった場合、ファイアウォールはパケットをブロックしませんでした（つまり、ターゲットホストが存在する必要があります）。
ファイアウォールによって拒否されたアウトバウンドICMPメッセージ、別のファイアウォールがインバウンドまたはアウトバウンドトラフィックをブロックしている、一般的なパケット損失、ターゲットホストがダウンしているか、ターゲットの前のファイアウォールの後にホップがないなど、これがうまくいかない可能性がある方法があります。サーバー、しかしあなたがそれから肯定的な応答を得るならば、あなたはそれが正確であることを知っています。 Firewalkツールには、偽陰性を検出しようとするテクニックがあります。
送信するパケットのタイプやサイズなどのオプションをいじる必要があり、偽陰性を除外するために多くの異なるプローブを送信する必要がある場合でも、おそらくtracerouteで同様の結果を達成できます。ホワイトペーパーでは、例の中でtracerouteを幅広く使用しています。