On 20/05/11 03:01, Boniforti Flavio wrote:
Hello Amos...

What does that forward loop mean

Your squid is sending requests out which subsequently arrive
back to it.

OK.

and how could it happen? I've noticed

Most likely your NAT rules are broken. Packets leaving Squid
MUST NOT be sent back to Squids listening port.

This is my iptables setup:

proxy:/var/log/squid3# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 208K packets, 20M bytes)
  pkts bytes target     prot opt in     out     source
destination
62956 3123K REDIRECT   tcp  --  eth0   *       0.0.0.0/0
0.0.0.0/0           tcp dpt:80 redir ports 3128
    10   548 REDIRECT   tcp  --  eth0   *       0.0.0.0/0
0.0.0.0/0           tcp dpts:81:83 redir ports 3128
<snip>

What you see there are some services redirected to my internal servers
and the rule for intercepting web traffic...

Okay. Looks okay. The use of "eth0" replaces a specific Squid bypass. Squid will be using the Internet link eth1.


Or maybe the requests are for a domain which is pointing at
your Squid with its IPs.

that the originating IP was from a PC I had in my LAN which was
infected with some sort of mal-/spy-ware...

Or some attempted attack which is being short-circuited by
setting the attackers domain to point at 0.0.0.0 or
127.0.0.1. In which case "http_access deny to_localhost" with
the default definition of to_localhost should block it before looping.

I get tons of these in the access.log:

1305812157.825  14481 172.16.16.38 TCP_MISS/000 0 GET
http://172.16.16.1:3128/ - DIRECT/172.16.16.1 -
1305812227.706  14095 172.16.16.38 TCP_MISS/000 0 GET
http://172.16.16.1:3128/ - DIRECT/172.16.16.1 -

What could this be meaning? It look like the PC is trying to connect to
the proxy port 3128, which is then directed to itself... uh?!

Yes, this is the access.log displayed for all the forwarding attempts which failed. For each "Forward loop detected" there will be one or more of these in access.log to show the request which was forwarded to Squid then abandoned.

The transaction looks something like this:
client ->
  squid (access.log "000" / request aborted by server) ->
    squid (access.log "000" / request aborted by server) ->
      squid (cache.log "forward loop" abort)


Congratulations, active use of the CVE-2009-0801 vulnerabilities.
I would be grateful if you could provide any detailed info about the malware seen on the client box and the traffic itself ("tcpdump -s0" traces would be great). If this can be confirmed as the malware and not just a forward-proxy config in the client browser I'm going to have to make an announcement that its finally gone wild.


The fix; is to follow the recommended config of not using port 3128 for intercept or transparent. Use a randomly selected high port instead.

Also, at the Squid box "mangle" table configure this for your newly chosen intercept port:
  iptables -t mangle -A PREROUTING -p tcp --dport $NEW_PORT -j DROP

Make sure *nobody* can get to Squid with that port directly from inside OR outside the network. If you want to be more selective and only block -i eth0 or -s 172.16.16.1, okay. But DNAT needs to be used then instead of REDIRECT since DNAT allows some explicit control over which IP gets picked by NAT and listened on by Squid. Match that IP to the mangle protected IP or NIC.

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.12
  Beta testers wanted for 3.2.0.7 and 3.1.12.1

Reply via email to