SYNパケットのみをドロップすると、ファイアウォールのパフォーマンスが向上または低下しますか？
Ipfwを設定していますが、次のことが提案されました。TCPのSYNパケットのみをドロップするルールを作成すると、接続を確立できず、ファイアウォールは他のパケットを確認する必要がなくなります。
それは私には直感に反しているようです。指定されたポートですべての通信をブロックすると（パケット検査が少なくなる）、ファイアウォールのパフォーマンスが向上すると思います。どちらの方法でも接続を確立できないため、着信パケットの数は同じになります。
本当に違いはありますか？
編集：具体的な問題、somehostからのSSHのブロック：
ipfw add deny tcp from somehost to any port 22 via em0 tcpflags syn
vs.
ipfw add deny tcp from somehost to any port 22 via em0
Synパケットのみをドロップする目的がありますが、それは（主に）パフォーマンスではありません。これは、着信接続に適用されるが、発信接続のパケットを返さないデフォルトの拒否ルールを作成する簡単な方法です。このようなルール：
deny tcp from any to any in setup
（「setup」は「tcpflagssyn、！ack」の省略形であることに注意してください）は、すべての着信TCP接続（優先度の高いルールでは許可されていません）をブロックします。
代替手段（状態保持ルールを使用して発信接続での戻りパケットを許可する）には動的ルール（およびそれらに対するすべてのパケットの作成、管理、およびチェック）が含まれるため、実際にはこれにはパフォーマンスの議論がある可能性があります。パフォーマンスへの影響。
念のために言っておきますが、これは、特定の小さい番号のポート（例では22）をブロックするルールの場合には関係ありません。これは、1024未満のポートが発信接続に割り当てられないことを確信できるためです。
パケット検査が少ないと言ったように、指定されたポートへのすべてのトラフィックをグローバルにブロックする方が、特定の種類のトラフィックをブロックするよりも効果的であるようです。それは本当にあなたの意図に依存します。サービスを開いて利用できるようにしたいが、誰かがそのポートをSYNスキャンしたくない場合は、この種のアクティビティを検出する他の方法があります。サービスをまとめて利用したくない場合は、ポートを閉じてください。
「TCPのSYNパケットのみをドロップするルールを作成すると、接続を確立できず、ファイアウォールは他のパケットを調べる必要さえありません」と面白いと思います。
ええと...ファイアウォールがパケットをまったく見たくない場合は、すべて拒否してください！指定されたポートへのSYNパケットのログ（何らかの理由で）が必要な場合は、これを行うことができますが、正直に言って、その利点を確認しました。
SYNパケットをブロックし、パフォーマンスを向上させることを提案した人は、Net +で調査する必要があります。
すべてのパケットをポートにドロップする方が、synパケットだけをドロップするよりも速いというのは私のテストされていない理論です。理由は次のとおりです。
- 予期しないパケットは通常、TCPリセットまたはICMPポート到達不能メッセージを生成する可能性があります。SYNパケットのルールを書き込むだけで、他のパケットがOSにトリガーされます。
- ルールはまだ一致する必要があります。どちらのルールもポート22をチェックしていますが、2番目のルールにSYNがあるかどうかをもう一度チェックする必要があります。
効果的にするには、ファイアウォールはとにかくすべてのパケットを調べる必要があります。ステートフルファイアウォールとして、SYN以外のパケットを他のルールセットからの既存の許可されたフローに一致させようとすると、さらに時間がかかる場合があります。
ポートへのTCP接続をドロップする場合は、すべてのTCPパケットをポートにドロップします。