Detecting Suspicious IP Behavior and Impossible Travel
CrowdSec Security Engine 1.5 in Action — Part II
Welcome to the second part of our CrowdSec Security Engine 1.5 in Action series!
In part one, we saw how to detect a successful SSH brute force attack with the new Security Engine v1.5 feature, conditional scenarios.
In this installment, I’ll demonstrate how you can leverage the same feature to detect impossible travel — aka an account connecting from two different locations, far from each other, in a short amount of time.
We will use the SSHD service again as an example for this article, but this feature can be used for any service logging authentication.
Setup the acquisition (optional)
Same as in part one, in this article, I'm running the CrowdSec Security Engine in replay mode. If you want to use service mode, you need to set up the acquisition.
Install the SSHD collection
You can find the collection here.
Parse successful authentication
As already seen in part one, this is the parser node to parse successful SSH authentication:
Enrich event with IP geolocation
To detect that an account connected from two different locations in a short amount of time, we need information on the geolocation of the source IP address.
We can get this info by installing the geoip-enrich parser.
Note: You can skip this step if you have already installed this parser.
Now we need to check that the IPs filled in our buckets are more than 1000km away from each other.
Here is the condition that we will use for our conditional bucket:
This condition checks that the buckets contain at least two events and that the distance between the IPs in those events is more than 1000km away. We can achieve that using the Distance() helper, which uses the Haversine formula to determine the distance between two points with their longitude and latitude.
Here is the full scenario that detects an account connecting from more than 1000km away since its last connection in 4 hours:
To make this scenario work, we must group the events by targeted user and only look at distinct IP addresses in the bucket.
Note: we set user as the scope for this scenario. If your profile configuration generates a decision only for alert with scope IP, triggering this scenario will not lead to any decision.
Bonus: Add context to the alert
With this scenario, the CrowdSec Security Engine will only log the user targeted by the attack. But it is also interesting to know from which IPs and countries the user logged in. To do that, I will use the new CrowdSec feature, called Alert Context. See more about this feature here.
To add the source IP addresses and the source countries, we need to run the following commands:
When you inspect an alert, you will be able to see all the source IPs and countries that have been poured into the bucket.
Test with CrowdSec replay mode
We can test this scenario with the CrowdSec replay mode to ensure everything works properly.
Here are some logs that represent two successful authentications from two different IPs, in 2 different countries, and in 2 hours intervals:
We can run the CrowdSec replay mode with the following command:
Tada! The impossible travel from the user root has been detected by CrowdSec!
To test this scenario in real life, we will connect to our server via SSH from France for the first time, and then, a few minutes later, we will use a VPN to connect to our server from Spain.
Note: First, don’t forget to restart CrowdSec since we have edited some parsers and scenarios and added context to alerts.
So, let’s connect for the first time on our server with the demo account:
Then we use our VPN to connect to the server in Spain:
And we connect again to our server with the same command.
The CrowdSec Security Engine has successfully detected this impossible travel:
With the Alert Context feature that we enabled before, we can see the two IP addresses and countries in the alert:
The conditional feature in CrowdSec Security Engine 1.5 is a powerful tool!
We already saw how to use it in detecting successful brute force attacks and impossible travel.
But did you know you can also use the conditional feature to detect post-exploitation? Come back to read part three of CrowdSec Security Engine 1.5 in Action series to learn how to do it.