-----Original Message-----
[mailto:snort-sigs-admin@lists.sourceforge.net]On Behalf Of Alex Kirk
Sent: Friday, January 14, 2005 9:36 AM
To: Adam Hogan
Cc: snort-sigs@lists.sourceforge.net
Subject: Re: [Snort-sigs] Apache Proxy
Adam,
Actually, these rules are never going to fire -- at least not under
normal circumstances where clients are following RFC 2616
(http://www.faqs.org/rfcs/rfc2616.html). GET requests look like this
when they come across the wire:
GET /path/to/file.html HTTP/1.1
Clients never need to transmit the http://<host> portion of a URL:
http:// is obvious because the packet is being received by an HTTP
server, and <host> is either implied from wherever the packet is being
sent, or stated explicitly with a directive of
Yes, sometimes clients *do* need to transmit the http://<host> portion.
Quoting from rfc2616, section 5.1.2:
"The absoluteURI form is REQUIRED when the request is being made to a
proxy."
An http/1.1 client making a request to a webserver for content on that
webserver will not include that portion. When making a request to a
web/proxy server when the client is asking the server to act as a proxy,
that portion *is* required. The RFC says it better than I can:
"To allow for transition to absoluteURIs in all requests in future versions
of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests,
even though HTTP/1.1 clients will only generate them in requests to
proxies."
so, if you see a request coming in that looks like "GET http://...";, then it
means one of 3 things:
1) it's a poorly written client that isn't adhering to the spec, but might
work anyway since the spec says that servers should accept such requests.
2) it's a client adhering to a future version of the HTTP spec. There isn't
one now, but once one is written, there will be clients for it, and who
knows, maybe a time traveller brought his laptop back from the future and is
trying to get to your website. That's the sort of thing you'd want to know
about. :)
3) the client is treating the server as a proxy server.
Case 3 is what these rules are meant to look for.
Of course, you can't tell from these rules whether the request was
successful (i.e., your web server really *is* configured to act as a proxy
server) or not (i.e., your web server told the client to go stuff it.) But
the matches for this rule can be interesting for other reasons. It's nice
to know if someone is trying to abuse your webservers. It's also fun to see
what they're trying to get via open proxies. And, if you start seeing a
huge amount of hits, then you might want to check if your webserver really
*is* acting as an open proxy, on the assumption that an attacker might try
this once or twice to check if your server is mis-configured, but wouldn't
send a whole bunch unless he was successfull.
and then, if you're bored and want to play a little, you can configure
apache to act as a proxy server, but use some re-writing rules within the
proxy configuration to send whatever content you want to to whoever tries to
use it that way.
-Joe
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
