Bug 29774
| Summary: | accept filters leave established connections without timeout | ||
|---|---|---|---|
| Product: | Base System | Reporter: | lwa <lwa> |
| Component: | kern | Assignee: | Alfred Perlstein <alfred> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 5.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255065 | ||
Responsible Changed From-To: freebsd-bugs->alfred Alfred, could you please look at this? ----- Forwarded message from Alfred Perlstein <alfred@FreeBSD.org> ----- Date: Thu, 16 Aug 2001 12:21:55 -0500 From: Alfred Perlstein <alfred@FreeBSD.org> To: ru@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org * ru@FreeBSD.org <ru@FreeBSD.org> [010816 10:46] wrote: > Synopsis: accept filters leave established connections without timeout > > Alfred, could you please look at this? I've already answered such questions before. Yes accept filters leave the connection open, however the connections will be dropped when SOMAXCON (or the listen(2) limit) is hit. I also suspect that you can enable keepalives on the listen socket to effect a timeout for incomming connections. Please let me know if this is acceptable. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? ----- End forwarded message ----- State Changed From-To: open->analyzed State Changed From-To: analyzed->feedback waiting for originator to report possible solutions and actually explore the problem fully to determine if there actually exists a real way to DoS accept filters. State Changed From-To: feedback->closed originator timed out waiting for responce, and I'm confident that my explanation of how this actually works is sufficient although patches to add a timeout would be accepted. |
When apache is used with httpready accept filter, the kernel notice apache than a connection is avaiable if data match what httpready is programmed for. On certain case, httpready keep the data without time limit, leaving one connection established and wasting some mbuf. After one day running, on a server never referenced and without any documents : % netstat -an -f inet | 'Proto|\.80' Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 3818 0 213.91.2.241.80 213.30.133.122.4647 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.93.113.136.2698 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.57.142.158.11000 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.8.86.29.2566 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.250.62.21.3955 ESTABLISHED tcp4 3818 0 213.91.2.241.80 62.10.54.49.2164 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.176.53.5.1383 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.242.144.68.1153 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.96.30.158.2110 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.46.202.155.4871 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.221.18.242.3455 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.66.113.35.3087 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.74.116.246.35836 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.194.95.185.1390 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.64.213.5.16989 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.131.135.241.1368 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.147.49.210.2503 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.132.46.58.3615 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.32.45.66.3813 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.217.37.10.1494 ESTABLISHED tcp4 3818 0 213.91.2.241.80 213.132.49.86.63509 ESTABLISHED tcp4 0 0 *.80 *.* LISTEN I suspect all this established connection are hits from Code Red worm. Code Red is a worm running on Microsoft Windows systems that scan the internet IP addresses to seek other Microsoft Windows systems on wich it can install itself (with a preference for IP address on the same Class A) It may be a serious security issue because a malicious user will be able to send the same sequence of TCP frames and buzy all avaiable TCP connections slots in few minuts. Fix: Accept filters are not enable on the kernel by default, but if they are, the apache port will use it without software configuration. Until accept filters are able to manage connection timeout : fix your kernel or your loader configuration to unload accept filters, so apache will be unable to use it. Then reboot. It will be a good thing to remove recommandation about the use of accept filter on the apache optimisation document about BSD. How-To-Repeat: - install apache 1.3.20 - kldload accf_http - start apache - wait some hours until few Code Red worms instance hit you