Web サーバーを DMZ に配置し、80 と 443 を除くすべてのポートへのインバウンド トラフィックをブロックする必要性を理解しています。また、サーバーが侵害された場合に備えて、ほとんどのアウトバウンド トラフィックもブロックする必要がある理由もわかります。
しかし、ポート 80 経由のアウトバウンド HTTP トラフィックをブロックする必要があるでしょうか? もしそうなら、なぜですか？最近の多くの Web アプリケーションは、外部 Web サービスおよび API からのデータの送信/取得に依存しているため、ポート 80 を介したアウトバウンド トラフィックをブロックすると、この機能が妨げられます。これを正当化するのに十分有効なセキュリティ上の懸念はありますか?
私が考えられる唯一の理由は、あなたのマシンが何らかの形でリモートから侵害された場合、ポート 80 で別の Web サイトに DDoS 攻撃を行うことができないということです。
それをブロックするのではなく、抑制します。iptables -m 制限を使用します。
外部 Web サービスを呼び出す Web アプリがいくつかあるので、出力 HTTP トラフィックをブロックするのはお勧めできません。セキュリティに関心がある場合は、ブロックして特定の宛先のみを許可できます。
SQL のバージョンによっては、SQL Server 2005 で証明書認証のタイムアウトの問題が発生する可能性があります。
まず、解決策の少なくとも一部として、「ブロックするのではなく、スロットルする。iptables -m limit を使用する」というスロットリングに関する @vartec に同意します。
ただし、ポート 80 アウトバウンドを常にブロックしない別の理由を提供できます。自動セキュリティ更新を有効にしている場合、サーバーはポート 80 経由で PPA にアクセスしてセキュリティ更新を開始できません。したがって、自動セキュリティ更新が設定されている場合、それらは実行されません。ubuntu では、14.04 LTS で次のように自動セキュリティ更新が有効になっています。
sudo apt-get install unattended-upgrades update-notifier-common && \
sudo dpkg-reconfigure -plow unattended-upgrades
(then select "YES")
より適切なソリューションは、ポートを自動的に開く ansible スクリプトです。AWS にいる場合は、iptables に加えて、CLI を介して AWS セキュリティ グループ ルールを変更することもできます。ステルス ボックスによって開始された AWS CLI を介して一時的にアウトバウンド ルールを変更することを好みます。これにより、更新が AWS S3 ログ バケットに強制的に記録されますが、サーバー自体のログには表示されません。さらに、更新を開始するサーバーは、プライベート サブネット ACL にある必要さえありません。
多分両方やりますか？攻撃がサブネット内の内部 IP を中継する場合があることを理解する必要があるため、バックアップとセキュリティ更新を自動化する機能を維持しながら、2 倍にするメリットがあります。
これが役立つことを願っています。返信がない場合は、より具体的かつ正確なコード例を提供してください。＃おげんきで ！
ポート 80 経由のアウトバウンド トラフィックをブロックするとはどういう意味ですか?
2 つの可能性があります。このセッションでクライアントから Web サーバーへの通信を許可する動的ルールを生成します。ステートフル ファイアウォール ルールを検索します。
または、通常、確立された接続が相互に通信したり発信したりできるようにします。
通常、ポート 80 経由のすべてのアウトバウンド トラフィックをブロックすると、Web サーバーはどのクライアントにも応答できません。
逆に、Web サーバーが何らかの API (jquery ライブラリなど) を取得する必要がある場合、API を保持する Web サーバーと通信するためのポートとしてポート 80 を使用しません。
Web サーバーは通常、ポート > 1024 を選択し、それを使用してリモート サーバーから API を取得します。
したがって、ポート 80 (接続元のポート) を介したすべてのトラフィックをブロックしても、サーバーが API などのリクエストを送信するのを防ぐことはできません。彼はクライアントとして動作するときにポート 80 を使用しないためです。