> Yes. But someone *does* own the botted computers, and their own > operations are slightly affected. I have wondered if there is some > way to make a bot so intrusive that many more owners will ask > themselves, "why is my computer so slow/weird/whatever? I'd better > get it looked at. Maybe I should install a virus scanner."
Somebody said earlier in the thread (sorry but I can't be bothered to find the exact quote and attribute it) something along the lines of "this is an arms race". The current bot software may not be there yet, but it is easy to see how the bot-net developers would like to have the job of probing IPs distributed over the botnet, so each target only receives a single call from each distinct IP, but together the 10,000 members of the bot-net each send one probe creating a full probe of known weak points in the server. The net result would be a) very hard to detect/defend against b) the proposal would not have a negative effect - you only add 1 second (or whatever value is agreed) to the async call time for each botnet member. I agree that currently if an attacker compromises a server, and then runs probes against the whole internet from that one host, your idea would slow the assault. However it will just encourage the next evolutionary step described above. However the bad guys are quite clever. The scanning software already has rate limiting switches to stop network intrusion detection systems from detecting probes. They would just use these to slow the attack and the computer user would not notice. As long as you have many bots in the whole net, it isn't a problem. I used to work in agrochemical research. They tried 1,000,000 different pseudo-random chemicals a year against plants, watching for a reaction. If something reacted in a "positive" manner, then they investigated what was going on. This is the same as the bad-guys are doing globally - probe every IP, and look for interesting responses. Yes the approach to slowing down these responses should in theory work, but if the clever guys distribute the load over a bot-net, and the bot-net is large enough, then it is just a numbers game. Enough bots sending probes, and then get a new target each day, that will be enough for them to abuse that target to send out that days mailshot of spam. The key security recommendation is to not have anything running unless required. The manager app has no users defined by default - perhaps the default install for tomcat could be such that it is a bare bones install? I do not know of any weaknesses in the manager app, but if it isn't even there, their presence/absence doesn't really matter. Same with the other default parts, e.g. help etc. As long as they can be installed easily if required, shouldn't be a problem. The OWASP recommendations for securing tomcat suggest removing all items under catalina_home/webapps as a first step. Just a thought. The first step an attacker performs when conducting a focused attack, is to map out the server. The presence of a response to http://server:8080/manager/html/ would seem to indicate a default install of tomcat. Once that have this initial reconnaissance performed, they will move onto using known exploits against it. By removing manager app from the default install, this would be made one step harder. You can't really prevent a dedicated attacker, but making it one step harder to attack your server, might make the not-bothered-which-server-I-attack guy move on to easier pickings Also one thing worth mentioning. There is an attack called a blind sql injection attack. The crux of it is that by timing the response from a sql injection, you can detect if your query was a success or a failure. Typically some processing occurs upon success, hence the response takes longer. During testing (obviously not against a real db :-)), I have used manged to download the whole contents of a db after a little scripting of a sql injection and some perusal of the results. If you deliberately delay 404 by a known amount of time, it will still stick out, and they can use this just as much as a positive indication. HTH somebody Chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
