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: 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: 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
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
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
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 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. /sarcasm 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: 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: 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: 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: 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?
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?
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: 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
