Home Blogs WAFチューニングを簡単に
Applications

WAFチューニングを簡単に

About The Author

Outline

中小企業および新規企業は、セキュリティに関する重大な課題に直面しています。 Webアプリケーションの安全性を維持しながら、専用のセキュリティ専門家やサードパーティのマネージドサービスを採用するコストを最小限に抑えるための高度なセキュリティソリューションが必要です。 新しい攻撃ベクトルが絶えず出現する中、ウェブアプリケーションのセキュリティはこれまで以上に重要で困難なものになっています。

Edgecast、現在はEdgio、WAFがソリューションです。 管理を簡素化する堅牢で洗練されたソリューションを提供します。 リアルタイムのダッシュボードとログ配信により、最新の可視性が得られるため、管理者は脅威を迅速に特定して対処できます。

このブログでは、企業が偽陽性を特定して排除し、追加のサポートコストを発生させることなくWebアプリケーション用にカスタマイズされたソリューションを構築する方法に焦点を当てます。

この分野を初めてお使いで、Edgio WAFをまだ使用していない場合は、この短いチュートリアルをご覧になり、ユーザーインターフェイスとその仕組みを理解してください。

すでにアカウントをお持ちの場合は、私と一緒にこの演習を行ってください。

1.リアルタイムダッシュボードに移動し、WAFイベントを時間でフィルタリングすることから始めましょう。 これは、Webトラフィックを分析する期間です。 (注:以前にルールのチューニングを実行したことがある場合は、必ず最新のチューニングの後のタイムフレームを選択してください)。

図1:直前の6時間に発生したWAFイベント

2.このトラフィックによってトリガーされた上位の10ルールIDを確認します。 ルールIDは、トラフィックをさらにフィルタリングし、さまざまなWAFイベントのペイロードを監視するのに最適な方法です。 ただし、詳細な分析のために、これらのルールIDでトラフィックを1つずつフィルタリングしてください。

図2:WAFイベントによって起動された上位10ルール

3.次に、Matched Valueフィールドを確認して、このルールをトリガーしたペイロード値を確認します。

図3:[Matched Value]列の[Payload]値

4.ペイロード値を分析して、それらが悪意のあるものであるかどうかを特定します。 どんな風に見えるかわからない? ペイロードに含まれる可能性のある悪意のある値をいくつか示します。

  • パストラバーサル: http://some_site.com.br/../../../../some dir/some file¹ http://testsite.com/get.asp?f=/etc/passwd²‍
  • LFIの脆弱性: 攻撃者が.iniなどのサーバー上の機密ファイルにアクセスしようとしています。 Edgecast WAFは、この拡張機能や他の多くの重要なファイルシステム拡張機能をデフォルトでブロックします。
  • クロスサイトスクリプティング: http://testsite.test/<スクリプト>alert(「テスト」);</スクリプト>▪ドキュメント <img src =”http://url.to.file.which/not.exist” onerror = alert(document.cookie);>Ω
  • SQLインジェクション: select * from items where‘a’=’a’;最小選択1;☐
  • リモートコードの実行: eval(“\$$user=‘$regdate’);☐
  • 時間ベースの攻撃: 1を選択してスリープ(2)を選択し、あたかもベンチマークを選択(2000000, MD5(‘a’)); ¹

5.ペイロードが悪意のあるものであるかどうかまだわからない場合は、対応するペイロードでリクエストを開始したクライアントIPのリストを調べることで、それを見つけることができます。 クライアントIPが分散されている場合、つまり変化している場合、ペイロードが偽陽性である可能性が高くなります。 ただし、すべてのクライアントIPの値が同じ場合は、潜在的なボリューム攻撃を示し、悪意のあるペイロードとして分類されます。 これを示すために、ステップ3を参照して、一致する値{“IATA”: [“TGZ”,”MEX”] }を選択し、例として使用します。 このペイロードを送信したクライアントIPのリストを調べるには、次のように一致した値をフィルタとして追加します。

図5:ペイロード値{“IATA”: [“TGZ”,”MEX”]}を送信したクライアントIP。

この場合、この要求を行うさまざまなIPアドレスを考えると、これらの要求が実際のユーザーから発信された可能性が高く、これは偽陽性の候補になります。

6. false positiveが特定されたら、Managed Rulesセクションで例外を作成できますが、その前に、このペイロードが見つかった場所(クエリ文字列、リクエストヘッダー、URL、またはその他の場所)を確認する必要があります。 これは、手順5の同じページのMatched On列を見ることで簡単に行えます。 この使用例では、次に示すように、ペイロードは「data」クエリ引数で検出されました。

図6:ペイロード値の場所:{“IATA”: [“TGZ”,”MEX”]}

7.これらの特定の一致をfalse positiveペイロードを含むフィールドでフィルタリングし、実際の悪意のあるペイロードを含むパラメータに一致する他のリクエストがないことを確認することをお勧めします。 つまり、特定のMatched Onフィールドのペイロードは悪意のあるものではありません。 これは、該当するフィールドの一致するにフィルタを追加することによって実現されます。 ユースケースを見ると、このクエリ引数に悪意のあるペイロードがないことを確認できます。

図7:クエリ引数で送信されたすべてのペイロード値:data。

8.例外を作成する前の最後の手順は、Matched OnフィールドによってトリガーされたルールIDを見つけることです。 このフォールスポジティブによってトリガーされたすべてのルール(ルールID)を記録しようとしています。 当社のユースケースに基づいて、この情報はステップ5から同じページで入手できます。

図8:ペイロード値によってトリガーされるルールのリスト:{“IATA”: [“TGZ”,”MEX”]}

9.例外を作成します。 [Managed Rules]セクションに移動し、これらの例外を追加する管理対象ルールをクリックします。

図9:WAF設定用に作成された既存の管理対象ルール

10. [例外]タブに移動し、[新しい条件の追加]をクリックします。 args、request_cookies、ペイロードが見つかったURLなど、フィールドで一致するタイプを選択します。 次に、queryやcookieなどのパラメータ名を入力します。 最後に、ペイロードがトリガーしたすべてのルールIDのリストを入力します。

図10:Managed Rule設定の下のExceptionsタブ

11.先に進み、その条件を作成します。 管理対象ルールを保存してから30秒以内に、このフォールスポジティブがWAFを通過するのを確認できます。

12.これがどのように機能するかがわかったので、手順3に戻り、別のルールIDでトラフィックをフィルタリングし、このプロセスを繰り返して、できるだけ多くの誤検出を排除します。

やったな トラフィックに合わせてWAFソリューションをカスタマイズしました。

最後のヒント

Edgio WAFを初めて使用する場合は、ブロックモードをオンにする前に、この演習の2 ~ 3ラウンドを実行することをお勧めします。 そしてあなたの交通量に基づいて、あなたは2~7日ごとにこの演習を繰り返すことができます。 Edgio WAFの既存のお客様には、この微調整演習を3 ~ 4週間ごとに実施することをお勧めします。 もう1つ考慮すべきことは、管理対象ルールのしきい値を10未満に下げ、徐々に最適値の5にすることです。 これにより、より正確で鮮明なルールセットを着実にキュレーションできます。 Edgio WAFは、リアルタイムトラフィック用の実際のステージング環境(監査モード)であるデュアルWAFを提供していることを忘れないでください。 監査モードを使用すると、定期的な更新やルールセットへの微調整をすべて実行できます。正規のトラフィックのドロップを心配する必要はありません。

ウェブアプリケーションを安全に保つためのすべてのセキュリティテクノロジーについて詳しくは、今すぐお問い合わせください。

リソース:

¹ ² OWASP、「Path Traversal」、owasp.org、 owasp.org/www-community/attacks/Path_Traversal。

³ Offensive Security、「ファイル包含の脆弱性」、offensive-security.com、 offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/

▪ファイル名OWASP、“Cross site scripting”、owasp.org、 owasp.org/www-community/attacks/xss/

私たちは、『SQLインジェクション』、owasp.org、 owasp.org/www-community/attacks/SQL_Injectionを参照してください。

IFNetsparker、「リモートコード評価(実行)の脆弱性」、netsparker.com、netsparker.com/blog/web-security/remote-code-evaluation-execution/。

 Action Plussで学ぶAshraf, Ahmad,“Timing-Based Attacks in Web Applications”, owasp.org owasp.org/www-pdf-archive/2018-02-05-AhmadAshraff.pdf .