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.
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
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 it out!)
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.
I hope, it made sense to you. I’d be happy to get feedback!