[squid-users] file descriptors leak
André Janna
andre61 at brazcubas.br
Tue Dec 15 11:42:24 UTC 2015
Em 28/11/2015 22:46, André Janna escreveu:
> I took another network trace this time both at Squid and Windows
> client ends.
>
> cache.log:
> 2015/11/27 11:30:55.610 kid1| SECURITY ALERT: Host header forgery
> detected on local=177.43.198.106:443 remote=192.168.64.4:61802 FD 5465
> flags=33 (local IP does not match any domain IP)
>
> ------------------------------
> network trace at Squid side
>
> client connects
> 11:30:55.604870 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],
> seq 1701554341, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
> 11:30:55.604992 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags
> [S.], seq 3125704417, ack 1701554342, win 29200, options [mss
> 1460,nop,nop,sackOK,nop,wscale 7], length 0
> 11:30:55.605766 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> ack 1, win 256, length 0
>
> client sends SSL hello
> 11:30:55.606242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
> [P.], seq 1:198, ack 1, win 256, length 197
> 11:30:55.606306 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, length 0
>
> client OS sends TCP keep-alive packets
> 11:31:05.607191 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 197:198, ack 1, win 256, length 1
> 11:31:05.607231 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
> 11:31:15.608966 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 197:198, ack 1, win 256, length 1
> 11:31:15.609005 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
> 11:31:25.614527 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 197:198, ack 1, win 256, length 1
> 11:31:25.614589 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
>
> client sends FIN
> 11:31:29.384280 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
> [F.], seq 198, ack 1, win 256, length 0
> 11:31:29.421787 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, length 0
>
> client OS sends TCP keep-alive packets
> 11:31:39.417426 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 198:199, ack 1, win 256, length 1
> 11:31:39.417489 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
> 11:31:49.425366 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 198:199, ack 1, win 256, length 1
> 11:31:49.425443 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
> 11:31:59.426153 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 198:199, ack 1, win 256, length 1
> 11:31:59.426233 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
> .... it continues this way until I powered off Windows client after
> three hours ...
>
>
> ------------------------------
> network trace at Windows client side
>
> client connects
> 11:30:34.894242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],
> seq 1701554341, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
> 11:30:34.898234 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags
> [S.], seq 3125704417, ack 1701554342, win 29200, options [mss
> 1460,nop,nop,sackOK,nop,wscale 7], length 0
> 11:30:34.898298 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> ack 1, win 256, length 0
>
> client sends SSL hello
> 11:30:34.898712 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
> [P.], seq 1:198, ack 1, win 256, length 197
> 11:30:34.899479 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, length 0
>
> client OS sends TCP keep-alive packets
> 11:30:44.899271 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 197:198, ack 1, win 256, length 1
> 11:30:44.899986 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
> 11:30:54.900495 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 197:198, ack 1, win 256, length 1
> 11:30:54.901323 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
> 11:31:04.905731 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 197:198, ack 1, win 256, length 1
> 11:31:04.906560 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
>
> client sends FIN
> 11:31:08.675299 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
> [F.], seq 198, ack 1, win 256, length 0
> 11:31:08.713746 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, length 0
>
> client OS sends TCP keep-alive packets
> 11:31:18.708086 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 198:199, ack 1, win 256, length 1
> 11:31:18.708917 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
> 11:31:28.715600 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 198:199, ack 1, win 256, length 1
> 11:31:28.716516 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
> 11:31:38.714887 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
> seq 198:199, ack 1, win 256, length 1
> 11:31:38.716911 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
> ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
> ...
>
>
> So after less then one minute after connection Windows client sent a
> FIN and Linux server acknowledged.
> Windows netstat showed that connection changed to FIN_WAIT_2 state
> while Linux netstat showed that connection at Squid endpoint changed
> to CLOSE_WAIT state.
> # date; netstat -tno | grep 192.168.64.4
> Fri Nov 27 11:32:13 BRST 2015
> tcp6 1 0 172.16.10.22:3126 192.168.64.4:61802
> CLOSE_WAIT off (0.00/0/0)
>
> According to
> http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm in
> this state the server IP stack is waiting for Squid to be ready to
> close the connection.
>
> After 3 hours from initial connection netstat state on client was
> still FIN_WAIT_2 and on server was still CLOSE_WAIT.
> So I powered off Windows laptop and waited 3 hours more but nothing
> changed, connection remained in CLOSE_WAIT state and Squid didn't
> release the file descriptor.
> Fri Nov 27 18:22:25 BRST 2015
> squid 2708 proxy 5465u IPv6 620209
> 0t0 TCP 172.16.10.22:3126->192.168.64.4:61802 (CLOSE_WAIT)
>
>
> Regards,
> André
I installed Squid 3.5.12 on another machine and got the same problem as
before.
Squid keeps using file descriptors for connections that have been in
CLOSE_WAIT state for hours.
My guess is that Squid doesn't release the file descriptor when
intercepts an https connection that triggers "local IP does not match
any domain IP" warning in cache.log.
Regards,
André
More information about the squid-users
mailing list