<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Arial'; font-size:10pt; font-weight:400; font-style:normal;">Another good resource is the fwbuilder program. It displays your firewall rules like a Checkpoint firewall, and it can optionally generate a bash script to configure iptables, install, and run it. It has a handy section to enable logging so you know where a packet is disappearing. Of course, you can do that by hand as well.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>On Tuesday 19 May 2009 07:04:32 pm David L. Anselmi wrote:<br>
> Bruce Ediger wrote:<br>
> > Can anyone point me to good web pages on iptables firewalling?<br>
> <br>
> I've always used Rusty's guide:<br>
> <br>
> http://netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html<br>
> <br>
> It's really old but it covers what I've needed.<br>
> <br>
> > More specifically, I'm curious about any bad interactions between SSL and<br>
> > iptables.<br>
> <br>
> There should be a way to log what your rules are doing that will show <br>
> you what's dropping SSL.<br>
> <br>
> > The problem was that http://www.citicards.com does an HTTP 304 "permanently<br>
> > moved" redirect to https://www.citicards.com/blah/blah/blah.do<br>
> > <br>
> > The iptables rules I came up with just wouldn't let the SSL part of HTTPS<br>
> > pass. No error, no "network unreachable", just apparently a connect()<br>
> > system call timeout.<br>
> <br>
> Yes, that's what happens if your rule is drop. Packets go out, they <br>
> never come back. You can confirm that all you're getting is retransmits <br>
> (probably SYN to port 443) with wireshark.<br>
> <br>
> So did you set up specific allow rules and then drop everything else? <br>
> The hardest part of iptables is keeping everything consistent enough <br>
> that you don't confuse yourself.<br>
> <br>
> In terms of boolean expressions, if you have a set of accept rules <br>
> followed by a drop then you've got the logical or of all your rules to <br>
> get in:<br>
> <br>
> a || b || c || d || e || false<br>
> <br>
> If you have a set of drop rules followed by an accept then you have:<br>
> <br>
> !a && !b && !c && !d && !e && true<br>
> <br>
> which of course is just the negation of the first. If you keep it <br>
> simple like that then you can probably make sense of it. But of course <br>
> the state rules and such mean it's never quite that simple. Still, if <br>
> you mix chains and try to cluster your tests you're in for some <br>
> debugging. (Hmm, is there a simulator that can send all possible <br>
> traffic at your rules and show what goes where? And perhaps one of the <br>
> rule builder tools can let you create rules at a higher level of <br>
> abstraction.)<br>
> <br>
> If you get into rules for specific nets or hosts it's harder to get <br>
> right, but the above still holds--it has to be simple enough for you to <br>
> think about clearly.<br>
> <br>
> So most likely if you post your rules someone can find the problem. Or <br>
> post your required behavior and see who can make the most elegant rules <br>
> to implement it.<br>
> <br>
> Dave<br>
> _______________________________________________<br>
> clue-tech mailing list<br>
> clue-tech@cluedenver.org<br>
> http://www.cluedenver.org/mailman/listinfo/clue-tech<br>
> <br>
> <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p></body></html>