Kelihos Botnet Comes Back To Life 97
angry tapir writes "A botnet that was crippled by Microsoft and Kaspersky Lab last September is spamming once again and experts have no recourse to stop it. The Kelihos botnet only infected 45,000 or so computers but managed to send out nearly 4 billion spam messages a day, promoting, among other things, pornography, illegal pharmaceuticals and stock scams. But it was temporarily corralled last September after researchers used various technical means to get the 45,000 or so infected computers to communicate with a "sinkhole," or a computer they controlled."
Expected (Score:5, Informative)
Researchers knew that it would only be a matter of time before its controller used the botnet's complex infrastructure of proxy servers and communication nodes to regain control.
The linked story says they fully expected this, and that the method they used (sink-holing) was never expected to be a permanent solution. One has only to hope that stating they have no "recourse" is merely baffle-gab to embolden the controllers. It might also mean "lets make believe we haven't compromised some of the bots and planted a few or our own".
They also suggest that the suspected Russian controller couldn't be extradited, but conveniently neglect to mention that Kaspersky Lab is a Russian company that could influence internal Russian enforcement actions.
Kaspersky Lab Expert Maria Garnaeva Posts in her Blog some of the difference between the new and old control mechanisms: http://www.securelist.com/en/blog/655/Kelihos_Hlux_botnet_returns_with_new_techniques [securelist.com]
She also mentions it is not as bleak as the original article, because:
It is still possible to neutralize the botnet with sinkholing but using slightly different techniques as was used before, and it is still possible to push an update tool on infected machines to neutralize the botnet. In this case the botmasters need to infect machines again to build another botnet.
Re:Expected (Score:5, Funny)
Which OS do all these botnets run on?
Silly question.
Windows. Obviously.
Macs are immune to all attacks and viruses and Linux just does not have the market share to be a target of interest. All regulars here on Slashdot know this. You must be new here.
Re: (Score:3)
Macs aren't immune. Getting users to install malware is easy, but why bother. Windows is easier and more wisely deployed.
Re:Expected (Score:5, Funny)
Macs aren't immune. Getting users to install malware is easy, but why bother. Windows is easier and more wisely deployed.
You mean, less wisely?
Re: (Score:2)
That's a typo. I meant to type "widely". The distance between the virtual keys on my phone is about a third the width of my finger.
A contextual spellchecker would flag the words "Windows wisely" as a probable typo.
Re:Expected (Score:5, Insightful)
No OS is immune to the dancing pig problem [wikipedia.org].
Re: (Score:2)
No OS is immune to the dancing pig problem [wikipedia.org].
The porcine polka?
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Who do you trust? (Score:1)
Thanks for the link. I knew user ignorance is the primary vector for malware spreads, but I did not know what to call it.
Corporations/Governments seem to love to keep underlings ignorant so they can be controlled - Knowledge is Power.
Ignorance of digital hygiene on the internet is just as risky as ignorance of bacterial hygiene in the kitchen.
A big problem is a few people profit immensely from privileged information. They will lobby like hell to keep
Re:Expected (Score:5, Funny)
Darn, I was hoping your link led to a page with dancing pigs on it!
Re: (Score:2)
Re: (Score:1)
Re:Expected (Score:5, Insightful)
Kaspersky Lab is a Russian company that could influence internal Russian enforcement actions.
You must be new to the eastern hemisphere. In the sovereign democracy of Russia, the enforcement influences companies, not the other way around.
Re: (Score:2)
There's labor unions there, too?
Re: (Score:2)
Have they considered following the money trail and targetting the operators and clients for arrest or assassination?
Re: (Score:2, Insightful)
Simpler option: Temporarily direct the botnet to a sinkhole not to take it down, but to add movie download/seeder functionality to it. Then sit back and watch the **AAs take it down piece by piece.
Re: (Score:2)
Re: (Score:2)
Obviously, the assassination comment was in jest. The arrest possibility is serious. These operators and the people who pay them are a criminal enterprise. Law enforcement could shut them down if they wanted to. The botnet would still be there if anybody wanted to use it. So you wait for it to go active again and round up the next batch of perps.
You still have to deal with non- cooperating jurisdictions. But users could use fairly simple means to block spam from them because they have identifiable ran
Re: (Score:3)
Why not just turn on windows auto update fix whatever maybe stopping auto update from running and plant the removal tool on windows update. If done via the bot nets control servers who can really tell who did it ?
Just asking this but kaspersky is Russian and no extradition right. They can kick it off with barely any worries.
Heroes (Score:4)
Security researchers really are the unsung heroes.
If there are anyone reading Slashdot who works in that area: I would like to express my deepest gratitude for all the efforts you go through in combatting this global problem. Thank you so much for making the web a less shit place to be.
Workable solution? (Score:5, Insightful)
Half the business world seems to believe that it is acceptable to mail my ISP, and have me disconnected from the internet if I download a couple of songs, movies, or whatever. Three strikes, and you're out.
So - why isn't anyone clamoring to have these machines disconnected by the ISP's? If they had all those machines communicating with a sinkhole for months, then surely they have identified real IP addresses for most, if not all of them.
We have the ability to unplug people and computers from the internet. Why do we only want to use that ability to punish small time downloaders?
Re: (Score:3)
Re: (Score:2)
I'll just say, that I hate hearing that Android is "linux based". The wife's computer has nothing that didn't come from a trusted repository. The two worst things on her computer are Java and Flash - and only one of those came from a proprietary vendor. That is "Linux".
My own computer has a lot more proprietary stuff on it than hers does. I play with VMWare, I've diddled with some game emulators, and I experiment with stuff now and then, just to see what it does. Even so, there is nothing on my machine
Re: (Score:2)
During a raid; are the peers involved? (Score:1)
The common answer is no. When they roll up a botnet they usually pick up the suspects which have been using this botnet, but all the peers are usally (if not most often) left alone.
Not surprising considering the kind of peers, but doesn't that aspect alone make scenario's like these plain out obvous? Its only a matter of time before another "botmaster" picks up where the previous owner was cut off.
It's a zombie botnet (Score:1)
Re: (Score:2)
Already been done. Another head finds the body. Didn't you even read the summary?
Re: (Score:1)
aren't there some structural ways to curtail this? (Score:4, Insightful)
I assume that the zombie-workstations send out e-mail via SMTP. Why not require real mail servers to comply with DNS to have an MX record for the domain or IP, and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
That would prevent a non-MX mail server from being able to send mail since other mail servers would reject it based on DNS, and would prevent zombie botnets from using the SMTP servers of the service provider that the computer is connected to in order to spam through.
It wouldn't eliminate spam, but it might serve well to reduce it significantly. Yes, it would require some more programming in the SMTP daemon, but it shouldn't jack with the protocol.
Re: (Score:1)
because MX implies location for reception, not necessarily for sending. get any kind of serious mail volume and you'll very quickly decide to separate your outbound SMTP from your inbound SMTP.
Re:aren't there some structural ways to curtail th (Score:4, Interesting)
MX record is inbound only. period.
However, ISP's could block outbound port 25 unless using their servers (such as my cable company) and/or make arrangements for a particular IP range to be outgoing mail servers. That starts to make sending servers a little more accountable.
If you need to send mail direct to a server outside this network, use ssl and submission port, not port 25.
Re: (Score:3)
Other problem is: How to do that without essentially eliminating all illusions of privacy.
Re: (Score:2)
That actually doesn't sound quite that hard. Changing PHP and Perl would be easy; the maintainers of those languages would simply change their implementations to use email 2.0. As soon as web hosts upgrade, they'd be using the new version, and web hosts usually stay fairly current on scripting languages because customers demand it (newer versions, particularly with PHP, mean more built-in functions and easier coding).
With email servers, again there's not that many pieces of software out there that are rea
Re:aren't there some structural ways to curtail th (Score:5, Interesting)
There are plenty of rules that could be set up to prevent rogue systems from sending spam, but the problem is with getting network operators and individual server administrators on board. Trying to get all network operators (or ISPs) around the world doing something is like herding cats. Trying to get all individual server administrators to do something is like herding millions of catnip-infused cats.
Your thought about MX records is not quite right. There is a difference between servers that recieve mail (which should be pointed to by MX records) and servers that send mail (which should have valid PTR records in reverse DNS for their IP). While a single server may perform both duties, that is not by any means guaranteed. One action that would block a large number of infected systems from delivering their spam would be receiving mail servers blocking all mail from senders that do not have a valid RDNS record. This is the correct version of your proposal, and some major providers already do this. An even greater benefit could be achieved if all ISPs were to block outbound traffic headed for TCP port 25 by default, requiring subscribers to "opt-in" to initiate port 25 traffic. Some ISPs already do this, but far too many do not. Yet another good measure would be for recipients to block mail from servers that fail to identify themselves with a valid fully-qualified domain name in their HELO message and require that domain to resolve by DNS. Like the RDNS solution, this would require all legitimate mail server operators to set their sending servers up properly. As more receiving operators start blocking non-compliant mail servers, we may slowly push more sending server operators to do things right, but it is a long, slow process when users demand that every legitimate message get through.
Re: (Score:3)
and servers that send mail (which should have valid PTR records in reverse DNS for their IP).
Since MUA can use SMTP to send email, it is not required that there be a PTR for every sending host. It is true that there MAY be one, but it isn't a requirement. Large sites that may not publish DNS records for every internal system can likely get around any requirement from the recipient MTA by using a central mail server through which outgoing mail is sent. That server would have a PTR (and SPF) record.
That, however, seems to be an undesirable solution when it comes to an ISP serving many customers, ho
Re: (Score:3)
End-users should not be using SMTP to communicate directly with recipient servers, and almost none do. Nearly all ISPs provide authenticating SMTP relays for their subscribers, and end-users should be using those ISP-provided SMTP servers or some other mail provider's SMTP servers to relay their mail. If they have some legitimate reason to send mail directly (such as operating their own server), then requiring them to ask their ISP for a port 25 blocking exemption is perfectly reasonable.
Legitimate large-vo
Re: (Score:2)
End-users should not be using SMTP to communicate directly with recipient servers, and almost none do.
"Almost none"? I believe that Outlook does. Evolution does. Pine does. The mail program on my smart phone uses SMTP to send email. I would hardly call that "almost none".
Nearly all ISPs provide authenticating SMTP relays for their subscribers,
Yes, which talk SMTP to the "end user".
Legitimate large-volume senders have already dealt with this.
They haven't already dealt with some new proposal that requires MX records for sending hosts and "human" limits on sending email.
Re: (Score:1)
SMTP consists of both a message submission part and a message transfer part. They both use the same protocol and appear extremely similar.
The way it works is, Sender connects to SMTP Server S and transfers message. SMTP Server S connects to SMTP Server R and transfers message. Recipient connects to Server R (via POP3 for example) and retrieves the message.
Nearly all ISPs provide authenticating SMTP relays (Server S in the explanation) so that the Sender never needs to communicate directly to Server R.
Re: (Score:2)
End-users should not be using SMTP to communicate directly with recipient servers, and almost none do. (Emphasis added.)
"Almost none"? I believe that Outlook does. Evolution does. Pine does. The mail program on my smart phone uses SMTP to send email. I would hardly call that "almost none".
I very much doubt your mail client is configured to send mail directly. It almost certainly has an SMTP relay configured for sending mail. Nearly all MUAs lack the option to send directly -- they require that a relay be configured.
Nearly all ISPs provide authenticating SMTP relays for their subscribers,
Yes, which talk SMTP to the "end user".
Legitimate large-volume senders have already dealt with this.
They haven't already dealt with some new proposal that requires MX records for sending hosts and "human" limits on sending email.
"This" in my statement above specifically referring to having the appropriate PTR records set up, as the context in the following (unquoted) sentence indicates. No part of my post supports any funky use of MX records or sending volume limits.
Context -- it changes things.
Re:aren't there some structural ways to curtail th (Score:5, Informative)
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP,
Because there is no rule that says any destination must have an MX record associated with it. RFC 5321 lists how to determine the host a server connects to, and "no MX" is an allowed case.
and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
What is a "human real-world number"? How do you deal with mailing lists that have hundreds of recipients? One email to the list results in hundreds of emails all at the same time.
That would prevent a non-MX mail server from being able to send mail since other mail servers would reject it based on DNS,
I'm sorry, but I don't think you understand the purpose of an MX record. The MX record isn't for the SENDING server, it is so the sending server can find a defined host to which email FOR a domain is sent. In fact, if an MUA uses SMTP to send mail, then it is highly unlikely that the sending host (the user's computer) will be the address pointed to by the MX record for any domain.
Yes, it would require some more programming in the SMTP daemon, but it shouldn't jack with the protocol.
As long as you don't consider "not being able to send email at all" a problem, no, your idea won't "jack with the protocol".
The more correct means of dealing with the problem is two-fold. SPF (sender permitted|policy framework) is how a recipient server looks up the authorized hosts that might be sending it email from a domain. Greylisting is how a server typically dispatches botnet senders, since the botnet is usually not going to try resending an email after getting a 500-level error.
Re:aren't there some structural ways to curtail th (Score:5, Informative)
Jeez where do I start? You must not be that familiar with email or how it is actually run today.
First off, email is an archaic platform that gets a bunch of glue and duct tape every so often.
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP, and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
You can already do this with most mail servers. You have two problems here:
1) Requirement.
2) ISP involvement.
You cannot legally compel any person operating a mail server to do anything as part of configuration. The only legal liability I am aware of is sending SPAM itself, and even then the claim that you are merely a victim usually works.
ISPs don't want to be involved on a general basis. On business connections they don't do a damn thing, because businesses would go ape shit. I would. On residential connections some have at some points in time restricted port 25 destination traffic and the TOS usually prevent operating services off the IP address anyways. That being said, it has been awhile since I have actually seen a US based ISP actually block port 25 traffic anymore.
What is done on a day-to-day basis now:
1) Inspection of the IP address communicating with the mail server. Policy based lists, which are contributed to by the ISPs, tell us if it is a residential connection (Dynamic IP address ranges). There are also other lists that allow us to see if that specific IP address is flagged for SPAM. Look at Spamhaus or Cisco's Senderbase products. If the IP address is on a list it the session can be terminated immediately or the SPAM score increased sufficiently.
2) Headers. Who is it being sent to? Who is it being sent from? You have to ignore who the email is claiming to be from in most cases since that is easily forged. Every part of the email address can be forged except the remote IP address. Sent to addresses can be on white list to get it into the Inbox regardless of SPAM heuristics. Part of what you seemed to be alluding to is the EHLO statement. You check the reverse DNS for the remote IP address and see if it matches, or even exists in the first place. You're right that most real mail servers run by professionals, and not on home networks, will have a proper reverse DNS. Shutting down the connection solely based on that is questionable though.
3) URI inspection. Parse out all the links in the email and compare them against lists of known malware host sites. Fairly effective, and I personally don't allow the email to even reach the junk mail folder when one is found. New URIs pop up very fast so this is only effective for older campaigns.
4) Certifications, DKIM, SPF. These are methods outside of the mail server communication that involve 3rd parties, certificates, and DNS records that can validate a mail server as authentic and provide policies on how to treat remote IP addresses.
5) Anti-virus and Anti-malware. Inspection of attachments.
6) Heuristics. Evaluating all of the above plus content inspection to arrive at an overall SPAM score. If it exceeds the threshold throw it in the junk mail folder.
Now that is just off the top of my head for the mail servers I run. You also alluded to gray listing which is temporarily denying an email and asking that it be resent later. This is controversial because a lot of people are waiting for an email ASAP and can't wait 15 minutes. Throttling is also not very useful because on an IP address basis the SPAM load is distributed.
There are already quite a number of tools to reduce SPAM. The biggest problem I face is backlash from executives. Requiring proper reverse DNS left out half the vendors we were communicating with right off the bat. I have had to tone down the security a number of times because the remote part has no clue what they are
Re: (Score:2)
Re:aren't there some structural ways to curtail th (Score:5, Interesting)
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
(X) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(X) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
(X) Willingness of users to install OS patches received by email
(X) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
(X) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
(X) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
commons (Score:5, Insightful)
What I don't get in the whole spam saga - and I've been following it for 15 years now - is why it is possible for law enforcement to cooperate internationally and do joint raids in several countries when it comes to fake products, unauthorized DVD presses or computer games piracy groups - but not when it comes to spam.
Ask Spamhaus - we know most of the top offenders. We know who they are and in many cases we know where they live. And law enforcement is sitting on their hands.
Because it is a small damage on many people - an attack on the commons, not on one particular company or individual. We as humans assess damages instinctively, not mathematically. And that leads to crazy results. We consider someone stealing $50k from a bank a serious criminal, but someone stealing $0.01 from 50 mio. people is a nuissance - even though the actual damage is 10 times higher.
Sadly, that's a trend not only with spam. When Mommy Jane illegally downloads a Disney movie, she is fined ridiculous amounts of money. When Disney corrupts the law to steal from the public domain by retroactively taking content back under copyright, or extending it so it enters it later (if ever), it is hard to even explain to people why that's bad.
We have lost the concept of the commons, and that is the real tragedy of the commons, not the bullshit neo-liberal bedtime story by the same name.
Re:commons (Score:5, Interesting)
Re: (Score:2)
That would not even be prosecuted under SPAM. It would be considered a DDOS and most likely part of a terrorist act. Since there is campaign contributions involved... you would see several three-letter-agencies involved and a predator drone sent to the remote site or some CIA asset in the area ready to "fake a heart attack" at a coffee shop.
Re: (Score:2)
It's possible simply because law enforcement, particularly where property is concerned, doesn't exist to protect the common man. Law enforcement and property law exist to protect the rich from the common folk. Protecting your average joe is outside the scope of their purpose, so they won't bother to do it.
It costs money to enforce the law. If they operate like a wolf chasing a mouse, then they risk budget cuts and firings.
Re: (Score:3)
Ask Spamhaus - we know most of the top offenders. We know who they are and in many cases we know where they live. And law enforcement is sitting on their hands.
What do you want them to enforce? Spam laws vary from laughable (CAN-SPAM act) to nonexistant. Do you want US marshalls breaking down the doors of a Moscow apartment to enforce CAN-SPAM?
Re: (Score:2)
In all seriousness if you threw 100 people in jail tomorrow, SPAM would take a small hit then climb back up to regular volumes. What is needed is going after the people paying for SPAM. That is possible some of the time. I agree with your sentiment.
However, what I find surprising after following it as long as you have is why, why, why have we not made a concerted effort as a group to fundamentally change the way email works? Where is the IPv6 analog for email?
Do you know how ridiculous it is that execut
Re: (Score:2)
However, what I find surprising after following it as long as you have is why, why, why have we not made a concerted effort as a group to fundamentally change the way email works?
We have. But inertia is a force more powerful than any amount good ideas put together. Just ask Microsoft - their past mistakes are their worst enemies.
The technology isn't the problem. I believe we have the solution for every single "but" from a technological POV.
The problem is that we have several billions of devices out there that speak SMTP, POP3 and IMAP and nobody wants to exclude any of them. We have thousands of programs interfacing the these protocols. Millions of hacks, injections, senders and rec
Re: (Score:2)
And with every download you get the latest malware too.
Re: (Score:2)
Spam earns a pittance for the pirates
There's your wrong assumption.
The top spammers have all grown rich doing it. Maybe not Megaupload rich, but in the same ballpark. We're talking houses, cars, several millions here.
Sissies (Score:5, Insightful)
"We could have issued an update to those machines to clean them up, but in several countries that would be illegal," said Ram Herkanaidu, security researcher and education manager for Kaspersky Lab.
Don't be a sissy! If you have the means to clean up machines infected with a botnet client without screwing it up, do it! If some pedantic rule-thumper complains about good-faith efforts to make clueless people's spamming machines stop doing that, rat them out by name to The Internet and sit back and watch a million people demand video evidence of their head being placed on a spike.
Re: (Score:1)
I wish I could take every mod point I ever had and put on this one post.
Re:Sissies (Score:5, Insightful)
OTOH, felony convictions can be soooo tiresome, although they do often come with free room and board. And then there's the question of whether a convicted, imprisoned felon is still liable for all the $million+ civil suits by every luser out there who thinks that your clean-up virus (which is what it is) has destroyed their porn collection. Hint - still liable.
Re: (Score:3)
Re: (Score:2)
I don't think your idea is particularly insightful. The problem is that if the user was dumb enough to install malware in the first place, simply removing the malware won't fix things in the long term, so it's a hell of a risk to take for no long term gain. They might get a short term gain but they already got that without doing anything illegal.
Even the obvious solution of just nuking the PC's from orbit (only way to be sure!) won't solve anything. The user will just buy another PC and get it infected agai
Re: (Score:2)
You fail to account for the fact that the bypass switch would soon be set in the wide-open mode.
Re: (Score:2)
too few intermediates care (Score:4, Interesting)
The reason these assholes can run all over us is that too few of those involved care. I am very happy that MS has started to care, and it's probably the only good thing they've done all century, but it really is a powerful signal.
The next people who need to start caring are the ISPs. Just recently I complained to my own ISP that they are hosting the actual website that the spam I get is advertising. They told me to use the "unsubscribe" link. Yeah, right. Living under a nice rock there, customer service idiot?
I'm all for making ISPs responsible if they knowingly host spammers. I'm for vigilante action at this point, as nothing else seems to work. Get Anonymous on the subject. Blast the ISPs who say "fuck off" when you point out that they have a spammer in their hosting center off the 'net.
We all know that there is no single, simple solution to the issue. So instead of looking for it, why not combine all the imperfect, partial solutions we have? Let MS & Co. take down the botnets. Put pressure on the CC companies to stop dealing with them. Make the banks liable and cut off the money flow. Make the ISPs care and make it harder (thus more expensive) for the spammers to find a home. Shoot some spammers. Shoot some idiots who keep them in business by buying from them. Sacrifice a goat, stick needles in a puppet and pray to your god(s). Do it all at once.
Re: (Score:2)
I know that I am replying to you twice here, but why go after the command and control? Most SPAM is sent from infected computers and not infected servers. To my knowledge at least.
Residential ISPs would be doing a service if they shut off a connection and routed all port 80 requests to a web page explaining to the consumer that they have been identified as belonging to a bot-net and are harming others through their continued inaction. Give them links to solutions. Allow some proxied access to Google map
Re: (Score:2)
Residential ISPs would be doing a service if they shut off a connection and routed all port 80 requests to a web page explaining to the consumer that they have been identified as belonging to a bot-net and are harming others through their continued inaction. Give them links to solutions. Allow some proxied access to Google maps to find Geek Squad or some shit. Upsell a service to come out to their home and fix the computer.
This is already being done and is getting more widespread, and when it's done well it's great, but the last time I helped someone fix up a spambot I then called the ISP and asked to be unblocked and they completely denied they were blocking, even though it was plainly obvious that it was happening.
There are a few blacklists around for infected PC's and more and more banks are refusing to let you log in if malicious activity has been detected coming from your IP address.
Until the botnet's become completely P
Re: (Score:2)
Until the botnet's become completely P2P with no central C&C server(s), detecting C&C traffic is easy enough that all ISP's should be doing it.
They will the moment enough ISPs do it that it hurts them. The concepts and technology have been around for almost a decade.
Re: (Score:2)
Residential ISPs would be doing a service if they shut off a connection and routed all port 80 requests to a web page explaining to the consumer that they have been identified as belonging to a bot-net and are harming others through their continued inaction. Give them links to solutions. Allow some proxied access to Google maps to find Geek Squad or some shit. Upsell a service to come out to their home and fix the computer.
I used to work for an ISP and actually proposed exactly that solution... I don't remember, maybe 8 years ago? Must've been around that.
Technology? No problem, easy to do.
Legal is the mess. Unless you've done this from the start, it means changing contracts. I could never get it pushed through because legal and marketing resisted.
That is why I think we need to make ISPs responsible - right now, their "safe" choice is always with the spammers. Making them responsible in whatever way - legal, financial or by s
Too many ISPs are in for it... (Score:1)
I wish I could say that you made that up, but alas. Other pathetic replies are
The latter ISP didn't like my bugging them too much, and in the end they firewalled my IP address in their firewall, so their customer couldn't spam me anymore.
Some ISPs just don't care. For example,
How to neutralize the botnet? (Score:1)
How to neutralize the botnet, use Ubuntu [ubuntu.com] on the desktop
Re: (Score:3)
Re: (Score:2)
The problem with Windows and Android is that software/apps are available to end users
agreed
Shut them down (Score:3)
Any machine being used for purposes outside of the intent of the owner should be shut down. Owners should be notified and given time to respond, but if they are unaware of the additional traffic their computer is spewing then they should be shut down until corrected.
Unfortunatly service providers probably don't care, they would probably rather have the $29.99/mo customer rather then shutting them down until it's fixed.
Re: (Score:2)
Re: (Score:2)
1). Gain control of botnet.
2). Look up support@ email addresses of all major ISPs.
3). Write code to lookup a user's ISP (based on IP address, whois, traceroute, etc), and return the ISP's own email address(es).
4). Push code out to botnet. Have botnet run code.
5). Order botnet to begin spamming ISPs responsible for botnet, as hard and fast as possible.
I don't get it... (Score:1)
Pornography - What's the problem with that? It's not like we don't want that, now is it?
"Illegal" pharmaceuticals - Well, the pharma industry certainly doesn't want that. After all, it could harm the sales of their harmful pharmaceuticals.
Stock scam - Huh? There's stock options that are not a scam? The whole stock marked is a scam by definition.
I have no problem with calling it spam and scams. I have a problem with there being