Tracee has a unique feature that lets you capture interesting artifacts from
running applications, using the --capture flag.
./dist/tracee man capture
sudo ./dist/tracee --capture xxx
Tip
All captured artifacts are saved in Tracee's "output directory", which can
be configured using --capture dir:/path/to/dir. You may also use
--capture clear-dir if you want contents of the destination directory
to be cleared every time you execute tracee.
Tracee can capture the following types of artifacts:
I/O Files
Anytime a file is being written to and/or read from, the contents of the
file will be captured. I/O files can be filtered using 3 optional filters:
1. path - prefix of the file written/read. Up to 3 path filters can be
provided per capture type.
2. type - file's type can be pipe, socket, elf or regular.
3. fd - standard FD, one of the following: stdin, stdout and stderr.
Anytime a memory unpacker is detected, the suspicious memory region
will be captured. This is triggered when memory protection changes from
Write+Execute to Write.
You may opt not to have any output from tracee with --output none
command flag is given. This makes tracee to work in capture mode only.
Network PCAP Files
Anytime a network packet is delivered to a process, traced by tracee,
this packet might be captured into one or multiple pcap files.
Attention
The default behavior when capturing network traffic is to capture
ALL traffic, despite given event filters. If you want to make
capture feature to follow the given event filters, like for example
capturing DNS events only, then you have to provide --capture
pcap-options:filtered argument in the command line. Then only
net_packet_XXX events will be captured (IPv4, IPv6, TCP, UDP,
ICMP, ICMPv6, DNS, HTTP, etc).
A great thing is that you may have multiple pcap files, divided by:
single: a single pcap file containing all packets (the default)
process: one file per process executed, ordered by host and container
container: one file for the host and one pcap file per container
per-command: one file per command executed (even if multiple times)
and you can even have multiple ways at the same time. Example: a ping
command is executed inside a container. You want to summarize captured
traffic per container and per command. You will find the same captured
data for that ping command inside commands/container_id/ping.pcap and
inside containers/container_id.pcap.
you can see the packets by executing tcpdump on any pcap file:
tcpdump -r pcap/containers/b86533d11f3.pcap
reading from file pcap/containers/b86533d11f3.pcap, link-type NULL (BSD loopback), snapshot length 65535
02:52:00.524035 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 476, length 64
02:52:00.533145 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 476, length 64
02:52:01.525455 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 477, length 64
02:52:01.535414 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 477, length 64
02:52:02.526715 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 478, length 64
02:52:02.536444 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 478, length 64
02:52:03.528739 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 479, length 64
02:52:03.538622 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 479, length 64
tcpdump -r pcap/commands/b86533d11f3/ping.pcap
reading from file pcap/commands/b86533d11f3/ping.pcap, link-type NULL (BSD loopback), snapshot length 65535
02:52:00.524035 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 476, length 64
02:52:00.533145 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 476, length 64
02:52:01.525455 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 477, length 64
02:52:01.535414 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 477, length 64
02:52:02.526715 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 478, length 64
02:52:02.536444 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 478, length 64
02:52:03.528739 IP 172.17.0.3 > dns.google: ICMP echo request, id 5, seq 479, length 64
02:52:03.538622 IP dns.google > 172.17.0.3: ICMP echo reply, id 5, seq 479, length 64
Note
Note that the same packets were written to 2 different pcap files: the
pcap file describing the container b86533d11f3 (because it was
executing a single process: ping) and the pcap file describing ANY ping
command executed in that container (commands/b86533d11f3/ping.pcap).
The format for the pcap filenames inside output_dir is the following:
By default, all pcap files will contain packets with headers only. That
might too little for introspection, since sometimes one might be
interested in a few bytes of the captured packet (or event it all). Next
item shows how to capture a specific packet payload size.
In order to capture a specific payload size you may specify:
Wheneber a BPF program is loaded, the BPF bytecode will be captured.
This captured bytecode represents the BPF program as it was loaded by the loading process.
It is basically the BPF section of the compiled ELF that loads the BPF program, which contains the program instructions themselves.
You can disassemble the bytecode with the help of binutils-bpf package and the following command line:
objdump -D -b binary -m bpf <path>