Am I missing anything here?

[Blason R]

Hi Team,

Trying to restrict access only through one country with below rule and not sure whats going wrong. Can someone please help?

vi REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

SecRule REMOTE_ADDR "@geoLookup" \
                "chain,\
                id:22,\
                drop,\
                msg:'BLocking China IP address'"
SecRule GEO:COUNTRY_CODE "!@streq CN"

nginx -t
nginx: [emerg] "modsecurity_rules_file" directive Rules error. File: /etc/nginx/modsec/vendorportal/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf. Line: 172. Column: 71. Expecting an action, got:  # bring additional examples which can be useful then tuning a service. in /etc/nginx/conf.d/vendorportal.nrb.co.in.conf:6
nginx: configuration file /etc/nginx/nginx.conf test failed

[Andrew Howe]

Hi Blason,

> nginx: configuration file /etc/nginx/nginx.conf test failed

I see that you're using nginx.

The configuration snippet you provided does *not* cause an error with
ModSecurity in Apache. I've tested and confirmed that your config
snippet *does* cause an error with ModSecurity (v3) in nginx.

I think this must be a 'quirk' with the configuration parser in nginx.
Try adding a newline after your final rule:
"SecRule GEO:COUNTRY_CODE..."
That should work.

My guess is that the configuration parser under nginx will accept either
SecRule VARS OPERATOR ACTIONS EOL EOF
or
SecRule VARS OPERATOR EOL EOF
but not just
SecRule VARS OPERATOR EOL

As a note, I'd recommend explicitly putting your geolocation rule in
phase 1 so that you drop connections as early as possible (e.g. no
body processing to take place for geo-blocked clients).

Do you have a SecGeoLookupDb directive defined somewhere? Also, your
rule's message doesn't match its meaning: the rule is set to drop all
*non*-Chinese IP addresses at present:
GEO:COUNTRY_CODE "!@streq CN"
Although maybe you were just testing different things to try and make it work...

Thanks,
Andrew

[Blason R]

HI Andrew,

Well I am not clear on the part you said. What exactly changes should I implement?

And yes I am testing the setup hence can safely ignore the message.

Do you mean this?

SecRule GEO:COUNTRY_CODE "!@streq CN" EOL EOF

[Blason R]

And forgot to mention - my SecGeoLookupDB is

SecGeoLookupDB /usr/share/GeoIP/GeoLite2-Country.mmdb

[Blason R]

Thanks Andrew - That works for me

Rule REMOTE_ADDR "@geoLookup" \
                "chain,\
                id:22,\
                drop,\

                msg:'Non-India IP address'"
SecRule GEO:COUNTRY_CODE "!@streq IN"

And rule phase 1 should look like this?

Rule REMOTE_ADDR "@geoLookup" \
                "chain,\
                id:22,\

                deny,\

                phase:1 \

                msg:'Non-China IP address'"

SecRule GEO:COUNTRY_CODE "!@streq CN"

[Andrew Howe]

Hi Blason,

> Thanks Andrew - That works for me

Glad to hear it worked.

> And rule phase 1 should look like this?
>
> Rule REMOTE_ADDR "@geoLookup" \
> "chain,\
> id:22,\
> deny,\
> phase:1 \
> msg:'Non-China IP address'"
> SecRule GEO:COUNTRY_CODE "!@streq CN"

Yes, that looks good. Personal preference (and CRS policy): it's
always a good idea to indent chained rules. Indentation makes the
chain-ing easier to spot and makes the rule flow easier to read.

Maybe you've already determined that this is the best solution for
your use case. However, it is worthwhile to consider the question: is
ModSecurity the *best* place to perform geolocation logic?
Can this same outcome be achieved:
- at the (edge) firewall? Geo-blocked packets then never hit the WAF
and never consume any WAF resources.
- in nftables etc. on the WAF machine? Geo-blocked packets are then
caught much earlier and never hit ModSecurity, hence they consume much
fewer resources.
- in the web server that holds ModSecurity, e.g. Apache, nginx?
Generally more flexible, and makes it easy to add geolocation info as
request headers: your back end servers can use and log the info for
statistics, troubleshooting, etc. (e.g. X-Country-Code: PS)
Just some ideas, which may or may not be helpful.

Thanks,
Andrew

[Blason R]

Thats great idea!! Let me see nftables.

Does anyone have any ready references for nftables and GeoLocation?

[Andrew Howe]

Hi Blason,

> Does anyone have any ready references for nftables and GeoLocation?

The nftables wiki has a page with examples:
https://wiki.nftables.org/wiki-nftables/index.php/GeoIP_matching

It requires a bit of setup and juggling between formats, but I think
the end result would be worth it. It's the approach I would personally
take if I needed to implement geolocation blocking.

Also, if working with older machines, ipset can be used to do
something very similar. (There are lots of ipset tutorials around that
cover this.)

Thanks,
Andrew

[Blason R]

Well - Thanks again. This will not work with my setup since I am serving around 15 portals on my nginx reverse proxy and certain urls needs to be accessed globally while certain from specific countries.

But thanks for the suggestion though.