Bug 122773
| Summary: | [pf] pf doesn't log uid or pid when configured to | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Josh <josh> | ||||
| Component: | kern | Assignee: | freebsd-pf (Nobody) <pf> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | ferdinand.goldmann, gonzo, kp, pascal.christen | ||||
| Priority: | Normal | ||||||
| Version: | 7.0-RELEASE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Josh
2008-04-14 23:10:02 UTC
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. |
