> Stateful inspection on gateway can hamper tcp-connections, when
> inbound or outbound packets goes another route (i.e. when one of
> directions not goes thru gateway).
well, yeah. How is a firewall supposed to deduce state if it doesn't
see any replies? psychic deduction?
>
> Connection wo
> I believe what is being requested is a kind of state engine that is
> smart enough to modify packets on the fly and recognize "related"
> packets. This is common in many commercial firewalls and also in
> SunScreen and Netfilter/IPTables.
Okay. To avoid confusion from here on in, take this as
> In fact, even if it does not really matter to you in fact, I'm not
> talking about a kernel "proxy" here. I'm talking about something smart
> enough to tag packets "related" and so to "pass" them.
A piece of kernel code smart enough to inspect packets comprising
a partular protocol, and extrac
> I see frequent inbound icmp from and to ports 256, 512, 768 and 1024 (and
> occasionally other ports). I've googled this, but got nothing useful.
> What's this traffic all about anyway?
That makes no sense. ICMP doesn't have port information.
-kj
T/TCP uses the SF combination. Read stevens, the RFC, or
just ask google:
http://www.google.com/search?q=T%2FTCP+flags+SA
-kj
> Is it possible to filter and control the state of connections during a
> T/TCP session?
Yes.
In fact, T/TCP is why some people prefer "flags S/SA" over "flags S/SAFR"
-kj
> This is cosmetics. However, whouldn't we get some performance increase
> if pf(4) didn't bother looking at packets (in certain situations) going
> 'out' at all?
>
> I assume that 'pass out all keep state' makes pf(4), at least, do a
> state lookup in the table? AFAIK, that's, in worst case scen
> Yes, but it could be nice if one could choose, eg.
> set filter-policy {in, out, both} or something.
You can choose. Either type:
block out all
or
pass out all keep state
I do not understand this part of your argument at all.
-kj
> Yes, thank you. I also still mean that pf(4) should not care about
> packets going 'out' of an interface, only in, but let's kill this
> thread.
Again: traffic can originate on the firewall box. Since this traffic
never passes inbound on an interface, filtering MUST be done
on the outbound direc
Okay, I think I'm starting to understand what you want. (because I
believe we tossed the idea around at the last hackathon)
Basically, you want a state-creating packet to be able to create state
on multiple interfaces, like:
pass in on $ext_if proto tcp from any to $webserver port 80 \
keep s
> Well, yeah, they do, but why have pf(4) look at them both on in and out
> and on the same interface?
Well, among other reasons, because traffic can originate on the firewall.
> set filter interface {vlan01, vlan02, vlan03}
>
> The rest is invisible to pf(4).
er:
set trusted_ifs {vlan04, vlan
> > There is nothing more frustrating than trying to help someone with a
> > problem, and then realizing you spent your time debugging a
> > typo made when "obfuscating" IP addresses.
> Are you suggesting that, more often than not, folks post their ruleset
> with macros so obfuscated as to render
> Gosh, you're so right. It's impossible someone might submit their real
> ruleset from a hotmail/yahoo/myrealbox email account. What was I ever
> thinking. Let's make it a requisite that all folks with broken rulesets
> post their firewall's external IP information to the list.
There is noth
> if you think about it for a minute,
> $interface/24
> and
> $interface:network
> are not the same.
> they CAN expand to teh same thing. one possibility. just one.
Well true, but in most cases where this is used, the intent is
the latter (the network $interface sits on). I would expect
:netw
> > BTW I find it quite annoying that <> (no including the limits of the
> > range) isn't the same as : (includes the limits of the range).
>
> Do you mean that you'd like to see <> and >< include the limits of the
> range?
That would be a silly and arbitrary change, accomplishing little else
tha
> BTW I find it quite annoying that <> (no including the limits of the
> range) isn't the same as : (includes the limits of the range).
<> was horrible syntax. It came from IPF, and was retained for compatibility.
We added : for exactly this reason.
-kj
> i have a good idea, how about an obfuscated pf.conf contest?
I have a better idea. How about an unobfuscated pf.conf contest.
Clearest ruleset style wins. I'll buy the beer.
-kj
> This looks very weird, almost as if the snapshots were not properly
> built. Can you fetch the -current source for sys/net/pfvar.h and
> usr.sbin/tcpdump, then
I just tried this (snap is mid-january). There did appear to be
a problem (incorrect tcpdump?)
dropping a freshly compiled (-stable) tc
> ok, it was a real bug. the snapshots are fine ;-)
>
> and here's the fix...
Man. I need some coffee, or something.. I just verified that my
previously posted workaround fixed
on a -stable machine (which already worked).
Grr. Three days of digging into ipsec has me seeing double.
Your diff is
> Return-Path: [EMAIL PROTECTED]
> Delivery-Date: Fri Jan 17 14:46:14 2003
> If the client supports the extention, it will add a TCP option to its
> initial SYN packet, indicating its support (and supplying its own scale
> factor). If the peer also supports the extention, it will add its own
> TCP
> ...Guess i should take a look at the authpf and pfctl code
Or just look at anchors in the -current code.
Basically, find the spot in the ruleset where you want to insert
your rules, and drop an "anchor attacks" in there.
Then, for an attack in progress, do a:
echo 'block in quck from $att
> Oh well, having just learnt the astonishing truth that OpenBSD CD
> images aren't available for download, the (probably unrealistic)
> possiblity of deploying an OpenBSD based firewall this Saturday rather
> than the planned Linux deployment has just dropped to precisely 0%.
This is the funniest
> Would it be interesting to write a generic proxy that included
> support for each protocol? I mean, instead of running a proxy for
> X, Y and Z, you could run 1 proxy and enable/disable support for
> each application with the rdr rules.
Monolithic pieces of security-oriented sofware are inevit
> I don't think adding such a mechanism to the rule set improves
> performance, quite the opposite. A single pointer comparison (for an
> empty tree of embryonic states) is about as cheap as it gets. Look at
Here's that infernal "Single pointer comparison" again. You mean, if
someone isn't using
> Actually, there wouldn't be any real performance penalty, because these
> embrionic states are in effect only a tree sorted list of one shot rules.
>
> When they match they're removed from the embrionic tree, filled in with
> some other details, and moved to the normal state tree. It's just done
When all you have is a hammer, everything looks like a nail:
> I understand the security implications. I agree that FTP should be
> handled in user space. I want a solution that can be used to firewall
> FTP servers. I was proposing that this should be done in userspace,
> and musing on what l
> Is this correct, and if so, are there any plans to enhance it to be
> fully transparent? Without a fully transparent proxy, the logs on an
> ftp server behind an openbsd firewall would be rendered useless.
The proxy is not intended for an ftp SERVER behind the firewall. It is
intended for FTP
> @24 pass in log quick on rl1 inet proto tcp from 192.168.1.42/32 to
> 192.168.1.182/32 port = ssh flags S/FSRA
You will want a "keep state" in there, or else ONLY the initial
SYN will match, which is what you are experiencing.
>
> In order to stop the rest of the tech network from accessing
> I have an idea.. Dunno if anyone else has suggested tried or shot it down
> previously. I'm not a programmer and as such am not sure if this is even
> possible with PF.
This is the approach ipf took. It is fraught with peril.
First, PF operates at the IP layer. To watch for these commands in
29 matches
Mail list logo
