Dayo Adewunmi wrote:
Hi
In my squid.conf I've got 'http_port 3128 transparent', and I configured
my firewall
to forward all request from port 80 to 3128. Everything seems to be
working fine, except
for nagios. This is from the man pages of the check_http module:
"check_http v2053 (nagios-plugins 1.4.13)
Copyright (c) 1999 Ethan Galstad <nagios@xxxxxxxxxx>
Copyright (c) 1999-2008 Nagios Plugin Development Team
<nagiosplug-devel@xxxxxxxxxxxxxxxxxxxxx>
This plugin tests the HTTP service on the specified host. It can test
normal (http) and secure (https) servers, follow redirects, search for
strings and regular expressions, check connection times, and report on
certificate expiration times.
This plugin will attempt to open an HTTP connection with the host.
Successful connects return STATE_OK, refusals and timeouts return
STATE_CRITICAL
other errors return STATE_UNKNOWN. Successful connects, but incorrect
reponse
messages from the host result in STATE_WARNING return values. If you are
checking a virtual server that uses 'host headers' you must supply the FQDN
(fully qualified domain name) as the [host_name] argument."
The module works for all servers on the LAN, except for the squid server
(192.168.0.1) (which also happens to be the firewall server):
access.log:
12/Apr/2010:06:01:00 +0100 192.168.0.9 TCP_DENIED/400 1651 GET
error:invalid-r
equest NONE/- text/html
cache.log:
2010/04/12 06:01:00| clientReadRequest: FD 70 (192.168.0.9:58818)
Invalid Request
If I manually run the check_http module on the nagios server (or from
any other client):
$ ./check_http -I 192.168.0.1
HTTP WARNING: HTTP/1.0 400 Bad Request
Been a while since I faced this with nagios. IIRC there is no Host:
header in the nagios test requests. This header is REQUIRED for requests
to travel over an intercepting proxy.
But from the squid server:
$ ./check_http -I 192.168.0.1
HTTP OK HTTP/1.0 200 OK - 965 bytes in 0.000 seconds
|time=0.000425s;;;0.000000 siz0
I've been googling around and the solutions I've been finding are people
doing things like not adding "transparent" to their http_port line, or
defining the line twice, etc. Which doesn't apply to
my case, because I check my squid.conf and the http_port line is fine.
No. The syntax is fine and loads (for now). However "fine" is not a good
word for the current state of it.
Squid is vulnerable to CVE-2009-0801. Which means if your http_port with
"transparent" flag is accessible or easily guessed your proxy can be
abused to poison your entire networks HTTP traffic. All it takes is one
infected client and the whole network is compromised.
The only way traffic should be able to enter a "transparent" or
"intercept" flagged port is by hitting the firewall NAT rules than
re-write packets to go there directly. The port should be blocked
(pre-NAT) when possible from any external access outside the box itself.
This means that port 3128 should be reserved for normal forward-proxy
traffic such as your nagios proxy tests. And another "secret" port used
for the Squid end of the firewall->squid linkage.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.1
