On May 11, 2011, at 4:01 AM, Thor (Hammer of God) wrote: > HTTP may be stateless, but the TCP connection isn't. The purpose for my > firewall in front of my web server is that if you get on the box, or can > somehow try to initiate an external connection (e.g. SQL injection), you will > not be able to do so.
Again, if I'm an attacker and I've already pwn3d your box, this is a trivial issue. But let's pretend it isn't. Since I've pwn3d your box, I can quite easily initiate an inbound connection to your box from some other outside box which is outside and is under my control, which will conform to your inverted state-check, and thus I have my connection, and can exfiltrate data. > How is a simple ACL allowing anything from 80 outbound secure? Given the above, the question is, how is it insecure? Especially since it removes the DDoS state-table vector? > The old "there are 10 ways to do it anyway so why bother" argument just don't > hold water for me. It should in a scenario in which the cost/benefit ratio is so clearly weighted towards the cost side, with so little on the benefit side. > My above response could easily obviate 5 of those ways, so there is value > add. Look, if you have stateless ACLs only allowing access to your box via destination ports TCP/80 and TCP/443 and denying everything else, and stateless ACLs which only permit outbound traffic sourced from TCP/80 and TCP/443 to ephemeral ports, then the only way someone is going to be able to access your box from the outside in the first place is via those selfsame TCP/80 and TCP/443 ports. Which means that your stateful outbound checking is for nought, since the attacker is going to be able to initiate a session which passes your firewall policy rules and the inverted state check, anyways, or he isn't going to be able to access your box at all. As far as a sidewise compromise or a compromise from 'inside' (assuming there is an 'inside'; public-facing servers ought not to be conflated with workstation access LANs and the like at all), again, if you have appropriate functional separation and network access policies in place, plus you're monitoring all of it using appropriate visibility technologies, that isn't an issue, either. So, all this stateful checking you're doing on outbound traffic from your Web server doesn't actually benefit you one iota, and it makes it trivially easy to exhaust the state-tables in your firewall. If you don't believe me, take a tool like Siege or Tsung and set it up to hammer your server through the stateful firewall with lots and lots of unique connections. > Of course there are firewalls in front of some of these services, and if it > is trivial for someone with a small bot to take down the firewall, then > someone is not doing their job. It's because of the nature of stateful firewalls. Yes, S/RTBH or flowspec or IDMS can and are used to protect said stateful firewalls and everything behind them from DDoS, but those stateful firewalls shouldn't be there in the first place. > The fact that someone was able to navigate through firewalls speaks to the > configuration, not the technology. Sony actually said they didn't have > firewalls, and only had ACLs, so you're point is lost there, I think. <http://gamer.blorge.com/2011/05/01/sony-press-conference-compensation-details-and-psn-to-resume-this-week/> ----------------------------------------------------------------------- Roland Dobbins <[email protected]> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
