Re: [squid-users] Squid, Firewall & TCP RST Flags

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sat, 28 Dec 2013 16:27:26 +1300

On 27/12/2013 9:12 p.m., Francesco Chemolli wrote:
>
> On 27 Dec 2013, at 07:39, Nyamul Hassan <nyamul_at_gmail.com> wrote:
>
>> Hi,
>>
>> Recently, we had some DDoS type attacks on our servers, so in an
>> attempt to secure our systems, we added some iptables rules, which
>> seems to work quite well on most of our servers.
>>
>> Even on systems dedicated to Squid, all seems to run well. However,
>> one rule in particular seems to catch up a lot of entries in Squid
>> machines, which are almost non-existent on the other non-Squid
>> machines:
>>
>> -A OUTPUT -p tcp -m tcp --tcp-flags RST RST -j OUTRST -m comment
>> --comment "OUTPUT: Catch RST pkt"
>> -A OUTRST -j LOG --log-prefix "OUTRST: "
>> -A OUTRST -j DROP -m comment --comment "OUTRST: Drop outbound RST"
>>
>> From what we have seen, this does not seem to have a detrimental
>> affect on Squid Proxy. But, out of academic interest, we would still
>> like to learn more on why so many RST packets would be generated from
>> the server itself.
>>
>> Can anyone shed some light?
>
> Hi Hassan,
> I guess that one of the reasons is that a proxy has way different traffic patterns than almost any other server: it talks to a lot of unreliably reachable servers, and as such it can have more often to reinitialise the TCP state of a connection. There may be other reasons, with slightly different motivations but the same pattern. For instance:
> - squid tries to keep TCP connection alive
> - firewall on the server side has too-short session timeout
> - firewall on server side silently drops connection
> - squid gives up on keep alive, closes TCP session
> - firewall drops FIN because no session in its session table
> - squid RST
>
> This pattern occurs more often than you'd think
>
> Kinkie
>

There is also the "Happy Eyeballs" algorithm causing clients to open
connections they will never use, which timeout and have to be RST from
the Squid end. This one happens a LOT with Chrome browser, and a fair
bit with the others.

And the pattern where client and server connections are having data
relayed between them and one side closes its connection. Squid is forced
to close the other connection with a RST.
 This one happens during any unknown-length object transfer, but more
often on pinned connections as used by ssl-bump, CONNECT tunnels, NTLM
and Negotiate auth.

There are probably more.

Amos
Received on Sat Dec 28 2013 - 03:27:47 MST

This archive was generated by hypermail 2.2.0 : Sat Dec 28 2013 - 12:00:06 MST