Re: Protocol inspection

[david () lang hm]

On Mon, 31 Mar 2008, Darden, Patrick S. wrote:

> You hit the nail on the head here.  You can do the following:
>
> 0.  firewall (include only specific endpoints for HTTP/SQL traffic)
> 1.  stateful (helps defeat MITM attacks/interceptions/stream injections on the HTTP/SQL streams)
> 2.  packet inspection (make sure port 80 is http traffic, 1443 is SQL, etc.)
> 3.  content filtering (reflexive IDS (called Intrusion Prevention (IP) by some products like Astaro) e.g. utilizing 
> Snort ruleset to create on the fly filters based on content)
>
> I don't know of a level 4 above, which would be:
>
> 4.  application proxy (SQL proxy that filters out all queries by default except those that match specific criteria, 
> i.e. a SQL whitelist ruleset)
>
> I think if someone did make such a beastie, it would make waves.  It 
> would probably have to be tightly bound into a Web Proxy, maybe a module 
> for a pre-existing Web Proxy like Apache or Squid.  You would think that 
> with SQL injection being such a large vector of attack, this would have 
> already been addressed.  Checking Google I can only find stuff like 
> this:

there are some companies that make products that work in this space. some 
require you to produce whitelists, some auto-learn 'normal' traffic and 
block 'abnormal' traffic

they are expensive, and their configuration (such that I've seen) is a 
nightmare. I won't start naming companies at the moment, but I may have 
suggestions in a few months.

David Lang

> Introducing mod_security http://www.onlamp.com/pub/a/apache/2003/11/26/mod_security.html
> (includes a blacklist version that prevents two specific SQl injection attacks, almost useless)
>
>
> Securing Apache: Step by Step http://www.securityfocus.com/infocus/1694
> It is worth emphasizing that the above model doesn't support PHP, JSP, CGI or any other technologies that make it 
> possible to interact with Web services. The use of such technologies may pose a large security threat, so that even a 
> small, inconspicuous script can radically decrease the server's security level. Why? Primarily, ASP/CGI applications 
> may contain security vulnerabilities (e.g. SQL injection, cross-site-scripting). Secondarily, the technology itself 
> can be dangerous (vulnerabilities in PHP, Perl modules etc.). That's why I strongly recommend using such technologies 
> only when an interaction with a Web site is absolutely necessary.
>
>
> 20 ways to Secure your Apache Configuration http://www.petefreitag.com/item/505.cfm
> (no mention of SQL injection at all)
>
> etc.
>
> If someone knows of one, please speak up!
> --Patrick Darden
>
>
>
>
> -----Original Message-----
> From: firewall-wizards-bounces () listserv icsalabs com
> [mailto:firewall-wizards-bounces () listserv icsalabs com]On Behalf Of Josh
> Sent: Friday, March 28, 2008 1:58 PM
> To: firewall-wizards () listserv icsalabs com
> Subject: [fw-wiz] Protocol inspection
>
>
> I have a question, that is hopefully approriate for
> this list, related to application inspection (whatever
> the vendors call it now).
>
> We recently had some problems with SQL injection, and
> I have been asked to look at whether our equipment can
> stop the attacks.  My knowledge about the attack is
> that there isn't a generic way to block the traffic,
> since a firewall can't differentiate between valid
> post data (to a forum, for example) vs one that is an
> attempt to use injection.
>
> If this is the case, any vendor's protection will just
> amount to responses to know attacks, and I could just
> as easily create a filter on my own that stops some
> portion of attacks (since I know better what data my
> webservers expect).
>
> Is this a reasonable path to go down, or is there more
> functionality in vendor responses to and protection
> against SQL injection?
>
> Thanks,
> Josh
>
>
>      ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards