1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
On Debian Linux systems conntrack uses the /proc/net/nf_conntrack device. This
device may not be available in other Linux variants (e.g., Ubuntu). Sebastian
Monte provided information about how conntrack can be used in those cases. See
README.no_nf_conntrack for a description of his findings.
Conntrack byte counts add the sizes of the IP headers (usually 20 bytes) to
the byte counts. So, icmp packets are usually reported as having size 84,
even though ping etc reports the payload (64 bytes). Since the actual size of
the IP headers cannot be determined from conntrack's output, the sizes
reported via natlog's conntrack mode are as reported, and are therefore not
corrected for IP header lengths.
Example conntrack lines:
The 'maybe' entries appear if the command
$ echo 1 > /proc/sys/net/netfilter/nf_conntrack_acct
has been issued before starting natlog.
[1338987414.52626 ] [NEW] tcp 6 120 SYN_SENT
src=192.168.1.4 dst=129.125.14.80 sport=59783 dport=22 [UNREPLIED]
src=129.125.14.80 dst=129.125.100.246 sport=22 dport=59783
[1387190223.487711] [DESTROY] tcp 6
src=192.168.17.21 dst=192.87.23.111 sport=50029 dport=443
packets=7 bytes=450 <-- maybe
src=192.87.23.111 dst=129.125.100.246 sport=443 dport=50029
packets=5 bytes=1679 <-- maybe
[ASSURED]
[1515751941.057688] [NEW] tcp 6 120 SYN_SENT
src=192.168.17.6 dst=129.125.3.162 sport=49590 dport=22 [UNREPLIED]
src=129.125.3.162 dst=192.168.8.17 sport=22 dport=49590
[1515752071.886964] [DESTROY] tcp 6
src=192.168.17.6 dst=129.125.3.162 sport=49590 dport=22
packets=29 bytes=4840
src=129.125.3.162 dst=192.168.8.17 sport=22 dport=49590
packets=30 bytes=5132 [ASSURED]
With conntrack records the source port and unique port combinations (1st line)
are unique and are used as the key.
-------------------------------------------------------------------------------
[1387190207.172139] [NEW] udp 17 30
src=10.4.0.6 dst=129.125.4.6 sport=42998 dport=53 [UNREPLIED]
src=129.125.4.6 dst=129.125.100.246 sport=53 dport=42998
[1387190187.423829] [DESTROY] udp 17
src=10.4.0.6 dst=216.239.34.10 sport=60840 dport=53
packets=1 bytes=138 <-- maybe
src=216.239.34.10 dst=129.125.100.246 sport=53 dport=60840
packets=1 bytes=524 <-- maybe
Note that the tcp and udp lines are identically organized
With conntrack records the source port and unique port combinations (1st line)
are unique and are used as the key.
-------------------------------------------------------------------------------
[1387190207.153486] [NEW] icmp 1 30
src=192.168.17.7 dst=129.125.3.162 type=8 code=0 id=7016 [UNREPLIED]
src=129.125.3.162 dst=129.125.100.246 type=0 code=0 id=7016
[1387190237.151720] [DESTROY] icmp 1
src=192.168.17.7 dst=129.125.3.162 type=8 code=0 id=7016
packets=1 bytes=84 <-- maybe
src=129.125.3.162 dst=129.125.100.246 type=0 code=0 id=7016
packets=1 bytes=84 <-- maybe
With conntrack records the IDs are unique and are used as the key.
-------------------------------------------------------------------------------
|
