How We Built an Intrusion Detection System on AWS using Open Source Tools

Image by defensivedepth

It’s roughly a year now that we built an intrusion detection system on AWS cloud infrastructure that provides security intelligence across some selected instances using open source technologies.

As more instances were spun, real-time security monitoring became necessary. We wanted the capability to detect when someone attempts an SQL injection, an SSH brute force, a port scan and so on. I forgot; we didn’t even want a ping request to go unnoticed if it was possible to ping any of the instances from the public and finally, centralize security logs from multiple EC2 instances which would then be visualized with Kibana.

AWS supports third-party IDS/IPS tools like Trend Micro, Alert logic to name a few, which are pretty good, however, we wanted to try and explore the possibility of getting close to what they offer using open source tools available at our disposal. Some of the best IDS and HIDS available (Snort, Suricata, Ossec) are open source and are actively supported by a large community. We could install them separately on each EC2 instance, this would have defeated our aim of having a centralized log of all security events and also would bring some maintainability issues.

Implementation

Security onion has been around for a while, a project started by Doug Burks and finds good use in monitoring home network but its usage in the cloud is an area that has not been fully explored. It’s a Linux distro based on Ubuntu and comes with Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, NetworkMiner. In short, it’s bundled with all the tools one would need for a powerful and free network monitoring system. I will not dwell on how to setup security onion because of already existing and compressive documentation which can be found on security onion wiki page.

Having read SANS paper titled Logging and Monitoring to Detect Intrusions and Compliance Violation with Security Onion, we decided to try it out by selecting a VPC with 2 subnets and some few EC2 instances. Basically, these instances power public-facing websites, and often witness low to moderate traffic a day.

Since security onion works by analyzing traffic and logs on the host machine, in other to get analysis for an instance, one must first find a way to mirror traffic from all the instances to security onion sensor.

AWS does not provide a tap or span port, at least none that I know of. So, we made use of netsniff-ng for the virtual tap which copies traffic from the instance to an OpenVPN bridge and transports the traffic to security onion sensor where it is then analyzed.

On each instance there is an OSSEC agent and a virtual tap. The purpose of OSSEC agent is to provide host-instrusion detection system (HIDS) that is, monitors events happening at the host level and reports back to the security onion server via the OSSEC encrypted message protocol, while the virtual tap mirrors traffic at the interface level and forwards that via an open VPN bridge to security onion server for analysis, serving as network-intrusion detection system (NIDS).

Our architecture looks like this, security onion server is sitting right there in the private subnet.

Reporting

Security Onion does not only support analyst tools like squert, squil,elsa, that can be used to access realtime events, session data, and raw packet captures but also ELK as at the time of writing this post.

Conclusion

The three core functions of security onion which are full packet capture, network-based and host-based instrusion detection systems (NIDS and HIDS), and analysis tools are all obtainable on AWS environment, although, network-based instrusion detection systems on windows instances have not been successful.