Three out of ten visitors to your website are malicious bots. Crazy, right? A report from Incapsula states that humans only account for 44 percent of website traffic. So what makes up the other 56 percent? Bots, mostly bad ones.

“Bad” bots are those involved in a variety of malicious activities such as taking down servers through denial service attacks, stealing data from servers, hijacking servers, spamming ads, and more. How can you defend your sites/servers against these bots? Through basic network security practices, including Intrusion Detection/Prevention Systems (IDS/IPS). Here’s some information on our setup, and how to install one yourself.

Incapsula report
2014 Bot Traffic Report by Incapsula

First Line of Defense: Firewall

Although a firewall is good to restrict traffic attempting to violate any rules that a user sets up, it is not dynamic enough to detect any malicious packets in “legitimate traffic”.

Second Line of Defense: IDS/IPS

Since the firewall cannot detect malicious packets from the “legitimate traffic” that server is receiving and sending out, we use an Intrusion Detection/Prevention System (IDS/IPS) to inspect each packet for malicious information.

  • An Intrusion Detection System (IDS) passively inspects all inbound and outbound network activities and identifies possible security breaches. When the threat is identified, IDS will passively alert administrator so that administrators can take action.
  • An Intrusion Prevention System (IPS) is a reactive system that actively drops malicious packets identified by Intrusion Detection System, block traffic from the source and resetting connections. Both IDS and IPS can easily scale to provide protection for the entire network.

Some of you might ask, “What’s the point of detecting an attack in the first place, if you are not going to do anything about it? Also, why would you use IDS when you have firewall in place already?”.

IDS Pros and Cons

IDS does several things that a basic firewall can’t do:

  1. IDS can determine how the incident happened. Since you can determine the cause of the incident, you can find which part of your system is vulnerable and come up with remediation plan.
  2. Identify anomalous packet content or patterns of traffic that is unusual. You can use this information to find traffic trend. If there is unusual traffic, you should be able to figure out that something is going on in your network.
  3. You might be able to figure out who was responsible for exploiting or attacking your system. You can simply deny them from accessing your system.

Although IDS and IPS have a lot of upsides, there are some drawbacks:

  1. False positives and negatives. When you deploy an IDS and IPS, it usually generates a surprising number of alerts and it is up to you to investigate and configure the IDS/IPS settings. Minimizing false negatives is very important because high false negative rate means that system admin will be bombarded by warning and alert messages from IDS.
  2. You require site/system administrators to monitor your IDS/IPS setup full-time in order to make sure it is operating as expected.

What does Hootsuite use?

Hootsuite uses Suricata. We use it because:

  • It’s multi-threaded
  • Has visibility at the application layer
  • Faster normalization and paring for HTTP streams
  • Supports file extraction
  • Supports hardware acceleration
  • Supports logging TLS/SSL cert, HTTP requests and DNS requests
  • Compatible with Snort rules
  • Open source (FREE!)

Suricata

Installing Suricata

Hootsuite uses an Ansible-Playbook to deploy and maintain Suricata on load balancers. Some of you might ask “Why use Ansible?” The answer is quite simple: Ansible allows you to deploy your solution to as many servers you want with one single command. In case of server downtime, you can simply spin up clone servers in few minutes to replace the server that went down. Following is a sample script used to install Suricata on my own server:

image
Hootsuite uses more complex and customized Ansible-Playbook script to make sure that the server is secured. In the above script, I am configuring Suricata to use rules from Emerging Threat Open Source. Since each server has different functionality and different customers I recommend that you create your own custom rules for your IDS/IPS.

How to Write Suricata Rules

Following is a syntax template to create a custom Suricata rule.

Custom Rule

This is an simple example of Suricata rule:

Example

Actions

There are four types of action that your rule can do:

  • pass: If Signature matches, Suricata stops scanning the packet and skips to the end of all rules
  • drop: Only works if Suricata is configured to run in IPS. If a signature matches, the packet will not be sent any further. Receiver does not receive anything due to timeout.
  • reject: If a signature matches, both sender and receiver will get reject packet. If Suricata is configured to run in IPS mode, the packet will be dropped like drop action from above.
  • alert: If a signature matches, it will generate alert message.

Protocol

Suricata can check each packet by protocols:

  • ip – When specified, it will watch for all or any packets on the network
  • tcp – When specified, it will match rule against TCP traffic
  • udp – When specified, it will match rule against udp traffic
  • icm – When specified, it will match rule against icm traffic
  • You can also specify layer seven protocols such as HTTP, SSL, TLS, FTP, etc…

Source/Destination

Suricata can check each packet by IP address:

  • any – Suricata will check every incoming/outgoing traffic from specified IP
  • ! ip_address – Exclamation mark specifies “not:. Ex. ! any, ! 1.1.1.1
  • [ ip ] – Specifies multiple IP. Ex. [ 1.1.1.1, ! 2.2.2.2]

Port

Suricata can check each packet by port:

  • any – Suricata will check every incoming/outgoing traffic from specified port
  • ! port – Exclamation mark specifies “not:. Ex. ! any, ! 80
  • [ ip ] – Specifies multiple IP. You can use “:” to specify port range Ex. [22, 80], [22:80]

Direction

  • -> – Suricata only checks for incoming traffic
  • <> – Suricata checks for both incoming and outgoing traffic

Rule Options

There are many options for rules available, but these are the three basic options that you can use it (more information is available here):

  • msg – Message that will be displayed when alert is prompted
  • sid – Unique id for rule for bookkeeping
  • rev – Revision number

Conclusion

Once Suricata is up and running, you can use software to parse and display logs for your needs. Hootsuite uses Elastic, Logstash and Kibana (known as ELK stack) to parse, store, and view Suricata logs efficiently.

I think it is worthwhile for organizations to consider using IDS/IPS solution in conjunction with a monitoring setup in order to detect or prevent network intrusion from hackers and malicious bots. Although some might believe that having correctly configured firewall and servers is good enough to defend against malicious activities, it is possible that there exists zero day vulnerability in the application. IDS/IPS in combination with a monitoring system like ELK is your best bet to detect zero day attack by surfacing abnormal activity in your network.

Resources

Thanks

Thank you to Security and Compliance team for teaching me something new everyday, and to Noel and Kimli for their valuable input.

SimonSAbout the Author

Simon Song is a co-op student on our Security and Compliance team. Simon is 4th year Computer Science student at University of Waterloo. His interests include hiking, building drones, learn about security, and network systems. Follow him on Twitter @simonirang.