Re: ipf pf beginner question
On Wed, Oct 30, 2002 at 01:38:59PM -0300, Helio Alexandre Lopes Loureiro wrote: How I said, keep state looks like not working properly nonsense.
Re: ipf pf beginner question
On Wed, Oct 30, 2002 at 07:13:17PM +0100, Per olof Ljungmark wrote:
At 18:42 10/30/2002 +0100, Henning Brauer wrote:
On Wed, Oct 30, 2002 at 01:38:59PM -0300, Helio Alexandre Lopes Loureiro
wrote:
How I said, keep state looks like not working properly
nonsense.
To make this a yes or no perhaps makes sense.
Is the following ruleset (in principle) enough for access to a dns server
behind a pf firewall?
pass in on xl0 inet proto {tcp, udp} from any to any port 53 keep state
given
-this is the last matching rule
-you don't filter one other interfaces that packet would need to pass
yes.
Re: ipf pf beginner question - about nonsense
On Wed, Oct 30, 2002 at 03:38:37PM -0300, Helio Alexandre Lopes Loureiro wrote: A stateful firewall is not designed to keep a pass rule over all interfaces? no. in practice the state is hammered to the interface, which is a very very very good thing (I rely on it for the firewalls in front of the server networks here whoch has tons of vlan interfaces. on the external interface I do spoof protection - out: src must be from an internal net, in: dest must be from an internal net -, on each vlan interface there are rules for incoming and outgoing policy, and a packet crossing vlans must go through the outbound policy on the source vlan interface and through the inbound policy on the destination vlan interface, where inbound and outbound is from teh network view and actually reversed when you look at the interface). well, they are not really hammered to the interface, but in practice that's the result. I'm not a OpenBSD expertise, but the same rules under Iptables iptables isn't really statefull. it doesn't do sequence number checking.
Re: ipf pf beginner question - about nonsense
no. in practice the state is hammered to the interface, which is a very very very good thing (I rely on it for the firewalls in front of the server networks here whoch has tons of vlan interfaces. on the external interface I do spoof protection - out: src must be from an internal net, in: dest must be from an internal net -, on each vlan interface there are rules for incoming and outgoing policy, and a packet crossing vlans must go through the outbound policy on the source vlan interface and through the inbound policy on the destination vlan interface, where inbound and outbound is from teh network view and actually reversed when you look at the interface). Henning and Daniel, You really got the point. Now everything have sense (I'm feeling me like a shinning). This description is missing on man pages and PF howto. Thanks guys. -- Hélio Alexandre Lopes Loureiro [[EMAIL PROTECTED]] Regional Software Supply Integration South America Tel.: + 55 11 6224-1795 Public Key ID: FB5972D1@http://search.keyserver.net
IP Accounting per IP
Hello, All. I have two bridging firewalls that provide redundancy via stp. I am looking for something that will give me statistics on how much traffic is going through the bridge by IP. In other words I want to be able to tell who (by IP address) is using what bandwidth. I have installed/configured a couple of tools and pointed them at the bridge but the numbers they return don't seem correct. Also, a lot of the tools are designed to give total traffic but not break it down by IP address. I'm getting tired of installing/configuring software and not having it work. If anybody else has done this please point me at what software you are using. Thanks in advance, +Samuel Freiberg +-(816)472-7878 x 236 +--www.lookandfeel.com +---Systems Administrator Looking for extra network security? Check out the Snort Alert Monitor written by yours truly and available as Open Source http://freesoftware.lookandfeel.com/sam.
fully transparent ftp-proxy?
The documentation for ftp-proxy seems to imply that it's only semi-transparent. ie that although it is transparent to the client, the server sees the connection come from the proxy and not from the true IP address of the client. 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. 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... Thanks in advance, -roy
re: audit of ruleset request
NoRouteIPs={0.0.0.0/32, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
172.16.0.0/12, 192.168.0.0/16, 204.152.64.0/23, 224.0.0.0/3,
255.255.255.255/32 }
Note that 224.0.0.0/3 already includes 255.255.255.255/32.
Specifically, it encompasses the Class D (multicast) addresses
224.0.0.0/4, the all-ones broadcast address 255.255.255.255, and the
unused Class E (experimental) space that lies between.
Also, I was under the impression that for historical classful reasons
all of 0.0.0.0/8 is invalid and should be dropped.
What's 204.152.64.0/23 ?
-roy
Re: fully transparent ftp-proxy?
On Wed, Oct 30, 2002 at 08:41:12PM +, Roy Badami wrote: 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... This could be solved with 'embryonic states', a separate list/tree of state entries that lack certain parts (like source ports, which are usually random and not known in advance). After the normal state lookup (if it fails), but before the rule set evaluation, a matching embryonic state would be completed and turn into a normal state. Proxies could insert embryonic states instead of listening for incoming connections, establishing connections and forwarding data between them. Also, embryonic states could include all sorts of address/port translations, so even connections established by the proxy (for instance the ftp control connection) could appear to originate from the real client address through a source address translation. There are many ways proxies could use this feature, potentially making the proxy code much shorter. But there are also security implications, as a state entry bypasses all filter rules. But it's definitely something I want to try. There are several problems to solve, like supporting different kinds of incomplete states while keeping lookups efficient. If they're solved, and the concept works and is safe, I guess ftp-proxy could (optionally, if necessary) use that to become fully transparent. Daniel
Re: fully transparent ftp-proxy?
I'm not proposing a kernel ftp proxy -- I agree that there are conditions [...] that are almost impossible to handle correctly. Actually, I think I'm going to change my mind here (am I allowed to do that? ;-) An imperfect kernel FTP proxy (as provided by iptables or ipfilter) is surely still better than nothing when firewalling an FTP server. If the userland FTP proxy can't easily be made fully transparent, then a kernel FTP filter is still useful. Implemented correctly, it's a second line of defense: it won't allow any packets that I wouldn't otherwise have allowed anyway, but might block some that I am currently forced to allow. Put another way: the fact that you can't spot all invalid packets that might be sent to my FTP server isn't an argument for not blocking those that you can spot... -roy
Re: fully transparent ftp-proxy and other stories...
On Wed, Oct 30, 2002 at 10:26:24PM +, Roy Badami wrote: Is that what everyone else does? Yes. If you can't ensure that the ftp server never has a vulnerable service listen on a port inside the range used for ftp passive data connections, you could use ftp-proxy with the reverse proxy diff (see archive), and open the port range only on the firewall, which then forwards the data connections to the ftp server. And ensuring no vulnerable service starts listening on a port in that range on the firewall should be possible... Incidentally, the other big thing I get with iptables (that pf lacks, as far as I can tell) is the ability for a rule to match on both the interface that a packet was received on and the interface that it will be forwarded out on. Whilst not a showstopper, it makes the rules a lot simpler and maintainable in the case of a large network (otherwise you essentially have to duplicate your routing table in your filtering rules in order to gain the same effect). I don't understand how the ability to specify both interfaces in a single rule in iptables helps you there. If a connection always comes in through interface A but can leave through B or C, depending on the (dynamic) routing table, how do you write the rule set so it covers both cases and doesn't duplicate the routing table? How is that different from filtering on all three interfaces and allowing connection in on A and out of B and C statefully? Daniel
Re: fully transparent ftp-proxy?
On Wed, Oct 30, 2002 at 10:52:28PM +, Roy Badami wrote: An imperfect kernel FTP proxy (as provided by iptables or ipfilter) is surely still better than nothing when firewalling an FTP server. If the userland FTP proxy can't easily be made fully transparent, then a kernel FTP filter is still useful. I agree, it's better than no firewall at all. But it's worse than a firewall that reliably blocks access to some vulnerable ports, because the in-kernel proxy could be tricked into opening those ports. Of course, even a wet towel is better than no firewall. Daniel
Re: fully transparent ftp-proxy?
Daniel Hartmeier wrote: On Wed, Oct 30, 2002 at 11:10:18PM +0100, Henning Brauer wrote: Uh well, this sounds like a massive performance penalty... I don't think I like that. A lookup in an empty list/tree would of course equal a single pointer comparison, so if someone is not using the feature, there's no additional cost. In any case, I'd expect the number of active embryonic connections to be pretty low in non-pathological circumstances anyway. You would probably want to have a hard-limit though. -d
Re: fully transparent ftp-proxy?
On Wed, Oct 30, 2002 at 10:38:09PM +, Roy Badami wrote: Uh well, this sounds like a massive performance penalty... I don't think I like that. More massive than sending your data through a userland daemon? YES YES YES and YES. it only affects ftp, while a second table of half baked state entries affects EACH and EVERY packet flowing through the firewall which doesn't match an existing state. If you don't use this facility then the performance impact will be negligible. nonsense. it's one lookup to the second table for EACH and EVERY packet flowing through the firewall which does not match an existing state. And if it's functionality that you need, then (like ftp-proxy) surely the CPU cost is worth the benefit? no. ftp handling is fine as it is. it belongs into userland as it is. you do not understand the security implications. read about the recent vulns in packet filtering packages that have (WRONG WRONG WRONG) in-kernel ftp connection tracking.
Re: fully transparent ftp-proxy?
On Wed, Oct 30, 2002 at 11:46:06PM +0100, Daniel Hartmeier wrote: On Wed, Oct 30, 2002 at 11:10:18PM +0100, Henning Brauer wrote: Uh well, this sounds like a massive performance penalty... I don't think I like that. A lookup in an empty list/tree would of course equal a single pointer comparison, so if someone is not using the feature, there's no additional cost. there is, you just wrote it: A lookup in an empty list/tree would of course equal a single pointer comparison ;-) And since the lookup happens after the ordinary state lookup (and only if that fails), the cost occurs only per connection, not per packet. Compare to the per packet cost of forwarding the connection through userland... well. there is additional cost. we need to take care. we start adding little nifty features here and there, and for itself they all don't cost much. a few doesn't cost much added together gives a noticeable additional cost. I question that it can be done secure at all. Aside from that: people using ftp-proxy in front of a ftp-server which is not NATed make a fault. it's not needed.
Re: fully transparent ftp-proxy?
On Wed, Oct 30, 2002 at 10:52:28PM +, Roy Badami wrote: An imperfect kernel FTP proxy (as provided by iptables or ipfilter) is surely still better than nothing when firewalling an FTP server. no it's not. again, you don't get the security implications. ftp connection tracking in the kernel is just plain wrong. please read about the recent problems wrt this in ipfilter and the linux packages.
Re: fully transparent ftp-proxy and other stories...
Yes. If you can't ensure that the ftp server never has a vulnerable service listen on a port inside the range used for ftp passive data connections [...] I would hope that I am always able to ensure this. But it's a matter of 'security in depth': you may as well firewall the systems you believe to be secure, not just those you believe not to be. It might conceivably defeat a backdoor that a hacker plants should the FTP server have a vulnerability. Don't underestimate the effectiveness of this -- given that most compromises are made by script kiddies running exploit scripts, anything that stops the script from behaving as expected might save you. And if nothing else the firewall might protect you from configuration errors on your server... [...] you could use ftp-proxy with the reverse proxy diff (see archive) I have to admit that I can't immediately see why ftp-proxy should need to be patched to allow this. Isn't this just the same as the usual case? I don't understand how the ability to specify both interfaces in a single rule in iptables helps you there. In my case the routing table is static, and it's largely just a syntactic convenience (but an important one) I currently (in ipchains) find myself doing the equivalent of: pass in on interface_A to long_list_of_networks_behind_interface_B ... which results in a rule that is far more complex than what I am conceptually trying to accomplish. It also means that the long list of networks behind interface B has to be maintained in two places, namely in my static routes and in my packet filters -- and there is a security risk if an error is made editing these lists. iptables allows me to neatly sidestep this issue by defining my rules in topological terms. I can write a rule that applies to packets sent from interface A to interface B without having to hardwire the list of networks into my packet filters. (And the explicit form gets really messy when you have a network routed out of one interface, except for a small subnet of it which sits on another interface.) -roy
Re: fully transparent ftp-proxy?
ftp handling is fine as it is. it belongs into userland as it is. you do not understand the security implications. read about the recent vulns in packet filtering packages that have (WRONG WRONG WRONG) in-kernel ftp connection tracking. 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. -roy
Re: fully transparent ftp-proxy?
Aside from that: people using ftp-proxy in front of a ftp-server which is not NATed make a fault. it's not needed. I don't understand. Why is firewalling my FTP server a bad idea? -roy
Re: fully transparent ftp-proxy and other stories...
On Wed, Oct 30, 2002 at 11:34:16PM +, Roy Badami wrote: I have to admit that I can't immediately see why ftp-proxy should need to be patched to allow this. Isn't this just the same as the usual case? The usual case is ftp clients behind a NATing firewall, allowing active data connections back from the server to the client. ftp-proxy inspects and modifies the control connection stream so the server makes active data connections to the firewall's address, and then connects to the client and forwards the data. If it's the ftp server behind the firewall, you want to modify 227 replies from the server and proxy passive data connections instead. iptables allows me to neatly sidestep this issue by defining my rules in topological terms. I can write a rule that applies to packets sent from interface A to interface B without having to hardwire the list of networks into my packet filters. I don't trust routing tables to influence filter rules. You set securelevel = 2 to prevent filter rules modifications and then some BGP fuckup opens your firewall wide open? Why do you need huge lists of addresses in rule sets? I agree that duplicating them on multiple interfaces is annoying, but that's what macros are for. (And the explicit form gets really messy when you have a network routed out of one interface, except for a small subnet of it which sits on another interface.) That can be covered with two simple rules with one netblock each, the second overriding the first, no? Daniel
Re: fully transparent ftp-proxy?
On Wed, Oct 30, 2002 at 11:43:36PM +, Roy Badami wrote: 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. it is already there. ftp-proxy is not needed for that. you just need to understand how ftp works (and thus what for a fucking stupid protocol ftp actually is). And heck, even given ftp-proxy is not needed, it does the job if you insist on doing so. msg00347/pgp0.pgp Description: PGP signature
Load balancing question?
I've just read Daniel's interview (damn slashdotted server!!). And I found that comented that load balancing was left out only because of patents. A couple of monthes ago we discussed about making multi NAT rules with the possiblility of turnin on and off some IP. Is this also covered by such patents? Were those ideas useful? Should the rest of the world pay for the idiotic US patents system? May be it could be made like ssh before the RSA patent wentpublic. Regards, Alejandro Belluscio PD: FTP should die a slow painful death. Use HTTP.
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?
it is already there. ftp-proxy is not needed for that. you just need to understand how ftp works (and thus what for a fucking stupid protocol ftp actually is). And heck, even given ftp-proxy is not needed, it does the job if you insist on doing so. Please don't assume what I know about IP networking and firewalling, I'm getting kind of tired of this. I understand how FTP works, and I understand firewalling. I am not familliar with OpenBSD, and am trying to understand how it would mesh with our requirements. Repeatedly implying that I don't understand IP networking and firewalling is not productive. I agree that your approach is probably adequate. I just feel happier only allowing passive data connections to the server after they've been negotiated on the control connection. Something that linux allows me to do. But on balance it's probably not a big deal. -roy
Re: fully transparent ftp-proxy and other stories...
The usual case is ftp clients behind a NATing firewall, allowing active data connections back from the server to the client. ftp-proxy inspects and modifies the control connection stream so the server makes active data connections to the firewall's address, and then connects to the client and forwards the data. If it's the ftp server behind the firewall, you want to modify 227 replies from the server and proxy passive data connections instead. The man page implies that ftp-proxy proxies passive mode data connections as standard (unless -n is specified). Are we talking at cross purposes here? The FTP server has a real, routable IP address. No NAT involved. I don't see why I would need to do anything special. -roy
Re: fully transparent ftp-proxy?
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. I admit that at this point I haven't a clue what reverse diff is -- I will search the archives. 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. Merging the ftp logs and the firewall logs is a workaround, certainly. But at this point, I no longer see what problem you're trying to solve. Not having to rewrite all the scripts that process the logs just because I'm using OpenBSD as my firewall... -roy
Re: fully transparent ftp-proxy and other stories...
I don't trust routing tables to influence filter rules. You set securelevel = 2 to prevent filter rules modifications and then some BGP fuckup opens your firewall wide open? Why do you need huge lists of addresses in rule sets? I agree that duplicating them on multiple interfaces is annoying, but that's what macros are for. My routing tables are static, so BGP doesn't come into it. The duplication is that I have to specify the same set of networks in the script that sets up the routes and in the filtering rules. Granted it's not the end of the world, I can live with it. But conceptually I'm firewalling domains of machines connected to physical interfaces. I still think it's much cleaner to be able to refer to those domains of machines by reference to the physical interface. I want to be able to say INSIDE, OUTSIDE, DMZ1, DMZ2, and have them guaranteed to correspond to what's physically plugged in to those ports. Curretnly it relies on my not screwing up with my macro definitions. -roy
Re: fully transparent ftp-proxy?
Interesting idea ;) As I also pointed out, the security could be increased by linking embrionic states with the filter rules. Like adding an embrionic keyword or something similar, so that an embrionic state will only try to match if it matches a permissive filter rule. That way, the proxies still need to have some form of permission given by the ruleset. To implement that however, for it to be effective, you would need to be able to give proxies access to some pf ioctl functions (like adding embrionic states), but not others (like adding rules). I'm guessing this could be accomplished with systrace, but I think some other check in pf_ioctl would be more secure. -- Rukh On Wed, 30 Oct 2002, Daniel Hartmeier wrote: On Wed, Oct 30, 2002 at 08:41:12PM +, Roy Badami wrote: 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... This could be solved with 'embryonic states', a separate list/tree of state entries that lack certain parts (like source ports, which are usually random and not known in advance). After the normal state lookup (if it fails), but before the rule set evaluation, a matching embryonic state would be completed and turn into a normal state. Proxies could insert embryonic states instead of listening for incoming connections, establishing connections and forwarding data between them. Also, embryonic states could include all sorts of address/port translations, so even connections established by the proxy (for instance the ftp control connection) could appear to originate from the real client address through a source address translation. There are many ways proxies could use this feature, potentially making the proxy code much shorter. But there are also security implications, as a state entry bypasses all filter rules. But it's definitely something I want to try. There are several problems to solve, like supporting different kinds of incomplete states while keeping lookups efficient. If they're solved, and the concept works and is safe, I guess ftp-proxy could (optionally, if necessary) use that to become fully transparent. Daniel
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. And if you don't like using embrionic states, then you would have an empty embrionic state tree and it would then only require one extra pointer comparison (and seeing that it's NULL), before moving on to evaluating the rule set. And if you were to follow my previous post, you wouldn't even have to evalutate the tree until you found a rule in the rule list that allowed you to do so. -- Rukh On Wed, 30 Oct 2002, Henning Brauer wrote: On Wed, Oct 30, 2002 at 10:24:29PM +0100, Daniel Hartmeier wrote: On Wed, Oct 30, 2002 at 08:41:12PM +, Roy Badami wrote: 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... This could be solved with 'embryonic states', a separate list/tree of state entries that lack certain parts (like source ports, which are usually random and not known in advance). After the normal state lookup (if it fails), but before the rule set evaluation, a matching embryonic state would be completed and turn into a normal state. Uh well, this sounds like a massive performance penalty... I don't think I like that.
Re: fully transparent ftp-proxy?
On Thu, Oct 31, 2002 at 01:03:23PM +1000, Rukh wrote: 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. oh yes, and the lookup is absolutely for free, sure. And if you don't like using embrionic states, then you would have an empty embrionic state tree and it would then only require one extra pointer comparison (and seeing that it's NULL), before moving on to evaluating the rule set. yes. extra cost. a little extra cost here, a little extra cost there, summarized is more than just a little extra cost. msg00358/pgp0.pgp Description: PGP signature
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
