2
2
.SH NAME
3
3
tcpconnect \- Trace TCP active connections (connect()). Uses Linux eBPF/bcc.
4
4
.SH SYNOPSIS
5
- .B tcpconnect [\-h] [\-c] [\-t] [\-p PID] [-P PORT] [-u UID] [-U] [\-\-cgroupmap MAPPATH] [\-\-mntnsmap MAPPATH]
5
+ .B tcpconnect [\-h] [\-c] [\-t] [\-p PID] [-P PORT] [-u UID] [-U] [\-\-cgroupmap MAPPATH] [\-\-mntnsmap MAPPATH] [ \- d]
6
6
.SH DESCRIPTION
7
7
This tool traces active TCP connections (eg, via a connect() syscall;
8
8
accept() are passive connections). This can be useful for general
@@ -14,9 +14,18 @@ This works by tracing the kernel tcp_v4_connect() and tcp_v6_connect() functions
14
14
using dynamic tracing, and will need updating to match any changes to these
15
15
functions.
16
16
17
+ When provided with the \- d or \-\- dns option, this tool will also correlate
18
+ connect calls with the most recent DNS query that matches the IP connected.
19
+ This feature works by tracing the kernel udp_recvmsg() function to collect DNS
20
+ responses.
21
+
17
22
Since this uses BPF, only the root user can use this tool.
18
23
.SH REQUIREMENTS
19
24
CONFIG_BPF and bcc.
25
+
26
+ If using the \- d or \-\- dns option, you must have the
27
+ dnslib and cachetools python packages installed. You can install them with pip3 or with
28
+ apt on Ubuntu 18.04+ using the python3\- dnslib and python3\- cachetools packages.
20
29
.SH OPTIONS
21
30
.TP
22
31
\- h
@@ -45,6 +54,26 @@ Trace cgroups in this BPF map only (filtered in-kernel).
45
54
.TP
46
55
\- -mntnsmap MAPPATH
47
56
Trace mount namespaces in this BPF map only (filtered in-kernel).
57
+ .TP
58
+ \- d
59
+ Shows the most recent DNS query for the IP address in the connect call.
60
+ This is likely related to the TCP connection details in the other columns, but is not guaranteed.
61
+ This
62
+ feature works by tracing the udp_recvmsg kernel function and tracking DNS
63
+ responses received by the server. It only supports UDP DNS packets up to 512 bytes
64
+ in length. The python code keeps a cache of 10k DNS responses in memory
65
+ for up 24 hours.
66
+
67
+ If the time difference in milliseconds
68
+ between when the system received a DNS response and when a
69
+ connect syscall was traced using an IP in that DNS response is greater than 100ms,
70
+ this tool will report this delta after the query.
71
+ These deltas should be relatively short for most applications. A
72
+ long delay between the response and connect could be either anomalous activity
73
+ or indicate a misattribution between the DNS name requested and the IP that
74
+ the connect syscall is using.
75
+
76
+ The \- d option may not be used with the count feature (option \- c)
48
77
.SH EXAMPLES
49
78
.TP
50
79
Trace all active TCP connections:
@@ -55,6 +84,10 @@ Trace all TCP connects, and include timestamps:
55
84
#
56
85
.B tcpconnect \- t
57
86
.TP
87
+ Trace all TCP connects, and include most recent matching DNS query for each connected IP
88
+ #
89
+ .B tcpconnect \- d
90
+ .TP
58
91
Trace PID 181 only:
59
92
#
60
93
.B tcpconnect \- p 181
@@ -110,12 +143,27 @@ Destination port
110
143
.TP
111
144
CONNECTS
112
145
Accumulated active connections since start.
146
+ .TP
147
+ QUERY
148
+ Shows the most recent DNS query for the IP address in the connect call.
149
+ This is likely related to the TCP connection details in the other columns, but is not guaranteed.
113
150
.SH OVERHEAD
114
151
This traces the kernel tcp_v[46]_connect functions and prints output for each
115
152
event. As the rate of this is generally expected to be low (< 1000/s), the
116
153
overhead is also expected to be negligible. If you have an application that
117
154
is calling a high rate of connect()s, such as a proxy server, then test and
118
155
understand this overhead before use.
156
+
157
+ If you are using the \- d option to track DNS requests, this tool will trace the
158
+ udp_recvmsg function and generate an event for any packets from UDP port 53.
159
+ This event contains up to 512 bytes of the UDP packet payload.
160
+ Typical applications do not extensively use UDP, so the performance overhead of
161
+ tracing udp_recvmsg is
162
+ expected to be negligible, However, if you have an application that receives
163
+ many UDP packets, then you should test and understand the overhead of tracing
164
+ every received UDP message. Furthermore, performance overhead of running
165
+ this tool on a DNS server is expected to be higher than average because all
166
+ DNS response packets will be copied to userspace.
119
167
.SH SOURCE
120
168
This is from bcc.
121
169
.IP
0 commit comments