Last update: May 8th 2023
There are several use cases for geo-location information in Citrix ADC / NetScaler.
- It may be helpful with WAF logs. I am European, I won’t spend much time on a positive, if the log comes from North Korea, but I would consider it to be a “false positive”, if it comes from Germany, Italy or Sweden.
- Even though I would not consider it to be secure, not even useful to elevate security, some of my customers want to “geo-fence” their applications. They want to drop requests not coming from a hand full of countries.
- In Gateway deployments it may be used to send people to the Virtual Appa and Desktops farm closest to local data.
There may be some more use cases. All of them have something in common: Even though, Citrix ADC / NetScaler supports Geo-Location based decission and may support adding Geo-Information into log files, it will turn out to fail. There is an important step missing.
Preparing a Citrix ADC / NetScaler for use of Geo-Location
It’s surprisingly easy: 2 command line commands, and the problem is solved! There are built in location files in /var/netscaler/inbuilt_db/: one of them for IP v4 (Citrix_Netscaler_InBuilt_GeoIP_DB_IPv4) and the other one for v6 (Citrix_Netscaler_InBuilt_GeoIP_DB_IPv6). These files origin from GeoLite.
Unfortunately, this database may not be suitable to your needs. Maybe you want to use a “private” geolocation database for your company (10.0.0.1-10.127.255.255.254 is Europe, 10.128.0.1 to 10.240.255.254 is Asia, 10.241.0.1 to 10.253.255.254 is Africa, the rest America). So you have to create a data base on your own. This is described in CTX130155. Perhaps, you want to import a fresher version into your Citrix ADC / NetScaler? So you may download the file from GeoLite and convert it for Citrix AD / NetScaler using this tool.
Geo-location files have to get imported into ADC:
add locationFile /var/netscaler/inbuilt_db/Citrix_Netscaler_InBuilt_GeoIP_DB_IPv4.
set locationParameter -matchWildcardtoany YES
This will create a location file at /var/netscaler/locdb/nslocation.db. The same, of course, may be done using GUI. The second line of code will allow wildcard characters to match locations, i.e. *.AT.*.*.*.* for Austria, instead of specifying Europe as well.
This data base may be tested easily.
nsmap -d -t <ip>
will return geo-location information for this IP address. I tested my own webserver’s IP and found out, it’s located in Europe/Austria. That’s great! Big surprise!
Creating responder-policies to drop requests from certain countries
Before actually creating a responder policy, we should think about which action would be the most suitable.
Responders allow NOOP, DROP and RESET. There are some custom actions as well (Redirect, Respond With, Redirect and Respond with HTML page).
Our plan is to hide our server from certain users, so I think, dropping silently would be the best suitable method. This means, to pretend, there is nothing. A reset would give too much feedback, it would mean: “I am there, but I don’t want to respond to your request”. We could do customized response, responding with a 500 (internal server error), but I don’t see and advantage over a simple drop.
So I will create a policy, to dropp North Korean users:
add responder policy res_pol_drop_NorthKorea "CLIENT.IP.SRC.MATCHES_LOCATION(\"*.KP.*.*.*.*\")" DROP [-logAction log_locationInformation]
You may see, I added a custom logging policy (see my blog about this subject). This is an optional step of course .The logging policy would look like that:
add audit messageaction log_locationInformation NOTICE "\"dropped request for \" + CLIENT.IP.SRC + \" from \" + CLIENT.IP.SRC.LOCATION" add responder policy res_pol_drop_NorthKorea "CLIENT.IP.SRC.MATCHES_LOCATION(\"*.KP.*.*.*.*\")" DROP -logAction log_locationInformation
The output would look like that:
Dropping (or allowing) access from several countries
If you want to drop all, but connections from, let’s say, Austria, you would create a policy with expression
CLIENT.IP.SRC.MATCHES_LOCATION(\"*.AT.*.*.*.*\").NOT
But what about several? Let’s say, Bulgaria, Portugal and Ireland?
CLIENT.IP.SRC.MATCHES_LOCATION(\"*.BG.*.*.*.*\").NOT && CLIENT.IP.SRC.MATCHES_LOCATION(\"*.PT.*.*.*.*\").NOT && CLIENT.IP.SRC.MATCHES_LOCATION(\"*.IE.*.*.*.*\").NOT
(I had a little mistake about Ireland. Thanks, Stuart, for pointing out! I had an other mistake about and and or (shame on me) Thanks Joris for telling me!)
Using location information in Citrix ADC / NetScaler WAF Logs
When examining Web Application Firewall (WAF) logs, it is very important to know whether the logged information is “false positive” or not. Location information will never prove to be a completely safe criterion, but it is a good indicator. One of my clients is a European bank. Their customers are spread all over Europe and three countries in the Arab world. So they wouldn’t consider a “positive”, coming from an American IP address, to be hardly meaningful, while one that, say, comes from Poland, is treated seriously.
Because of this, Citrix ADC / NetScaler supports adding geo-location information into WAF logs. It’s just a checkbox away (or, 2 check boxes, to be 100% honest). It is a general WAF setting.
CEF logging is a prerequisite for Geo-location logging
I hope, it made sense to you. I’d be happy to get feedback!
Johannes
Hi,
Don’t forget to run
set locationParameter -matchWildcardtoany YES
If not, some locations will show i.e Europe.SE.Ostergotland.*.*.* and that will not match Europe.SE.*.*.*.*
Thanks, I will add this line to my blog
Can we make a fake location?
There is nothing like a faked location currently supported. But you could add an IP into the data base
So which important step is missing? Hey does it turn out to fail?
Holgi, I didn’t get your question. It works fine.
Johannes
thank you for an excellent article.
If I want to apply this to a Gateway vServer rather than a WAF/LB/CS, will it still do GeoLocation Logging? you say that CF logging has to be ticked for GeoLocTION LOGGING but that option isn’t available in the Gateway
Regards
Ken Z
No, that’s not possible. But you could attach a policy (responder, rewrite, …) and add an Audit message like this one:
add audit messageaction log_position WARNING "\"Access from \" + CLIENT.IP.SRC + \" coming from \" + CLIENT.IP.SRC.LOCATION". Don’t forget to enable user configurable log messages (see https://blog.norz.at/citrix-netscaler-logging-and-policy-trouble-shooting/)Hi,
Just in case someone tries to copy the example of Several Countries, (\”*.IR.*.*.*.*\”) is Iran. Ireland is IE.
Oh. Yes. Absolutely. You are right. I have fixed it. Would not have been a perfect solution
Hi,
your expression for multiple countries:
CLIENT.IP.SRC.MATCHES_LOCATION(\\”*.BG.*.*.*.*\\”).NOT || CLIENT.IP.SRC.MATCHES_LOCATION(\\”*.PT.*.*.*.*\\”).NOT || CLIENT.IP.SRC.MATCHES_LOCATION(\\”*.IE.*.*.*.*\\”).NOT
Is not correct.
A rule is executed when the result is the Expression is TRUE, however, let”s say you come from BG: you get a
FALSE or TRUE or TRUE which result to TRUE, so you are from BG but you will be dropped 🙁
the expression should be with && in stead of ||, like below.
CLIENT.IP.SRC.MATCHES_LOCATION(\\”*.BG.*.*.*.*\\”).NOT && CLIENT.IP.SRC.MATCHES_LOCATION(\\”*.PT.*.*.*.*\\”).NOT && CLIENT.IP.SRC.MATCHES_LOCATION(\\”*.IE.*.*.*.*\\”).NOT
kind regards,
Joris
Thanks, you’re right. I’ll fix it immediately.
Hi,
Have you an idea, why the default WAF Syslog message allways show Geolocation=Unknown?
I activated CEF and Geolocation-Logging. When I run nsmap -d -t <ip> I can see the location. I created a custom log with the option “Geolocation: CLIENT.IP.SRC.LOCATION” and the syslog server shows the location. But the default WAF log is still showing Geolocation=Unknown.
Thank you and Regards,
Roberto
Unfortunately not. It works fine with all my customer’s environments.
Can you use this to block anything BUT a continent ? And I mean without placing all the countries from that continent in the Policy .
Thank you.
Sort of. You need two policies:
add responder policy rs_pol_allow-Austria "CLIENT.IP.SRC.MATCHES_LOCATION(\"*.AT.*.*.*.*\")" NOOPadd responder policy rs_pol_deny_all true DROP
bind lb vserver lb_vs_test -policy rs_pol_allow-Austria -priority 100 -gotoPriorityExpression ENDbind lb vserver lb_vs_test -policy rs_pol_deny_all -priority 10000 -gotoPriorityExpression END
That way, connections from Austria would be OK, the priority of
rs_pol_allow-Austriais 100 which is the higher priority.All other requests would get caught by
rs_pol_deny_all(which has a very high priority number, so you could add some more responder policies in front of it).