F5 EAPでシグネチャを例外登録したときの動作と修正方法を調べてみた

こんにちは、臼田です。

みなさん、WAF活用していますか？

今回はF5のSaaS型WAFであるEssential App Protect(EAP)でシグネチャを例外登録した際の動作とその修正方法を調べてみました。

F5 EAP自体について詳しく知りたい場合はまず下記をご覧ください。

F5 EAPのシグネチャ

EAPでは大きく3種類のアプリケーション保護機能があります。

• ハイリスク攻撃の軽減(High Risk Attack Mitigation)
• 悪意のあるIPからの保護(Malicious IP Enforcement)
• 脅威キャンペーン(Threat Campaigns)

そのうちEAP上でユーザーが調整するシグネチャはHigh Risk Attack Mitigationに含まれるの攻撃シグネチャになります。2020/07/27現在ではシグネチャが4,851個存在していて、F5によりメンテナンスされています。

シグネチャの例外登録とその動作

シグネチャの例外登録の方法とその動作について説明します。

まず何かのアクセスがBlockまたはMonitoringで検知された場合にはSecurity Incidentsというイベントが発生します。このイベントを「VIEW EVENTS」から確認します。該当のイベントを選択した際に右側から詳細が出てきますが、この右下に「Mark as exception」というボタンがありここから例外登録が可能です。

「Mark as exception」を押すと確認画面が出ます。イベントに対応する複数のシグネチャの例外登録が一度に登録されると表示されるので登録します。

これで反映が完了です。変更された内容は「VIEW EVENTS」の「Service-specific」の設定変更の中に含まれていて、Descriptionが「Mark as exception」として登録されます。変更内容は残念ながら現状では部分的でなく、WAF全体のConfigurationが表示されます。

Configurationにおける例外のスキーマは公式ドキュメントに詳細の説明があります。下記のような構造になっています。

 "high_risk_attack_mitigation": {
     "enabled": true,
     "enforcement_mode": "blocking",
     "signature_enforcement": {...},
     "allowed_methods": {...},
     "disallowed_file_types": {...},
     "api_compliance_enforcement": {...},
     "http_compliance_enforcement": {...},
     "websocket_compliance_enforcement": {...},
     "geolocation_enforcement": {...},
     "ip_enforcement": {...},
     "exceptions": {
         "url_objects": {...},
         "parameters_objects": {...},
         "headers": [...],
         "cookies": [...],
         "evasions": [...],
         "http_compliance": [...],
         "attack_signatures": [...]
     }
 }

いくつか要点を解説します。

例外登録はURL・パラメータ・ヘッダ・Cookieなどの条件と合わせて対応するシグネチャを除外する場合と、シグネチャのみで除外する場合があります。

「Mark as exception」から登録すると、シグネチャが該当するURLやパラメータなどを条件に含めて登録されます。

例えば上記画像で紹介したものはRefererに含まれている文字でのSQLインジェクションを検知したイベントで、シグネチャとしてはヘッダに含まれる文字列に対してSQLインジェクションを検知するものであったため、例外登録すると下記の条件で例外登録されました。

• ヘッダ名がReferer(Config上ではBase64して登録されるためUmVmZXJlcg==)
• シグネチャIDが200002424または200002171または200002836

上記はANDとなります。

他にもパラメータに対するSQLインジェクションを検知するシグネチャを例外登録すると下記のようになります。

• パラメータ名がid(Config上ではaWQ=)
• シグネチャIDが...

つまりシグネチャ自体がヘッダやパラメータ用で用意されているため、例外登録したら該当したヘッダやパラメータを条件として例外登録されます。

そのため「Mark as exception」から例外登録したら自動的にすべてのリクエストからそのシグネチャが例外とされるわけではありません。そこは安心ですね。

注意点としては条件が細かくないため例外登録により必要以上に影響がある可能性があります。

具体的には上記例のようにパラメータで除外された場合に別のページの同名パラメータも除外対象となり、そちらに適切な保護が適用されない可能性があります。上記例はidパラメータを例外条件としているため、別のページのidパラメータも除外対象となります。残念ながら現状これに複合的な条件を加えて例外対象をさらに絞り込むことはできないようです。

例外登録の修正方法

修正方法は大きく2つあります。

• 以前の設定にロールバックする
• 直接Configurationを変更する

順に紹介します。

以前の設定にロールバックする

これはボタン一発で簡単に設定を修正する方法です。「VIEW EVENTS」の「Service-specific」の右下に「Apply this version」というボタンがあります。これを押すことで設定を該当のConfigに戻すことが可能です。

この方法の欠点は、特定の例外登録だけを除外するのではなくすべての設定がロールバックすることです。つまり直前の例外登録を元に戻すには向いていますが、何度も変更した後に該当の例外登録を修正する際には使えません。

直接Configurationを変更する

例外登録の設定はすべてConfigurationのjson情報として保存されているため、これを直接変更すれば修正が可能です。「PROTECT APPLICATION」の「JSON configuration」から変更できます。

こちらであればどのような状況でも目的の設定のみ修正できますが、欠点としてはConfigを破壊してしまう可能性があったり、シグネチャIDやBase64の文字列のみのため該当のシグネチャを探しづらかったりします。

もし間違えてしまったら前述のロールバックを使いましょう。

まとめ

F5 EAPの例外登録の動作と修正方法についてまとめました。

例外登録が適切にヘッダやパラメータなどを条件に含めてくれる動作は非常に嬉しいですね。

反面修正については現状では色々注意が必要です。気をつけましょう。