Re: My ipfilter rules.
In order to be a good netizen, I applied the bogon list to my outbound traffic, too. I also moved the bad packet checks to the head of the incoming rules, as they make more sense there - no point in letting them use any more cpu than needed, if they are junk. At least 35 people have looked at my rules (http://www.ste-land.com/rules.html). I've updated the page, so be sure to hit refresh/reload, if you go to look at it again. So far, two people have responded. I took the suggestions of one. Anyone else? I'm putting the server on the Internet tonight, and would like the firewall done by then. Two questions: 1) Should I be performing the bad packet checks on the outbound path, too? 2) I looked at using groups to keep outbound packets from traversing rules for inbound packets, and vice versa, but I still don't understand them well enough to set them up. Suggestions? -ste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My ipfilter rules.
Shaun, I do have some (minor) additions: - letting in webmin from an external interface on your firewall doesnot seem like a good idea to me. webmin is not that secure... normaly I only allow this to the loopbackinterface and tunnel it in SSH for security - letting out everything is not the smartest thing to do, if one of your services gets compromised you'll never notice outgoing trafic. normaly I only allow out everything I know the server needs, anything else is either blocked or logged. Well it all depends on how secure you want to make things. Basicaly the script looks prety good. Arnoud In order to be a good netizen, I applied the bogon list to my outbound traffic, too. I also moved the bad packet checks to the head of the incoming rules, as they make more sense there - no point in letting them use any more cpu than needed, if they are junk. At least 35 people have looked at my rules (http://www.ste-land.com/rules.html). I've updated the page, so be sure to hit refresh/reload, if you go to look at it again. So far, two people have responded. I took the suggestions of one. Anyone else? I'm putting the server on the Internet tonight, and would like the firewall done by then. Two questions: 1) Should I be performing the bad packet checks on the outbound path, too? 2) I looked at using groups to keep outbound packets from traversing rules for inbound packets, and vice versa, but I still don't understand them well enough to set them up. Suggestions? -ste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
My ipfilter rules.
I've ported my iptables firewall rules to ipfilter. Since I'm new to firewalling under any *BSD, and because it never hurts to get a review, I was wondering if some of you, who are good at, would critique my rules. Rather than include the file here, I give a link to it, below. Feel free to critique both content and form. Note that I obfuscated my server's IP address in the one place it shows up. The firewall is to harden a stand-alone server, with a single interface. Policy is to let anything out, but be cautious about what is allowed in. Here's the file: http://www.ste-land.com/rules.html I'm sure I'll learn more, based on your responses. TIA. -ste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My ipfilter rules.
I wrote: I was wondering if some of you, who are good at, would critique my rules. Here's the file: http://www.ste-land.com/rules.html So far, I've gotten these suggestions: Apply the bogon list to the outbound path. Compress my blocking of netbios junk to one rule. Move bad options flags check to head of list. Any other suggestions? Question: Is there some way I can have all outbound packets skip being tested by rules for inbound packets, and vice versa? -ste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
