This is a discussion on Re: [fw-wiz] Protocol inspection - Firewalls ; 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 ...
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:
Introducing mod_security http://www.onlamp.com/pub/a/apache/2..._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)
If someone knows of one, please speak up!
[mailto:firstname.lastname@example.org]On Behalf Of Josh
Sent: Friday, March 28, 2008 1:58 PM
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
Is this a reasonable path to go down, or is there more
functionality in vendor responses to and protection
against SQL injection?
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsea...egory=shopping
firewall-wizards mailing list
firewall-wizards mailing list