Re: /usr/share/pf/ suggestion
On Tuesday 23 August 2005 11:58 pm, eric wrote: On Tue, 2005-08-23 at 16:53:25 -0600, Theo de Raadt proclaimed... It is plain simple bad advice. And totally ridiculous. And plus, with ipv6, it's imperative that the filters be pushed down to the end-host so we can quit relying on stupid firewalls and NAT bullshit to break networks and slow progress. Itojun mentioned the fact that each host should have a firesuit in the ipv6 world. It's quite good advice. Well, lets not get ahead of ourselves here. Filtering at the network edge is A Good Thing(TM) when done correctly, it is NAT that is not necessarily a good thing. Filtering incoming (and possibly outgoing traffic) helps do several things, first it decreases the burden on your hosts. It also allows you a place to stop traffic that should never leave your network, for example, only your mail servers should be allowed to send traffic on port 25. I'm not saying that we should ignore host based firewalls, because that isn't the case, I'm just recommending that you not be so quick to dismiss the value of having a filter beyond the host.
Re: /usr/share/pf/ suggestion
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bryan Irvine Sent: Wednesday, August 24, 2005 10:11 AM To: Misc OpenBSD Subject: Re: /usr/share/pf/ suggestion I personally like to 'pass keep state' with a 'scrub all' rule. This at least gives me some interesting statistics to poke at when I'm bored. Plus, I can firewall who gets to ssh into my machine. Another good use is {max-src-states ##} for webservers and the like. I have a webserver that would crash at 9am every morning when a few bots (2 in particaular) would crawl the site. They are poorly configured and open roughly 120 simlutaneous connections. They were very low bandwidth, but there went all available connections. To quote Theo it's Horse-shit to say you don't need to filter single hosts. --Bryan What crashed? Apache or OpenBSD?
Re: /usr/share/pf/ suggestion
I personally like to 'pass keep state' with a 'scrub all' rule. This at least gives me some interesting statistics to poke at when I'm bored. Plus, I can firewall who gets to ssh into my machine. Another good use is {max-src-states ##} for webservers and the like. I have a webserver that would crash at 9am every morning when a few bots (2 in particaular) would crawl the site. They are poorly configured and open roughly 120 simlutaneous connections. They were very low bandwidth, but there went all available connections. To quote Theo it's Horse-shit to say you don't need to filter single hosts. --Bryan
Re: /usr/share/pf/ suggestion
On Wed, Aug 24, 2005 at 09:15:48AM -0400, Timothy Donahue wrote: On Tuesday 23 August 2005 11:58 pm, eric wrote: On Tue, 2005-08-23 at 16:53:25 -0600, Theo de Raadt proclaimed... It is plain simple bad advice. And totally ridiculous. And plus, with ipv6, it's imperative that the filters be pushed down to the end-host so we can quit relying on stupid firewalls and NAT bullshit to break networks and slow progress. Itojun mentioned the fact that each host should have a firesuit in the ipv6 world. It's quite good advice. Well, lets not get ahead of ourselves here. Filtering at the network edge is A Good Thing(TM) when done correctly, it is NAT that is not necessarily a good thing. Speaking as a network guy NAT is A Good Thing granted it breaks some outdated notion of end to end commo. But if more people payed strict attention to the OSI model that would not matter. Simply put if an application puts a IP addy someplace my NAT box can't touch it the application is broken. And in today's world anything that puts one more layer between my network and the net is good. Other than that I agree with everything else you've said. Filtering incoming (and possibly outgoing traffic) helps do several things, first it decreases the burden on your hosts. It also allows you a place to stop traffic that should never leave your network, for example, only your mail servers should be allowed to send traffic on port 25. I'm not saying that we should ignore host based firewalls, because that isn't the case, I'm just recommending that you not be so quick to dismiss the value of having a filter beyond the host. -- BOFH excuse #381: Robotic tape changer mistook operator's tie for a backup tape.
Re: /usr/share/pf/ suggestion
On 8/24/05, Bryan Irvine [EMAIL PROTECTED] wrote: I personally like to 'pass keep state' with a 'scrub all' rule. This at least gives me some interesting statistics to poke at when I'm bored. Plus, I can firewall who gets to ssh into my machine. Another good use is {max-src-states ##} for webservers and the like. I have a webserver that would crash at 9am every morning when a few bots (2 in particaular) would crawl the site. They are poorly configured and open roughly 120 simlutaneous connections. They were very low bandwidth, but there went all available connections. To quote Theo it's Horse-shit to say you don't need to filter single hosts. I left out a lot of my reasoning for feeling the way I do in my first mail about not needing a packet filter on single hosts, and it's more a personal preference, not telling everyone that you're all idiots for wanting to. If your web server crashes because it has 240 connections open (I'm assuming 120 per bot) then there seems to be something else wrong with it, and shouldn't be ignored by just throwing up pf. It was more that for me, if I throw up pf to protect a single host, I tend to get lazy in the administration of it, and start ignoring things that should really be looked at (like applications opening up random ports, in reference to an earlier KDE post). I really don't think that a desktop environment should be opening up anything at all, and so I'd rather just not run it instead of run a desktop environment that I have no idea what it's doing on the network. If anyone is interested any further as to why I feel the way I do, email me privately, since this is getting way off topic and doesn't belong on the openbsd-misc mailing list anyways. Jason
Re: /usr/share/pf/ suggestion
On Wed, 2005-08-24 at 09:15:48 -0400, Timothy Donahue proclaimed... A Good Thing(TM) when done correctly, it is NAT that is not necessarily a good thing. Filtering incoming (and possibly outgoing traffic) helps do several things, first it decreases the burden on your hosts. It also allows you a place to stop traffic that should never leave your network, for example, only your mail servers should be allowed to send traffic on port 25. Ha, sure. Now get a job outside your little corporate entity and see how that goes over. Then let us decide on our own policies.
Re: /usr/share/pf/ suggestion
What crashed? Apache or OpenBSD? Apache of course! ;)
Re: /usr/share/pf/ suggestion
-Original Message- From: j knight [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 4:47 PM To: Will H. Backman Subject: Re: /usr/share/pf/ suggestion --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400: Would it be useful to add an example pf rule set for just a simple host? All of the examples assume a router. This would be more useful in the faq. Please send what you've written. :-) .joel # pf rules for a stand alone machine. #Change external interface to match yours ext_if=xl0 scrub in all block in all pass out keep state pass quick on lo all
Re: /usr/share/pf/ suggestion
-Original Message- From: Jason Crawford [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 5:25 PM To: Will H. Backman Cc: j knight; Misc OpenBSD Subject: Re: /usr/share/pf/ suggestion On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote: -Original Message- From: j knight [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 4:47 PM To: Will H. Backman Subject: Re: /usr/share/pf/ suggestion --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400: Would it be useful to add an example pf rule set for just a simple host? All of the examples assume a router. This would be more useful in the faq. Please send what you've written. :-) .joel # pf rules for a stand alone machine. #Change external interface to match yours ext_if=xl0 scrub in all block in all pass out keep state pass quick on lo all First off, it should be, set skip on lo0 (or lo, but by default there's only one lo interface anyways). Secondly, it seems pretty pointless to setup pf on a single host. Instead of worrying about the firewall, which takes up more memory and cpu and all that, just shut off services that you don't need and be done with it. If the attacker can hurt your OpenBSD machine, then your firewall is vulnerable as well, and it won't protect any applications that need open ports listening. Turning off services is always much better than turning on services (pf) if you need protection. And the way OpenBSD is setup by default, nothing is listening except a couple inetd services (which I always turn off), and sshd if you said y in install, that's it. Jason I agree in general, but then start adding the gnome or kde desktop or other applications and you never know what is listening.
Re: /usr/share/pf/ suggestion
On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote: -Original Message- From: j knight [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 4:47 PM To: Will H. Backman Subject: Re: /usr/share/pf/ suggestion --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400: Would it be useful to add an example pf rule set for just a simple host? All of the examples assume a router. This would be more useful in the faq. Please send what you've written. :-) .joel # pf rules for a stand alone machine. #Change external interface to match yours ext_if=xl0 scrub in all block in all pass out keep state pass quick on lo all First off, it should be, set skip on lo0 (or lo, but by default there's only one lo interface anyways). Secondly, it seems pretty pointless to setup pf on a single host. Instead of worrying about the firewall, which takes up more memory and cpu and all that, just shut off services that you don't need and be done with it. If the attacker can hurt your OpenBSD machine, then your firewall is vulnerable as well, and it won't protect any applications that need open ports listening. Turning off services is always much better than turning on services (pf) if you need protection. And the way OpenBSD is setup by default, nothing is listening except a couple inetd services (which I always turn off), and sshd if you said y in install, that's it. Jason
Re: /usr/share/pf/ suggestion
Secondly, it seems pretty pointless to setup pf on a single host. That is the most ridiculous thing I've heard all day. Lots of people run servers and must block them, on the same machine. Probably every single one of us. Instead of worrying about the firewall, which takes up more memory and cpu and all that, just shut off services that you don't need and be done with it. If the attacker can hurt your OpenBSD machine, then your firewall is vulnerable as well, and it won't protect any applications that need open ports listening. Turning off services is always much better than turning on services (pf) if you need protection. And the way OpenBSD is setup by default, nothing is listening except a couple inetd services (which I always turn off), and sshd if you said y in install, that's it. Anyone who says I only need to block packets in my firewall has got it all wrong.
Re: /usr/share/pf/ suggestion
--On 23 August 2005 17:25 -0400, Jason Crawford wrote: Secondly, it seems pretty pointless to setup pf on a single host. It has it's uses - spamd, for one...
Re: /usr/share/pf/ suggestion
That is the most ridiculous thing I've heard all day. Lots of people run servers and must block them, on the same machine. Probably every single one of us. I'm not sure I understand what you mean. If you're going to run a server, what's the point of blocking it? Might as well turn it off. My laptops filter port 6000 and up, thank you very much. I will not stop running X. You must just just plain not understand what you are saying. Your statements are beyond ridiculous. You are saying If you need to filter it, you should not be running it.
Re: /usr/share/pf/ suggestion
I never said that. PF isn't the only way to block packets, like TCP wrappers or ACL's within the server itself. That is horse shit, and shows that you don't know how actual code works. I prefer to filter problems BEFORE THE ACTUAL CODE RUNS. Perhaps you don't know what a pre-authentication bug is. It seems that adding another layer to the mix takes up more CPU and RAM than needed, since most servers have some sort of ACL list for acceptable hosts, and tcp wrappers does a good job too. More horshit. It uses LESS memory and cpu than all that TCP filters, and actually making the application wake up and decide that it does not want a connection. You are 100% wrong.
Re: /usr/share/pf/ suggestion
On 8/23/05, Stuart Henderson [EMAIL PROTECTED] wrote: --On 23 August 2005 17:25 -0400, Jason Crawford wrote: Secondly, it seems pretty pointless to setup pf on a single host. It has it's uses - spamd, for one... Which is already covered in the spamd man page and doesn't need another entry in the FAQ.
Re: /usr/share/pf/ suggestion
On 8/23/05, Theo de Raadt [EMAIL PROTECTED] wrote: Secondly, it seems pretty pointless to setup pf on a single host. That is the most ridiculous thing I've heard all day. Lots of people run servers and must block them, on the same machine. Probably every single one of us. I'm not sure I understand what you mean. If you're going to run a server, what's the point of blocking it? Might as well turn it off. Instead of worrying about the firewall, which takes up more memory and cpu and all that, just shut off services that you don't need and be done with it. If the attacker can hurt your OpenBSD machine, then your firewall is vulnerable as well, and it won't protect any applications that need open ports listening. Turning off services is always much better than turning on services (pf) if you need protection. And the way OpenBSD is setup by default, nothing is listening except a couple inetd services (which I always turn off), and sshd if you said y in install, that's it. Anyone who says I only need to block packets in my firewall has got it all wrong. I never said that. PF isn't the only way to block packets, like TCP wrappers or ACL's within the server itself. It seems that adding another layer to the mix takes up more CPU and RAM than needed, since most servers have some sort of ACL list for acceptable hosts, and tcp wrappers does a good job too. Jason
Re: /usr/share/pf/ suggestion
Your statements are beyond ridiculous. You are saying If you need to filter it, you should not be running it. X doesn't have to listen on TCP 6000, you can setup a unix socket, and it's no longer reachable from the network, and you still have full functionality (I know, I do just that). And I don't have the TIME OF DAY to do that, it is EASIER to filter! AND IT USES LESS PROCESSOR! AND IT USES LESS MEMORY! There's more than one way to do anything. If something needs to only be locally accessable, only have it listen locally, or use unix sockets instead of tcp/udp sockets completely. No, that is not what you said: You did not say there are many ways to do this. Instead, you very specifically suggested that people NOT filter using the packet filter, but to instead configure applications, or to NOT run the servers in those locations then. And THAT is what is utterly ridiculous. It is plain simple bad advice. And totally ridiculous. You're wrong. People should run packet filters wherever they want, since in many cases it is EASIER than thousands of lines of later code running and having a pre-authentication bug. Telling people to go tune their applications, tune tune tune tune, that is the mantra of Linux people who then run out of time and expertise, and then leave their machines open. People will NOT avoid running kde which opens half a thousand stupid ports, and they will NOT go and learn to configure those applications with a thousand buttons, because they don't have the TIME OF DAY to follow your ridiculous push more buttons you don't know advice. You're wrong. Everyone -- run pf wherever you find it easier.
Re: /usr/share/pf/ suggestion
On 8/23/05, Theo de Raadt [EMAIL PROTECTED] wrote: That is the most ridiculous thing I've heard all day. Lots of people run servers and must block them, on the same machine. Probably every single one of us. I'm not sure I understand what you mean. If you're going to run a server, what's the point of blocking it? Might as well turn it off. My laptops filter port 6000 and up, thank you very much. I will not stop running X. You must just just plain not understand what you are saying. Your statements are beyond ridiculous. You are saying If you need to filter it, you should not be running it. X doesn't have to listen on TCP 6000, you can setup a unix socket, and it's no longer reachable from the network, and you still have full functionality (I know, I do just that). There's more than one way to do anything. If something needs to only be locally accessable, only have it listen locally, or use unix sockets instead of tcp/udp sockets completely. Jason
Re: /usr/share/pf/ suggestion
On Tue, 2005-08-23 at 17:25 -0400, Jason Crawford wrote: Secondly, it seems pretty pointless to setup pf on a single host. I beg to differ. man pf.conf, and look at the user and group keywords. -- Shawn K. Quinn [EMAIL PROTECTED]
Re: /usr/share/pf/ suggestion
On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote: I agree in general, but then start adding the gnome or kde desktop or other applications and you never know what is listening. what the hell?
Re: /usr/share/pf/ suggestion
On Tue, Aug 23, 2005 at 06:57:43PM -0400, Will H. Backman wrote: -Original Message- From: Theo de Raadt [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 6:53 PM To: Jason Crawford Cc: Will H. Backman; j knight; Misc OpenBSD Subject: Re: /usr/share/pf/ suggestion snip (Crawling out of my protective hole) So does it make sense to include a basic pf rule set for a basic end-user host that blocks everything by default? I've done it using the example I gave. Don't know if my way has some errors or not. I'd say punch a hole for SSH. This is because I consider a *NIX box that can not be managed via SSH to be borken. And, of course, we are only talking about having this as an example and maybe mentioned in a FAQ someplace and not turned on by defualt, right? -- BOFH excuse #394: Jupiter is aligned with Mars.
Re: /usr/share/pf/ suggestion
There is an example: set pf=YES in /etc/rc.conf.local reboot pfctl -sr will give you: block drop all pass on lo0 all pass in proto tcp from any to any port = ssh keep state pass out proto tcp from any to any port = domain keep state pass out proto udp from any to any port = domain keep state pass out inet proto icmp all icmp-type echoreq keep state pass proto pfsync all pass proto carp all i.e Invoked from /etc/rc if [ X${pf} != XNO ]; then RULES=block all RULES=$RULES\npass on lo0 RULES=$RULES\npass in proto tcp from any to any port 22 keep state RULES=$RULES\npass out proto { tcp, udp } from any to any port 53 keep state RULES=$RULES\npass out inet proto icmp all icmp-type echoreq keep state RULES=$RULES\npass proto { pfsync, carp } case `sysctl vfs.mounts.nfs 2/dev/null` in *[1-9]*) # don't kill NFS RULES=scrub in all no-df\n$RULES RULES=$RULES\npass in proto udp from any port { 111, 2049 } to any RULES=$RULES\npass out proto udp from any to any port { 111, 2049 } ;; esac echo $RULES | pfctl -f - -e fi On Tue, Aug 23, 2005 at 06:57:43PM -0400, Will H. Backman wrote: I'd say punch a hole for SSH. This is because I consider a *NIX box that can not be managed via SSH to be borken. And, of course, we are only talking about having this as an example and maybe mentioned in a FAQ someplace and not turned on by defualt, right?
Re: /usr/share/pf/ suggestion
On Tue, 2005-08-23 at 16:53:25 -0600, Theo de Raadt proclaimed... It is plain simple bad advice. And totally ridiculous. And plus, with ipv6, it's imperative that the filters be pushed down to the end-host so we can quit relying on stupid firewalls and NAT bullshit to break networks and slow progress. Itojun mentioned the fact that each host should have a firesuit in the ipv6 world. It's quite good advice.
Re: /usr/share/pf/ suggestion
On Tue, 23 Aug 2005 16:53:25 -0600, Theo de Raadt wrote: You're wrong. Everyone -- run pf wherever you find it easier. Followed this discussion with interest. Doing the same thing (running pf) on my single-ended boxes; I actually questioned myself why all of this is not part of the base install. Would make my life easier; with pf turned on instead of me turning it on; and a default pf.conf that opens 22 only and only in case I had decided to run sshd during install. With the macros in PF it is much much easier to simply add service identifiers if I wanted more. And pfstat being in the base as well ! Would simplify my installs even more: vi /etc/pf.conf, add / remove services there. Over. Browse newbox.mydomain.com/usage/pfstat.png (because I'd add httpd-flags, and http in pf.conf), and I'd be knowing what is going on two minutes after reboot. Plus, I'd feel even safer out of the box. Uwe
Re: /usr/share/pf/ suggestion
On 8/24/05, Jason Crawford [EMAIL PROTECTED] wrote: On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote: -Original Message- From: j knight [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 4:47 PM To: Will H. Backman Subject: Re: /usr/share/pf/ suggestion --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400: Would it be useful to add an example pf rule set for just a simple host? All of the examples assume a router. This would be more useful in the faq. Please send what you've written. :-) .joel # pf rules for a stand alone machine. #Change external interface to match yours ext_if=xl0 scrub in all block in all pass out keep state pass quick on lo all First off, it should be, set skip on lo0 (or lo, but by default there's only one lo interface anyways). Secondly, it seems pretty pointless to setup pf on a single host. Actually you need not see PF as a tool that can be implemented only on a firewall an so on. For example. If you have a LAN that has webservers, ftpservers and so on in it, Protecting the entire LAN and its Servers from the Internet with an OpenBSD firewall and PF is good! but doing that alone would put the systems on your LAN especially servers at risk from Internal threats. You could enable PF on your servers and have appropriate rules to allow only certain hosts or users to access certain services on them. You could enable PF on your work stations and with appropriate rules it will act as an excellent personal firewall. This is especially true if you are directly connecting your servers, computers, laptops directly to the internet. Jacek Arymiak explains its importance in his book Building Firewalls with OpenBSD and PF Instead of worrying about the firewall, which takes up more memory and cpu and all that, just shut off services that you don't need and be done with it. If the attacker can hurt your OpenBSD machine, then your firewall is vulnerable as well, and it won't protect any applications that need open ports listening. Turning off services is always much better than turning on services (pf) if you need protection. I think turning on PF and putting the right kind of rules in /etc/pf.conf is the best thing you can do on any OpenBSD system if your concern is security. And the way OpenBSD is setup by default, nothing is listening except a couple inetd services (which I always turn off), If you enable PF and want FTP traffic to function properly with Active ftp-servers then you must enable ftp-proxy in inetd.conf and should not disable it. and sshd if you said y in install, that's it. Following the patches and applying them as soon as they are released should keep you securely running the ssh service in your OpenBSD. Ofcourse you should be careful not to allow direct root access and follow best practices like not giving dictinary words as passwords etc to your users. Hope this helps :-) kind regards Siju