badger.foo writes "We've seen stories about the slow bruteforcers — we've discussed it here — and based on the data, my colleague Egil Möller was the first to suggest that since we know the attempts are coordinated, it is not too far-fetched to assume that the controlling system measures the rates of success for each of the chosen targets and allocates resources accordingly. (The probes of my systems have slowed in the last month.) If Egil's assumption is right, we are seeing the bad guys adapting. And they're avoiding OpenBSD machines." For fans of raw data, here are all the log entries (3MB) that badger.foo has collected since noticing the slow bruteforce attacks.
The obvious solution is to use public/private key authentication and disallow password logins.
This is much safer anyways, since your private key and your passphrase stays on your local machine always, so even if the server is compromised and the SSHd is bugged, no one will have immediate access to your login token.
The other solution is to use asshole seeking missiles on the botnets. Of course it would probably end up leading astray from the pricks with the checklist that always responds to peoples' solutions to spam.
by Anonymous Coward
on Monday December 22 2008, @02:58AM (#26197857)
You can still use the standard port, just install a simple defense system in iptables.
iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 99 -j DROP iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set
Now any particular IP address can only open a tcp connection to your ssh server once every 99 seconds, or longer if they keep trying during the blackout period^^
Maybe put some whitelist rules before that. Change it to 900 (fifteen minutes) if you don't log into your server that often from other addresses.
I didn't change my ssh port to something that high, but I changed it to something above 1024, and the botnet attacks have stopped, so you can add my anecdote to yours...
This is all simply because they don't need to bother looking for you, there are plenty of others on 22. As well, if you know enough to change the port, you probably are resistant to brute-force attacks.
In short, you are not the intended target anyways.
Now, if everyone started doing it, they would do what they needed to hit the low-hanging-fruit again. Once again - you are not the intended target.
Using a high port number is like parking in an empty part of a parking lot. It adds a small amount of inconvenience, reduces the likelihood of an incident, but fails to mitigate any of the consequences of an incident that does happen.
Since changing my SSH ports to something really high (above 50000), I have had exactly *zero* failed password attempts in the last 14 months.
That means that you haven't been attacked by a portscanning bot yet. I don't know that any exist yet, so you would be safe until they do. Really, wouldn't any port other than 22 that isn't used for anything else bots attack work?
Actually no. Most port scanners (read: almost all of them) only scan up to 1024. This is because that is where 99% of vulnerable machines open their ports. The only people that scan higher than that are the ones with a list of specific targets. If you are on that list, chances are you are going to see some incoming traffic no matter what you do.
I use BlockHosts [aczoom.com] and even though I still get hit, the amount of tries is 4-5 and the IP address will be blocked for 12 hours. Very seldom I see them hit me a second time. The advantage is that it is live and although initially looks in the log files it does not depend on them.
Entry currently in my hosts.allow, which is after some IP addresses I specifically always allow.
Most vulnerabilities with simple contact forms are email header injections. A malicious user will inject newlines into something like the "Subject" and then rewrite the headers and the email message itself. The headers/message the programmer intended to be inserted into the email will still be added on at the end of the message, but it's usually in the body by that time and can be hidden. Google has more info, but I can't get much to pull up right now.
Unfortunately, this is often too hard for your users.
What's really scary is that I'm starting to see really good passwords coming through (I modified the OpenSSH source to log the password sent for one of my jails.) I'm seeing passwords that have no particular rhyme or reason (in other words, they're either random or are generated through an obfuscated scheme.) I have to assume that they're passwords which were harvested in some way. It really makes me wonder where they're getting them.
It really makes me wonder where they're getting them.
One way to get them is to set up some sort of site that logically requires you to log in, let it become popular, then harvest the password file and use it in your attacks. Be sure to make the site geeky, though, to get good passwords and give it an attention-getting name. Something like "Slashdot."
That's absurd. The system is a honeypot. It cannot be accessed directly--you must log in to the host system to do gain access. No accounts are allowed through SSH to the jailed host, but passwords are logged for the sole purpose of gathering information on the botnet. The jail has no users other than root, and root is not permitted to log in through SSH. Hell, strictly speaking, root isn't allowed to log in at all--the jail mechanism doesn't count as a login.
It's about as secure as you can make a system which listens on TCP ports.
I swear, some of the most adaptive, sophisticated, and advanced techniques seem to be coming out of the Botnets.
It's my (admittedly probably crazy) idea that we WILL begin to see "emergent intelligence properties" out of some sophisticated system at some point in time, whether it be Google, an AGI lab, or a botnet. I shudder at the prospect of our first AI of power will have grown from one of these botnets.
NOTE: I'm not saying this will happen tomorrow, but extrapolating the current state of botnets relative to the current state of other systems leads me to believe, on a relative basis, systems may be complex relative to one another as they are today. If that is the case, well... that would be bad.
My understanding of botnets is that all their activity is centrally coordinated: the bots sit in an IRC channel waiting for orders and do what they're ordered to do. It doesn't seem likely to me that the listeners are doing anything very sophisticated here. As it's always been with brute-force attacks, There are lots of target hosts, lots of usernames and passwords to try, and lots of bots to try them. Assuming every attempt gives you about the same odds of success it doesn't matter much what order you try them in. So some people changed the order, and changed the way they divide up work, to avoid detection.
I won't deny that it's a clever adaption, or claim I definitely would have thought of it in their situation. But as far as adaptivity goes, the major tactical advance came from an explicit change in behavior by the botnet masters themselves. The parts of the software that might be adaptive, slowing down attempts on hosts where they are repeatedly unsuccessful and avoiding OpenBSD boxes, were probably specifically programmed to adapt in these ways. They're no more advanced than, say, TCP flow control behavior, or P2P programs.
My understanding of botnets is that all their activity is centrally coordinated: the bots sit in an IRC channel waiting for orders and do what they're ordered to do.
For comment spam it's more sophisticated than that: I monitor all attempts at adding comment spam to
several sites I run. One site is interesting because it requires several distinct requests in order to post a
message (and you have to visit each of those pages in turn in order to be successful at posting). The bots
can perform these steps -- I watched as the controller in the Ukraine first worked it out manually -- but they do it from random IP addresses in turn. However, the cookie that I send
in the first request is faithfully sent back by the other IP addresses.
These are not human attacks using something like Tor - far too quick for that.
So the bots communicate that cookie back to their "master" between each request, and that happens
in sub-second times.
The idea that a system like SkyNet would evolve out of a system designed to get us to buy discount v1agra and c1al1s bodes poorly for our future prospects against the coming robotic onslaught. Truly our proud, erect soldiers will be no match.
In principle, OpenBSD is no more or less vulnerable to weak username/password pairs than is any other OS. I suspect that, on average, OpenBSD machines are more likely to be set up for keypair auth; but any that aren't are in the same boat as everybody else(since, after all, username/password guesses aren't OS weaknesses, OSes are supposed to respond to correct username/password pairs.)
There is still reason to avoid them, though. Because OpenBSD is something of a niche system, you can make plausible inferences about the systems running it. Specifically, they most likely have admins who are interested in security and are watching activity fairly closely, and are more likely than average to do something about it. If you are doing something illegal, why attract such attention?
Their code review seems to concentrate on external attacks. They have expressly derided mandatory access controls, for example, on the grounds that you've got to trust your users or you're already lost. So, OpenBSD is actually more likely to be vulnerable to such attacks than an OS with weaker reviews but superior access controls, such as Linux with the RBACS or GrSecurity patches in place. Thus, if anyone is using OpenBSD, they'd damn well better be using strong authentication.
(OpenBSD has the best strong authentication of any OS on the planet, and the best security from external attacks of any OS on the planet, but cliques of any kind are notoriously blind to any problem outside of their special interest and OpenBSD is no exception. Which is why they caught a rollicking from Slashdot when it came to failing to patch their PRNG after defects were found in the *BSD family of PRNGs. It's why you should never, ever trust a group - however good - to be good at everything.)
by Anonymous Coward
on Sunday December 21 2008, @10:47PM (#26196665)
Bots were knocking on my door to the point I was worry about performance degradation. I know there are many ways to defeat these but here was my solution.
In hosts.deny ----------------- sshd:ALL EXCEPT/var/www/html/allow.txt -----------------
Create a simple cgi-script (password protected and accessed via secret random url) that writes your browser IP address to the allow.txt file and all those nasty botnets and go to hell.
These people are a tremendous illness upon the world. If it were legal, I would contribute to a bounty on the lives of the people responsible for this stuff. These people make me beyond sick. I have said it many times and sometimes I actually mean it -- if I knew of someone involved in this sort of business close by, I would appear on the news shortly thereafter. And I am pretty sure I am not alone in this sentiment.
Nobody keeps you from putting a bounty on the head of a spammer and botnetter. You can't ask for them being killed, but you can without a problem issue a bounty on them, payable to whoever tracks down a botnetter and drags him to court.
Their attacks will make the internet stronger by helping it evolve defenses it would not otherwise have. Some steady pressure spurs evolution. So long as it does not kill the host we should smile and welcome the challenge.
Wow, you just made me completly re-evalute how I thought about dealing with botnets. I've long thought of internet security as something very, very analogous to meatspace problems like insects, virii, or bacteria. Every time we try to squish the buggers out, we just make them stronger.
Your post made me think about how we over-use antibiotics in meatspace and how it applies to security. Things like graylisting spam, or random port assignments will are only stop-gap until the fuckers up the ante and just portscan your ass to find SSH.
Already I'm noticing graylisting is becoming almost useless. Everybody has started to deal with it, from registration emails to spam. A year ago, what used to take five minutes thanks to graylisting now takes 30 seconds (the bottom end of my retry limit). The people who boast about using random ports are only going to make the problem worse because soon everybody will be using random ports.
That said, I think in the end we will be forced to have our cake and eat it too. We do need to lock any asshole we catch up and toss the key. Make no mistake, we cannot send signals that this sort of behavour is tolerated in modern society. But at the same time, we need to not pretend that locking them up will make the illness go away. All we can do is beef up our immune systems and lock the assholes we manage catch up for a long, long, long, long time.
How would the botnet know they are attacking an OpenBSD box (vs Linux or something else)?
Is there some sort of server signature involved (that I'm not aware of)
My (Linux) ssh server at home just responds with a password prompt. I don't see any easy way to determine the underlying system from that.
BTW. On my server at home I use Hashlimits to limit each IP to 1 attempt per minute (maximum). This has taken the attacks down from hundreds / thousands per day ( The most attacks I ever got was ~7,000 from one IP) to about 3 to 6. This is typically, 1 attempt each, they then get blocked, and then they go away.
You can infer a lot about the OS from the way it crafts it's packets. Nmap does a rather good job with host identification. I don't know all the things it does, but more or less it's a case of "Find an open port, send is various kinds of packets, see how it reacts."
Probably it is just avoiding secure hosts, like yours. OpenBSD hosts tend to be secure because it is selected by people who put security before other requirements.
Don't forget about the economies surrounding botnets. There are two sides, those that profit from the botnets (the operators), and those that profit fighting the botnets (the fighters). Additionally, there are those that profit from providing botnet remedial "solutions" whilst not being in either of the primary (operator or fighter) categories. If botnets ceased to exist, there would be a *lot* more lost on the fighter and solution side than on the operator side. So... like SPAM, this raises the question of just who actually benefits the most from botnet existing.
As someone being in the latter group (to avoid confusion, the ones fighting them), yes, we make some money fighting that crap. Looking at the money being made on the other side, some are already wondering why we stay here.
We stay on this side because we (well, most of us) hate botnets. Most people I met at various conventions and meets are somewhere between zealous, fanatic or outright crazy, but generally see the money as some sort of pleasant side effect.
Believe me one thing: We know we cannot fight it, we know it's almost impossible to track them down and we know how it works. If we were in it for the money, we'd switch sides before you're done reinstalling your system. There's about ten times the money to be gained on the dark side.
Conservatively estimating, that is.
If spam and botnets ceased to exist overnight, we'd gladly return to more interesting and maybe also more profitable professions. Most of us are network experts. Some know more about the way Windows works on the "inside" than most people at MS. And if everything fails, we could actually maybe even create a copy protection system that is hard enough to break that nobody would willingly do it (after all, we spend a good deal of our time with disassembly). Do you really think that any of the (good) spam and botnet fighters would have a hard time finding a "honest" job that maybe even paid better than this?
I could enjoy having a life again, instead of this sorta permanent on-call duty. Again, no christmas for me, because yes, this is one of the hottest times of the year (many people at home, many new computers needing infections, so many new opportunities for botherders...). I would also prefer to create something, like some new software to make people happy or more productive, instead of poking at malware and trying to find a sensible way to detect it. It's not really good for your ego if your product is seen as the necessary evil that steals valuable computer time instead of something that people actually want to have.
Thanks for hearing out the rant. Now we're back to your scheduled program.
I'd recommend not connecting it to any network and not installing any software if he wants the machine to be secure.
Snideness aside, yes, you can get Windows to a sensible, workable security level. Not 100%, but nothing is 100% secure. Even Raid6 systems have been seen blowing up, and even the tightest security has its cracks.
IT security is by definition the minimum of the system's capabilities and the administrator's capabilities. Not an average thereof, but the minimum of both. You can have the most secure system in the world and some stupid admin can f..k up its security beyond repair (provided it's somehow connected to the outside world). Likewise, you can be the absolute guru of computer security, you cannot secure an inherently insecure system.
Therefore just saying "use $OS and you're safe" is a dangerous misconception. No system is inherently secure, it also depends on its administrator.
You have to understand that most threats are tailored for the Windows platform, simply because it offers the largest target being the most widely used. Since all Windows machines are also mostly alike when it comes to their software makeup since critical networking programs like webbrowser or email client are part of the package, you have a fair lot of standard targets. You can be certain that a Windows installation has IE installed. Why? Because it's certainly installed in the installation routine and cannot be completely removed. Linux is much more modular and you cannot simply assume a certain browser, a certain mail client or even a certain editor being installed. This offers a much smaller target.
But still a Windows machine can be secured to sensible levels. First, put a router in front of it so no direct connection can be made to the machine from the internet. This pretty much eliminates most RPC based attacks (you might remember the worm craze of a few years ago. They're still there. There are still infected machines blasting into the internet and few providers filter that crap). Never connect a Windows machine directly to the internet. I made an experiment recently, the lifetime of a clean Windows XP SP1 machine directly connected to the net is less than one minute. Yes, I'm aware that SP1 is a bit dated, but most people got SP1 on their install CD and they usually don't know how to create one that contains the latest patches. Often, reinstalling the system only builds a new home for their problems.
So, make sure you install all critical patches before you connect the machine to the net. The Service Packs can now be downloaded and stored locally, I do highly recommend doing that. USB sticks are cheap and a quite useful tool for storing them.
Next, get an alternative browser. IE is the most attacked browser today. And with the growing market share of Firefox it became a target, too. Opera looks ok so far, at least most iframe drive by attacks don't care about it yet. This may change, though. For now, Opera would be it. Not because it's better or safer, but simply because it has a low enough market share to be off the radar of attackers.
An alternative mail client is the next thing you need. It should not be able to process HTML mails (because most mail clients that do use the engine of the IE, do the math). It has to show extensions of attachments, and it should, if possible, disable direct execution of executable files from attachments. Funny enough, the older the mail client the better, since most of the times this means fewer features that can get into the way of security. Just make sure there are no known bugs. Again, the less mainstream the client is, the better.
If you really, really have to use instant messaging, again, don't use the normal IM clients. Same reason, they're main targets for attackers. Use alternative clients, preferable with a low market share. As a beneficial side effect, they often also enable you to bundle more than one service.
An antivirus toolkit. Yes, I know, many people here don't think too highly of them, and yes, they cannot
Are you implying that the botnets operators are in bed with their adversaries? If so, why not spell it out? And who are these fighters exactly? Anti-virus firms, sysadmins, politicians?
What you write sounds a bit like the broken window fallacy. Specifically, if there were no botnets those who are fighting them could use their time to pursue other goals most likely creating value elsewhere. Meanwhile, there would be no damage done by botnets, resulting in a net plus.
Here. I admit. I'm part of the so-called "whitehat guys" who profit from stoping the botnets. But since I have no ethics or morals, I dont really stop them, I just give them kickbacks to make it look like I'm stopping them.
Now excuse me while I go get a back massage on from the hot ladies serving me martinis on the beach in Tahiti. Me and my fellow whitehats are making millions off you poor fools. If you only knew!
(adjust your tinfoil good sir, you are blocking the wrong signals)
I do computer and network security for a university.
This distributed SSH password guessing is not a new tactic. We have seen and tracked this tactic off and on for over a year.
If this tactic was a game changer, we would have seen it ramp up before now. It would occur all the time. But it doesn't. It only seems to occur during holidays.
At it's heart, this tactic is not any more effective than non-distributed password guessing. Either way, the attacker has to enumerate the same number of guesses before finding a hit. If a machine is vulnerable, it will be successfully attacked by either approach to password guessing. If it is not vulnerable, neither approach will work.
Modern hacking is a economic activity. It must balance risk and reward. This attack doesn't offer any more reward than conventional password guessing. It's main feature is to try to change the risk side of the equation.
Conventional SSH password guessing is noisy. One machine will portscan for TCP/22. Then it rapidly guesses passwords against everything that responds. That one machine is usually lost to the attacker. Automated defense systems block it. Also, defenders report it to the owning ISP. The only way this works for the attacker is if he can harvest more that he loses.
The distributed guessing attack is also noisy, but in a different way. Currently, we see the attacker start by sacrificing 1 computer to do a TCP/22 portscan. At this point, he has already risked as much as a conventional password guessing attack. Then he feeds the results to a bunch of bots. Each bot then takes turns guessing passwords. Each bot guesses 1 password at a time. However, each bot guesses against multiple SSH servers at the same time.
This attack is inherently more risky that conventional password guessing. The attacker exposes many of his computers. If we can detect and respond, this attack is not as cost effective as conventional password guessing.
It is easy for my university to detect and respond to these attacks. We detect it in three different ways. 1) Each attacker has a distinctive network behavior pattern. We can automate detection by looking at aggregate Cisco netflow data. 2) It is trivial to pick off this attack using a SSH honeypot. 3) We use a network visualization tool to watch aggregate SSH activity. This password guessing is obvious on our visualization tool.
Once we have detected the attackers, we respond to them in the normal way. We block them. We inform our peer institutions and the authorities. We inform the owning ISP.
The main difference in this situation is that detection and response is easy if you have access to aggregate traffic or multiple SSH servers. It is difficult if you only manage 1 SSH server.
I don't expect this form of attack to last much longer. I am sure that everybody else is adapting. Once the defenders adapt, this tactic is too expensive to be used.
We like our visualizers. Our router guy has created 2. They are both GPL. We use them every day. I suppose you could consider them late Beta.
The IPVisualizer: https://it.wiki.usu.edu/IPVisualizer [usu.edu] gives us a real-time overview of our entire IP address space. It is particularly good for revealing reconnaissance attacks.
The Organic IP Visualizer: https://it.wiki.usu.edu/OIP [usu.edu] provides a focused view of the activity of a subset of our network.
ipchains is Linux's 2.2 kernel firewall protection. BSD uses 'IPF'.
No matter what system you're using, a closed port is a closed port.
I think the main selling point between the two would be that IPF is slightly better performing and that iptables has quite a few addons that make for niceness if you know about and how to use them.
OpenBSD doesn't use ipchains -- it uses pf [openbsd.org], which many people -- myself included -- like a lot. OpenBSD is secure and easy to get routing.
I'd give the beginners using Ubuntu a break. They're overwhelming sometimes, but the community growing is a good thing. I'm sure someone I've introduced to Linux has needed online help (badly!), but another friend I introduced to Linux really dug in and we're now both better developers because of it. You just don't know.
Solution: Public Key Auth (Score:5, Interesting)
The obvious solution is to use public/private key authentication and disallow password logins.
This is much safer anyways, since your private key and your passphrase stays on your local machine always, so even if the server is compromised and the SSHd is bugged, no one will have immediate access to your login token.
Re:Solution: Public Key Auth (Score:5, Funny)
The other solution is to use asshole seeking missiles on the botnets. Of course it would probably end up leading astray from the pricks with the checklist that always responds to peoples' solutions to spam.
Parent
Re:Solution: Public Key Auth (Score:5, Funny)
That wont work and Ill tell you why:
1)Those launching the missiles also have assholes.
2)Knives would be funner
3)Barney sucks
4)People like checklists
Parent
Re:Solution: Public Key Auth (Score:5, Informative)
Another idea, is change the port SSH uses to some a random high number, that will kill off most of them also.
Parent
Re:Solution: Public Key Auth (Score:4, Interesting)
You can still use the standard port, just install a simple defense system in iptables.
iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 99 -j DROP
iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set
Now any particular IP address can only open a tcp connection to your ssh server once every 99 seconds, or longer if they keep trying during the blackout period^^
Maybe put some whitelist rules before that. Change it to 900 (fifteen minutes) if you don't log into your server that often from other addresses.
Parent
Re:Solution: Public Key Auth (Score:5, Interesting)
Since changing my SSH ports to something really high (above 50000), I have had exactly *zero* failed password attempts in the last 14 months.
I know the plural of 'anecdote' is not 'data', but this is the case across *all* my servers.
Parent
Re:Solution: Public Key Auth (Score:5, Interesting)
I didn't change my ssh port to something that high, but I changed it to something above 1024, and the botnet attacks have stopped, so you can add my anecdote to yours...
Parent
Re:Solution: Public Key Auth (Score:5, Funny)
Parent
Re:Solution: Public Key Auth (Score:5, Informative)
This is all simply because they don't need to bother looking for you, there are plenty of others on 22. As well, if you know enough to change the port, you probably are resistant to brute-force attacks.
In short, you are not the intended target anyways.
Now, if everyone started doing it, they would do what they needed to hit the low-hanging-fruit again. Once again - you are not the intended target.
Parent
Re:Solution: Public Key Auth (Score:4, Funny)
Using a high port number is like parking in an empty part of a parking lot. It adds a small amount of inconvenience, reduces the likelihood of an incident, but fails to mitigate any of the consequences of an incident that does happen.
Parent
Re:Solution: Public Key Auth (Score:5, Interesting)
That means that you haven't been attacked by a portscanning bot yet.
I don't know that any exist yet, so you would be safe until they do. Really, wouldn't any port other than 22 that isn't used for anything else bots attack work?
Parent
Re:Solution: Public Key Auth (Score:5, Funny)
That means that you haven't been attacked by a portscanning bot yet.
That or they got the password right...
Parent
Re:Solution: Public Key Auth (Score:4, Funny)
Parent
Re:Solution: Public Key Auth (Score:5, Interesting)
Parent
Re:Solution: Public Key Auth (Score:5, Interesting)
I use BlockHosts [aczoom.com] and even though I still get hit, the amount of tries is 4-5 and the IP address will be blocked for 12 hours.
Very seldom I see them hit me a second time.
The advantage is that it is live and although initially looks in the log files it does not depend on them.
Entry currently in my hosts.allow, which is after some IP addresses I specifically always allow.
#---- BlockHosts Additions
ALL: 216.146.46.29 : deny
ALL: 65.111.164.53 : deny
ALL: 77.48.41.174 : deny
#bh: ip: 122.166.17.253 : 1 : 2008-12-22 09:48:44 CET
#bh: ip: 216.146.46.29 : 5 : 2008-12-22 09:43:41 CET
#bh: ip: 65.111.164.53 : 4 : 2008-12-22 02:02:53 CET
#bh: ip: 77.48.41.174 : 5 : 2008-12-22 02:02:49 CET
#bh: logfile: /var/log/messages
#bh: offset: 5717251
#bh: first line:Dec 20 19:15:07 pasta syslog-ng[2148]: new configuration initialized
#---- BlockHosts Additions /usr/bin/blockhosts.py & : allow
sshd : ALL: spawn
Parent
Re:Solution: Public Key Auth (Score:5, Informative)
Most vulnerabilities with simple contact forms are email header injections. A malicious user will inject newlines into something like the "Subject" and then rewrite the headers and the email message itself. The headers/message the programmer intended to be inserted into the email will still be added on at the end of the message, but it's usually in the body by that time and can be hidden. Google has more info, but I can't get much to pull up right now.
---John Holmes...
Parent
Re:Solution: Public Key Auth (Score:5, Interesting)
Unfortunately, this is often too hard for your users.
What's really scary is that I'm starting to see really good passwords coming through (I modified the OpenSSH source to log the password sent for one of my jails.) I'm seeing passwords that have no particular rhyme or reason (in other words, they're either random or are generated through an obfuscated scheme.) I have to assume that they're passwords which were harvested in some way. It really makes me wonder where they're getting them.
Parent
Re:Solution: Public Key Auth (Score:5, Funny)
One way to get them is to set up some sort of site that logically requires you to log in, let it become popular, then harvest the password file and use it in your attacks. Be sure to make the site geeky, though, to get good passwords and give it an attention-getting name. Something like "Slashdot."
Parent
Re:Solution: Public Key Auth (Score:5, Funny)
Unfortunately, this is often too hard for your users.
We need to grow smarter users.
Parent
Re:Solution: Public Key Auth (Score:4, Informative)
That's absurd. The system is a honeypot. It cannot be accessed directly--you must log in to the host system to do gain access. No accounts are allowed through SSH to the jailed host, but passwords are logged for the sole purpose of gathering information on the botnet. The jail has no users other than root, and root is not permitted to log in through SSH. Hell, strictly speaking, root isn't allowed to log in at all--the jail mechanism doesn't count as a login.
It's about as secure as you can make a system which listens on TCP ports.
Parent
Re:Solution: Public Key Auth (Score:5, Funny)
You seem to be a chatbot. I'm not sure how you got onto slashdot, but welcome!
Parent
AI (Score:5, Interesting)
It's my (admittedly probably crazy) idea that we WILL begin to see "emergent intelligence properties" out of some sophisticated system at some point in time, whether it be Google, an AGI lab, or a botnet. I shudder at the prospect of our first AI of power will have grown from one of these botnets.
NOTE: I'm not saying this will happen tomorrow, but extrapolating the current state of botnets relative to the current state of other systems leads me to believe, on a relative basis, systems may be complex relative to one another as they are today. If that is the case, well... that would be bad.
Re:AI (Score:5, Insightful)
My understanding of botnets is that all their activity is centrally coordinated: the bots sit in an IRC channel waiting for orders and do what they're ordered to do. It doesn't seem likely to me that the listeners are doing anything very sophisticated here. As it's always been with brute-force attacks, There are lots of target hosts, lots of usernames and passwords to try, and lots of bots to try them. Assuming every attempt gives you about the same odds of success it doesn't matter much what order you try them in. So some people changed the order, and changed the way they divide up work, to avoid detection.
I won't deny that it's a clever adaption, or claim I definitely would have thought of it in their situation. But as far as adaptivity goes, the major tactical advance came from an explicit change in behavior by the botnet masters themselves. The parts of the software that might be adaptive, slowing down attempts on hosts where they are repeatedly unsuccessful and avoiding OpenBSD boxes, were probably specifically programmed to adapt in these ways. They're no more advanced than, say, TCP flow control behavior, or P2P programs.
Parent
Re:AI (Score:4, Interesting)
My understanding of botnets is that all their activity is centrally coordinated: the bots sit in an IRC channel waiting for orders and do what they're ordered to do.
For comment spam it's more sophisticated than that: I monitor all attempts at adding comment spam to several sites I run. One site is interesting because it requires several distinct requests in order to post a message (and you have to visit each of those pages in turn in order to be successful at posting). The bots can perform these steps -- I watched as the controller in the Ukraine first worked it out manually -- but they do it from random IP addresses in turn. However, the cookie that I send in the first request is faithfully sent back by the other IP addresses.
These are not human attacks using something like Tor - far too quick for that.
So the bots communicate that cookie back to their "master" between each request, and that happens in sub-second times.
Rich.
Parent
Re:AI (Score:4, Insightful)
The idea that a system like SkyNet would evolve out of a system designed to get us to buy discount v1agra and c1al1s bodes poorly for our future prospects against the coming robotic onslaught. Truly our proud, erect soldiers will be no match.
Parent
Re:AI (Score:5, Funny)
It's like saying to a robot "Can you watch this lamb in the oven?" and they do. They bloody watch it burning for three hours.
Ahh thank you Red Dwarf, even historically, you were so accurate of the future...
Parent
OpenBSD hosts make stupid targets... (Score:5, Interesting)
There is still reason to avoid them, though. Because OpenBSD is something of a niche system, you can make plausible inferences about the systems running it. Specifically, they most likely have admins who are interested in security and are watching activity fairly closely, and are more likely than average to do something about it. If you are doing something illegal, why attract such attention?
Re:OpenBSD hosts make stupid targets... (Score:4, Informative)
Their code review seems to concentrate on external attacks. They have expressly derided mandatory access controls, for example, on the grounds that you've got to trust your users or you're already lost. So, OpenBSD is actually more likely to be vulnerable to such attacks than an OS with weaker reviews but superior access controls, such as Linux with the RBACS or GrSecurity patches in place. Thus, if anyone is using OpenBSD, they'd damn well better be using strong authentication.
(OpenBSD has the best strong authentication of any OS on the planet, and the best security from external attacks of any OS on the planet, but cliques of any kind are notoriously blind to any problem outside of their special interest and OpenBSD is no exception. Which is why they caught a rollicking from Slashdot when it came to failing to patch their PRNG after defects were found in the *BSD family of PRNGs. It's why you should never, ever trust a group - however good - to be good at everything.)
Parent
Re:OpenBSD hosts make stupid targets... (Score:5, Funny)
Yes
You are obviously a Windows user.
Parent
Botnet solution (Score:5, Interesting)
Bots were knocking on my door to the point I was worry about performance degradation. I know there are many ways to defeat these but here was my solution.
In hosts.deny /var/www/html/allow.txt
-----------------
sshd:ALL EXCEPT
-----------------
Create a simple cgi-script (password protected and accessed via secret random url) that writes your browser IP address to the allow.txt file and all those nasty botnets and go to hell.
I want to see a death bounty for these people (Score:5, Interesting)
These people are a tremendous illness upon the world. If it were legal, I would contribute to a bounty on the lives of the people responsible for this stuff. These people make me beyond sick. I have said it many times and sometimes I actually mean it -- if I knew of someone involved in this sort of business close by, I would appear on the news shortly thereafter. And I am pretty sure I am not alone in this sentiment.
Re:I want to see a death bounty for these people (Score:5, Interesting)
Nobody keeps you from putting a bounty on the head of a spammer and botnetter. You can't ask for them being killed, but you can without a problem issue a bounty on them, payable to whoever tracks down a botnetter and drags him to court.
Parent
Re:I want to see a death bounty for these people (Score:4, Interesting)
Their attacks will make the internet stronger by helping it evolve defenses it would not otherwise have.
Some steady pressure spurs evolution. So long as it does not kill the host we should smile and welcome the challenge.
Parent
Re:I want to see a death bounty for these people (Score:4, Insightful)
Wow, you just made me completly re-evalute how I thought about dealing with botnets. I've long thought of internet security as something very, very analogous to meatspace problems like insects, virii, or bacteria. Every time we try to squish the buggers out, we just make them stronger.
Your post made me think about how we over-use antibiotics in meatspace and how it applies to security. Things like graylisting spam, or random port assignments will are only stop-gap until the fuckers up the ante and just portscan your ass to find SSH.
Already I'm noticing graylisting is becoming almost useless. Everybody has started to deal with it, from registration emails to spam. A year ago, what used to take five minutes thanks to graylisting now takes 30 seconds (the bottom end of my retry limit). The people who boast about using random ports are only going to make the problem worse because soon everybody will be using random ports.
That said, I think in the end we will be forced to have our cake and eat it too. We do need to lock any asshole we catch up and toss the key. Make no mistake, we cannot send signals that this sort of behavour is tolerated in modern society. But at the same time, we need to not pretend that locking them up will make the illness go away. All we can do is beef up our immune systems and lock the assholes we manage catch up for a long, long, long, long time.
Parent
Next Slashdot headlines... (Score:5, Funny)
If only it were so simple (Score:5, Funny)
At the risk of being unpopular ..... Just turn off the Internet already!
How do the botnets know it's OpenBSD? (Score:4, Interesting)
How would the botnet know they are attacking an OpenBSD box (vs Linux or something else)?
Is there some sort of server signature involved (that I'm not aware of)
My (Linux) ssh server at home just responds with a password prompt. I don't see any easy way to determine the underlying system from that.
BTW. On my server at home I use Hashlimits to limit each IP to 1 attempt per minute (maximum). This has taken the attacks down from hundreds / thousands per day ( The most attacks I ever got was ~7,000 from one IP) to about 3 to 6. This is typically, 1 attempt each, they then get blocked, and then they go away.
Re:How do the botnets know it's OpenBSD? (Score:5, Informative)
You can infer a lot about the OS from the way it crafts it's packets. Nmap does a rather good job with host identification. I don't know all the things it does, but more or less it's a case of "Find an open port, send is various kinds of packets, see how it reacts."
Parent
Re:How do the botnets know it's OpenBSD? (Score:4, Funny)
You can infer a lot about the OS from the way it crafts it's packets.
Similarly, you can learn a lot about a person from the way it crafts it is sentences.
Parent
Re:How do the botnets know it's OpenBSD? (Score:5, Insightful)
Parent
Re:How do the botnets know it's OpenBSD? (Score:5, Informative)
sudo nmap -O host
will usually do the trick.
Parent
Economics (Score:5, Interesting)
Don't forget about the economies surrounding botnets. There are two sides, those that profit from the botnets (the operators), and those that profit fighting the botnets (the fighters). Additionally, there are those that profit from providing botnet remedial "solutions" whilst not being in either of the primary (operator or fighter) categories. If botnets ceased to exist, there would be a *lot* more lost on the fighter and solution side than on the operator side. So... like SPAM, this raises the question of just who actually benefits the most from botnet existing.
Re:Economics (Score:5, Interesting)
As someone being in the latter group (to avoid confusion, the ones fighting them), yes, we make some money fighting that crap. Looking at the money being made on the other side, some are already wondering why we stay here.
We stay on this side because we (well, most of us) hate botnets. Most people I met at various conventions and meets are somewhere between zealous, fanatic or outright crazy, but generally see the money as some sort of pleasant side effect.
Believe me one thing: We know we cannot fight it, we know it's almost impossible to track them down and we know how it works. If we were in it for the money, we'd switch sides before you're done reinstalling your system. There's about ten times the money to be gained on the dark side.
Conservatively estimating, that is.
If spam and botnets ceased to exist overnight, we'd gladly return to more interesting and maybe also more profitable professions. Most of us are network experts. Some know more about the way Windows works on the "inside" than most people at MS. And if everything fails, we could actually maybe even create a copy protection system that is hard enough to break that nobody would willingly do it (after all, we spend a good deal of our time with disassembly). Do you really think that any of the (good) spam and botnet fighters would have a hard time finding a "honest" job that maybe even paid better than this?
I could enjoy having a life again, instead of this sorta permanent on-call duty. Again, no christmas for me, because yes, this is one of the hottest times of the year (many people at home, many new computers needing infections, so many new opportunities for botherders...). I would also prefer to create something, like some new software to make people happy or more productive, instead of poking at malware and trying to find a sensible way to detect it. It's not really good for your ego if your product is seen as the necessary evil that steals valuable computer time instead of something that people actually want to have.
Thanks for hearing out the rant. Now we're back to your scheduled program.
Parent
Re:Economics (Score:5, Informative)
I'd recommend not connecting it to any network and not installing any software if he wants the machine to be secure.
Snideness aside, yes, you can get Windows to a sensible, workable security level. Not 100%, but nothing is 100% secure. Even Raid6 systems have been seen blowing up, and even the tightest security has its cracks.
IT security is by definition the minimum of the system's capabilities and the administrator's capabilities. Not an average thereof, but the minimum of both. You can have the most secure system in the world and some stupid admin can f..k up its security beyond repair (provided it's somehow connected to the outside world). Likewise, you can be the absolute guru of computer security, you cannot secure an inherently insecure system.
Therefore just saying "use $OS and you're safe" is a dangerous misconception. No system is inherently secure, it also depends on its administrator.
You have to understand that most threats are tailored for the Windows platform, simply because it offers the largest target being the most widely used. Since all Windows machines are also mostly alike when it comes to their software makeup since critical networking programs like webbrowser or email client are part of the package, you have a fair lot of standard targets. You can be certain that a Windows installation has IE installed. Why? Because it's certainly installed in the installation routine and cannot be completely removed. Linux is much more modular and you cannot simply assume a certain browser, a certain mail client or even a certain editor being installed. This offers a much smaller target.
But still a Windows machine can be secured to sensible levels. First, put a router in front of it so no direct connection can be made to the machine from the internet. This pretty much eliminates most RPC based attacks (you might remember the worm craze of a few years ago. They're still there. There are still infected machines blasting into the internet and few providers filter that crap). Never connect a Windows machine directly to the internet. I made an experiment recently, the lifetime of a clean Windows XP SP1 machine directly connected to the net is less than one minute. Yes, I'm aware that SP1 is a bit dated, but most people got SP1 on their install CD and they usually don't know how to create one that contains the latest patches. Often, reinstalling the system only builds a new home for their problems.
So, make sure you install all critical patches before you connect the machine to the net. The Service Packs can now be downloaded and stored locally, I do highly recommend doing that. USB sticks are cheap and a quite useful tool for storing them.
Next, get an alternative browser. IE is the most attacked browser today. And with the growing market share of Firefox it became a target, too. Opera looks ok so far, at least most iframe drive by attacks don't care about it yet. This may change, though. For now, Opera would be it. Not because it's better or safer, but simply because it has a low enough market share to be off the radar of attackers.
An alternative mail client is the next thing you need. It should not be able to process HTML mails (because most mail clients that do use the engine of the IE, do the math). It has to show extensions of attachments, and it should, if possible, disable direct execution of executable files from attachments. Funny enough, the older the mail client the better, since most of the times this means fewer features that can get into the way of security. Just make sure there are no known bugs. Again, the less mainstream the client is, the better.
If you really, really have to use instant messaging, again, don't use the normal IM clients. Same reason, they're main targets for attackers. Use alternative clients, preferable with a low market share. As a beneficial side effect, they often also enable you to bundle more than one service.
An antivirus toolkit. Yes, I know, many people here don't think too highly of them, and yes, they cannot
Parent
Re:Economics (Score:5, Insightful)
Are you implying that the botnets operators are in bed with their adversaries? If so, why not spell it out? And who are these fighters exactly? Anti-virus firms, sysadmins, politicians?
What you write sounds a bit like the broken window fallacy. Specifically, if there were no botnets those who are fighting them could use their time to pursue other goals most likely creating value elsewhere. Meanwhile, there would be no damage done by botnets, resulting in a net plus.
Parent
Oh great (Score:5, Insightful)
Here. I admit. I'm part of the so-called "whitehat guys" who profit from stoping the botnets. But since I have no ethics or morals, I dont really stop them, I just give them kickbacks to make it look like I'm stopping them.
Now excuse me while I go get a back massage on from the hot ladies serving me martinis on the beach in Tahiti. Me and my fellow whitehats are making millions off you poor fools. If you only knew!
(adjust your tinfoil good sir, you are blocking the wrong signals)
Parent
This is not a game changing tactic. (Score:5, Interesting)
I do computer and network security for a university.
This distributed SSH password guessing is not a new tactic. We have seen and tracked this tactic off and on for over a year.
If this tactic was a game changer, we would have seen it ramp up before now. It would occur all the time. But it doesn't. It only seems to occur during holidays.
At it's heart, this tactic is not any more effective than non-distributed password guessing. Either way, the attacker has to enumerate the same number of guesses before finding a hit. If a machine is vulnerable, it will be successfully attacked by either approach to password guessing. If it is not vulnerable, neither approach will work.
Modern hacking is a economic activity. It must balance risk and reward. This attack doesn't offer any more reward than conventional password guessing. It's main feature is to try to change the risk side of the equation.
Conventional SSH password guessing is noisy. One machine will portscan for TCP/22. Then it rapidly guesses passwords against everything that responds. That one machine is usually lost to the attacker. Automated defense systems block it. Also, defenders report it to the owning ISP. The only way this works for the attacker is if he can harvest more that he loses.
The distributed guessing attack is also noisy, but in a different way. Currently, we see the attacker start by sacrificing 1 computer to do a TCP/22 portscan. At this point, he has already risked as much as a conventional password guessing attack. Then he feeds the results to a bunch of bots. Each bot then takes turns guessing passwords. Each bot guesses 1 password at a time. However, each bot guesses against multiple SSH servers at the same time.
This attack is inherently more risky that conventional password guessing. The attacker exposes many of his computers. If we can detect and respond, this attack is not as cost effective as conventional password guessing.
It is easy for my university to detect and respond to these attacks. We detect it in three different ways.
1) Each attacker has a distinctive network behavior pattern. We can automate detection by looking at aggregate Cisco netflow data.
2) It is trivial to pick off this attack using a SSH honeypot.
3) We use a network visualization tool to watch aggregate SSH activity. This password guessing is obvious on our visualization tool.
Once we have detected the attackers, we respond to them in the normal way. We block them. We inform our peer institutions and the authorities. We inform the owning ISP.
The main difference in this situation is that detection and response is easy if you have access to aggregate traffic or multiple SSH servers. It is difficult if you only manage 1 SSH server.
I don't expect this form of attack to last much longer. I am sure that everybody else is adapting. Once the defenders adapt, this tactic is too expensive to be used.
Miles
Re:This is not a game changing tactic. (Score:5, Informative)
We like our visualizers. Our router guy has created 2. They are both GPL. We use them every day. I suppose you could consider them late Beta.
The IPVisualizer:
https://it.wiki.usu.edu/IPVisualizer [usu.edu]
gives us a real-time overview of our entire IP address space. It is particularly good for revealing reconnaissance attacks.
The Organic IP Visualizer:
https://it.wiki.usu.edu/OIP [usu.edu]
provides a focused view of the activity of a subset of our network.
Miles
Parent
Re:OpenBSD vs Linux (Score:5, Informative)
ipchains is Linux's 2.2 kernel firewall protection. BSD uses 'IPF'.
No matter what system you're using, a closed port is a closed port.
I think the main selling point between the two would be that IPF is slightly better performing and that iptables has quite a few addons that make for niceness if you know about and how to use them.
Parent
Re:OpenBSD vs Linux (Score:5, Informative)
OpenBSD doesn't use ipchains -- it uses pf [openbsd.org], which many people -- myself included -- like a lot. OpenBSD is secure and easy to get routing.
The end result is the same, but pf can be easily adapted to many tricks like this, automatically blocking SSH bruteforcing [home.nuug.no].
I'd give the beginners using Ubuntu a break. They're overwhelming sometimes, but the community growing is a good thing. I'm sure someone I've introduced to Linux has needed online help (badly!), but another friend I introduced to Linux really dug in and we're now both better developers because of it. You just don't know.
Parent