Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
0
Help us understand the problem. What is going on with this article?
@Eoli_Tanuki

F5 WAF の設定理解 - URL entity 編

F5 WAF の設定理解 - URL entity 編

F5 WAF の設定項目を個別に理解していこうという試みです.まずは最も分かり易そうな URL entity から.
テストで使用した Version は 15.1.2 です.

WAF を使う前段階の構築についてはこの辺をみるといいと思う.
https://dev.classmethod.jp/articles/f5-advanced-waf/
https://f5j-easy-setup-waf-15.readthedocs.io/en/latest/content1/module02/module02.html
https://qiita.com/PIED_PIPER/items/5ed3824b546750924417

現状の URL entity の設定を確認する

GUI 左の Security タブから,Application Security -> URLs -> Allowed URLs を開きます
URL1.png
スクリーンショットで見られるように,現状は HTTP と HTTPS それぞれに対して wildcard の * (全てのURLにマッチ)が設定されています.
写真のアップロードサイズの制限があるのでスクリーンショットは撮っていませんが,Disallowed URLs には何も定義されていません.

URL entity の設定によってどのようにリクエストハンドリングに影響するのか理解する

URL_CHART3.png
先ほどのスクリーンショットの設定例を当てはめると,どのような URL へのリスエストが来てもチャートの 『Allowed URL リストに該当』が yes となり,URL entity に設定されている検査項目が実行される.

チャートの中に書いてある,『blocking mask』というのは各種 violation ごとに,検知した後のアクションを定義する設定のことです.
GUI 左の Security タブから,Application Security -> Policy Building -> Learning and Blocking Settings に,全 violation がカテゴリごとに整理されています.下記のスクリーンショットでは,URLs のカテゴリに illegal URL という violation があることが分かります.illegal URL は Alarm と Block が有効になっていますね.
URL2.png
次に,同じくチャートに書いてある 『ポリシーの enforcement mode 』です.これは WAF ポリシー全体のモードで blocking と transparent の二つのモードがあります.これが blocking になっていないと,個別の violation 有効になっていてもリクエストはブロックされません.なので,ブロックされると期待したのに結果が異なるような場合,個別の violation の blocking mask の確認とポリシー全体の enforcement mode を確認する必要があります.enforcement mode の設定は古いバージョンだと blocking mask と同じ画面で確認できます.比較的新しいバージョンだと
GUI 左の Security タブから,Application Security -> Security Policies -> Policies List から目的のポリシーを選択することで確認できます.
URL3.png

実際にリクエストを投げて,illegal URL の violation でブロックされない事を確認してみる.

WAF 自身から Virtual Server へリクエストを投げてみます.

[root@waf:Active:Standalone] config # curl 10.79.200.22

GUI 左の Security タブから,Application Security -> Event Logs -> Application -> Requests
から,リクエストイベントログを確認すると,特に violation は何も検知されていないことが確認できました.
URL4.png
ちなみに,WAF がイベントログを残すようにするには log profile を事前に virtual server にセットしておく必要があります.

GUI 左の Local Traffic タブから Virtual Servers -> Virtual Server List -> 該当の Virtual Server  を選択して, 画面上部の Security タブの Policies で,log profile をセットできます.

URL entity の詳細設定を確認する

GUI 左の Security タブから,Application Security -> URLs -> Allowed URLs を開き, HTTP * の詳細を見てみます.
URL5.png
画面上部の Advanced を選択すると設定の詳細が全て表示されます.スクリーンショットではこの URL entity 上の Meta Characters のタブを表示しています.Meta Characters というのは,その名の通りメタ文字に関する設定で,この URL entity に関してどのようなメタ文字が許可・拒否するのかを細かく定義することができます.スクリーンショットから例をあげると,$(0x24) は拒否で &(0x25) は許可となっていますね.それでは実際にこの二つのメタ文字を URL に含むリクエストを投げて, リクエストイベントログを確認してみます.設定によると,$ は WAF でブロックされ % はサーバーへ届くはずですね.

[root@waf:Active:Standalone] config # curl 10.79.200.22/test$   
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>
[root@waf:Active:Standalone] config # curl 10.79.200.22/test%
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>

URL6.png
想定と違って,両方のリクエスト共にサーバーへ届いてレスポンスが返ってきました (サーバー上にそのようなリソースは存在しないので,404 Not Found が返ってきました).イベントログでも,緑の✔︎に○がついており両方とものリクエストがブロックされなかったことが確認できます.

なぜ$がブロックされなかったのかというと,前述の blocking mask で illegal meta character in URL の項目が block になっていないためです.blocking mask の設定を更新して再度リクエストを投げてみましょう.
URL7.png

[root@waf:Active:Standalone] config # curl 10.79.200.22/test$
<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: 5987551084866961453<br><br><a href='javascript:history.back();'>[Go Back]</a>
</body></html>

[root@waf:Active:Standalone] config # curl 10.79.200.22/test%
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>

今回は$の方は,先ほどの異なるレスポンスが返ってきました.これは WAF が生成する blocking page というもので,クライアントに support id (問合せ番号のようなもの) が通知されます.通常はクライアントはウェブブラウザだと思うので,ブラウザにこの番号が表示される.リクエストイベントログをみると,今度は $ はブロックされたことが確認できます.また,violation の情報やリクエストの詳細, support id も確認できるので,ユーザーからの問合せがあった時にここを見て調査することになります.
URL8.png

最後に

F5 WAF の URL entity 設定まわりについて整理しました.
次は Parameter entity の設定について整理しようと思います.

0
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
0
Help us understand the problem. What is going on with this article?