私たちはIP上で開発サーバーを実行し、ポート5000でAPIを公開し、nginxはポート80でリッスンします。ただし、ポート 5000 に HTTPS 要求が発生すると、バックエンド全体がクラッシュします。その結果、アクセス時に脆弱性が発見されました。https://SERVER_IP:5000、HTTPS要求を処理できないため、要求が中断され、バックエンド全体が停止します(したがって、他の要求に対してもAPIが中断されます)。リクエストがバックエンドに届かないことを願っています。
私はUFWに対して次の規則を設定しました。
To Action From
-- ------ ----
8000 ALLOW Anywhere
22/tcp ALLOW Anywhere
80 ALLOW Anywhere
5000 ALLOW Anywhere
443/tcp DENY Anywhere
8000 (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
5000 (v6) ALLOW Anywhere (v6)
443/tcp (v6) DENY Anywhere (v6)
ただし、ユーザーが次に移動した場合https://SERVER_IP:5000、サーバーがまだクラッシュしています。これは、httpsトラフィックが必ずポート443ではなくポート5000で発生し、そのポートがパブリック(HTTPトラフィックにのみ必要)であるためです。それでは、5000のHTTPSトラフィックがUFWを通過しないように無効にする方法はありますか?それとも、nginxで何かを設定する必要がありますか?
ベストアンサー1
いいえ、UFWはそうすることはできません。
TCP接続のトラフィックが有効なHTTP要求であることを確認するには、接続を受け入れてクライアントが送信しようとしているデータ型を確認する必要があります。つまり、コンテンツベースのフィルタリングです。
UFWは、データを含まないTCP接続の初期SYNパケット内のデータに基づいて決定を下す必要があります。その時点では、顧客の要件が何であるかはわかりません。 APIに適合しないURIを含むすべての正しい形式のHTTPリクエストをフィルタリングするには、APIの前にある種のHTTPリバースプロキシが必要になるようです。
APIの入力検証を改善することを提案できますか?少なくとももはや本番に入れる前にランダムなゴミを送ってもクラッシュしませんか?そうしないと、APIが軽微なサービス拒否攻撃( War_and_Peace.txtがAPIが提供する入力バッファより絶対に大きい)にnc your.API.server.example 5000 < /dev/urandom
脆弱nc your.API.server.example 5000 < War_and_Peace.txt
になる可能性があります。