3 ms·

Nftables and Linux still hasn’t been able to filter —-> INBOUND <—-packets by Process ID, by Process group ID, by process name, and possibly by process namespac

Nftables and Linux still hasn’t been able to filter —-> INBOUND <—-packets by Process ID, by Process group ID, by process name, and possibly by process namespace.

process_me 5y ago
Can you explain how this would work? An ingress packet doesn’t come with a process ID. How can the wanted functionality not be implemented by applying filters to the port bound by the process?
- egberts1 5y ago
  If a process opens a socket, OS has sufficient info to tag the packet with a process ID. Perfect for alerting while under the Default-Deny Firewall. Somehow, FreeBSD has those.
- mhio 5y ago
  An ingress packet will end up mapped to a process by the OS, so it should be feasible to extend a network rule to include the process based information: Example Rule: allow process "squid" with shasum "1a2b3d4" running as user "squidy" to receive packets via "TCP" port "3138" > How can the wanted functionality not be implemented by applying filters to the port bound by the process? A port filter is dumb in a sense, anything can be underneath. It's fine for something like a web server, run by root, on a couple of consistent ports, running all the time. Process based rules might be more useful for services with dynamic port ranges or real people running random things. Your questions concept may be the easiest way around the issue in Linux world. It could be easier to have BPF monitor process start/stop and port open/close changes and modify the allowed ingress to suit the process based ruleset than it is to attempt the lookup purely on the inbound path. Due to the multi process listening feature, the connection > process mapping info may only be available after it's happened which might not be the best point to firewall something.
  - egberts1 5y ago
    dont forget about those errant processes who may want to open an unbinded but shared socket port and emulate that service … maliciojsly.
emj 5y ago
It is said in the article says you have to get your hands dirty, but yeah I can not see any easy way. Researching the naive way I got stuck in eBPF filters, and that will also fail with doing process/socket lookups since several applications can listen on a port. I guess you can filter on delivery to the application in some way..
- egberts1 5y ago
  But you can get your process ID associated with a network packet … just in FreeBSD bind to socket (single process)
dsp 5y ago
Would you be able to share more about your use cases? I’m currently working on some related tech, and your perspective would be helpful.

Nftables and Linux still hasn’t been able to filter —-> INBOUND <—-packets by Process ID, by Process group ID, by process name, and possibly by process namespace.

process_me 5y ago

Can you explain how this would work? An ingress packet doesn’t come with a process ID. How can the wanted functionality not be implemented by applying filters to the port bound by the process?

egberts1 5y ago
If a process opens a socket, OS has sufficient info to tag the packet with a process ID. Perfect for alerting while under the Default-Deny Firewall. Somehow, FreeBSD has those.
mhio 5y ago
An ingress packet will end up mapped to a process by the OS, so it should be feasible to extend a network rule to include the process based information: Example Rule: allow process "squid" with shasum "1a2b3d4" running as user "squidy" to receive packets via "TCP" port "3138" > How can the wanted functionality not be implemented by applying filters to the port bound by the process? A port filter is dumb in a sense, anything can be underneath. It's fine for something like a web server, run by root, on a couple of consistent ports, running all the time. Process based rules might be more useful for services with dynamic port ranges or real people running random things. Your questions concept may be the easiest way around the issue in Linux world. It could be easier to have BPF monitor process start/stop and port open/close changes and modify the allowed ingress to suit the process based ruleset than it is to attempt the lookup purely on the inbound path. Due to the multi process listening feature, the connection > process mapping info may only be available after it's happened which might not be the best point to firewall something.
- egberts1 5y ago
  dont forget about those errant processes who may want to open an unbinded but shared socket port and emulate that service … maliciojsly.

emj 5y ago

It is said in the article says you have to get your hands dirty, but yeah I can not see any easy way. Researching the naive way I got stuck in eBPF filters, and that will also fail with doing process/socket lookups since several applications can listen on a port. I guess you can filter on delivery to the application in some way..

egberts1 5y ago
But you can get your process ID associated with a network packet … just in FreeBSD bind to socket (single process)

dsp 5y ago

Would you be able to share more about your use cases? I’m currently working on some related tech, and your perspective would be helpful.