Re: How can I get >100 connections in FIN_WAIT_2 state from the same IP?
On Tue,13-10-2009 [17:50:00], Michael Powell wrote: > Chuck Swiger wrote: > > > On Oct 13, 2009, at 10:33 AM, Martin Turgeon wrote: > >> I would like to know if anyone knows the reason why I get a lot of > >> connections (more than 100) from the same IP in FIN_WAIT_2 state. > > > > That IP is probably running a web proxy or possibly some kind of > > spider. It could also be malicious, trying to exploit webserver > > vulnerabilities, etc-- search your logs for that IP and see what it is > > doing. > > > >> In this case the connections are on port 80. Is it a problem with the > >> client's browser or OS? Is it possible that some mobile devices > >> doesn't > >> close their connections correctly to save bandwidth and battery? > > > > Yes, it's not uncommon for various platforms to simply drop > > connections rather than closing them properly. You can run tcpdrop to > > forcibly get rid of them, but they should time out within a few > > minutes anyway. If you believe the remote IP is being abusive, > > consider firewalling it > > > > This is also common from the differences in TCP/IP stacks across various > platforms. Windows, Linux, Solaris, etc are all slightly different in this > regard. > > If you're running a web server you can set the following in /etc/sysctl.conf > in an attempt to mitigate. Don't know if the timeout period can be altered. > > net.inet.tcp.fast_finwait2_recycle=1 > > This won't stop it from happening but it will trim the pool down some. Hi, maybe you'll find this info useful as well: >From man pf.conf: [...] Options tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets. [...] It looks like this pf tunable has a 45s default value: #pfctl -st [...] tcp.finwait 45s [...] Setting pf optimization to 'aggressive' changes it to 30s value. -- Best regards, Jeff | "Nobody wants to say how this works. | | Maybe nobody knows ..." | | Xorg.conf(5)| ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: How can I get >100 connections in FIN_WAIT_2 state from the same IP?
Chuck Swiger wrote: > On Oct 13, 2009, at 10:33 AM, Martin Turgeon wrote: >> I would like to know if anyone knows the reason why I get a lot of >> connections (more than 100) from the same IP in FIN_WAIT_2 state. > > That IP is probably running a web proxy or possibly some kind of > spider. It could also be malicious, trying to exploit webserver > vulnerabilities, etc-- search your logs for that IP and see what it is > doing. > >> In this case the connections are on port 80. Is it a problem with the >> client's browser or OS? Is it possible that some mobile devices >> doesn't >> close their connections correctly to save bandwidth and battery? > > Yes, it's not uncommon for various platforms to simply drop > connections rather than closing them properly. You can run tcpdrop to > forcibly get rid of them, but they should time out within a few > minutes anyway. If you believe the remote IP is being abusive, > consider firewalling it > This is also common from the differences in TCP/IP stacks across various platforms. Windows, Linux, Solaris, etc are all slightly different in this regard. If you're running a web server you can set the following in /etc/sysctl.conf in an attempt to mitigate. Don't know if the timeout period can be altered. net.inet.tcp.fast_finwait2_recycle=1 This won't stop it from happening but it will trim the pool down some. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: How can I get >100 connections in FIN_WAIT_2 state from the same IP?
On Oct 13, 2009, at 10:33 AM, Martin Turgeon wrote: I would like to know if anyone knows the reason why I get a lot of connections (more than 100) from the same IP in FIN_WAIT_2 state. That IP is probably running a web proxy or possibly some kind of spider. It could also be malicious, trying to exploit webserver vulnerabilities, etc-- search your logs for that IP and see what it is doing. In this case the connections are on port 80. Is it a problem with the client's browser or OS? Is it possible that some mobile devices doesn't close their connections correctly to save bandwidth and battery? Yes, it's not uncommon for various platforms to simply drop connections rather than closing them properly. You can run tcpdrop to forcibly get rid of them, but they should time out within a few minutes anyway. If you believe the remote IP is being abusive, consider firewalling it Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
How can I get >100 connections in FIN_WAIT_2 state from the same IP?
Hi everyone, I would like to know if anyone knows the reason why I get a lot of connections (more than 100) from the same IP in FIN_WAIT_2 state. Refering to this diagram (http://www.jxos.org/Projects/TCP/tcpstate.html), the connection enter in FIN_WAIT_1 when the server closes the connection and in FIN_WAIT_2 when the client ACK the FIN from the server. For the connection to stay in FIN_WAIT_2, the client must never send his FIN, right? In this case the connections are on port 80. Is it a problem with the client's browser or OS? Is it possible that some mobile devices doesn't close their connections correctly to save bandwidth and battery? I know this isn't specific to FreeBSD, but thanks for your answer anyway Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
