QoS and bot traffic

i am starting a discussion in the relevant groups on this subject, to try and come up with some suggestions and to-do items we can follow up on, or maybe even better – find another solution.

networks require a means by which they can control their botnet population. yes, “curing” the problem is great, but it won’t happen in the near future.

obviously, having isp’s call even one customer to remove infections doesn’t work (costs significantly more than the subscription fee per attempt) and people just get re-infected.

i am looking to utilize proven technology to be able to reduce the cost of what a botnet can do.

if botnet traffic is detected, even by not very sophisticated technologies such as simply checking for email sent from dynamic ranges or netflow data, it should be possible to use routing technology to “mitigate”.

qos can limit the traffic these bots can utilize much like it would p2p users in most isp’s today. these users are already of limited traffic due to the effects of the bot.

how can this be done using today’s technology? does it require re-design of hardware or new systems to be designed? i hope to find out and get a proposal ready,

gadi evron,

  • http://security.eweek.com Larry Seltzer

    Cable modems in all modern networks are based on DOCSIS standards which use QoS extensively for similar purposes. I haven’t looked into this in years but I think the idea may have been originally to give them options to sell higher or lower service levels. In any event, the stadards are easily in place for cable companies to do what you discuss.

    I’d have to think DSL companies can do the same because they do explicitly sell different service speeds for different prices. The highest speed they can obtain for a customer is often a function of line quality, but they could step people down. What if the customer already bought the lowest available speed?

  • http://anti-virus-rants.blogspot.com/ kurt wismer

    trying to use the same technology against bots that is being used against p2p networks will only result in the p2p community working against you (and they have already made steps in working around selective traffic shaping technologies)…

    not that they are looking to make malware easier to spread, mind you, but they are very interested in defeating the kind of technology you’re talking about and they tend to be open source these days so the bot creators can easily make use of their efforts…

  • sunshine

    Kurt – then it becomes a battle rather than a lost cause.

  • http://blogs.securiteam.com/index.php/archives/author/mattmurphy/ Matthew Murphy

    What I’d like to see is an opt-out-required policy from consumer-class ISPs blocking port 25 connections to external endpoints. Such connections would be dropped by default, and would only be permitted after the customer asked the ISP to enable them. A less-invasive version would use QoS to severely bandwidth-deprive the first n connections from a customer to a foreign SMTP server, and drop all subsequent attempts. It wouldn’t solve or even mitigate the entire botnet problem, but it would be an effective way of dealing with spam zombies. Ironically, though, a QoS-based approach might actually ENCOURAGE botnet build-up, as more compromised PCs would be required to send the same amount of spam.

  • http://anti-virus-rants.blogspot.com/ kurt wismer

    a battle where the enemy gains an unintended (and large) ally, where the technology to thwart your efforts is not only legitimate but widely desirable…

    you think that won’t still be a lost cause? i have my doubts… it certainly doesn’t seem like an example of choosing your battles wisely…

    full quarantine of affected machines seems better – it stops the bot in it’s tracks and it provides the customer with notification about the failure of their security efforts… the isp’s don’t have to eat the cost of clean-up as they can charge the user extra for that service (the phone company where i live takes a similar approach to technical support in that if the problem is on the customer’s end the customer has to pay for the technician’s visit), and nothing short of getting the customer to change their ways is going to address repeat contamination…

    adjusting the ‘quality of service’ is just going to look like there’s a problem with the isp’s service and encourage the customer to find an alternative provider…

  • http://www.BeyondSecurity.com Aviram

    Matt – many ISP’s already block outbound SMTP connections, ever since the large Virus floods from years ago; one of the problems is that many road warriors complain about it.

    In general, it is much easier for the botnet builders to find a way around whatever limitations will be put in place (and I agree that P2P is a good example of how that fails) while the legitimate users have to wonder why mail isn’t sent, HTTP traffic is slowed down or just funny things are happening because a ‘transparent’ filtering system is in place or the QoS is acting up.

  • rodolfo

    your point bring an interesting nuance to the dichotomy do-nothing/block, which is worth exploring.

    we also need to distinguish between residential and enterprise traffic.the cloud of zillion of remediation calls from residential customer is daunting, but the enterprise scenario may be different. and a premium service for residential customers is not out of the question.

  • Stefan

    If you can
    1. Detect botnet activity
    2. Define the botnet network traffic
    I dont see why not close it down the botnet network traffic alltogether. I suppose that if you cannot do either of these, it would make sense to limit external smtp by use of QoS for all customers. Not many sends legitimate bulk e-mail from residential homes anyway.