Thank you all for your responses! This is setup as a forward transparent proxy for an ISP. Most of the RST packets are targeted towards remote IPs (not the ISP users). Although we do not see any detrimental effect on Squid functioning in our setup, would you recommend that we stop blocking these in iptables? Regards HASSAN On Sat, Dec 28, 2013 at 9:27 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 27/12/2013 9:12 p.m., Francesco Chemolli wrote: >> >> On 27 Dec 2013, at 07:39, Nyamul Hassan <nyamul@xxxxxxxxx> 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
