Re: Note: states with asymmetric routing
> 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 works fine on low rate, but fast transfers stops on > each 64K (because suddenly PF stops passing packets). > > I guess, it is not bug, just some feature (like some > tcp-window-related state protection). So think, is there reasons to > correct this PF behavior. Correct? If you can design a prescient packet filter, then more power to you. -kj
Re: Brige, Traffic Shaping and FTP
> 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 a definition: Def'n: (Kernel Proxy) A kind of state engine, implemented in the kernel that is smart enough to modify packets on the fly and recognize "related" packets. The naming comes from the ipf kernel-proxy for FTP. > I would argue that this is not quite the same as a proxy. However, > now-a-days, the difference between a stateful/NAT firewall and a Proxy is a > fine line and somewhat subjective. No. It's not a proxy. It's a "kernel proxy." We are ALL talking about the same thing here. > > Yes. Since the kernel sees traffic a packet at a time, it essentially > > has to "fake" the statefulness of TCP in order to track these things. > > It's a layer violation. It's also next to impossible, without re- > > implementing TCP. > What I don't get, is if what you are saying is true, how do commercial > firewall products work? They don't have access to the O/S source code and > manage. What am I missing? They implement a kernel proxy. They also implement kernel proxy bugs. (c.f. explots for both ipf and checkpoints' FTP proxies, allowing the malicious user to create arbitrary firewall states) > How is it a layer violation? Can't you link in with a callback or > something? Why do you have to re-implement TCP? Because you have to inspect traffic at the TCP level in order to determine what "related" traffic to allow through the firewall. (i.e. monitor the FTP control connection). Unfortunately, you are looking at packets as they arrive (i.e. the IP layer). If packets all arrived uniquely, un-fragmented, and in-order, this would be straigtforward. They do not. See Ptacek and Newsham's paper for a thousand reasons why this is a bad assumption. > In the end, I think Daniel is right. It sounds like a cool feature, but > someone would have to step up or help fund it. Perhaps some day, I'll learn > enough to be able to contribute... And if they are going to step up, they should think about scrub, bpf, and userland. Not kernel and payload inspection. Now, I've said my peace. Back to slackin' -kj
Re: Brige, Traffic Shaping and FTP
> 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 extract enough information to determine if they are, in fact "related" is exactly what Henning is referring to as a kernel "proxy" > If we go on with FTP, a piece of code that attach data connexions to > the command connexion initiated before. In case of a bridge, I > clearly do not need (and do not want !) a proxy, nor NAT support. Yes. Since the kernel sees traffic a packet at a time, it essentially has to "fake" the statefulness of TCP in order to track these things. It's a layer violation. It's also next to impossible, without re-implementing TCP. This is EXACTLY why the decision to make these kinds of per-protocol decision was relegated to userland in the first place: because TCP will handle the state issues, before userland sees the packets. Think fragment attacks. Think of the attacks against IPF's ftp kernel code. Think of EVERY ambiguity that scrub was intended to help correct. We had this debate long ago. The kernel way is the WRONG way. Writing a userland proxy for a particular protocol is by definition easier than writing the kernel equivalent, since you don't have to figure out what the TCP will do with ambiguities. -kj
Re: icmp on ports 256, 512, 768 & 1024
> 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
Re: T/TCP Stateful filtering
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
Re: T/TCP Stateful filtering
> 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
Re: pf(4) schemantics
> 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 scenario, 16 > searches down the binary tree? That ought to eat a few cycles. In the immortal words of Donald Knuth: "We should forget about small efficiencies ... premature optimization is the root of all evil" I really doubt there is a performance issue here, or really, that this would be the bottleneck. If it is, show the facts, and we (I use the royal we here, meaning Daniel or Henning) can address it then. Out. -kj
Re: pf(4) schemantics
> 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
Re: pf(4) schemantics
> 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 direction. (ie - transparent proxies). -kj
Re: pf(4) schemantics
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 state on {$ext_if $int_if} flags S/SAFR
(The way I had envisioned it, this would only occur for the
state-creating packet, and it would only do so for the interfaces
indicated.)
Is this what you mean?
-kj
Re: pf(4) schemantics
> 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, vlan05, ..., vlan09, lo0}
pass in quick on $trusted_ifs all
pass out quick on trusted_ifs all
am I missing something?
-kj
Re: PF related crash? (fwd)
> > 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 them illegible? Or perhaps > you're simply fabricating an impractical happenstance to validate your > zealotry? right. I made up that "impractical happenstance." I frequently make up hypothetical situations and act like they really happened, because I want people to think I'm important. no, Jason. I'm saying when people mangle their rulefiles before posting them, THEY OFTEN MANGLE THEIR RULEFILES. This is why I don't bother reading obviously mangled rulefiles any more. out -kj
Re: PF related crash? (fwd)
> 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 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. Also, when these addresses are obfuscated, often they are NOT done in a consistent manner. This makes the config files impossible to read. it is ALWAYS easiest to track down a problem from the actual ruleset used. Unless you have a good reason to change something, DON'T. -kj
Re: Syntax error in Snapshot pf.conf
> 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 :network and :broadcast syntax to satisfy just about everyone. -kj
Re: CVS: cvs.openbsd.org: src
> > 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 than to break existing rulesets in subtle ways. -kj
Re: CVS: cvs.openbsd.org: src
> 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
Re: RFC#1 - chmod pf.conf
> 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
Re: bridge
> 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) tcpdump on the box fixed the problem. -kj
Re: bridge
> 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 correct, henning. -kj
Re: PF NAT and Oracle/Linux mystery
> 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 option to the SYN+ACK, supplying its scale factor (the two factors > can be different). If only one of the peers understands the extention, > the ignorant one will not add the TCP option, and the proposing one must > not scale its window values. We could add a "strip-wscale" option to scrub. It doesn't solve the state pickup issue, but could prevent clients communicating through the firewall from negotiating this option. -kj
Re: RFC: libpf, simplifying pf(4) access to userland apps
> ...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 $attacker to any' | pfctl -a attacks -R -f - Alternately, you can now use tables for that purpose. In fact, that may be even more useful, as you can add/remove hosts from the table on the fly, without disturbing the existing entries. What is being said here is: you don't need a utility. you will be able to do it from the command line. (effectively, pfctl *IS* the API) -kj
Re: Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
> 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 thing I have heard in a while. If you were planning on downloading the IMAGE and burning it to a CD, what exactly is preventing you from downloading the tarfiles and burning THEM to a CD? IT'S THE SAME FRIGGIN THING! > Sorry to complain, just feel the need to vent my frustration at the > fact that it appears I can't get hold of a copy of OpenBSD at short > notice... In fact, it is EASIER to download a few 10's of megs worth of .tgz files than it is to download a 640M iso image. I can pull them down, burn the cd, and have the firewall installed in the time it takes be to pull down a single RedHat ISO. -kj
Re: Bad protocols and pf/nat
> 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 inevitably a bad idea. We should probably cobble together a plugboard proxy, however, as a kind of sample for proxy writers. -kj
Re: fully transparent ftp-proxy?
> 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 embryonic states (ie - embryonic list is null) there is a single pointer comparison. I'll buy that. Then again, if the feature is useful for proxies, it will probably eventually find its way into ftp-proxy, and there will be very few empty embryonic state tables out there. But again, I hate arguing against something based on "performance" data that is hypothetical. Thus, I'll reserve judgement. > The point of an embryonic state inserted by a proxy is that it's an > exception from the static filter policy. If you could allow these > connections using a static rule set, there would be no need for > embryonic states. If you can't, you also have troubles expressing, > statically, _what_ embryonic states to allow. A proxy making use of such > a feature would require access to /dev/pf and it would have to be written > as carefully as authpf, for instance. Actually, now that I try to construct something, it is quite hard to get the block rules correct without some idea like templating. Consider a passive FTP Server protected by a pf firewall: The ephemeral rule is: pass in on $evil_if proto tcp from any port * to $ftp_server port $pasvport uid proxy keep state ephemeral How much can we lock down a rule like this, to limit the damage the proxy can cause? Ideally, we'd want to restrict things so that the source port must be ephemeral, and so that the list of ports acceptible for the $pasvport choice are limited to a fixed range. If the ftp server was on the firewall box, we'd also want to limit things so that only sockets owned by user proxy could be connected to. I can't see a way, short of templating. Now, having argued myself into a complete circle, I'm going to just sit down and shut up for a bit. -kj
Re: fully transparent ftp-proxy?
> 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 > faster than if you added rules to match the same things. Though I hate to make performance-based arguments without any code to make an evaluation on, I have to say this makes me feel uneasy. It seems to me the only time the filter would NOT have to search the embryonic state table is: 1) If an existing state is matched 2) If the entire embryonic rule list is empty. So basically, every potentially state-creating packet is going to have to traverse this list. Sure, you can use skip steps to minimize the cost of the traversal, but this still seems like a hell of a hit. And though I like the idea of rule templates, I can't help but wonder if we can't achieve the same thing (limiting what kind of rules a proxy can insert) just by some well-thought-out "block [in/out] quick uid foo-proxy" rules (assuming the proxy's dynamic rules are added at the end.) -kj
Re: fully transparent ftp-proxy?
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 level of kernel support such a solution would > require. You have a solution. ftp-proxy + reverse diff. (If you don't see the need for the reverse diff, you're obviously not thinking of both active and passive connections). Firewalling is achievable. As far as I can tell, your complaint is logging, which can surely be handled by the ftp-proxy. It can do all sorts of logging. Feed them back to your loghost via a rotate script, or syslog. But at this point, I no longer see what problem you're trying to solve. -kj
Re: fully transparent ftp-proxy?
> 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 clients behind the firewall. > It seems to me that whilst it might require a minimal amount of kernel > machinery to permit setup of the outgoing connection from the proxy, > once established it is identical in nature to the incoming > connection... Minimal? Not even close. It requires the kernel to fully emulate TCP based on the information in the IP datagrams it is seeing. This is almost assuredly impossible to do correctly, and is the basis for just about every "open an arbitrary connection" attack on stateful firewalls that I can think of. so, no. There are no plans. Dangerous proxies like this one belong in userland, period. -kj
Re: pf 3.1 rule reading oddness
> @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 22 I have > > @9 block in log on rl1 inet proto tcp from 192.168.1.0/24 to > 192.168.1.182/32 port = ssh -kj
Re: Idea about automagic handling of active and passive mode FTP woes
> 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 the data stream (and do it right) is to essentially re-implement TCP inside the PF code (think fragments, tcp windows): clearly not desirable. Second, it opens up a whole new class of attacks, whereby you fool the firewall into opening arbitrary ports by getting FTP-looking packets to pass the firewall. This is not particularly far fetched. I can think of many, MANY ways to do it. The only way to avoid these style attacks is to eliminate the code duplication, and rely on the TCP layer to do your reassembly for you. In other words, implement a userland proxy, which is exactly the approach taken in PF. -kj
