Email alerting on geographically suspicious firewall connections using, geoiplookup and AbuseIPDB


Earlier this week, we released, a simple python tool that can be used to pipe standard output to email for the purpose of alerting. In this blog post we want to give a concrete example of how can be used to get simple & reliable email notifications about suspicious firewall connections, based on geographical information.

We understand that a few bash scripts and email notifications will not replace your full-fledged SIEM or other monitoring solutions – we love these systems ourselves & use them everyday! However, in a smaller environment, or for a simple use case, the use of built-in Unix tools in combination with and some external lookup services can be very powerful. We want to demonstrate that through a practical example in this blog post.

For those who just want to see the example script, you can find it here:

For those wanting a bit more context, read on!

Detecting suspicious firewall connections

In this example, we want to build a simple use case that can detect suspicious firewall connections that require further investigation. We want to achieve the following:

  • Run through all firewall ACCEPT events.
  • Check each inbound connection for requests coming from suspicious countries.
  • For each of the suspicious requests, perform an automated lookup against a reputation database online (e.g. AbuseIPDB) and report on the IPs that are not yet known to be malicious (which are most likely automated scanners).
  • All firewall ACCEPT events that pass the above two checks (suspicious country & not yet known to be part of the abuse database) are reported through

The example implementation of this use case, along with comments for each command, can be found here:

A few remarks:

  • You need to register for an AbuseIPDB account (free plan is sufficient) in order to get your API key.
  • In our example, all firewall ACCEPTS are logged to /var/log/syslog. Your log source might be different and you might want to focus on other events containing IP information too (logon events, DROP events, etc.). In our case, the number of ACCEPT events on the firewall is very low (management system), so the approach to investigate them in this way is doable.
  • The part of the command “grep -v -f /home/pi/scripts/logalert_whitelist.txt” will ignore alerts for countries we don’t want to alert on. It might for example contain the following string if that’s where our teams are operating from: Firewall accept from Belgium .
  • You can modify the parameters to the AbuseIPDB API call to your own liking (different filtering on reputation, longer history window, etc.). In our case, we decided to ignore all known malicious hosts and focus on the unknown suspicious ones instead.

When testing this example, we can verify that we receive a successful alert by email. This confirms that our use case works, resulting in the below example email being sent.

In order to trigger the test, we changed the filter to include all known malicious hosts using the grep '"abuseConfidenceScore":100' filter in the use case instead of grep '"abuseConfidenceScore":0'to ensure we got some hits – we were sure our firewall logs would have several accepted connections for already known malicious hosts!

Final thoughts

In this blog post we demonstrated a very simple but effective way to alert on geographically suspicious firewall connections. Although the example is used in a low-interaction environment (management interface of a router), it illustrates how combining open source tools with the power of command line tools can give you visibility into security-related events happening in your environment.

We have also published a bunch of other examples to inspire you on how could be useful in your environment to get started with simple but effective alerting.

About the author

Daan Raman is in charge of NVISO Labs, the research arm of NVISO. Together with the team, he drives initiatives around innovation to ensure we stay on top of our game; innovating the things we do, the technology we use and the way we work form an essential part of this. Daan doesn’t like to write about himself in third-person. You can contact him at and find him on Twitter and LinkedIn.

Leave a Reply