web-dev-qa-db-ja.com

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

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

シナリオ

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

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

これは私の混乱が咲くところです。 conntrackは、何らかの方法で1337に確立された接続を取得できるセキュリティの欠陥を公開し（ワールドオープンであるため）、その接続を利用して、 SSHポート（またはそのことについては他のポート）？

securityiptablesiptcp
9
Dencker

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のようなツールを使用して、繰り返しアクセスが失敗したときに自動的にアクセスをブロックすることを検討してください。
8
BillThor

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にとってより重要な役割を果たすことに注意してください。）

2
countermode