2

特定の URI パスに対する GET リクエストをブロックする必要があります。アノマリー モードを使用していますが、ストレート ブロック ルールを使用しているため、ルールが正しく機能しません。

例GET /secure/test/bla/bla/ 例https://bla.bla.com/secure/test/bla/bla?www.test.com

SecRule REQUEST_URI "@streq \/secure\/test\/bla\/bla\?.+" \
 "phase:1,id:92,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

これを reg 式で書いてもいいですか?

SecRule REQUEST_URI "!@rx ^(:?\/secure\/test\/bla\/bla\?.+)$" \
 "phase:1,id:91,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

これらが機能せず、その理由がわかりません。別の方法で正規表現を記述する必要がありますか?

2 番目のルールでは、追加する必要があり"@rxますか? 違いは何ですか"!@rx and @rx

4

1 に答える 1

3

したがって、これはこの質問の続きです: modsecurity create rule disable GET request

example GET /secure/test/bla/bla/ example
https://bla.bla.com/secure/test/bla/bla?www.test.com

これが何を意味するのかわかりません。より意味のあるものに書き換えることはできますか？URL に別のドメインが含まれると言っていますか?

あなたが与えた例にはいくつか問題があります。たとえば、この部分：

"@streq \/secure\/test\/bla\/bla\?.+"

@streqつまり、これは単純な文字列比較です。?.+したがって、正規表現の一部と思われる部分を使用することはできませんか? @streq正規表現が必要な場合は、それがデフォルトであるため、次のビットを含めないでください。

"\/secure\/test\/bla\/bla\?.+"

また、スラッシュをエスケープする必要はないと思いますが、そうしても害はありません。

また、これがあります：

SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

getリクエストをブロックしたいのに、なぜpostをチェックするのですか?

2 番目のルールでは、「@rx? Whats the difference between "!@rx and @rx" を追加する必要がありますか?

@rx は、後に続くものが正規表現であることを意味します。別の @ コマンドが提供されない限り @rx が想定されるため、これはデフォルトであるため、実際に含める必要はありません。

!@rx は、正規表現が一致しないことを意味します。つまり、この規則は、この正規表現に一致しない要求に適用されます。

これを reg 式で書いてもいいですか?

SecRule REQUEST_URI "!@rx ^(:?\/secure\/test\/bla\/bla\?.+)$" \
 "phase:1,id:91,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403

Access Denied',chain" SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

いいえ。これは、最初の正規表現に一致せず、投稿もブロックする必要があることを示しています。

したがって、/anything への POST リクエストはブロックされます。また、/anything への GET リクエストはブロックされません。これはあなたが望むものとは正反対のようです！ただし、/secure/test/bla/bla/ への POST は、最初のルールに一致しないため通過が許可されるため、引き続き許可されます。

明らかにこれを理解するのに苦労しているので、ModSecurity の基本を学ぶ必要があると本当に思います。

ModSecurity ルールの基本的な構文は次のとおりです。

SecRule \
  VARIABLE_TO_CHECK \
  VALUE_TO_CHECK_FOR \
  ACTION_TO_TAKE_IF_MATCHED \

\ を使用すると、読みやすくするためにルールを複数のラインに分けることができます。

  • VARIABLE_TO_CHECK は、ModSecurity 変数のリストのいずれかにすることができます ( https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables )

  • VALUE_TO_CHECK_FOR はデフォルトで正規表現です。たとえば、単純な文字列比較に変更できますが。VARIABLE_TO_CHECK の値と比較され、一致する場合は ACTION_TO_TAKE_IF_MATCHED が実行されます。一致しない場合、ModSecurity はこのリクエストに対するこのルールの処理を停止し、次のルールに進みます。

  • ACTION_TO_TAKE_IF_MATCHED はアクションのリストです ( https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions )。各ルールには ID が必要であり、通常は上記に一致するリクエストをブロックするか ( を使用deny)、ホワイト リスト リクエストをブロックします ( を使用 allow)。

たとえば、次のようになります。

SecRule \
  REQUEST_URI \
  "^/secure/test/bla/bla/.*" \
  "id:1234,deny"

/secure/test/bla/bla/ (GET および POST) へのすべてのリクエストを拒否します。

2 つの変数をチェックしたい場合は、2 つの異なるルールを連鎖させる必要があります。この場合、破壊的なアクション (拒否など) は、完全な連鎖がすべてのルールに一致する場合にのみ発生します。取った。

SecRule \
  REQUEST_URI \
  "^/secure/test/bla/bla/.*" \
  "id:1234,deny,chain"
 SecRule \
    REQUEST_METHOD \
    "GET"

したがって、このルールは、GET 要求でもある /secure/test/bla/bla/ で始まるすべての場所への要求を拒否します。

チェーン ルールを作成するとすぐに混乱する可能性があるため、最初に個々のルールをテストして適切にブロックされることを確認してから、それらをチェーンすることをお勧めします。

前にアドバイスしたように、 ModSecurity ハンドブックを購入して読んで、ModSecurity の仕組みを学ぶことを強くお勧めします。

于 2016-10-14T20:56:32.740 に答える