UFWはHTTPSを介して特定のポートへのアクセスを拒否しますか?

UFWはHTTPSを介して特定のポートへのアクセスを拒否しますか?

私たちは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になる可能性があります。

おすすめ記事