Date: Wed, 21 Mar 2001 20:57:04 +0000 From: Paul Richards <paul@freebsd-services.co.uk> To: Alfred Perlstein <bright@wintelcom.net> Cc: Paul Richards <paul@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw.c Message-ID: <3AB915A0.123B16CB@freebsd-services.co.uk> References: <200103210819.f2L8JWm19214@freefall.freebsd.org> <20010321105412.B47802@sunbay.com> <20010321102355.M12319@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > > > Er, no that's not as good as being able to put the rules into a > class (example): > > /sbin/ipfw add foo,100 deny ip from any to any > /sbin/ipfw add bar,200 deny ip from any to any > /sbin/ipfw add baz,300 deny ip from any to any > # ^ > # | > # rule 'class' -/ > > /sbin/ipfw flush bar > # this would flush rule 200 and any others entered with a 'bar' > # prefixed to the rule number. I don't disagree with this direction but if your going to start discussing grouping rules then you might as well go the whole way and deal with per interface lists, separate ingoing/outgoing etc. > Simply put this is a pretty disgusting hack Paul and should > have been thought out better. > > I mean seriously this doesn't deserve a sysctl! Maybe an option > in a config file or something... Ok, let's analyse the problem I solved and not the problem that you'd have liked it to solve. The problem is that it's difficult to flush the rules of a remote server because you'll get cut off. What seemed intuitive to me would be to be able to specify what the default rule was so that rather than it just being deny or allow all it could be something useful. To be useful it needs to be more than one rule so we're heading towards the idea of groups as you suggest but a very simple solution is to just protect the first few rules and treat them as built-in defaults. I did that with 10-15 lines of code which were easily audited, having minimal impact on the design of IPFW and zero impact on existing installations. A config setting would not have had minimal impact on existing implementations since it would have changed the interface behaviour. Also, what happens when you're at the console and you really want to flush all the rules? If it's a compiled in value then you have to rebuild the kernel, whereas with a sysctl you just set the value to 0 and flush, put your new default rules in and then reset the sysctl. What you're trying to do is implement an all singing all dancing way of structuring rules that requires redesigning the internal queues and re-writing the parser. That's an admirable goal and no-one who's used commercial firewall tools is going to disagree with you but that's not the solution to the problem I had. Deciding to redecorat the bathroom because the tap dripped is not sensible engineering. > Leave it in, but I think you owe it another shot when you get > a chance. :) I will revisit this, since I agree with your suggestions and other peoples comments about a more comprehensive set of controls for ipfw lists but that wasn't what this fix was about. > None of this probably belongs in the kernel, it really belongs > in a ipfw front end tool. It belongs in the kernel; how would you deal with multiple processes manipulating the lists. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB915A0.123B16CB>