IP Reputation

Suricata also includes support for an IP address reputation system. Basically, Suricata can take three sets of lists: known good hosts, known bad hosts, and shared hosting machines. The idea is that this allows you to create rules for things like known command and control hosts for malware; in other words, IP addresses that you will never have a legitimate reason to connect to. You will find numerous lists of such malicious IPs – Google terms like "botnet ip address list" will result in a lot of results [11]. The known good list is, of course, known good addresses. I might list my testing network IPs, for instance, so I don't get spammed by alerts when I test exploits. The shared hosting list is meant for lists of IP addresses that host multiple websites; a major proxy provider like CloudFlare, for instance, might have thousands or more websites behind a single address.

Encrypted Traffic and Performance

It is pretty obvious at this point that you can easily drown in data if you deploy Suricata and start collecting everything. One of the first big architectural decisions to make with Suricata is whether to centralize or decentralize the IDS/IPS systems. For example, do you run a single system and force all your traffic through it? Do you run two servers and load balance connections? Do you run one server for inbound traffic and one server for outbound traffic? Each decision has benefits and drawbacks. Centralized servers mean fewer logfiles to merge, and load balancing traffic across multiple servers means that connection limits might not be as effective; conversely, splitting inbound and outbound traffic across different servers means that an inbound denial-of-service attack won't affect the monitoring of outbound traffic.

Where you encrypt and decrypt traffic is also important. If you use end-to-end TLS/SSL encryption, you won't be able to sniff it. For client systems, it isn't easy to intercept and monitor TLS/SSL traffic; however, if you are running servers, you can terminate the traffic at a TLS/SSL server and then send cleartext to the servers, making it easy to monitor traffic to your servers. For high-volume networks, you might also want to partition network traffic. Using iptables, for example, you can divert all outbound traffic to port 80 to a network with an IPS/IDS dedicated to handling HTTP traffic.

Snorby GUI

As with any network monitoring system that collects large amounts of data, you'll want to stick a GUI on it to make sense of everything. Oftentimes, graphing the data can immediately reveal trends much more easily than staring at a sheet of numbers. For Suricata (and Snort), users have the Snorby [12] front end. Snorby requires a number of dependencies, including Ruby 1.9, Ruby on Rails, libxml2-devel, libxslt-devel, mariadb-devel, and ImageMagick. Once you download Snorby, you need to run bundle install and then play whack-a-mole with any resulting errors (depending on your platform you might encounter quite a few).