Sorry if this is too wordy. And let me know if it doesn't make any sense.
I think I didn't communicate my thoughts clearly.
If my Internal Workstation (192.168.100.100) has a stateful connection to
the internet (tcp 5000 to 20.20.20.20) that is already open and in your
state table(s), then I want pF to allow UDP ports 4900-4901 back to my
internal workstation (192.168.100.100). If my internal workstation
doesn't have that tcp 5000 port open to an internet address, then I don't
want pF to leave 4900&4901 open.
Sort of like this (this isn't proper syntax, just my attempt to show the
logic behind what I am asking about):
enet = ne3
inet = xl0
X=192.168.100.100
If port 5000 from $X to any on $inet then
pass all in $enet udp 4900-4901
rdr udp 4900-4901 to $X
else block in all in $enet udp 4900-4901
X should be variable (depending on what machine is trying to do the
outbound traffic)
enet is my external network card (attached to a router on the internet)
inet is my internal LAN (192.168.100.1)
This would not require any authentication, since my internal workstation
is a trusted entity already (its my own computer).
This would be VERY useful functionality to have in pF. By having pF look
for a trigger port (in this case, a connection outbound on tcp/5000)
BEFORE it opens ports for the inbound traffic, you can setup complex
rules that only activate when a certain application is requesting
communications thru the firewall.
I don't think this would be feature bloat - I think it would be an
EXCELLENT way for a corporate administrator to fine-tune their firewall
to their particular environment.
Chris
-----Original Message-----
From: Daniel Hartmeier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sat, 10 Aug 2002 23:00:14 +0200
Subject: Re: Newbie Question (one of many to come)
> On Sat, Aug 10, 2002 at 09:37:15AM -0700, Chris Willis wrote:
>
> > I would like to create a filter that allows 4900&4901 inbound to the
> > machine that already has tcp 5000 open. If tcp 5000 isn't open, then
> I
> > do not want the UDP ports to be open inbound.
>
> Short answer: you can't.
>
> I know this is possible with Linux' netfilter, but I don't think it's a
> feature that can be used securely. If you think about it, how does the
> existing TCP connection authenticate the peer in any way that makes you
> trust him more than the rest of the world? Anyone could establish that
> TCP connection first and get access to the other ports. If you're not
> allowing the whole world to establish the TCP connection (by blocking
> on
> peer address), you could use the same restrictions for the other ports.
>
> Ok, someone spoofing the source address couldn't complete a TCP
> handshake, so the established TCP connection excludes that. But a
> source
> spoofer could just as well pick an address that is likely to have a TCP
> connection already established with you and use that to send UDP
> packets.
>
> There is a way to open ports after peers have truely authenticated
> themselves: authpf(8). Logging in via ssh might seem overly
> complicated,
> but what you get in exchange is a real authentication, as compared to
> security by obscurity that the 'related' (or whatever it's called in
> netfilter) feature offers.
>
> Daniel
