[Snort-sigs] Apache Proxy

Joe Patterson jpatterson at ...2901...
Fri Jan 14 12:08:23 EST 2005


> -----Original Message-----
> [mailto:snort-sigs-admin at lists.sourceforge.net]On Behalf Of Alex Kirk
> Sent: Friday, January 14, 2005 9:36 AM
> To: Adam Hogan
> Cc: snort-sigs at 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





More information about the Snort-sigs mailing list