Re: [mod-security-users] Geo Proxy Blocking - I WANT THIS!
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] Geo Proxy Blocking - I WANT THIS!
|
From: Ryan B. <RBa...@tr...> - 2011-02-02 21:07:20
|
From: Sergio <se...@gm...<mailto:se...@gm...>>
Date: Wed, 2 Feb 2011 14:32:14 -0600
To: Ryan Barnett <rba...@tr...<mailto:rba...@tr...>>
Cc: Liddy <lid...@gm...<mailto:lid...@gm...>>, "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: Re: [mod-security-users] Geo Proxy Blocking - I WANT THIS!
Ryan,
what is the lastest version of this rule?
The version below is the latest -
SecRule REQUEST_HEADERS:X-Forwarded-For "^\b\d{1,3}(?<!192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}\b" \
"chain,phase:1,t:none,capture,block,msg:'GEO Mismatch of X-Forwarded and Remote-addr Country',logdata:'IP Country is: %{geo.country_code} and
X-Forwarded-For is: %{tx.geo_x-forwarded-for}'"
SecRule TX:0 "@geoLookup" "chain,setvar:tx.geo_x-forwarded-for=%{geo.country_code}"
SecRule REMOTE_ADDR "@geoLookup" "chain,t:none"
SecRule GEO:COUNTRY_CODE "!@streq %{tx.geo_x-forwarded-for}"
Let me know how it works for you.
-Ryan
Regards,
Sergio
On Wed, Feb 2, 2011 at 9:25 AM, Ryan Barnett <RBa...@tr...<mailto:RBa...@tr...>> wrote:
Liddy,
Were you able to do more testing? This rule seems to work for me fine.
What version of ModSecurity are you using?
-Ryan
On 1/29/11 7:10 PM, "Ryan Barnett" <RBa...@tr...<mailto:RBa...@tr...>> wrote:
>
>On 1/29/11 2:58 PM, "Liddy" <lid...@gm...<mailto:lid...@gm...>> wrote:
>
>>Oh boo. The rule does not quite work.
>>
>>First one is SG = SG, blocked
>>
>>Remote: 220.255.2.52
>>X-Forwarded-For: 220.255.29.212
>>
>>Match of "streq %{tx.geo_x-forwarded-for}" against "GEO:COUNTRY_CODE"
>>required. [file "/home/servtast/modsecurity/countries.conf"] [line "16"]
>>[msg "GEO Mismatch"] [data "IP Country is: SG and X-Forwarded-For is:
>>SG"]
>
>
>Hmm... I am testing these using this ruleset -
>
>SecGeoLookupDb
>/usr/local/apache/conf/modsec_current/base_rules/GeoLiteCity.dat
>SecRule ARGS:X-Forwarded-For
>"\b\d{1,3}(?<!192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}\b$"
>"chain,phase:1,t:none,capture,block,msg:'GEO Mismatch of X-Forwarded and
>Remote-addr Country',logdata:'IP Country is: %{geo.country_code} and
>X-Forwarded-For is: %{tx.geo_x-forwarded-for}'"
> SecRule TX:0 "@geoLookup"
>"chain,setvar:tx.geo_x-forwarded-for=%{geo.country_code}"
> SecRule ARGS:remote_addr "@geoLookup" "chain,t:none"
> SecRule GEO:COUNTRY_CODE "!@streq
>%{tx.geo_x-forwarded-for}"
>
>
>Notice that I am passing the x-forwarded-for and remote_addr as arguments.
> This allows me to test with requests like this -
>
>http://localhost/foo.php?remote_addr=220.255.2.52&x-forwarded-for=220.255.
>2
>9.212
>
>I just ran this request using these rules and everything works fine. As
>the both resolve to SG, the last SecRule does not trigger. In your case,
>however, it is triggering for some reason - even though the country_code
>is the same.
>
>What version of ModSecurity are you using? I am running the latest
>v2.5.13.
>
>
>>
>>===
>>
>>Next is - are you sure the last IP is the origin?
>
>Ah, good catch. I had that back-wards :( Just checked wikipedia and is
>states this -
>
>The general format of the header is:
>
> X-Forwarded-For: client1, proxy1, proxy2
>
>where the value is a comma+space separated list of IP addresses, the
>left-most being the farthest downstream client, and each successive proxy
>that passed the request adding the IP address where it received the
>request from. In this example, the request passed proxy1, proxy2 and
>proxy3 (proxy3 appears as remote address of the request).
>
>
>So, we should probably change the ruleset to this (changed the anchors
>from the end-of-line ($) to beginning-of-line (^) -
>
>SecRule REQUEST_HEADERS:X-Forwarded-For
>"^\b\d{1,3}(?<!192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}\b"
>"chain,phase:1,t:none,capture,block,msg:'GEO Mismatch of X-Forwarded and
>Remote-addr Country',logdata:'IP Country is: %{geo.country_code} and
>X-Forwarded-For is: %{tx.geo_x-forwarded-for}'"
> SecRule TX:0 "@geoLookup"
>"chain,setvar:tx.geo_x-forwarded-for=%{geo.country_code}"
> SecRule REMOTE_ADDR "@geoLookup" "chain,t:none"
> SecRule GEO:COUNTRY_CODE "!@streq
>%{tx.geo_x-forwarded-for}"
>
>
>
>>
>>Remote: 163.28.112.100 - Taiwan
>>X-Forwarded-For: 109.230.221.139 (Germany) , 203.68.23.23 (Taiwan)
>>
>>So the connection was Taiwan -> Germany -> Taiwan? Weird - but still
>>spam.
>>
>>Anyway, same problem, TW = TW, blocked
>>
>>Match of "streq %{tx.geo_x-forwarded-for}" against "GEO:COUNTRY_CODE"
>>required. [file "/home/servtast/modsecurity/countries.conf"] [line "16"]
>>[msg "GEO Mismatch"] [data "IP Country is: TW and X-Forwarded-For is:
>>TW"]
>>
>>
>>Wouldn't we want to block the last hop? In the example above, the remote
>>IP is Taiwan, and the connection before that, Germany - isn't that the
>>mismatch we are trying to spot?
>
>Right - using the updated ruleset example from above - I tested with the
>IP addresses you listed above and I got this -
>
>[Sat Jan 29 19:01:34 2011] [error] [client ::1] ModSecurity: Warning.
>Match of "streq %{tx.geo_x-forwarded-for}" against "GEO:COUNTRY_CODE"
>required. [file
>"/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_15_custo
>m
>rules.conf"] [line "15"] [msg "GEO Mismatch of X-Forwarded and Remote-addr
>Country"] [data "IP Country is: TW and X-Forwarded-For is: DE"] [hostname
>"localhost"] [uri "/foo.php"] [unique_id "TUSqXsCoAWQAAQmMMDAAAAAA"]
>
>
>I think you have an issue with your ModSecurity version.
>
>
>>
>>
>>===
>>
>>I'm sure I'm nowhere near as good on regex's as I need to be (or Ryan
>>is) but I've tried a simpler regex. Having the closing $ should "work
>>backwards" and still pickup the last IP if there is more than one -
>>that's my theory anyway :)
>>
>> !(192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}$
>
>First issue here is that if you are using the ModSecurity operator
>negation (with the !) - then you can't do regular expression data capture.
> See the 1st SecRule with the capture action. This can usually be worked
>around by using macro expansion and %{matched_var} however in this case,
>the x-forwarded-for may have more than one IP address listed. This is why
>I went the route of using the regex negative lookbehind and capture.
>
>-Ryan
>
>
>> (!192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}$
>>
>>Running the edited rules it looks like they either do not trigger or
>>catch the local IP's so - fail.
>>
>>===
>>
>>Totally informal observation, but I might be tempted to block the 127 IP
>>addresses as they have been the spammers, perhaps servers are more 127
>>and local nets are 10 and 192... just a thought.
>>
>>
>>
>>
>>
>>Liddy
>>
>>
>>
>>On Jan 27, 2011, at 2:53 PM, Ryan Barnett wrote:
>>>
>>> Try this ruleset. I did some minimal testing and it seems to work -
>>>
>>> SecRule REQUEST_HEADERS:X-Forwarded-For
>>> "\b\d{1,3}(?<!192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}\b$"
>>> "chain,phase:1,t:none,capture,block,msg:'GEO Mismatch of X-Forwarded
>>>and
>>> Remote-addr Country',logdata:'IP Country is: %{geo.country_code} and
>>> X-Forwarded-For is: %{tx.geo_x-forwarded-for}'"
>>> SecRule TX:0 "@geoLookup"
>>> "chain,setvar:tx.geo_x-forwarded-for=%{geo.country_code}"
>>> SecRule REMOTE_ADDR "@geoLookup" "chain,t:none"
>>> SecRule GEO:COUNTRY_CODE "!@streq %{tx.geo_x-forwarded-for}"
>>>
>>>
>>>
>>> The trick here was to update the 1st SecRule and have a regular
>>>expression
>>> that will -
>>>
>>> 1) Capture the LAST IP address listed - as there may be more than one
>>>IP
>>> listed. For this rule, we want the origin IP which should be the last
>>>one
>>> listed.
>>> 2) In the RegEx, we need to do a negative lookbehind on the first octet
>>> captured in the IP and only match if it is NOT an internal one (10, 127
>>>or
>>> 192).
>>>
>>> From them on, it is similar processing.
>>>
>>> Let me know if this works for you.
>>>
>>> -Ryan
>>>
>>>
>>
>>
>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
mod-security-users mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html
|
