Re: Sony: No firewall and no patches

["Dobbins, Roland" <rdobbins () arbor net>]

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 <rdobbins () arbor net> // <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/