After enabling pflow exports, is it possible to see TCP flags?
I think the answer might be no since
grep -r pflow /usr/src led me to
/usr/src/sys/net/if_pflow.c which contains
flow1->tcp_flags = flow2->tcp_flags = 0
and I didn't see other changes to tcp_flags after
trying grep -r tcp_flags /usr/src.
Internet searches tell me many routers also don't export
TCP flags.
Is it the case that there's no good reason to look for
anomalies such as packets with only SYN-RST set if
our pf rules modulate state and would drop weird packets
anyway?
If adding this feature would be a worthy goal and might be
something a novice programmer such as your humble servant
could attempt, any advice about getting started would be
greatly appreciated.
Below are my attempts to see the TCP flags anyway. At the
very end is a question about collector software.
My router running OpenBSD 7.2 -current exports
flows, but when I view them on the collector
(also 7.2 -current):
e.g.
nfdump -o raw -r nfcapd.x
I get output like
low Record:
Flags = 0x06 NETFLOW v10, Unsampled
...
tcp flags = 0x00 ........
The "tcp flags" line always says 0x00 in all of the files. I had a
similar experience when setting up TCP control bit primitives (as
described in Network Flow Analysis by Michael W. Lucas, page 63)
in flow-tools on another collector before I switched to nfsen/nfdump:
filters that looked for only resets or syn-resets never caught
anything.
Even if I create a packet that I know only has a RST, for example,
I can see the flow but not the tcp flags.
On a Linux box (192.168.1.2) I ran nmap against my router:
sudo nmap --send-ip --scanflags RST -Pn -p 80 192.168.1.1
A tcpdump on my router 192.168.1.1 shows
Jan 22 pass in on re2: 192.168.1.2.62851 > 192.168.1.1.80: R ...
and the corresponding flow after
nfdump -o raw -r nfcap.X:
# === begin partial nfdump output ===
Flow Record:
Flags = 0x06 NETFLOW v10, Unsampled
label = <none>
export sysid = 1
size = 76
...
src addr = 192.168.1.2
dst addr = 192.168.1.1
src port = 62851
dst port = 80
fwd status = 0
tcp flags = 0x00 ........
biFlow Dir = 0x00 arbitrary
end reason = 0x00
proto = 6 TCP
(src)tos = 0
(in)packets = 1
(in)bytes = 40
input = 3
output = 0
ip router = 192.168.2.1
# === end partial nfdump output ===
But I think we'd want tcp flags to be 0x4.
In my router's pf.conf I have
# === begin part of router /etc/pf.conf ===
# egress is re3
match on egress scrub (no-df random-id max-mss 1440)
# === end part of router /etc/pf.conf ===
I wouldn't think that this scrubbing should affect
traffic that stays on interface re1. . . .
Here is the part where we allow the test packets through on
the router and export them with pflow:
=== begin part of router /etc/pf.conf ===
pass log on re1 proto tcp from 192.168.1.2 to 192.168.1.1 \
flags any \
keep state (pflow) \
label "nmap tcp $srcport $dstport"
pass log on re1 proto udp from 192.168.1.2 to 192.168.1.1 \
flags any \
keep state (pflow) \
label "nmap udp $srcport $dstport"
pass log on re1 proto icmp from 192.168.1.2 to 192.168.1.1 \
flags any \
keep state (pflow) \
label "nmap icmp $srcport $dstport"
# === end part of router /etc/pf.conf ===
I've also tried modulate state and
keep state (sloppy pflow).
I am exporting pflow over re2:
# === begin router /etc/hostname.pflow0
flowsrc 192.168.2.1 flowdst 192.168.2.2:9995
pflowproto 10
# === end router /etc/hostname.pflow0
I'm not sure how to more directly test the output of pflow since
it doesn't seem to be possible to tcpdump pflow0.
Thanks to Stuart Henderson for mentioning nfdump and ntopng
and to Peter Hansteen's for the Evil Network Overlord article.
Just wondering also if anyone has experience with any other
collector software besides nfsen and flow-tools. I really
like ntopng's displays but I haven't figured out whether
it can only receive flow data from nprobe (which isn't
a package) or whether there's a way for it to get it from
my existing export over port 9995. I have some problems with
nfsen and PHP crashing that I'll save for another day . . .
