min-width: mobile
min-width: 400px
min-width: 550px
min-width: 750px
min-width: 1000px
min-width: 1200px

Blog & News

Detecting the adversary with Sagan & GeoIP

Posted by Champ Clark on September 23, 2014

GeoIP (i.e., determining the physical location of an IP address) has been a log analysis tools for quite some time.  Although mapping IP addresses in logs to physical locations is not new, it is sometimes disheartening to see these tools only used in very simplistic, unhelpful ways.  For instance, one popular log analysis tool just adds GeoIP data to alerts; “an invalid login just occurred, and the source of the invalid login is from Russia”. Unfortunately, this sort of information is mildly interesting, at best, although one could argue that GeoIP data in alerts can show patterns and trends. On the other hand, I would argue that even the trend data via GeoIP would not tell you very much about current or future attacks.

Sagan uses GeoIP data in a different way; it uses GeoIp data as part of the detection scheme. Let's take a look at a Sagan rule that uses GeoIP data:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTPS_PORT (msg: "[CISCO-GEOIP] VPN Login from outside HOME_COUNTRY"; program: %ASA-6-716038; country_code: track by_src, isnot $HOME_COUNTRY; classtype: successful-user; parse_src_ip: 1; fwsam: src, 1 day; reference: url, wiki.quadrantsec.com/bin/view/Main/5001868; sid: 5001868; rev: 1;)

This rule is from the Sagan cisco-geoip.rules. When a Sagan rule contains a “-geoip.rules” within its name, it indicates that part of the detection process Sagan uses is GeoIP driven. 
When a Cisco ASA sends logs via syslog, it assigns a Cisco “code” in the field typically reserved for the “program” name. This is useful in that Sagan can determine the log’s contents without ever having to parse the syslog “message” portion.   The “%ASA-6-716038” translates to:

“%ASA-6-716038: Group group User user IP ip Authentication: successful,
Session Type: WebVPN.”


When Sagan detects a log with the program field “%ASA-6-716038”, it knows that a user just “successfully” logged in via a WebVPN.  However, the detection of successful logins via WebVPN isn't terribly interesting in-and-of-itself. The part of the rule that does make detection of successful WebVPNs interesting is as follows:

country_code: track by_src, isnot $HOME_COUNTRY;

What we are telling Sagan is that we are interested in the GeoIP location of the successful WebVPN connection.  In particular, we are interested in the source address of the valid WebVPN connection.   What we are asking Sagan to do is create an alert if it detects a valid WebVPN connection AND the source address “isnot” in our $HOME_COUNTRY.  How is the $HOME_COUNTRY defined?  Within the sagan.conf,   we can declare the $HOME_COUNTRY variable like this:


This means that Sagan will generate an alert when it detects a valid “WebVPN” connection whose source address “isnot” from the United States or Canada.  Sagan can also take matters into its own hands via this Sagan rule option:

fwsam: src, 1 day;

This allows Sagan to communicate to “Snortsam” sensors and automatically “block” or “firewall” the inbound connection, in real time!   Sagan could also easily be configured to fire off a custom shell script to mitigate the attack.

Over the past six months, Quadrant Information Security has used this simple, yet effective, detection technique to mitigate three “stolen” VPN credentials incidents. Specifically, Sagan was able to detect that a WebVPN connection was being established from a suspicious location.   Quadrant Information Security was able to relay this information to its affected customers, who were then able to terminate the VPN connection and start the mitigation process. A benefit that came from discussions after Sagan detected these types of attacks was the apparent need for these and other organizations to deploy two factor authentication!

A central feature of Sagan that I have highlighted numerous times is its primary goal of detecting these types of attacks as they happen. If we discover via log analysis one week later that a VPN connections was established from a suspicious location, the damage is likely already done, meaning that the attacker has had plenty of time to exfiltrate data out of the network.  

This has become a popular attack vector, with Target as a prime example.  Stolen VPN credentials appear to be on the rise, which makes timely detection much more important. 
Sagan comes “out of the box” with “stock” GeoIP enabled rules for various protocols.  For example, SSH, FTP, RDP, Cisco, Fortigate and many more are available.   We invite you to browse our GitHub rules.  

We also offer other detection techniques like our Sagan and Websense integration.

Posted in Sagan Blog Post