[clue-tech] iptables firewall and SSL

[Shawn - Red Mop]

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.

On Tuesday 19 May 2009 07:04:32 pm David L. Anselmi wrote:
> Bruce Ediger wrote:
> > Can anyone point me to good web pages on iptables firewalling?
> 
> I've always used Rusty's guide:
> 
> http://netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html
> 
> It's really old but it covers what I've needed.
> 
> > More specifically, I'm curious about any bad interactions between SSL and
> > iptables.
> 
> There should be a way to log what your rules are doing that will show 
> you what's dropping SSL.
> 
> > The problem was that http://www.citicards.com does an HTTP 304 "permanently
> > moved" redirect to https://www.citicards.com/blah/blah/blah.do
> > 
> > The iptables rules I came up with just wouldn't let the SSL part of HTTPS
> > pass.  No error, no "network unreachable", just apparently a connect()
> > system call timeout.
> 
> Yes, that's what happens if your rule is drop.  Packets go out, they 
> never come back.  You can confirm that all you're getting is retransmits 
> (probably SYN to port 443) with wireshark.
> 
> So did you set up specific allow rules and then drop everything else? 
> The hardest part of iptables is keeping everything consistent enough 
> that you don't confuse yourself.
> 
> In terms of boolean expressions, if you have a set of accept rules 
> followed by a drop then you've got the logical or of all your rules to 
> get in:
> 
> a || b || c || d || e || false
> 
> If you have a set of drop rules followed by an accept then you have:
> 
> !a && !b && !c && !d && !e && true
> 
> which of course is just the negation of the first.  If you keep it 
> simple like that then you can probably make sense of it.  But of course 
> the state rules and such mean it's never quite that simple.  Still, if 
> you mix chains and try to cluster your tests you're in for some 
> debugging.  (Hmm, is there a simulator that can send all possible 
> traffic at your rules and show what goes where?  And perhaps one of the 
> rule builder tools can let you create rules at a higher level of 
> abstraction.)
> 
> If you get into rules for specific nets or hosts it's harder to get 
> right, but the above still holds--it has to be simple enough for you to 
> think about clearly.
> 
> So most likely if you post your rules someone can find the problem.  Or 
> post your required behavior and see who can make the most elegant rules 
> to implement it.
> 
> Dave
> _______________________________________________
> clue-tech mailing list
> clue-tech at cluedenver.org
> http://www.cluedenver.org/mailman/listinfo/clue-tech
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue-tech/attachments/20090519/58648bb4/attachment.html