iptables内のすべてのソースに対してRELATED、ESTABLISHEDを受け入れると、「オープンすぎる」と見なされますか？

ルールが-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT適用されるのをよく見ました。私は専門家ではありませんが、その特定の行は私に関係しています。接続が確立されているか、確立された接続に関連している必要があることを除いて、ルールがすべてのトラフィックを許可していることは明らかです。

シナリオ

• 22サブネット内のサーバーLANなどから、デフォルトのSSHポートへの接続を許可します192.168.0.0/16。
• SuperInsecureApp®ポート1337に何かを公開します。これをINPUTチェーンに追加します。
• すべてのソースからconntrack受け入れESTABLISHED、受け入れるルールを追加しましたRELATED
• チェーンポリシーは DROP

したがって、基本的にその構成では、LANからのSSH接続のみを許可し、世界からのポート1337での受信トラフィックを許可します。

これは私の混乱が咲くところです。でしょうconntrackどのような方法で1を取得できるようになり、セキュリティ上の欠陥公開確立された接続（それが世界のオープン以来）1337上に、その後、SSHポート（またはそのことについては、他のポート）へのアクセスを得るために、その接続を利用しますか？

ESTABLISHEDとRELATEDのトラフィックがあまりにもオープンであるとは考えません。RELATEDを省略できる場合もありますが、ESTABLISHEDは必ず許可する必要があります。これらのトラフィックカテゴリはどちらもconntrack状態を使用します。

ESTABLISHED接続はすでに別のルールによって検証されています。これにより、単方向ルールの実装がはるかに簡単になります。これにより、同じポートでのみトランザクションを続行できます。

RELATED接続も別のルールによって検証されます。それらは多くのプロトコルには適用されません。繰り返しになりますが、ルールの設定がはるかに簡単になります。また、適用される接続の適切なシーケンスを保証します。これにより、実際にルールがより安全になります。これにより、別のポートに接続することが可能になる場合がありますが、そのポートはFTPデータ接続のような関連プロセスの一部である必要があります。どのポートが許可されるかは、プロトコル固有のconntrackモジュールによって制御されます。

ESTABLISHEDおよびRELATED接続を許可することにより、ファイアウォールが受け入れる新しい接続に集中できます。また、リターントラフィックを許可することを目的とした、新しい接続を許可する違反ルールも回避します。

ポート1337のプログラムを安全でないと分類した場合、専用の非rootユーザーIDを使用してプログラムを開始する必要があります。これにより、アプリケーションをクラックしてアクセスを強化した場合に、ユーザーが受ける可能性のある損害が制限されます。

ポート1337への接続を使用してリモートでポート22にアクセスできる可能性はほとんどありませんが、ポート1337への接続を使用してポート22への接続をプロキシできる可能性があります。

SSHのセキュリティを徹底的に保護したい場合があります。

• ファイアウォールの制限に加えて、hosts.allowを使用してアクセスを制限します。
• rootアクセスを防止するか、少なくともキーの使用を要求し、authorized_keysファイルでのアクセスを制限します。
• ログイン失敗の監査。ログスキャナーは、異常なアクティビティの定期的なレポートを送信できます。
• fail2banなどのツールを使用して、繰り返しアクセスが失敗したときに自動的にアクセスをブロックすることを検討してください。

ESTABLISHEDおよびRELATEDは、「ステートフル」パケットフィルタリングの機能です。フィルタリングは、静的ルールセットだけでなく、パケットが考慮されるコンテキストにも依存します。接続を機能させるにはESTABLISHEDが必要であり、関連するICMPメッセージにはRELATEDが必要です。ステートフルフィルタリングにより、静的な「ステートレス」ルールと比較してより正確にフィルタリングできます。

最初にESTABLISHEDを見てみましょう。たとえば、ポート22のTCPについて考えます。イニシエータ（クライアント）がにを送信SYNしserverIPaddr:22ます。サーバーはSYN+ACKクライアントに戻ります。今度はクライアントがを送信する番ACKです。「一致」のみACKが受け入れられるように、サーバー上のフィルタリングルールはどのように見えるべきですか？一般的なステートレスルールは次のようになります。

-A INPUT --proto tcp --port 22 -j ACCEPT

これは、対応するステートフルなルールよりもリベラルです。ステートレスルールは、任意のTCPセグメントを許可します。たとえばACK、FIN最初に接続を確立していなくてもかまいません。ポートスキャナーは、OSフィンガープリントのこの種の動作を利用できます。

次に、RELATEDを見てみましょう。これは、ICMPメッセージ、主にエラーメッセージに使用されます。たとえば、サーバーからクライアントへのパケットがドロップされると、エラーメッセージがサーバーに送信されます。このエラーメッセージは、以前に確立された接続に「関連」しています。RELATEDルールがない場合は、一般に（コンテキストなしで）着信エラーメッセージを許可するか、多くのサイトではカスタムであるように、ICMPを完全に削除して、トランスポート層でタイムアウトを待つ必要があります。（これはIPv6にとっては悪い考えです。ICMPv6は、IPレガシー用のICMPよりもIPv6にとってより重要な役割を果たすことに注意してください。）