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: Thu, 12 May 2011 14:10:23 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: Craig Miskell <craig@...alyst.net.nz>, "full-disclosure@...ts.grok.org.uk"
	<full-disclosure@...ts.grok.org.uk>
Subject: Re: Sony: No firewall and no patches

> On 11/05/11 23:05, phocean wrote:
> >  Also, if you filter (and you should) both inbound and outbound
> > traffic,  how do you allow legitimate responses to the server?
> I think Roland said earlier that outbound connections from these boxes
> should be going out another interface, presumably (my presumption)
> through a stateful firewall of some kind, because ACLs wouldn't be sufficient.
> 
> This is perhaps the aspect that has been missed in this discussion (mentioned
> once, not particularly picked up on, and not really noted again).  It eliminates
> many of the concerns of using ACLs over stateful.

Actually, the stateless solution was to just ACL via "known good" source ports.  And this was a large part of my original response of the value of firewalls in front of a server. Limiting outbound traffic to responses to valid initiated traffic is an important security control, specifically because the "ACL's wouldn't be sufficient."

The examples I was going to tally up for Roland were any number of SQL injection attacks where tftp and ftp command files were created (in this case, by some tool that I presume created .cmd files just like we all used to do with "echo >>") to get other toolsets.  These requests failed as the SQL box couldn't make outbound connections.  There was no capability for the attacker to initiate another remote connection to craft a response to.  

I was actually going to try to get detailed information from way back where Code Red propagation was avoided by outbound connection attempts as well, but I don't really see the value in doing that at this point.  I also had Slammer research where I tested ISA's resilience to blocking outbound UDP 1434 connections, but I think it suffices to say that there are many, many valid examples of why stateful inspection of traffic is valuable and adds security in depth. 

I had some other responses as well, but I have to bolt.  I'll make sure to catch up on the rest of the responses before I do so as well.

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