Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Firewall Wizards: Re: IPS vs. Firewalls (why vs. ?)

Re: IPS vs. Firewalls (why vs. ?)

From: Chris Byrd <cbyrd01_at_gmail.com>
Date: Tue, 7 Feb 2006 18:04:37 -0600

Often you can find other indicators in otherwise protocol compliant
traffic based upon policy enforcement, such as length of the URI,
permitted user agents strings (before someone says it, yes it could
easily be spoofed - but it can't hurt to check), content length,
content type mismatches, etc.

Also, often traffic analysis can be your friend, or as Marcus Ranum
said it best, in his signature sang-froid manner, "The first law of
log analysis (and IDS) reads: The number of times an uninteresting
thing happens is an interesting thing."

If all else fails, a review of your DNS logs or signature-based IDS
can pick the rest out.

Then it's time to get out the LART.

On 2/4/06, Gabriele Buratti <gabriele.buratti_at_netasq.com> wrote:
> Dave Piscitello wrote:
> > If you take issue with this, consider
> > that some companies who bash proxies as being performance inhibitors
> > bolt SSL VPNs onto their firewalls.
>
> Yep ! You still need proxies to do this SSL stuff as long as to hook an
> antivirus for example.
> Remember the old networking rule "switch when you can, route when you
> must" ? In this field could be read as "analize on-the-fly when you can,
> rewrite with a proxy when you must".
> This is something more than "cutting the corners" this is using the best
> tool available for each job.
>
> > Marcus J. Ranum wrote:
> > The fundamental issue always boils down to whether your product
> > inherently implements default permit or default deny; what it
> > does with the stuff that it will, inevitably, encounter that is
> > outside of its knowledgebase.
>
> You have to use both approaches here: let's say our knowledgebase is the
> definition of http protocol as it should be. So, if you find malformed
> http (=non compliant) you drop it. What if you find some instant
> messaging traffic (you don't want in your network) that is http compliant ?
>
> Gabriele
>
>
>
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Received on Feb 08 2006

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos