攻撃から防御するための安全な iptables 設定のヒント。 （クライアント側！）

さまざまな意見があることは承知していますが、ネットワークとセキュリティについて本当に知っている人々の主な態度の 1 つは、これらの iptables/sysctl ルールのほとんどは冗長であり、ユーザーとネットワークに損害を与えないということです。理由もなく標準的な行動を破ったとして、あなたを積極的に批判する人もいます。いくつかの例:

• 標準的な TCP/IP の動作は、ピアが何が起こっているかについて何らかのヒントを得るために拒否することです。誰かが URL を間違って入力したか、管理者がホストを数えているか、または誰かがゲーム サーバーに接続しようとして間違ったポートを入力した可能性があります。 DROP を使用すると、あいまいで煩わしいタイムアウトしか発生しません。

• 無効または不正なパケットをドロップする必要はありません。これらの攻撃はすべて 10 年前のものです。 Linux カーネル開発者は、どの種類のパケットが有効でどれが無効かに関して、あなたよりもはるかに最新です。 「将来の欠陥についてはどうですか」と主張する人もいるかもしれません。では、将来の欠陥が iptables TCP パーサーではなく TCP ハンドラーにあることをどうやって知ることができますか?

• ほとんどの sysctl 設定はデフォルトです。そうでない場合は、通常、何らかの理由があります。たとえば、リダイレクトの送信を無効にするのはなぜですか?自動的に反応 ("accept_redirects", default=0) することはないとしても、私のルーティングが悪いことをピアから通知されると非常に便利です。

• log_martians やその他のロギング ルールを使用して、/var/log にもクォータがあることを願っています。そうしないと、ディスクをリモートでいっぱいにして、通常はサービスやアプリを停止させるのがとても楽しくなります。さらに、ロギングにレート制限を使用する必要があります。そうしないと、誰かがクォータをいっぱいにして、auth.log などで SSH パスワードのブルート フォース試行を確認できないようにする必要があります。それらのログを実際にデスクトップで読んでいますか?ログチェックをお勧めします。

• ICMP をブロックしているようです。前述の DHCP の問題とは別に、これにより PMTU の検出も妨げられます。 PMTUD がないと、DSL 接続またはその他のネットワーク設定のある場所でシステムを使用すると、奇妙な動作が発生します。一部のパケットは破棄されるだけで、その理由は誰も教えてくれません.

• アウトバウンド パケットのフィルタリングは、わかりにくいものです。自分を信用していませんか？通常、信頼できないプログラムは実行しないでください。一般的なオペレーティング システムでは、盗聴や他のプログラムのデータの操作 (キャッシュ タイミング攻撃など) からこれらのプログラムを隔離することはほとんどできません。

• NEW パケットには SYN が必要です。これは、iptables のそれぞれの状態がすでにタイムアウトした後に TCP 接続が継続されると、壊れます。デフォルトのタイムアウトが何であるかはわかりませんが、何人かの netfilter の人がそれについて警告しました.

では、いつデスクトップにファイアウォールを設置する必要があるのでしょうか?

• ニュースに特定の攻撃があり、現在の OS またはサーバーが脆弱であり、推奨される迅速な修正の 1 つがファイアウォール ルールである場合。

• 安全な構成を許可しない特定のサービスを実行する必要があります。ほとんどはそうであり、残りは安全な代替物に置き換えるのが最善です.

• デスクトップ上に複数の VM やインターフェイスを備えた、より複雑なネットワークがあります。

ネットワーク セキュリティの最も重要なツールは、システム アップデートです。次に、実行中のサービスを見つけて確認するために使用する netstat と nmap があります。次に、不要なものを無効にするか、127.0.0.1 に制限します。

ここまで読んだ場合のボーナス:パケットは ESTABLISHED、RELATED、または NEW のいずれかであり、それ以外はすべてドロップします。 SYN のみが設定されていない限り、NEW もドロップします。 ESTABLISHED,RELATED はフラグをチェックしているように見えるため、これによりすべての --tcp-flags ルールと -f ルールが冗長になります。 OUTPUT についても同じですが、とにかく OUTPUT に対して ACCEPT されるパケットがないため、おそらく問題にはなりません。

信頼できるネットワーク内のデバイスと DMZ 内のデバイスに対して、これらの部分を同じルールセットにする際には注意が必要です。そこで定義したルールを使用することで、IP が使用中かどうかを尋ねる DHCP サーバー (ICMP エコー) に応答しなくなります。これにより、アドレスが重複する可能性があります。

各シナリオに適用する 2 つの異なるルール セットを作成します。上記のようなものが DMZ マシンの適切なベースラインですが、一般的な LAN ではいくつかの課題が生じます。

また、martians、アウトバウンド ドロップ、インバウンド ドロップ接続などにログを追加することを強くお勧めします。これはトラブルシューティングに不可欠であり、SIEM が使用するより有用なデータになる可能性があります。

ppp 経由でインターネットに直接接続されているクライアント PC の場合、次のルールセットが適切な出発点です:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -j REJECT

<オール>

内部ローカル インターフェースのすべてを許可します。

送信したパケットに対する応答であるすべてのパケットを許可します。これには、TCP 接続内のパケット、小さな DNS クエリなどの UDP パケットへの応答が含まれます。古いスタイルの暗号化されていない FTP プロトコルの場合、ip_conntrack_ftp がロードされていると仮定すると、これにはデータ接続が含まれます

外部からの TCP 接続を開こうとする試みをすべて拒否する

すべての初期 (応答なし) udp パケットを拒否します。

または、最後の 2 つのルールで -j DROP を使用できます。このトピックに関する議論については、ICMP エラーで IP パケットを拒否するか、単にドロップするかを参照してください。