Today the OpenDNS engineering team is releasing Traffic Cop, a simple, open source tool to uncover to where your host is communicating, and help you write iptables rules. In a nutshell, it does three things:
- Configures and enables logging of all inbound and outbound connection attempts (by default it looks for TCP SYN packets).
- Generates a report showing the IPs and services of the peers the host is communicating with.
- Generates iptables rules for each connection type.
Motivation
Let’s start with a quick example:
You have a fresh host for your new project and want to “lock it down.” You know it needs to talk to your database server and a few backend services, and that it will need inbound access from admins over SSH, plus web access for your clients. Writing the rules is not very easy either, but there are a few good tools out there for helping with that. You finalize your ruleset and put them in place. Everything works good for a few days, until your users can’t login because you forgot to enable access to your NTP (time) server, and the auth components need to stay in sync with time!
This is just one simple example, but the big picture is that in today’s fast-paced development world, where we’re building widgets using libraries built on top of other libraries, we don’t always know what our dependency chains looks like. This can make allow lists for security difficult, and sometimes a bit scary, as we want to do the right thing but not break anything.
How TrafficCop Helps
Let’s redo our example. This time we configure Traffic cop to log all connections on our server in a development/test environment (you probably don’t want to experiment in production). We let it run for a few days to get a good sense of the traffic. At the end of the learning phase, we’ve captured a rough baseline for the host. We review the rules it generated, select the ones that make sense, tweak the IP ranges as we see fit, and put them in place.
Note that we’re not just talking about inbound firewall rules here. We’re putting outbound rules in place too. This is traditionally an uncommon practice on host-based firewalls, as outbound traffic is typically more painful to classify and understand per application, but we’re using live data to drive the configuration, therefore we can take advantage of outbound traffic filtering. A blanket allowance of outbound traffic is one of the big drivers for malware to be primarily outbound focused (connecting back to “the mothership”), rather than attempting to communicate with the target inbound.
Demo Time!
We spin up a fresh EC2 instance, in a public subnet, using the default security groups (allows port 22 inbound from anywhere and all outbound).
SSH into the instance:
$ ./tcop enable
$ curl google.com (to show outbound log)
(waited about 5 minutes)
$ ./tcop report
That first inbound IP is us logging into the instance. The others are not! Notice that within just a few minutes we’re already getting IPs from around the world hitting our SSH port.
Great, How do I get Started?
Head over to the GitHub page for instructions on setting it up and generating reports. Contributions definitely welcome! Feel free to fork & feature requests! Hope you find it useful.
