この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、コンサルティング部の網走で生まれた大村です。
AWS WAFにルールを設定した後、設定したルールで検知するかテストしたくなりますよね。今回はAWSのマネージドルールについて手軽に検知ログを出力するアクセスパターンをまとめました。
WebACLの画面にBLOCKか、COUNTって表示したい。
環境
AWS WAFの構築は下記をご参照ください。
S3にログを出力するAWS WAFの構築 | Developers.IO
テストWEBサーバはEC2インスタンスにNginxを入れて文字だけを表示するページ一枚のサイトです。 WEBサイトの内容に関係なくWordPress向けのルールや、SQL向けのルールも検知してくれました。
テストWEBサーバにcurlでリクエストした様子
curl http://[test_domain]
<html>
<head>
<meta charset="utf-8">
<title>Simple Test Site</title>
</head>
<body>
こんにちは、網走<br>
</body>
</html>やってみた
AWS managed rule groupsの中から９個のルールセットに対して簡単な疑似攻撃のリクエストパターンを備忘録です。 ルールセットの優先順位によっては意図しないルールで優先的に検知する可能性がございます。
注意：テストする際はご自身で管理されているドメインとAWS WAFの環境で試してください。
ルールセット内の個別のルールについての詳細はこちらをご参照ください。
AWS Managed Rules rule groups リスト - AWS WAF、AWS Firewall Manager、および AWS Shield アドバンスド
Admin protection
管理者保護ルールグループには、公開されている管理ページへの外部アクセスをブロックするためのルールが含まれています。これは、サードパーティーのソフトウェアを実行している場合や、悪意のあるアクターがアプリケーションへの管理アクセスを得るリスクを軽減したい場合に便利です。
WordPressの初期インストールページにアクセスすることで検知できました。 当初WordPressが必要になるかと思っていたのですが、リクエスト時に特定の文字列が含まれていれば検知されるようです。 テストWEBサイトにこのようなページは存在しておりませんので、ログ生成目的であれば簡単にテストできます。
curl http://[test_domain]/wp-admin/install.php
Anonymous IP list
匿名 IP リストルールグループには、ビューワー ID の難読化を許可するサービスからのリクエストをブロックするルールが含まれています。たとえば、VPN、プロキシ、Tor ノード、ホスティングプロバイダー (AWS を含む) からのリクエストです。このルールグループは、アプリケーションから ID を隠そうとするビューワーを除外する場合に便利です。これらのサービスの IP アドレスをブロックすると、ボットの軽減や地理的制限の回避に役立ちます。
なるほど、Tor経由でアクセスするだけでよさそうです。 DockerでTorプロキシーサーバをたて、プロキシー経由してテストWEBサイトにアクセスして検知できました。 ELBのセキュリティグループで特定のIP・ポートからのアクセスのみ許可している場合、一時的にTor経由のグローバルIPを許可しないとアクセスできないため検証できません。 検証後はすみやかに設定を戻してください、危険です。
docker run -d --name tor-socks-proxy -p 127.0.0.1:9150:9150/tcp peterdavehello/tor-socks-proxy:latest
docker start tor-socks-proxy
curl https://ipinfo.io/ip # 現在のグローバルIPを確認
curl --socks5-hostname 127.0.0.1:9150 https://ipinfo.io/ip # Tor経由のためグローバルIPが変更されていることを確認
curl --socks5-hostname 127.0.0.1:9150 http://[test_domain] # Tor経由で対象のドメインにアクセス
docker stop tor-socks-proxy個別のルール名は「HostingProviderIPList」で検知しています。 「匿名化することがわかっているソース」と說明されているルール名「AnonymousIPList」で検知するものだと思っていたのですが違いました。
Core rule set
コアルールセット (CRS) ルールグループには、ウェブアプリケーションに一般的に適用可能なルールが含まれています。これは、OWASP の出版物に記載されている高リスクの脆弱性や一般的な脆弱性など、さまざまな脆弱性の悪用に対する保護に役立ちます。すべての AWS WAF ユースケースでこのルールグループを使用することを検討してください。
ルールセット内の個別ルールに「HTTP User-Agent ヘッダーのないリクエストをブロックします。」と説明があるため、ヘッダーのないリクエストを送り検知できました。
curl -H 'User-Agent: ' http://[test_domain]個別のルール名は「NoUserAgent_HEADER」で検知しています。
Known bad inputs
既知の不正な入力ルールグループには、無効であることがわかっており脆弱性の悪用または発見に関連するリクエストパターンをブロックするルールが含まれています。これにより、悪意のあるアクターが脆弱なアプリケーションを発見するリスクを軽減できます。
ルールセット内の個別ルールに「URI パスに、悪用可能なウェブアプリケーションパスにアクセスする試みがないかを検査します。パターンの例には、web-inf などのパスがあります。」と説明があるため、WEB-INFディレクトリ配下の設定ファイルにアクセスを試みることで検知できました。 テストWEBサイトにこのページは存在していませんが、リクエスト時に特定の文字列が含まれていれば検知されます。
curl http://[test_domain]/WEB-INF/web.xml個別のルール名は「ExploitablePaths_URIPATH」で検知しています。
Linux operating system
Linux オペレーティングシステムルールグループには、Linux 固有のローカルファイルインクルージョン (LFI) 攻撃など、Linux 固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者がアクセスしてはならないファイルの内容を公開したり、コードを実行したりする攻撃を防ぐことができます。アプリケーションの一部が Linux で実行されている場合は、このルールグループを評価する必要があります。このルールグループは、POSIX オペレーティングシステム ルールグループと組み合わせて使用する必要があります。
テストWEBサーバの/etc/passwdを表示できないか試みるリクエスト送り検知できました。
特定の文字列がキーのようで末尾のdを抜いた/etc/passwでは検知しませんでした。
curl http://[test_domain]/../../etc/passwd個別のルール名は「LFI_URIPATH」で検知しています。
PHP application
PHP アプリケーションルールグループには、安全でない PHP 関数のインジェクションなど、PHP プログラミング言語の使用に固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者が許可されていないコードまたはコマンドをリモートで実行できる脆弱性の悪用を防ぐことができます。アプリケーションが連結するサーバーに PHP がインストールされている場合は、このルールグループを評価します。
実際に攻撃を受けて検知パターンがわかり、調べたところPHPのフレームワークThinkPHPの脆弱性を突く攻撃でした。 特定の文字列が含まれていれば検知する仕組みのようなのでパスを加工して紹介します。
curl "http://[test_domain]/index.php?s=call_user_func_array"個別のルール名は「PHPHighRiskMethodsVariables_QUERYARGUMENTS」で検知しています。
POSIX operating system
POSIX オペレーティングシステムルールグループには、POSIX および POSIX と同等のオペレーティングシステムに固有の脆弱性の悪用 (ローカルファイルインクルージョン (LFI) 攻撃など) に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者がアクセスしてはならないファイルの内容を公開したり、コードを実行したりする攻撃を防ぐことができます。アプリケーションの一部が POSIX または POSIX と同等のオペレーティングシステム (Linux、AIX、HP-UX、macOS、Solaris、FreeBSD、OpenBSD など) で実行されている場合は、このルールグループを評価する必要があります。
說明を読んでもアクセスパターンが思いつきませんでした。 WEBアプリケーション脆弱性スキャナーのNikto2を使ってスキャンをかけることにしました。 結果は大量に検知したためテスト用に一部加工したパターンを紹介します。
curl "http://[test_domain]/ans.pl?p=../../usr/bin/id"個別のルール名は「UNIXShellCommandsVariables_QUERYARGUMENTS」で検知しています。
SQL database
SQL Database ルールグループには、SQL インジェクション攻撃などの SQL データベースの悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、不正なクエリのリモートインジェクションを防ぐことができます。アプリケーションが SQL データベースと連結している場合は、このルールグループを評価します。
Nikto2でスキャンかけた結果から簡単に試せるパターンを紹介します。 テストWEBサーバにデータベースはありませんが、リクエスト時に特定の文字列が含まれていれば検知されます。
curl "http://[test_domain]/?pattern=/etc/*&sort=name"個別のルール名は「SQLi_QUERYARGUMENTS」で検知しています。
WordPress application
WordPress アプリケーションルールグループには、WordPress サイト固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。WordPress を実行している場合は、このルールグループを評価する必要があります。このルールグループは、SQL データベース および PHP アプリケーション ルールグループと組み合わせて使用する必要があります。
Nikto2でスキャンかけた結果から簡単に試せるパターンを紹介します。 テストWEBサーバはWordPressではなく静的なサイトですが、リクエスト時に特定の文字列が含まれていれば検知されます。
curl http://[test_domain]/crossdomain.xml個別のルール名は「WordPressExploitablePaths_URIPATH」で検知しています。
ログの分析
AWS WAFのログをS3バケットに保存している場合は、テストしたログを詳細に確認したくなるかと思います。
確認方法はこちらをご参考にしてください。
S3に保存した AWS WAFログを Athenaで分析してみる | Developers.IO
おわりに
AWSマネージドルールを使えば楽にAWS WAF導入できて便利ですね。検知したログ欲しさにcurlを打ち続けた記録でした。どなたかのお役に立てれば光栄です。
5
