Hi Aleph, Sent this already to you a couple of months ago but I presume it got sucked into a quasar on its way to you.Maybe it gets lucky this time. Looks like there are some problems in some of the most popular TCP/IP stack implementations. I've found a kiddie-tool on the internet that looks like it's rising some problems in a matter of CPU usage for handling incoming UDP packets. Its initial aim was another one (read the source) but accidentally it can be used for locking up machines. You can try it from http://rootshell.com/archive-j457nxiqi3gq59dv/199803/biffit.c I'm not a TCP stack-writing guru but I presume the behaviour described below is way beyond normal, as its results are quite different depending on the OS used. Please don't bash me if I'm wrong. Here are the reactions of major OS'es on the market on this simple UDP flood. Be aware that the results are working on the quoted kernels no matter if their specific ip-filtering mechanisms have UDP filtering rules enabled or not and no matter if you really have in.comsat running or not, you may change the destination port to whatever and get the same result: 1. Linux 2.4.7 UP (pristine source, waiting for a new shiny Alan Cox patch) - system gets frozen after 3 seconds of flood on a gigabit link. Same result at a 100Mbps. The top utility shows (at least as long as it can) that system(kernel) gets 100% of the CPU in its march to death. Same for Linux kernel 2.2.19. 2. Linux 2.4.7 SMP (same origin) - the flood effect is distributed on the 2 CPUs (p3/1Ghz) at a ratio of 30-40% per processor. Linux SMP is superb, it implements load-sharing of everything, even DoS :) 3. Windows 2000 Server UP. - the system graphs jump from 2% cpu usage (in a calm evening with no ongoing backups and domain synchronizations) to approx. 35% and holds it steady. The flood is performed via a Gigabit link. The packet rate handling of win2k is wonderful, it even beats an OpenBSD 2.8. Kudos to MS guys, this one is a real hit. As I couldn't believe my eyes I ran some applications on it (crunching queries on the local MS SQL2k server etc) and I got timely-fashion responses. 4. Open BSD 2.8 UP, no patches applied - top utility shows a 45% processor load and holds it steady. The system is responsive (unlike Linux) and the apps are running okay. 5. Windows 2000 Professional UP. - systems gets an extra 60% load average payload over its initial one. It is still responsive to commands, doesn't choke a bit. 6. Windows ME UP - this little bitch runs OpenGL apps under heavy UDP hammering with no CPU cost ! Like nothing happened. Heilz to MS again. 7. Cisco IOS - tested on Cisco 7513 (12.1(4)E, DCEF enabled), Cisco 2621 (12.2.1), Cisco Catalyst 35xxXL (12.0.5.2.XU and 12.0.5.1.XP). I'm walking here on Linux-behaviour land. The CPU is burning at high load averages from the start and I get no control over it. I can get the result either directly attacking the router, either forwarding for a host behind it. IOS plays the brave guy and gets it for anyone else too. 8. SunOS 5.7 running on an UltraEnterprise 3500 - beautiful reaction. No CPU waving on this SMP system, looks like nothing happened to it. I'll buy one for home when I'll be a millionaire :) I would like to hear some other results for other operating systems. Greetz go as usual to Gore, my old one-eye pirate parrot and to his fat wife that ruined his long glorious life. P.S. [offtopic] can someone please write a detailed mail here to explain how easily is to defend/log CodeRed with Snort and FlexResp support? It would have been the only practical thing discussed about it among tons of repetitive and identical advisories of 'security experts' that solve nothing so far. I block hundreds of worms daily this way without having a patched IIS. My recent post regarding this was blocked already because the thread was (err...) "ended" by fate or whatever so it wasn't relevant or even read. -- Stefan Laudat CCNA,CCAI Senior Network Engineer Allianz-Tiriac SA "Let's call it an accidental feature." -- Larry Wall
This archive was generated by hypermail 2b30 : Wed Jul 25 2001 - 13:26:37 PDT