Full Packet Capture for Dummies
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
Reverse-Engineering Malware: Malware Analysis Tools and Techniques | Frankfurt | Dec 9th - Dec 14th 2024 |
Comments
Anonymous
Nov 7th 2016
8 years ago
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.
Anonymous
Nov 7th 2016
8 years ago
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.
Anonymous
Nov 8th 2016
8 years ago
Anonymous
Nov 10th 2016
8 years ago