こんにちは。
タイトルの通り、自社WebサーバにAWS WAFを適用しまして、
正常に稼働していることが確認できた頃合いだったので、
社内への技術的な共有も兼ねて寄稿することにしました。
全5回以下のような構成となります。
- 構成編
- 費用算出
- 構成変更における課題
- AWS WAFとALBの初期設定
- 運用後の経過
目次
AWS WAFとALBの初期設定にあたって
今回はロードバランシングの要件がなかったため、簡単な設定のみでした。
Webアプリケーションの前段にロードバランサを置く場合、
セッション維持の方法などがガラッと変わるので、複雑な対応が必要になります。
必要に応じて、事前検証をするようにしてください。
AWS WAFの初期導入設定ポイント
① 精査除外用ルールを作る
以下は除外することを検討するとよいです。
- 脆弱性診断用IPアドレスからのリクエスト
② 適用するマネージドルールを検討する
AWS マネージドルールルールグループリスト
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-list.html
費用算出の時点で既にやっていましたが、各ルールグループの説明を読みつつ、
サーバに必要なものかを確認します。
③ マネージドルールのアクションを [ Count ] に変更する。
可能であれば、アクションを [ Count ] へ変更して、検知状態を確認するべきです。
LogStare Quintを使えば、導入時のログ分析は特に問題ないと思ったため、
[ Count ] にて様子を見ていました。
ALBの初期導入設定ポイント
設定項目数が多いため、注意が必要な設定をピックアップしています。
① セキュリティポリシー
(以下引用)
ロードバランサーは、セキュリティポリシーと呼ばれる
Secure Socket Layer (SSL) ネゴシエーション設定を 使用して、
クライアントと SSL 接続を管理します。
TLS接続確立時に、サーバサイドで利用する暗号化プロトコル、暗号化スイートを設定します。
レガシーなシステムではクライアントサイドの都合で、
古いTLSプロトコルを許容しないといけないことがあります。
（クライアントが提示できる暗号化スイートとサーバが許可する暗号化スイートが一つも一致しないとTLSハンドシェイクが失敗します。）
システムの性質に応じて、設定変更を検討する必要があります。
② TLS バージョンと暗号ヘッダー
(以下引用)
有効にした場合、ロードバランサーは、クライアントリクエストに 2 つの TLS ヘッダー (x-amzn-tls-version および x-amzn-tls-cipher-suite) を追加してから、そのリクエストをターゲットに送信します。
TLSバージョン及び暗号化スイートを取得する必要はないと判断したため、無効にしています。
「セキュリティポリシー」を切替える前に有効化して、情報を集めるという使い方ができそうです。
③ HTTP/2
（以下引用）
プロトコルバージョン HTTP/2 を使用してロードバランサーにリクエストを送信します。
無効にしています。
HTTP/2では仕様上、全てのHTTPヘッダが小文字になります。サーバへ影響が出る可能性があり、
今回の作業では切替えない判断をしました。今後の改善事項になりそうです。
後日、先輩社員からの指摘によって、クライアントとALB間をHTTP/2にして、
ALBとサーバ間をHTTP/1.1で通信をするようにしたところ、
ALBとサーバ間では小文字になったHTTPヘッダをもとに戻しているような挙動が見られました。
オリジナルのヘッダ名であるのかは保証できませんが、バックエンドへのサーバの影響は抑えられそうです。
④ WAFのフェイルオープン
（以下引用）
Application Load Balancer が AWS のウェブアプリケーションファイアウォール (WAF) に接続できない場合に、バックエンドターゲットへのリクエストを許可します。
攻撃によるリスクが高いサーバではないので、有効にしています。
LogStare Quintを使って、フェイルオープンの発生を検知できるようにしているのですが、
過去3ヶ月間一度もフェイルオープンは起きていません。
⑤ Connection idle timeout
（以下引用）
The amount of time a client or target connection can be idle before the load balancer closes it.
ロード バランサーがクライアント接続またはターゲット接続を閉じる前に、
クライアント接続またはターゲット接続がアイドル状態でいられる時間とのことです。
当初はサーバのデフォルト値5秒に合わせていましたが、
一部のシステムで504 Gateway Timeoutが発生したことが確認されたので、少し延ばしていました。
LogStare Quintで生成されるアクセスログレポートをチェックすると、
ALBが応答したコードが確認できるため、時々参照しています。
⑥ Desync緩和モード
（以下引用）
アプリケーションにセキュリティリスクを与える可能性のあるリクエストを、
ロードバランサーがどのように処理するかを決定します。
RFC7230（HTTPのルール）に違反するリクエストをどれだけ許容するのか決める設定です。
よほどセキュリティに妥協できない場合でなければ、「Defensive」が推奨になります。
ALBのアクセスログに判定結果も残るため、
LogStare Quintで生成されるアクセスログレポートをチェックすると傾向が確認できます。
⑦ 無効なヘッダーフィールドを削除(Drop invalid header fields)
（以下引用）
有効ではないヘッダーフィールドを持つ HTTP ヘッダーを、ロードバランサーで削除する (true) か、
ターゲットにルーティングする (false) かを示します。
HTTPリクエストヘッダに対して特別な処理をかけることもなく、
不具合を起こすようなヘッダは削除したほうが良いと判断したため、trueにしています。
レガシーなシステムにおいて有効化する際には、検証環境を構築したうえで、
動作確認を取ることが推奨されます。
まとめ
弊社環境では、構成がシンプルだったので、ALBの設定に悩むことはありませんでした。
今回は弊社環境で気にするべきだったポイントを列挙していますので、
皆様の環境でALB及びAWS WAFを利用される際には、改めて全ての設定値を確認してほしいのですが、
[ Connection idle timeout ] はバックエンドのサーバにも影響が及ぶので、
入念に確認をしたほうが良いと思います。
次回は実際に運用してみたうえでのレポートを記載していこうと思います。
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
