Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Signatures
[Top] [All Lists]

Re: [Snort-sigs] Snorting gzip encoded http source code

Subject: Re: [Snort-sigs] Snorting gzip encoded http source code
Date: 02 Sep 2004 18:56:16 +0200
El jue, 02 de 09 de 2004 a las 05:45, Jason Haar escribiÃ:
On Tue, Aug 31, 2004 at 10:21:06PM +0200, Jose Maria Lopez wrote:
Maybe I'm wrong but you would get the performance benefits of having the
traffic compressed if what you want it's to save bandwidth in your
internet connection, because the 'gunzip' would be done in your local
network, where it shouldn't matter to have more traffic. So the proxy
option could be a good option.

I don't know off the top of my head if any do that. I know Squid can remove
the "Accept-Encoding.." field from outgoing HTTP links - so that the
end-server just sends back the data uncompressed, but I don't know if it
could "pretend" it was incapable to compressing to the client, but actually
do it to the server...


I have really never tried to do it, I was just talking about what other
people have commented about the matter. I know it works for SSL but as
I said never tried for gzip.

Also, that would imply you have your IDS *behind* your proxy - most tend to
have them out on the edge of their networks.


Ok. That's right, but if you want to check the SSL traffic the only way
to do it it's to have the IDS behind the proxy, and use the proxy to
do the SSL work.

OTOH, we've taken to installing Snort on our proxy servers - as there are
just too many things being hidden by the proxies! It's pretty hard to track
down a trojan downloaded onto an internal box when all that Snort can tell
you is "the proxy did it" :-/

It's better to know that something happened even if you don't know the
source that don't even knowing it. The only way to use snort over SSL
it's to have the IDS after the proxy, so it's just a matter of what
you really want.

The ideal would be to have an IDS for general traffic in the edge of
your network and then an IDS just for SSL traffic after your proxy.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÃA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&opÌk
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs

<Prev in Thread] Current Thread [Next in Thread>