When pf is configured to log the UID and PID of the process sending traffic, it doesn't. How-To-Repeat: Configure pf with a rule such as: pass out log (user) quick on $exif inet proto tcp from $exif to any keep state Start pflog (/etc/rc.d/pflog + rcvar), then run "tcpdump -netttvvvi pflog0", which is supposed to display the info. You should get something like (from google): rule 10/(match) [uid 0, pid 1807] block in on fxp0: 85.100.124.74.14464 \ server1.443: [|tcp] (ttl 249, id 65259, len 40, bad cksum 0! differs by f890) But I actually get something like: 044014 rule 17/0(match): pass out on bge0: (tos 0x10, ttl 64, id 11138, \ offset 0, flags [DF], proto TCP (6), length 60) 64.132.211.219.57274 > \ 66.94.234.13.80: [|tcp] Other users on #freebsd@freenode reported the same behavior.
Responsible Changed From-To: freebsd-bugs->freebsd-pf Over to maintainer(s).
The problem is twofold: 1) FreeBSD doesn't store the PID for the opening process in the socket credentials. 2) tcpdump currently doesn't report uid/pid at all. The first issue could probably be fixed, but would touch quite a lot of things - it's really an industrious task. Feel free to submit patches ;) I don't currently have the time to do this. The second issue can be addressed with the attached patch, which should enable you to display the UID. It will report NO_PID (100000) for everything as long as 1 isn't fixed, though. -- Max
Hi, I've got the same problem on 9-stable too. pflogd didn't add the good UID value on its pcap. Here is a pflogd packet displayed on wireshark (my user had UID 1001 for this test): No. Time Source Destination Protocol Length Info 1 0.000000 10.2.1.3 10.2.0.67 TCP 124 [pass em0/0] 32186 > ssh [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 TSval=615127099 TSecr=0 Frame 1: 124 bytes on wire (992 bits), 124 bytes captured (992 bits) PF Log IPv4 pass on em0 by rule 0 Header Length: 61 Address Family: IPv4 (2) Action: pass (0) Reason: match (0) Interface: em0 Ruleset: Rule Number: 2 Sub Rule Number: 16777216 UID: -385679360 PID: -1601830656 Rule UID: 0 Rule PID: -1990852608 Direction: out (2) Padding: 000000 Internet Protocol Version 4, Src: 10.2.1.3 (10.2.1.3), Dst: 10.2.0.67 (10.2.0.67) Transmission Control Protocol, Src Port: 32186 (32186), Dst Port: ssh (22), Seq: 0, Len: 0 Source port: 32186 (32186) Destination port: ssh (22) [Stream index: 0] Sequence number: 0 (relative sequence number) Header length: 40 bytes Flags: 0x002 (SYN) Window size value: 65535 [Calculated window size: 65535] Checksum: 0xe2c8 [validation disabled] Options: (20 bytes), Maximum segment size, No-Operation (NOP), Window scale, SACK permitted, Timestamps Regards, Olivier
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
It looks like the kernel side of this (at least for uid) is present. I've updated the patch: diff --git a/contrib/tcpdump/print-pflog.c b/contrib/tcpdump/print-pflog.c index 265efd3c866..38201c55ee3 100644 --- a/contrib/tcpdump/print-pflog.c +++ b/contrib/tcpdump/print-pflog.c @@ -97,8 +97,12 @@ pflog_print(netdissect_options *ndo, const struct pfloghdr *hdr) else ND_PRINT((ndo, "rule %u.%s.%u/", rulenr, hdr->ruleset, subrulenr)); - ND_PRINT((ndo, "%s: %s %s on %s: ", - tok2str(pf_reasons, "unkn(%u)", hdr->reason), + ND_PRINT((ndo, "%s", tok2str(pf_reasons, "unkn(%u)", hdr->reason))); + + if (hdr->uid != UID_MAX) + ND_PRINT((ndo, " [uid %u]", (unsigned)hdr->uid)); + + ND_PRINT((ndo, ": %s %s on %s: ", tok2str(pf_actions, "unkn(%u)", hdr->action), tok2str(pf_directions, "unkn(%u)", hdr->dir), hdr->ifname)); A simple ping now produces this: tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes 00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 20885, offset 0, flags [none], proto UDP (17), length 55) 172.16.2.2.64345 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x964f!] 27130+ A? google.be. (27) 00:00:00.071014 rule 0/0(match) [uid 0]: pass out on vtnet0: (tos 0x0, ttl 64, id 63862, offset 0, flags [none], proto ICMP (1), length 84) 172.16.2.2 > 172.217.18.163: ICMP echo request, id 35102, seq 0, length 64 If anyone is still interested in this, can you test it and let me know if this works for you?
Review in https://reviews.freebsd.org/D17625
A commit references this bug: Author: kp Date: Sun Oct 21 21:17:43 UTC 2018 New revision: 339557 URL: https://svnweb.freebsd.org/changeset/base/339557 Log: tcpdump: Log uid on pflog interfaces If pf logs the user id ('pass out log (user)') have tcpdump also print this. Example output: 00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55) 172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27) PR: 122773 Differential Revision: https://reviews.freebsd.org/D17625 Changes: head/contrib/tcpdump/print-pflog.c
There was a commit referencing this bug, but it's still not closed and has been inactive for some time. Closing as "fixed". Please re-open it if the issue hasn't been completely resolved.
Note that while we do log the uid we don’t log the pid. Offhand I think that that was a nontrivial bit of extra work. I have no immediate plans to implement that, so I’m okay with keeping this closed.
This still does not seem to work. I have the following rule in my pf.conf: block out log (user) quick on $pub_if all user { >= 1001 } However, when I log blocked connections, I cannot see the UID in the logged messages (IP addresses X'ed out): # tcpdump -i pflog0 -n -p -e -tttt -vv action block tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes 2020-01-16 14:47:23.314075 rule 1/0(match): block out on bge0: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) X.X.X.33.47508 > X.X.X.65.25: Flags [S], cksum 0x212d (incorrect -> 0xdb8e), seq 631109046, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1497242932 ecr 0], length 0 I'm running a current version of FreeBSD: freebsd-version -kru 11.3-RELEASE-p5 11.3-RELEASE-p5 11.3-RELEASE-p5 I have tried various different invocations of tcpdump and even tcpdump from the ports to no avail. When I look at the packets in wireshark, I see that either negative or very high values are logged for both UID and PID. Any ideas? Shouldn't it print at least the UID by now?
A commit references this bug: Author: kp Date: Thu Jan 16 21:53:36 UTC 2020 New revision: 356814 URL: https://svnweb.freebsd.org/changeset/base/356814 Log: MFC r339557: tcpdump: Log uid on pflog interfaces If pf logs the user id ('pass out log (user)') have tcpdump also print this. Example output: 00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55) 172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27) PR: 122773 Changes: _U stable/12/ stable/12/contrib/tcpdump/print-pflog.c
A commit references this bug: Author: kp Date: Thu Jan 16 21:53:38 UTC 2020 New revision: 356815 URL: https://svnweb.freebsd.org/changeset/base/356815 Log: MFC r339557: tcpdump: Log uid on pflog interfaces If pf logs the user id ('pass out log (user)') have tcpdump also print this. Example output: 00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55) 172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27) PR: 122773 Changes: _U stable/11/ stable/11/contrib/tcpdump/print-pflog.c
(In reply to ferdinand.goldmann from comment #10) That's because this fix was never MFCd back to stable/11 or stable/12. It's fixed in head, but only there. I've now done the MFC, so it should at least be fixed in the next 11 and 12 released.