RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

WAF とは?【まとめ】

まえがき

お初の方は初めまして。
そうでない方はこんにちは。
ラクスでインフラを担当していますru369と申します。
今回は、WAFについて記事にまとめましたのでよろしくお願いします。

WAFについて(概要)

WAFとは・・・Web Application Firewall の略称で通称:ワフと呼びます。
Webアプリケーションの脆弱性を突いた攻撃への対策のひとつであり、Webサーバの前面に配置して通信を解析し、Webサイトを保護するセキュリティ対策です。

動作としては一般的なファイアウォールと似ていますが、異なるところはデータの中身をアプリケーション層レベルで解析できるのが特徴です。
ECサイトなどでのオンラインショッピングやゲームといった個人情報やクレジットカード情報など、ユーザーからの入力を受け付けるようなタイプのWebサイトを不正な攻撃から守ってくれます!

WAFと似たセキュリティ対策として、Firewall、IPS/IDSがありますが、それぞれ用途(防御の箇所)が異なります。

WAFとの違い

WAFとFirewallファイアウォール)とは異なる点

Firewallネットワーク層レベルでのセキュリティ対策です。
送信元と送信先の情報(IPアドレスやポート番号など)を元に内部ネットワークへのアクセスを制限します。
ポートスキャンなどの外部公開が不要なサービスを狙った通信は制限できますが、 通信の中身までは検査しません。
➡正常な通信(パケット)を装った攻撃を区別できず対処できません。

WAFとIPS/IDSとは異なる点

  • IPS(Intrusion Prevention System)
    • 不正侵入防止システムと呼ばれプラットフォームレベルでのセキュリティ対策です。
  • IDS(Intrusion Detection System)
    • 不正侵入検知システムと呼ばれ、異常な通信を検知する為に使われます。

➡簡単に言えば、異常な通信を検知するのはIDS、それをさらに防御まで行うのがIPSというイメージです。

IPS/IDSは、種類により様々ですが、ファイアウォールよりも内側、反対の外側、DMZ上といった設置パターンがあります。
Firewallよりも内側に設置する場合はファイアウォールを補完する形で防御性能をアップさせます。
一方で外側に設置する場合は、ログを取得して攻撃を把握、分析します。
DMZ上では、Firewallをすり抜けてきた攻撃を検出・防御します。

このように使い方によりけりではありますが、IPS/IDSは、OSやミドルウェア脆弱性を突いた攻撃や、ファイル共有サービスへの攻撃など、さまざまな種類の攻撃を検査・防御します。
しかしながら、Webアプリケーションへの攻撃は多種多様に増えているため、IPSでは攻撃を防ぎきれないことがあります。
また、解析のためにネットワークの性能劣化や遅延が起きてネットワークが使えなくなることがあります。

WAFの効果

WAFを導入しておくと、どのようなことに役に立つのかご紹介します。
情報流出等のセキュリティインシデントが発生すると、以下のようなことに遭遇し得ます。

  • 企業の社会的信用の失墜
  • Webサイトの長期的閉鎖による機会損失
  • 機会損失により売り上げが下がり直接的/関節的な対策のコストが必要

一方でWAFによる対策をしていると、以下のような事態に遭遇した際に即対応することができます。

実害がある場合(攻撃を受けた状態)
  • 攻撃を受けたWebサイトが実害を受けた場合、元の状態に戻すまでに時間がかかってしまう
  • すぐに防御できないため、対策できるまで被害が拡大してしまう恐れ
  • 攻撃を受ける前と同じ状態でサービスを暫定的であっても再開できない
実害はない場合(脆弱性が発見された場合など)
  • Webアプリケーションに脆弱性が発見されてもすぐにアプリケーションの改修を行うことは難しく、暫定的な緊急措置がとれない
  • Webアプリケーションが複数ある場合は、それぞれに対応が必要なため、すべてに対応するまで時間がかかる
WAFで対応可能な攻撃の種類

基本的にWAFは OWASP Top 10(OWASP:The Open Web Application Security Project)に準拠していると思います。
導入製品によって異なる部分もあると思いますが、例として以下のような攻撃に対してWAFは効力を発揮します。

WAFの種類

主に以下の3種類があります。
OSSのWAFもありますので合わせて紹介です。

  • アプライアンス型WAF(ゲートウェイ型WAF)
    WAF専用機器をゲートウェイに設置して導入します。
    既存のネットワークに直列で接続する「インライン型」や、スイッチなどのミラーリングポートに接続する「ミラー型」などがあります。
    導入にはネットワーク構成を考慮する必要がありますが、保護対象のWebサーバには負荷がかかりません。

  • クラウド型WAF(サービス型WAF)
    ネットワーク設定を一部変更し、インターネットを経由してクラウドサービスを受けることができます。
    基本的に運用はクラウドサービス提供者が行うため、チューニングや脆弱性対応も自分で行う必要はありません。
    また、機器購入等が不要なことから初期費用を抑えることができます。

  • ソフトウェア型WAF(ホスト型WAF)
    保護対象となるWebサーバーにWAFのソフトウェアをインストールし、通信内容を検査します。
    保護対象のサーバーに直接インストールするため、ネットワーク環境の構成や他のサーバーなどに影響を与えず導入することが出来ます。

  • オープンソースのWAF
    無料で利用できるオープンソースのWAFもあります。
     ・ModSecurity
     ・NAXSI
     ・WebKnight
    余談ですが、「OSS WAF」で調べてみるとModSecurityが突出している印象です。

クラウド型WAFを触ってみた

過去にModSecurityを触ったことはありますが、最近クラウド側WAFに触る機会がありましたのでそのお話を少しできればと思います。
(なお、WAFそのものよりどちらかというとリバースプロキシサーバの話になります。)
ここでの導入イメージは、1台のWebサーバ(Apache)の前段にWAF(リバースプロキシ(nginx))を導入する形です。

  • 導入前の準備
    WAFに転送先(実際のアクセス先)のWebサーバのIPアドレスを登録します。
    細かいことでいうとSSH接続や接続方法(HTTP(S)接続)の設定、チューニングなどが後の作業として控えていますが、最低限の導入準備はこれで終わりです。
    ※Webサーバの前段にLoadbalancerサーバがあるような構成であれば、LoadbalancerのIPアドレスを登録することになると思います。

  • 導入してみる
    WAFの導入は、Webサーバに設定しているグローバルIPアドレスDNSレコード(CNAMEレコードやAレコード)にWAFのIPアドレスを登録するのみです。

  • 導入後
    導入後はWAFを経由している分、経由していない場合と比較して、アクセスにかかる時間は数ミリ秒伸びました。
    Webアクセスには基本的に影響はなく、WAFの検知テストを行ってもきっちり検知されブロックもされました。

思わぬ落とし穴

WAF自体とは少しずれますが、リバースプロキシサーバの運用経験がほとんどなかったことから嵌ってしまった落とし穴がありました。
良かったことと悪かったことに遭遇しました。

■良かったこと

これまでWebサーバが受け付けていたすべてのアクセスを前段のWAFが受けてくれる形になったことで、Webサーバの負荷が減少しました。
WAF側でキャッシュ機能を有効にしていたり、レスポンスの圧縮をしてくれること、クライアントごとのSSL/TLSリクエストの暗号化と復号化を代わりにやってくれるためと考えられます。

■悪かったこと

ブラウザからWebアクセスをしていると、WAFにて502エラー、504エラーがランダムで発生していることが確認できました。 実際ブラウザ側では稀にエラー画面が表示されることがありました。

  • 504エラー
    WAFとWebサーバとのタイムアウト値の関係がWAF < Webサーバとなっていたことが原因でした。
    WAF >= Webサーバにタイムアウト値を直したところ激減(ほぼ0件)になりました。

  • 502エラー
    当初難航しました。
    なぜなら特定のアクセスに起因するものではない上、WAF、Webサーバ双方のログから調査することができなかったためです。
    (ググってもあまり情報がでてこなかったのも辛かったです)

この問題を回避するには、WAFとWebサーバのKeepAliveTimeoutの値の関係をWAF < Webサーバにする必要がありました。

(KeepAliveとKeepAliveTimeoutの補足)
KeepAliveは、一度TCPの接続が行われると同じ接続内で複数のリクエストのやり取りを行うための設定であり、KeepAliveTimeoutで設定した時間内にクライアントから次のリクエストが送信されてこなくなるとTCP接続を切断します。

導入当初は、WAF > Webサーバの関係でKeepAliveTimeout値が設定されてしまっていました。
クライアント→WAF→Webサーバの流れでアクセスがありますが、 後続の WAF→Webサーバ間 のコネクションが クライアント→WAF間 よりも短いタイムアウトで切断 され、そのタイミングでクライアントから握ったままになっていたコネクションを利用しようとしたときにエラーになることがあるのだと思います。
➡WAF < Webサーバの関係のことはAmazonのELB関係のページにも記載がありました。
(参考:https://aws.amazon.com/jp/premiumsupport/knowledge-center/apache-backend-elb/

WAF < Webサーバの適正なKeepAliveTimeout値は、2倍3倍以上の差にする必要がありますが一概には言えないので、チューニングしてエラーが発生しない分岐点を探っていく必要があります。
なお、KeepAliveTimeoutを0にするとエラーは発生しなくなりますが、 動作が驚くほど遅くなります のでお勧めしません。

(KeepAlive が0(=無効)になっていると、最初にTCPコネクションを確立したあと、リクエストの送信及びレスポンスの送信が行われ、都度 TCP の接続がいったん切れます。複数のリクエストを送る場合にはリクエストの度に TCP の接続を確立する必要がでてきてしまうためと思われます。)

まとめ

昨今のセキュリティ事故事情から様々なセキュリティ強化を求められると思います。
WAF導入の話が出てきた際に、(拙くて申し訳ないですが)本ブログが少しでもお役に立てれば幸いです。

※参考にしたページ
https://httpd.apache.org/docs/2.4/ja/mod/core.html#keepalivetimeout
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout
https://kinsta.com/jp/blog/reverse-proxy/
https://aws.amazon.com/jp/premiumsupport/knowledge-center/apache-backend-elb/
https://it-trend.jp/waf/article/poodle
https://www.digicert.com/jp/waf/waf-ips-ids
https://it-trend.jp/ids-ips/article/difference
https://cweb.canon.jp/it-sec/solution/siteguard/waf/
https://www.jbsvc.co.jp/useful/security/what-is-waf.html


◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

Copyright © RAKUS Co., Ltd. All rights reserved.