AWS/Azure

自社WebサーバにAWS WAFを適用しました(3)~構成変更における課題編~

こんにちは。
タイトルの通り自社WebサーバにAWS WAFを適用しまして、
正常に稼働していることが確認できた頃合いだったので、
社内への技術的な共有も兼ねて寄稿することにしました。

全5回以下のような構成となります。

  1. 構成編
  2. 費用算出
  3. 構成変更における課題
  4. AWS WAFとALBの初期設定
  5. 運用後の経過

構成変更における課題の把握

当初、構成変更するにあたって、どのような課題があるのかがあまりわかっていませんでした。
Webサーバの構築や運用に関わっていなかったため、
どういう設定が入っているのかが分からなかったためです。
そのため、最初はWebサーバ構築時の経緯を追うことと、コンフィグに目を通すことから始めました。

お客様環境に製品を導入する際には、関連するコンフィグ全てのパラメータの値を確認して、
どういう影響があるのかを確認しています。
ただ、自社Webサーバに対してそこまでの可用性を求められていない雰囲気を察して、
ある程度妥協をしながら設定値を確認しました。
(パラメータから実際どういう影響が及ぶのかを想像することも限界があるので、
結果として本番環境のスナップショットをもとに、
テスト環境を作って色々試験をしてみるという気持ちに切り替えたのが正解でした。)

洗い出した課題で特にインパクトがあったもの

移行において、問題になった課題を3つ紹介します。

  • DNSのリソースレコード変更
  • 送信元IPアドレス制限方法の切替
  • HTTPSを無効化するにあたっての対応

DNSのリソースレコード変更

ALBを作成すると、「~~.elb.amazonaws.com」というFQDNが払い出されます。
その払い出されたFQDNにアクセスすれば、ALBを経由してWebサーバに通信が到達します。

ただし、元々弊社では [ www.secuavail.com ] [ secuavail.com ] のいずれにアクセスしてもWebサイトが表示されるようにしていました。
そのため、 [ www.secuavail.com ] 及び [ secuavail.com ] にアクセスしたら、[ ~~.elb.amazonaws.com ] に通信をするようにするために、CNAMEレコードを使う必要がありました。

弊社ドメインは、AレコードでElastic IPと紐づけていたため、レコードの変更が必要になりました。
ただ、 [ secuavail.com ] のようなネイキッドドメインはRFCの規定上、紐づけることはできません。
(https://datatracker.ietf.org/doc/html/rfc1912#section-2.4)
※Route53では追加拡張機能を使うことで、実現することができます。

元々ネイキッドドメインでのアクセスは想定しておらず、件数も多くないだろうということで、
社内で調整したうえで、ネイキッドドメインでWebサイトにアクセスできないようにしました。
※Network Load Balancerを使えば固定IPアドレスをALBに紐づけることもできるようです。
要件によっては、こちらで実装することも考えてもよさそうです。

送信元IPアドレス制限方法の切替

Webサーバで、送信元IPアドレスでアクセス制限をしているURLがありました。
ALBではプライベートサブネットのIPアドレスへ送信元NATが行われます。
つまり、これまでグローバルIPアドレスベースでアクセス制限をしていた設定が使えなくなってしまいます。

これについては、X-Forwarded-Forの情報をもとに送信元IPアドレス制限をするようにしました。
幸い弊社で使っているWebサーバのミドルウェアでは、XFFを送信元IPとして扱うモジュールが用意されており、
そのモジュールを有効化すると、既存の送信元制限の設定を変更する必要がありませんでした。

XFFを詐称してのリクエストを試してみましたが、
サーバに到達した時点での最後のXFFの値に制限されることが確認でき、これまで通りの制限が行えました。

HTTPSを無効化するにあたっての対応

ALB+ACMによってTLS終端をするので、WebサーバでHTTPS通信を受け取らなくなります。
不要なプロセスを動かしたくないほか、切り分けなどが面倒になるため、
HTTPSを有効化するモジュールを無効化するようにしました。

関連する課題として、HTTPリクエストをHTTPSへリダイレクトする設定を削除する必要がありました。

HTTPSでのリクエストが普通になりましたが、過去に作成されたページのリンクやユーザのアクセス方法によって、
HTTPでリクエストが飛んでくる可能性があります。
それに備えて、HTTPSのURLへリダイレクトするような設定がサーバに入っていました。

その設定は削除して、ALBのリスナールールにて、HTTPSへリダイレクトする設定を入れることで引き継ぎました。

まとめ

発生した課題についていくつか紹介させていただきました。
いずれもロードバランサをWebサーバの前段に配置する場合にありがちな問題だと思います。
DNSのリソースレコードの変更については、危うく社内インフラにも影響が及んでいた可能性があるため、
課題によって割く労力に濃淡をつけるのはやはり重要だと思った次第です。

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。

自社WebサーバにAWS WAFを適用しました(2)~費用算出編~前のページ

自社WebサーバにAWS WAFを適用しました(4)~AWS WAFとALBの初期設定~次のページ

ピックアップ記事

  1. ログフォワーダー「okurun.jar」について
  2. IoT機器「Raspberry pi」とLogStare Collectorで温…
  3. Zabbixヒストリデータのレポート生成について
  4. 自社製品をAMIにしてAWSマーケットプレイスへ出品

関連記事

  1. AWS/Azure

    LogStare CollectorでのVPCフローログの取得方法とログレポート

    当記事では、LogStare CollectorでのVPCフローログの…

  2. NW機器

    AWS Transit Gateway で集約したトラフィックをFortiGate で精査する

    当記事では、AWS Transit Gateway を用いて通信を集約…

  3. 実践記事

    初学者が一番初めに読むべき正規表現入門

    この記事では正規表現を知らない方に向けて簡単な例と共に解説します。…

  4. AWS/Azure

    RDS関連メトリクス一覧

    当記事では、CloudWatch監視にて対応しているRDS関連メトリク…

  5. 実践記事

    DNSキャッシュポイズニングやってみた

    令和4年秋季情報処理安全確保支援士試験にてDNSキャッシュポイズニング…

  6. Azureマーケットプレイスへの出品

    AWS/Azure

    Azureマーケットプレイスに自社製品を出品する手順と注意点

    弊社では「LogStareCollector」をAWSマーケットプレイ…

月額200円でM356の監査ログの運用レベルUP LogStare M365

AWSのログ分析・モニタリングに 次世代のマネージド・セキュリティ・プラットフォーム LogStare

  1. AWS/Azure

    AWSマーケットプレイス上から無償版のLogStare Collectorを試す…
  2. 実践記事

    DNSキャッシュポイズニングやってみた
  3. デフォルト画像イメージ

    FortiGate

    FortiGateのSD-WAN設定について
  4. NW機器

    SonicWall UTMにSyslog送信設定を追加する方法について
  5. ログ分析・監視テクニック

    nProbeであらゆる通信をログに記録し可視化する
PAGE TOP