guardicore/ipcdumpRastreador de IPC para Linux basado en BPF para tuberías, señales, sockets Unix, loopback y pseudoterminales con captura de metadatos y contenido, filtrado y salida en JSON.
ipcdump es una herramienta para rastrear la comunicación entre procesos (IPC) en Linux. Cubre la mayoría de los mecanismos IPC comunes: tuberías, fifos, señales, sockets unix, redes basadas en loopback y pseudoterminales. Es una herramienta útil para depurar aplicaciones multiproceso y también una forma sencilla de entender cómo las diferentes partes móviles de su sistema se comunican entre sí. ipcdump puede rastrear tanto los metadatos como el contenido de esta comunicación, y es particularmente adecuado para rastrear IPC entre procesos de corta duración, lo que puede ser difícil usando herramientas de depuración tradicionales como strace o gdb. También tiene algunas capacidades básicas de filtrado para ayudarle a examinar grandes cantidades de eventos. La mayor parte de la información que ipcdump recopila proviene de hooks BPF colocados en kprobes y tracepoints en funciones clave del kernel, aunque también completa algunos registros del sistema de archivos /proc. Para ello, ipcdump hace un uso intensivo de gobpf, que proporciona enlaces de golang para el marco bcc.
| Ubuntu 18.04 LTS | Ubuntu 20.04 LTS |
|---|
| 4.15.0 | Probado | No probado |
| 5.4.0 | No probado | Probado |
| 5.8.0 | No probado | Probado* |
*Requiere compilar bcc desde el código fuente
snap install go --classic
o directamente desde sitio web de golang
git clone https://github.com/guardicore/IPCDump
cd IPCDump/cmd/ipcdump
go build
./ipcdump -h
Usage of ./ipcdump:
-B uint
max number of bytes to dump per event, or 0 for complete event (may be large). meaningful only if -x is specified.
-D value
filter by destination comm (can be specified more than once)
-L do not output lost event information
-P value
filter by comm (either source or destination, can be specified more than once)
-S value
filter by source comm (can be specified more than once)
-c uint
exit after <count> events
-d value
filter by destination pid (can be specified more than once)
-f string
<text|json> output format (default is text) (default "text")
-p value
filter by pid (either source or destination, can be specified more than once)
-s value
filter by source pid (can be specified more than once)
-t value
filter by type (can be specified more than once).
possible values: a|all k|signal u|unix ud|unix-dgram us|unix-stream t|pty lo|loopback lt|loopback-tcp lu|loopback-udp p|pipe
-x dump IPC bytes where relevant (rather than just event details).
Ejecutar como root:
# dump all ipc on the system
./ipcdump
# dump signals sent between any two processes
./ipcdump -t kill
# dump loopback TCP connection metadata to or from pid 1337
./ipcdump -t loopback-tcp -p 1337
# dump unix socket IPC metadata and contents from Xorg
./ipcdump -t unix -x -S Xorg
# dump json-formatted pipe i/o metadata and first 64 bytes of contents
./ipcdump -t pipe -x -B 64 -f json
ipcdump está construido a partir de una serie de recolectores, cada uno encargado de un tipo particular de evento IPC. Por ejemplo, IPC_EVENT_LOOPBACK_SOCK_UDP o IPC_EVENT_SIGNAL.
En la práctica, todos los recolectores se construyen utilizando hooks bpf adjuntos a kprobes y tracepoints. Sin embargo, sus implementaciones son completamente separadas: no hay una razón particular para asumir que nuestra información siempre provendrá de bpf. Dicho esto, los diferentes recolectores deben compartir un único módulo bpf, porque hay algo de código común que necesitan compartir. Con este fin, compartimos un único BpfBuilder (que es esencialmente un envoltorio alrededor de la concatenación de cadenas de código bcc) y cada recolector registra su propio código con ese constructor. El script bcc completo se carga entonces con gobpf, y cada módulo coloca los hooks que necesita.
Actualmente hay dos tipos de registros que se comparten entre los recolectores IPC:
SocketIdentifier (internal/collection/sock_id.go) -- mapea entre struct sock* del kernel y los procesos que los usan.CommIdentifier (internal/collection/comm_id.go) -- mapea entre números de PID y el nombre del proceso correspondiente (/proc/<pid>/comm).El registro realizado en cada uno de ellos es particularmente importante para procesos de corta duración; aunque esta información puede completarse más tarde en modo usuario analizando /proc, a menudo el proceso relevante habrá desaparecido para cuando el evento llegue al manejador. Dicho esto, a veces completamos información desde /proc. Esto ocurre principalmente para procesos que existían antes de ejecutar ipcdump; no captaremos eventos como el nombramiento de procesos en este caso. SocketIdentifier y CommIdentifier intentan de alguna manera abstraer esta dualidad entre el código bcc y el análisis de /proc detrás de una única API, aunque no es súper limpio. Por cierto, en versiones muy nuevas de Linux (5.8), los iteradores bpf pueden reemplazar completamente este registro, aunque por compatibilidad hacia atrás probablemente deberíamos mantenernos en el paradigma de hooks y procfs por ahora.
La salida de eventos se realiza a través de la función común EmitIpcEvent(), que toma un formato de evento estándar (proceso fuente, proceso destino, pares clave-valor de metadatos y contenido) y lo genera en un formato unificado. Para ahorrar ancho de banda de eventos, los recolectores típicamente no generan el contenido IPC si no se especifica la bandera -x. Esto se hace con algo de magia de preprocesamiento elegante en internal/collection/ipc_bytes.go.
¡Por favor, hágalo! Consulte TODO para lo realmente importante. La mayor parte del trabajo inicial en ipcdump probablemente implicará hacer ajustes para diferentes versiones y símbolos del kernel.