Allow rules to match TCP and UDP ports

[JohnCampionJr]

A rule's target can now end in :PORT or :FIRST-LAST, for example --allow=192.168.0.10/32:8443 or --block="out @host:22". It matches TCP and UDP traffic with that port on the target's side: the destination for outbound traffic, the source for inbound.

The use case: a VM whose private ranges are blocked but which still needs to reach one service on another host. Today the only option is to allow the whole host, which also exposes SSH and anything else listening on it.

A rule with ports takes precedence over rules without them, so one port of a host can be opened through a block of its network. Among rules with ports, the longest prefix wins and blocking wins a tie, as with the existing rules. Only the first fragment of a packet carries ports, so later fragments never match a port rule.

The same syntax works through the control channel. This picks up the "ports" item from #184.

[JohnCampionJr]

For context: I read through the syntax discussion in #184 before opening this. Ports came up there, with forms like out proto tcp to @host port 8080, but #188 shipped direction only, so this adds the smallest piece on top of it: an optional port on the existing target, matching both TCP and UDP.

If you'd rather go with the proto … to … port … form from #184, I'm happy to rework it that way. The matching and precedence logic wouldn't change, only the parser.

[edi-oai]

Is there a reason to separate the port-based rules from the regular ones?

Also, we should approach the rule syntax with more thought to accommodate different use-cases in the future. For example, one might want to:

• specify a range of ports
• a protocol
• differentiate between the source or destination port

See pf.conf(5)'s for a good example for such extensibility (proto, from and to actions). There are other packet filters that allow this flexibility as well.

It would be nice if was an issue in the first place, where we would be able to discuss the shape required to support both (1) your use-case and (2) possible future ones, and only then jump into the implementation.

[edi-oai]

If you'd rather go with the proto … to … port … form from #184, I'm happy to rework it that way. The matching and precedence logic wouldn't change, only the parser.

Sorry, I've totally missed this message.

Yes, I think we should prioritize extensibility from the outset to avoid ending up with overly complex syntax. Or worse: a syntax that cannot express certain rules at all.

That would be particularly unfortunate given how how many existing packet-filter implementations we can draw inspiration from.

My preference goes for pf.conf(5), but I'm happy to compare it with the other approaches as well.

[JohnCampionJr]

Thanks, happy to go the pf.conf route. Proposed subset, so we can agree the shape before I rework the parser:

rule      = [direction] [proto] target
direction = "in" | "out"
proto     = "proto" ("tcp" | "udp" | "icmp")
target    = "from" endpoint ["to" endpoint] | "to" endpoint
endpoint  = (CIDR | "@host" | "any") ["port" port]
port      = N | N ":" M

Examples: out proto tcp to 192.168.0.10 port 8443, in proto tcp from @host to any port 22, out to 10.0.0.0/8. Existing rules keep working: a bare TARGET stays shorthand for to TARGET, and in/out behave as they do today. A port requires proto tcp or udp. Precedence stays longest-prefix with block winning ties, with a rule that names a port counting as more specific than one that doesn't.

If you'd prefer this as a separate issue, I'll open one.