私はカーネル3.18.21とMIPSのいくつかのアプリケーションを含む組み込みLinuxシステムを実行しています。 Linuxでiptablesとip6tablesを実行すると、次のようになります。
iptables -A 入力 -p tcp --dport 80 -j 削除
ip6tables -A 入力 -p tcp --dport 80 -j 削除
httpにはtcpポート80が使用されます。その後、このLinuxサーバー（Webサーバーアプリケーションが実行されている）へのhttp接続が機能しなくなったことがわかりました。
しかし、次のようにnatstatコマンドを実行すると：
netstat -tulnネットワーク統計grepを聞く|
画面は次のとおりです。 （ポート80万抽出しました。）
tcp 0 0 :::80 :::* 聞く
これは、ポート80がまだ開いているという意味ですか？では、なぜhttpを使用してLinux上で実行されているWebサーバーにアクセスできないのですか？ （Webサーバープロセスがまだ実行中であることを確認して確認しました。）
ベストアンサー1
iptablesアプリケーションがTCPまたはUDPポートを開くことは禁止されていません（これによりアプリケーションが中断される可能性があります）。代わりに、着信パケットが実際のポートに到達するのをブロックします。発信トラフィックに適用すると、一致するパケットが実際に送信されない可能性があります。
を使用すると、iptables ... -j DROPルールに一致するすべてのパケットの処理が一時的に中断され、事実上応答なしにパケットが無視されます。正当なTCP接続の場合、これは通常、接続がタイムアウトするまで送信者を中断します。ただし、ホストはまだARP要求に応答する必要があるため、スキャナはまだホストの存在を検出し、ポートを「ファイアウォール」としてマークできます。
（スキャナが同じネットワークセグメントにない場合は、ARP応答を直接観察することはできませんが、ターゲットネットワークセグメントのルータがICMP「ホスト。到達不能」の接続試行に応答していることを確認して、ARP応答の有無を推測できます。あります。
「ホストに接続できません」エラーなし+ TCPリセット/ICMPなし「ポートに接続できません」=ポートがファイアウォールで保護される可能性が高いです。 )
使用すると、iptables ... -j REJECTルールに一致するすべてのパケットが処理されます。問題の宛先ポートが開いていないのと同じです。、ポートの実際の状態に関係なく。これにより、ファイアウォールなしで閉じたポートに接続しようとした場合と同様に、TCPリセットまたはICMPエラー応答パケットが元のパケットの送信者に送信されます。これにより、発信者は接続拒否を検出でき、接続の試行がより速く失敗する可能性があります。スキャナの場合、これらの結果は一般的な「閉じた」ポートと区別できないはずです。
送信者が送信元パケットの送信元IPアドレスを偽造する場合、応答は他のホストに対するサービス拒否攻撃の一部として乱用される可能性がありますが、最新のオペレーティングシステムはTCPリセット/ICMP転送速度および/または優先順位を下げます。エラーパケットはデフォルトで制限されているため、これは大きな問題ではありません。