☰

ベストプラクティス：SSHのiptablesファイアウォールルールの適用

tag-icon • tag-icon rhel iptables firewall
ベストプラクティス：SSHのiptablesファイアウォールルールの適用

QA環境で使用する必要がありますiptables。リモートで変更する必要があります。一部の変更には、少数のSSHネットワークの無効化も含まれます。

SSH何らかの理由でサービスがブロックされた場合、ホストを再起動せずにアクセスを復元できるようにするためのベストプラクティスは何ですか？

私が計画しているいくつかの点は次のとおりです。

chkconfig iptables off

これは、ホストを再起動する必要がないため、iptables起動が失敗するのを防ぐためです。

しかし、これはホストを再起動するときにホストを再起動せずに回復を可能にする何かを探しています。ところで、consoleサーバーでは機能しません。

どんな提案がありますか？

答え1

それがiptables-apply目的です。 ~からマニュアルページ:

iptables-apply will  try  to  apply  a  new  rulesfile  (as  output  by
   iptables-save,  read by iptables-restore) or run a command to configure
   iptables and then prompt the user whether the changes are okay. If  the
   new  iptables  rules  cut the existing connection, the user will not be
   able to answer affirmatively. In this case, the script  rolls  back  to
   the previous working iptables rules after the timeout expires.

デフォルトのタイムアウトは10秒です。この時間が短すぎると、--timeout 3030秒後に確認が受信されない場合は、ルールをリセットするように変更できます。

答え2

INPUTこのような作業に対して私が一般的に取るアプローチは、既存の管理接続を明示的に許可するチェーンの先頭に安全装置ルールがあることを確認することです。これにより、接続をブロックできる後続のルールが現在のルールに影響を与えません。すべてのルールを作成した後、許可する必要がある2番目の接続でテストしましたが、これは安全装置のルールと一致しません。機能している場合は、元のセッションの接続を安全に切断し、緊急安全ルールを削除できることを知っています。

たとえば、192.168.0.0/16（192.168.2.0/24を除く）でSSHを許可しようとしていて、現在192.168.22.22でサーバーに接続しているとします。タイプミスを防ぐには、次のようにルールを設定できます。

iptables -I INPUT -p tcp -s 192.168.22.22  --dport 22 -j ACCEPT
iptables -I INPUT -p tcp                   --dport 22 -j LOG
iptables -A INPUT -p tcp -s 192.168.2.0/24 --dport 22 -j DROP
iptables -A INPUT -p tcp -s 192.168.0.0/16 --dport 22 -j ACCEPT

この場合、最初のルールを-Iチェーンの先頭に挿入し、チェーンの最後に別のルールを追加するように-A追加します。あなたの規則はこれより複雑になるかもしれませんが、重要なのは安全装置の規則が最優先であることを確認することです。これにより、誤って2行目に192.168.22.0/24と入力しても、安全装置の行が最初に一致するため、アクセスが維持されます。

192.168.0.0/16と192.168.22.22または192.168.2.0/24の間で接続を試みてルールをテストします。結果は何でも記録する必要があります/var/log/kern.log。接続が失敗した場合は、追加の作業が必要であることがわかります。また、ログは失敗の原因を特定するのに役立ちます。

テストが成功したら、緊急安全ルールを安全に削除できます。

iptables -D INPUT -p tcp -s 192.168.22.22 --dport 22 -j ACCEPT

関連情報