私はこの規則が-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTかなり頻繁に適用されるのを見ます。私は専門家ではありませんが、この特定のパスが心配です。明らかにルールは受け入れます。みんな唯一の例外は、接続が確立または確立された接続に関連する必要があることです。
想像する
22サーバーLANまたはサブネットの他のポートから192.168.0.0/16プライマリSSHポートへの接続を許可します。SuperInsecureApp®ポートに何かを公開し1337、それをチェーンに追加しますINPUT。conntrackルールを受け入れ、ESTABLISHED次RELATEDのルールを追加しました。みんな源泉- チェーンポリシーは
DROP
したがって、デフォルトでは、設定はLANのSSH接続のみを許可する必要があり、世界中でポート1337の着信トラフィックを許可する必要があります。
これが私が混乱しているところです。conntrack人々がセキュリティの脆弱性を取得できるようにセキュリティの脆弱性が公開されていますか？接続設定1337（世界中に公開されているので）その後、その接続を使用してSSHポート（または他のポート）にアクセスしますか？
ベストアンサー1
私はESTABLISHEDとRELATEDトラフィックがあまりにもオープンであるとは思わない。 RELATEDは省略できますが、ESTABLISHEDは必ず許可する必要があります。両方のトラフィッククラスはconntrackステータスを使用します。
ESTABLISHED 他のルールによって接続が確認されました。これにより、一方向ルールの実装がはるかに簡単になりました。これにより、同じポートでのみ引き続き取引できます。
RELATED接続は他のルールを介しても確認されます。多くのプロトコルでは動作しません。言い換えれば、ルールの構成ははるかに簡単になります。また、適用時に正しい接続順序を保証します。これは実際にルールをより安全にします。これにより他のポートに接続できますが、そのポートはFTPデータ接続などの関連プロセスの一部にしかなりません。許可されるポートは、プロトコル固有のconntrackモジュールによって制御されます。
ESTABLISHED および RELATED 接続を許可すると、ファイアウォールで許可する新しい接続に集中できます。また、戻りトラフィックは許可しますが、新しい接続は許可しないルール違反を防ぎます。
ポート1337のプログラムは安全ではないと分類されているため、rootではなく専用のユーザーIDを使用してプログラムを実行する必要があります。これにより、誰かがアプリをハッキングし、強化されたアクセス権を取得した場合に発生する可能性があるダメージが制限されます。
ポート１３３７の接続はポート２２へのリモートアクセスには使用されないが、ポート１３３７への接続を使用してポート２２への接続をプロキシすることができる。
SSHが完全に保護されていることを確認したい場合があります。
- ファイアウォールの制限に加えて、ホスト.許可を使用してアクセスを制限できます。
- root アクセスを防止するか、少なくともキーの使用を要求し、authenticate_keys ファイルからアクセスを制限します。
- 監査ログインに失敗しました。ログスキャナは、異常なアクティビティに関する定期的なレポートを送信できます。
- 繰り返しアクセスが失敗したときに自動的にアクセスをブロックするには、fall2banなどのツールを使用することをお勧めします。