NETI@home Data Analyzed 155
An anonymous reader writes "The NETI@home Internet traffic statistics project (featured in Wired and Slashdot previously) has a quick analysis on the malicious traffic they observed. It's a rough world out there." Perhaps not suprising, but still disheartening, the researchers find among other things that a large portion of typical end-user traffic consists of malicious connection attempts.
RBL of infected/malicious sites? (Score:5, Interesting)
Re:Considering.. (Score:2, Interesting)
Oh, so there should be a central hub where the virus/worm can talk to other copies of itself. Any place it could talk to itself would quickly be located and shutdown. Besides, I don't think the writers of these kinds of programs are really concerned with your network utilization.
Most of the malicious type traffic I'm seeing lately (aside from SPAM) is ssh worms trying to log into my boxes. Most boxes are set to only allow ssh from a few IPs or subnets, but I have one that I block class A's anytime I see a worm trying to get in. I've got about 1/2 the IP space blocked right now.
It would be like setting up a massive feedback loop on a mail server. When user X gets message X, he passes message X to user Y, who upon receiving message X sends it back to user X
I remember a Banyan mail system I worked with. In the event that you set up a vacation (while I'm out) type mail minder and we're near your mailbox limit, it was possible to start and endless loop of a mailbox full notifications (mailbox full notifications were allowed even if the limit was reached).
Re:RBL of infected/malicious sites? (Score:2, Interesting)
Flow observation conclusions... news u can use (Score:4, Interesting)
ISPs are already starting to work together on this type of information. If an ISP sees malicious worm spreading behavior, it can upload the offending IP into a global db that all ISPs can use to block at their borders.
Again, the authors conclusions are that nothing beats having a nice dark block to trigger alerts.
Cheap access means unsafe computing (Score:5, Interesting)
At least such is their thought process as often presented. I suspect it's bad cost-benefit analysis; if your dumber customers leave, it's probably a net win for you. Smarter customers mean less bandwidth (at least, they don't act as spam zombies maxing out the bandwidth) and fewer tech support hours explaining how to fix the cup holder.
The big players (AOL, Comcast) are the best targets for this logic, but they live for those left-side-of-the-bell-curve customers. They're the "default" ISPs that people get because they're so readily available, so they get all the customers who don't know better. (Hell, I don't know better; I use Verizon for my DSL but I don't let them do anything but provide me bits.)
So AOL and Comcast are in a bit of a bind; they don't want these customers, but they don't want to lose them, either. I think that they're probably going to have to use gentle persuasion to say, "Hey, it looks like you've a spam zombie. Please call your cousin's best friend to clean the crap off your computer again and give you a stern talking-to. And please stop downloading Bonzi Buddy."
Re:Not necessarily a Bad Thing... (Score:4, Interesting)
Maybe it would be a good idea to throttle the users down to a bare minimum and redirect all http traffic to a gateway page to tell them they have a problem with their computer they need to correct. It seems to work for wireless access points in hotels/airports/coffeeshops. Why can't big ISPs do the same thing?
Re:Not necessarily a Bad Thing... (Score:2, Interesting)
This should be an issue the industry should tackle together. Due the nature of broadband in most markets, these customers aren't really going to have many service alternatives either if they don't like the way their ISP is trying to help them help themselves. If the major players make it known that they won't let their customers unknowingly crush the internet under the load of their spyware and malware riddled boxen, it would go a long way to making a dent in the problem.