Full Packet Capture for Dummies

Published: 2016-11-05
Last Updated: 2016-11-05 09:18:16 UTC
by Xavier Mertens (Version: 1)
4 comment(s)

When a security incident occurred and must be investigated, the Incident Handler's Holy Grail is a network capture file. It contains all communications between the hosts on the network. These metadata are already in goldmine: source and destination IP addresses, ports, time stamps.  But if we can also have access to the full packets with the payload, it is even more interesting. We can extract binary files from packets, replay sessions, extract IOC's and many mores.

Performing FPC or "Full Packet Capture" is a must but has many constraints:

  • It has a huge impact on the required storage
  • It has privacy issues as the captured data may contain confidential information (for a user or the company)
  • Within complex architectures, it is complex to implement (multiple Internet gateways, distributed sites, ...)

So, the idea: Instead of deploying a full packet capture solution for the entire network, you can focus on more sensitive assets and collects locally. That's what I'm doing with all my servers hosted here and there. How?

First of all, when I deploy a new server, the first piece of software that I install after the operating system is Docker[1]. It is so convenient to deploy applications in a container for production or test/development. Docker containers can be deployed at boot time and do not need specific startup scripts. We can quickly deploy a Docker container that will capture packets for us. Based on Tcpdump, it will use some of the nice features to manage the storage space and have a rotating buffer.

The Docker file is very simple:

FROM ubuntu
MAINTAINER Xavier Mertens​​
VOLUME  [ "/data" ]
RUN apt-get update && apt-get -y -q install tcpdump​
CMD [ "-i", "any", "-C", "1000", "-W", "10", "-w", "/data/dump" ]
ENTRYPOINT [ "/usr/sbin/tcpdump" ]

Build your image:

# docker build -t system/tcpdump .

And you're ready to go. By default, the container will capture packets from any interface and write them to the /data volume. It will keep a sliding window of 10 x 1GB. But you can pass any Tcpdump parameter via the command line. Here is my favorite:

# docker run -d --net=host -v /var/log/tcpdump:/data --restart=always \
             --name  tcpdump -i eth0 -n -s 0 -C 1000 -W 10 -w /data/dump.pcap

Keep in mind:

  • Sometimes it takes some delays to detect an incident and to start investigations.
  • Adapt the sliding window of your PCAP files accordingly to the traffic handled by the server! (It is easy for an attacker to full fill your PCAP files with junk traffic to force the rotation and discard evidence)​
  • PCAP files are stored on the computer and could be deleted by the attacker.
  • Add any BPF[2] filter to log only relevant traffic (but you could loose some interesting data)
  • Tcpdump does not provide data persistence. If the container is restarted (ex: the server is rebooted), PCAP files rotation will restart with the file '0'.

Happy logging!

[1] https://www.docker.com/
[2] http://biot.com/capstats/bpf.html

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

4 comment(s)

Comments

I know I pale in comparison to some of the knowledge many people have in this regard, but what apart from the portability of the docker container is a benefit from just running at startup tcpdump. Also I realize tcpdump might just be an easy example, but tcpdump is highly portable, and I am trying to understand this docker bandwagon everyone is on. I just havent seen the light my friend
[quote=comment#38219]I know I pale in comparison to some of the knowledge many people have in this regard, but what apart from the portability of the docker container is a benefit from just running at startup tcpdump. Also I realize tcpdump might just be an easy example, but tcpdump is highly portable, and I am trying to understand this docker bandwagon everyone is on. I just havent seen the light my friend[/quote]

I agree with this statement. Why go to Docker for the tcpdump instance?

I put Nessus in a docker container, and it's been bulletproof there. I was in a situation where being able to roll out a new Nessus install efficiently was needed, and the docker solution worked perfectly. I can restore our instances easily.

https://github.com/jcwx/docker-nessus

However, what is to be gained by running tcpdump in a container? It appears automating the process of starting the container might be it? That could be done via rc.local or whatever systemd is doing now, so I'm not sure what is to be gained there.
Yes, I admit... A Docker container just to run a tcpdump can be a little bit overkill but I like containers ;-)
The main reason is indeed to automate the launch of the tcpdump without playing with rc.local (or other system files)
Tx for the hint about the Nessus container, I'll have a look.
Ahhh youre not a fan of systemd then? I will admit systemd files can get a little bit cumbersome, they are a little bit different than the olden init files, but i actually like systemd after getting accustomed to it.

Diary Archives