lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 May 2011 21:01:52 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "Dobbins, Roland" <rdobbins@...or.net>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Sony: No firewall and no patches

> How does inserting a stateful firewall in front of a Web server help, given the
> stateless nature of HTTP and the fact that all incoming connections to the
> server are unsolicited?  Same for a DNS server.  There is no state for the
> firewall to inspect in order to determine whether to pass/fail those packets,
> stateless ACLs in hardware-based routers/layer-3 switches are the way to go.

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.  My web server will only respond with return HTTP traffic if the session has already been initiated.  You can't make any outbound connections from it no matter what your source port is.   How is a simple ACL allowing anything from 80 outbound secure?  

> All the talk of exfiltration via a covert channel is irrelevant, given that a) when
> the httpd on the server stops responding, that's a big giveaway that there's a
> problem, and b) that if the attacker is in control of a remote host to which he
> wishes to exfiltrate data, he can simply initiate an inbound connection and
> then generate the appropriate outbound responses, since he's effectively in
> charge of both ends of the connection, and c) there're far easier and less
> visible/onerous ways to exfiltrate data, anyways.

Which is why we have security in depth.  The old "there are 10 ways to do it anyway so why bother" argument just don't hold water for me.   My above response could easily obviate 5 of those ways, so there is value add.   Your stance of "irrelevant" and "unnecessary" and other superlative postures is far too heavy handed in my opinion - and just because ops likes something doesn't mean it has anything to do with security.  I'm not sure who you are talking to, but no one in my org ever considers a firewall a security panacea, nor any single technology for that matter. 

> 
> There are no stateful firewalls emplaced in front of the extremely popular
> servers/services accessed by gazillions of Internet users on a daily basis - at
> least, the ones that stay up, heh.  And every time I get a call from someone
> screaming 'the IDC and everything in it is down', it's because there's an
> unnecessary stateful firewall fronting the whole thing, and it's trivially easy
> for an attacker with even a very small botnet to take down said stateful
> firewall with programmatically-generated attack traffic which will conform to
> all the firewall rules and 'inspectors' and whatnot, but which will fill up the
> firewall state-tables, crowd out legitimate traffic, and eventually cause said
> firewall to fall over.

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.  

> Stateful firewalls make perfect sense in front of endpoint networks
> comprised of client machines which shouldn't receive unsolicited connections
> across some defined policy boundary.  They make no sense in front of
> servers, but folks have been conditioned to think that firewalls are some kind
> of universal security panacea.  Which is especially ironic in the context of this
> thread, given that Sony have publicly stated that their servers were in fact
> exploited by traffic which passed straight through their stateful firewalls.

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.  

t

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ