Distributed, Low-Intensity Botnets 167
badger.foo writes "We have seen the future of botnets, and it is distributed and low-key. Are sites running free software finally becoming malware targets? It all started with a higher-than-usual number of failed ssh logins at a low-volume site. I think we are seeing the shape of botnets to come, with malware authors doing their early public beta testing during the last few weeks."
First Post (Score:3, Funny)
And I didn't even need to use a botnet!
Isn't that... (Score:2)
Isn't that what already do? Distributed, rather than monolithic, spamming?
Anyway, it's not that surprising...
Re: (Score:2, Insightful)
Um, ssh attacks aren't new. They've been hitting my server's for year's, and mine are for a private consulting company, with trivial amounts of random 'consumer' traffic.
Re:Isn't that... (Score:5, Interesting)
Yeah these worms were attacking my home linux router as well, like a year ago or some.
Worms just tried to brute force ssh using "administrator" and such as username. I guess they were trying to get into badly (default) configured broadband routers. That's never going to work of course on my linux box but all the login attempts caused the hd to be busy *all* the time.
My sollution was to drop ssh packets by default in the firewall. Not that these attacks were likely to succeed but I didn't want my consumer grade hd to wear down in a year ;) I then created a small php script that'd insert a firewall rule to accept ssh connections from the IP it's called from. Finally I password protected the php script with .htaccess.
So now I can enable ssh to my machine wherever I am, while still blocking the rest of the internet.
Re:Isn't that... (Score:5, Interesting)
You could also be interested in port knocking [wikipedia.org].
Turned out to be quite handy when I had that same issue with bots connecting to my ssh port all day long.
Re: (Score:2)
Re: (Score:2)
Well initially I just had
<?php
$ip = $_SERVER['REMOTE_ADDR'];
exec("sudo
?>
Just now I niced it up a bit taking http proxies into account, report the results and do some error checking (I'm absolutely no php wiz, just grabbed the function from http://blog.4rev.net/2007-10/get-ip-address-of-the-visitor-php-script/ and added the rest... it's all pretty simple):
<?php
function getIP()
{
if (isset($_S
Re: (Score:2)
btw in /etc/sudoers I use
www-data localhost = NOPASSWD: /sbin/iptables
For .htaccess check out this page [password-protection.com]
Re: (Score:2)
This is why my openbsd box is called 'linksys'. LOL. Might as well have some
fun with a little misdirection. Sure enough people try to log in as admin, but rarely root.
Re: (Score:2)
Fleas on a dog (Score:5, Insightful)
If the bad guys can siphon off what they need without being more than a mild annoyance, they can operate without fear of retribution.
Re: (Score:2)
Fleas on a dog ... without fear of retribution
Flea deterrence is a big business (at least in the USA).
Nothing abnormal about SSH probes... (Score:5, Insightful)
I've seen SSH probes on my one-man-and-a-dog site for aeons. I don't think there's anything out of the ordinary, the scum has been trying (and failing) to get in for as long as I've had something listening on the 'net - and that is a long time. There's also nothing new in them trying to root FLOSS-sites as those sites - with their fixed IP addresses, good uptime, high reliability and abundance of crappy PHP-scripts to open the doors - make for good C&C hosts for their flock.
So all I read from this flog is that a grumpy BSD user should probably check his logs more often. This is nothing new.
Re: (Score:2)
Yeah, I had flashbacks to 2000. I remember setting something up (I think it was portsentry) that would put ip's in the hosts.deny file after too many bad logins, or was it hitting too many different ports on my PC? (probably both)
Re: (Score:2)
For real. I had my single-page-o'-html site up for a little more than a week with inbound 22/80 open before getting ssh probes. Heck, even when I had my dyndns domain, it was getting probed.
Nothing new at all.
Re: (Score:2)
Run ssh on a non standard port (Score:3, Informative)
One of the effective ways to not worry about these probes, is to run your ssh daemon on a non standard port.
So, instead of it being on port 22, run it on port 1022 or some other port.
You can do that by modifying your /etc/ssh/sshd_config to contain the line: Port 1022.
This means that scp and ssh will have to be told about the port on the command line though.
Re: (Score:2)
One major annoyance with the non-standard port is the port flag option passed to both SSH and SCP.
For ssh: ssh -p2222 ... ...
For scp: scp -P2222
Re: (Score:2)
I've seen SSH probes on my one-man-and-a-dog site for aeons. I don't think there's anything out of the ordinary, the scum has been trying (and failing) to get in for as long as I've had something listening on the 'net - and that is a long time.
Ditto. I saw a suspiciously high number of genuine accounts being attempted. I drew the conclusion that this was coming from bulk email lists.
1. Buy bulk email list, containing fred@foo.com and others.
2. SSH to foo.com as fred - try some common passwords. Maybe try fred@ftp.foo.com for good measure.
3. Profit!
Re:Nothing abnormal about SSH probes... (Score:4, Insightful)
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
How is this new? Botnets have had this capability for a looong time.
Re:Nothing abnormal about SSH probes... (Score:4, Insightful)
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
The parasite doesn't want to kill the host, because it would die too. This thing will tick away, slowly getting bigger.
Re: (Score:2)
Good point, but if he's got control over what traffic is routed his way, he should be able to handle low amounts.
It's folks running websites from home that have the most to worry about. Even then, their ISP should have a cut-off if someone tries to flood the host with incoming connections. Keyword there is *should*....and you're right that we should worry when that starts happening and ISPs don't move against it. I mean, if someone wanted, they could easily knock my SSH server out and kill my download/uploa
Re: (Score:2)
Here's how I solve this problem. I use iptables to block inbound ssh except for from one highly secure IP address. Then, I have a simple perl daemon set up which requires you to attempt to connect to one port, then another, and then it will open ssh to new connections for the next 60 seconds. The daemon doesn't respond to those connection requests. Just notes them.
The result? Someone has to guess the two "knock knock" ports, which is basically impossible. I don't get zillions of logon attempts, because my s
Re: (Score:2)
portknocking is well known, yes.
maybe a bit less secure, but easier to implement and use - just set iptables to reject further connections to ssh port after some amount of connection attempts in a minute from single ip.
for my low-usage systems that's few connects per minute, and then it's some 5-10 minutes of rejects.
this alone drops password guessing from thousands a day to few dozens. most probes give up after first 5 minutes if being unable to connect.
tune these values according to your system usage patt
Re: (Score:2)
This new attack is a coordinated brute force from tens or hundreds of thousands of IP addresses. Each one is only hitting you a few times, so they won't trip per-ip blocking thresholds, but collectively they perform a brute force in the same way that a single host would be able to if you had no blocking threshold in place at all.
Port knocking is a good solution to this, but it's not super portable; I would be unable for example to ssh in from most corporate networks which would block my knocking ports.
I've
Re: (Score:2)
And there would be nothing you could do about it.
Change the port that ssh listens on? Only listen for ssh on the intranet, and nothing external?
Re: (Score:2)
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
Well, not nothing... you could always keep copies of your web site available on various hosts around the Internet, and when one of them gets DDOS'd, start serving from another one.
But how to set up a large number of mirroring servers for free? Your best bet is to use a botnet to do it...
My preferred term is "free radicals" (Score:2, Interesting)
Looks like the malware ecosphere is learning... (Score:3, Interesting)
How to detect them (Score:2)
Heuristics. They're an ancient art, but they can work.
Also, default deny. It's annoying to answer the question, "Do you want to connect to x4rubotnet%a7b.ru?" but it's more annoying not to be asked. If your users have no legitimate reason to be accessing .cn, .ru or other .?? addresses there's no reason to configure your DNS to give legitimate returns for those as an organization. Likewise for the more vile quadrants of the IP space. For some networks it's better just not to ask.
Sure, it causes a Bal
SSH probes are nothing new (Score:2, Informative)
I get somewhere between twenty and thirty attempts per day agianst my SSH server alone. The server blocks the IP permanently after 3 bad attempts and they always try repeatedly until blocked. most of the attempts come from cable or dsl address spaces. I use gibberish for usernames and only allow certificate based authentication. They still keep trying however.
Re: (Score:2)
I'm in pretty much the same boat with my home ssh server, except I would get 20-30 attempts an hour. Occasionally I would sift through some of the attempts just to see what they were trying to guess as usernames. Root and admin were usual attempts, but I would also see oracle, sa, mysql, etc as well as just random first names like John, Mary, Bob, etc. I eventually grew tired of it just filling up my log files so I switched to a non-standard port and haven't seen an attempt since.
Re: (Score:2)
I eventually grew tired of it just filling up my log files so I switched to a non-standard port and haven't seen an attempt since.
I keep ssh open on the standard port because I block offending hosts in pf. It is much easier to detect attacks on ssh, but I get attacked on other ports as well, such as pop3 and smtp.
I would rather know who the enemy is, than be completely blind.
If anybody is interested I would be happy to post my current list of blocked hosts.
Re:SSH probes are nothing new (Score:5, Interesting)
Yeah, same here, except right now there's a rather humongous distributed bruteforce campaign going on. The 20-30 attempts I tend to see have skyrocketed to several thousand per day. It's actually pretty impressive - it's clearly a distributed sequential dictionary attack. Most of the IPs will only try once or twice, in an effort to avoid exactly the sort of reactive firewalling you mention.
Dec 1 11:17:57 shaunc sshd[35178]: Failed unknown for illegal user griffin from 196.211.53.74 port 20893 ssh2
Dec 1 11:18:17 shaunc sshd[35262]: Failed unknown for illegal user griffith from 92.50.243.18 port 40689 ssh2
Dec 1 11:18:30 shaunc sshd[35308]: Failed unknown for illegal user griffith from 82.207.103.151 port 60822 ssh2
Dec 1 11:18:33 shaunc sshd[35354]: Failed unknown for illegal user grizelda from 65.203.231.41 port 60602 ssh2
Many thousands of these, seconds apart, all day long. It got so bad that for the time being I've moved sshd to a different port.
Re: (Score:2)
Re: (Score:3, Informative)
You can cut down on the noise by just moving your ssh port to something other than port 22. Such a move won't stop a serious cracker who will do a port scan, etc. However, since it seems to be sufficient to keep the script kiddies and similar types from doing the sort of stuff described in the article, it means you're far more likely to notice when someone with a little higher skill level tries to crack in.
Best bet if you have a small user base is to only allow public key authentication and move the ssh p
Nothing new, move along (Score:5, Insightful)
Okay, how is this different than previous patterns of hacking activity, other than the fact that they're aquiring compromised machines via a bot net? It's not! These "security researchers" remind me sometimes of my pothead friends. You can always tell someone who's new to smoking weed because they constantly ask the question, "but have you done it on WEED?" It's like somehow the idea that these people are using a botnet makes it all strange and new again. No, fail!
Re:Nothing new, move along (Score:5, Insightful)
Okay, how is this different than previous patterns of hacking activity, other than the fact that they're aquiring compromised machines via a bot net?
You're sort of missing the point, I think, in that what's different about this pattern of activity is precisely the fact that it's being done with a botnet.
For one thing, there's a new level sophistication, primarily in that this bruteforce campaign is not the least bit random. I'm being hit by thousands of distinct attackers, yet the progression of usernames being attempted is undeniably alphabetical. Occasionally a particular username is attempted more than once, but it's typically sequential. One attempt per username with the attacking hosts only making one attempt every few hours.
The level of coordination required for this sort of attack is unprecedented. Across thousands of bots, each one at any given moment is able to determine:
In the past, brute force SSH attacks have always been obvious. Typical hit and runs. One host will spew hundreds or thousands of attempts at a target, typically in quick succession, typically focusing on system accounts, and typically trying a shitload of passwords against each account. Firewalls and IDS deployments far and wide will now easily detect (and often block) these attacks immediately because they're so easy to recognize.
This attack is very different. It's not targeting system accounts, it's hoping to get lucky against a vast list of potential userland lognames. It's only trying once or maybe twice per account. And it's distributing these attempts, round-robin style, across an impressive number of sources, with enough logic so that bot B will not attack host H unless all other bots in the network have sequentially exhausted their "token" attempt on host H.
What we're seeing is flying under the radar of a shit-ton of IDS/firewall implementations, and is harder to fight.
I would love to get my hands on the C&C database being used to coordinate all of this. Much as I hate to admit it, the architecture of this attack is unique and innovative, and I'd like to see what makes it tick.
Re: (Score:2)
It seems to me you could accomplish the same thing without such a complex architecture. I'd build an intrusion robot that iterates over usernames and target IPs and sends each request out via a different compromised host. Imagine setting up TCP proxies or VPN tunnels on each compromised machine that connect it to hundreds of other compromised machines. Then the robot is assigned a target address to which it starts making ssh login attempts via the tunnels. After a while it switches to another target IP
Re: (Score:2)
I just don't get what the big deal is. Bad? Yes. New? NO!
I write network applications for a living. This type of coordination with a large number of hosts is precisely the kind of thing that I write professionally. While it takes some work to get this kind of coordination in place, it's probably a man-week with standard tools and commonly available information for somebody who understands how to write network applications.
Years ago (2002?) I saw similar behavior in what I called a "spam attack". I was the s
Go install fail2ban (Score:2, Informative)
fail2ban will watch your log files and when it sees probing will firewall ban the offender. It has virtually eliminated probing attacks on my networks of machines. Sure, a distributed botnet can still probe you, but I haven't seen that happening.
Do be careful though...
Re: (Score:2)
Denyhosts does the same thing, but has a global synchronization method. If one person using the sync feature bans someone, they all do.
It only works for ssh though. fail2ban is flexible enough to monitor anything and do anything, in response to any pattern. Pretty damned powerful really.
Re:Go install fail2ban (Score:5, Informative)
Please read more of the article before posting. The activity being described is a brute-force SSH login attack that is distributed across a botnet.
(Yes, the title of the article is misleading, as botnets are by definition distributed; the interesting bit is that SSH brute-force attacks against a specific host don't seem to have been distributed before.)
Here's the relevant bit:
fail2ban is not effective against this.
Re: (Score:2)
I am undergoing the same kind of attack here, with what looks like the same dictionary. Fail2ban has picked up some 600 hosts, for about 3000 attempts. So it's not useless for all botnet attacks.
Re: (Score:2)
There should be a memory efficient alternative, maybe I'll have to write that.
Mine uses 53 lines of ksh.
IPtables rate limiting is better (Score:2)
Actually, a simple one line IPtables rate limit on port 22 new connection attempts (or whichever port you use for SSH is better than Fail2ban or Denyhosts, because it will never lock yourself out.
I suspect that the author has such a limit on his firewall machine and that it is the reason why he sees the slow attack rates and that the slowness has nothing to do with the attackers!
Re: (Score:2)
Most of the time, these limits are by source IP-address. This new attack self-limits the rate of connections from a single IP address, and instead hits the same destination from multiple sources. Rate limiting globally will work here, but will mean that legitimate SSH connections will be slowed down.
Re: (Score:3, Informative)
While it's been pointed out that fail2ban isn't effective against this particular attack, I wanted to point out a similar utility called BruteForceBlocker [rulez.sk].
It was written as a reactive firewall that parses pf logs on OpenBSD and FreeBSD (pf is "the iptables of BSD"). The coolest feature IMO is that it's a community effort, in that each participating host can elect to share its logs with a centralized server. That server then publishes a list of recently reported SSH attackers [rulez.sk] which you can script into your f
Re: (Score:2)
Only if you have it monitor unidirectional traffic -- it's pretty hard to spoof TCP because the connection doesn't open until you send packets in both directions. A TCP spoofer needs to be able to see and inject packets that are being routed along legitimate paths, which essentially means they need to be on the local network at your end or the local network of the legitimate remote host.
And if someone is on your local network attacking you an IP-based block won't work not matter what you do.
Very interesting; this bypasses my auto-banning fw (Score:4, Interesting)
I use Fail2ban [fail2ban.org] on all of my iptables-based SSH servers, as it eliminates the possibility of brute-force attacks from single IPs (fail2ban will ban any IP with five failed ssh logins in a ten minute period. The ban vanishes after ten minutes).
However, this new botnet attack distributes the attack over the IP-space and time. That bypasses fail2ban!
The only solution I can see to this would be to take an approach similar to the centralized spam-fighting solutions; a DNSBL [wikipedia.org] specialized for brute-force botnets. You run something that monitors your logs for failed logins (with a large scope for time, say ten failed attempts in a month). When an IP triggers it, you block that IP for a month and report it to the DNSBL. The DNSBL operates like Spamcop [spamcop.net], trying to verify the nature of the IP (and trying to address the issue), then adding it to the blocklist. Anything listed on a DNSBL gets permanently blocked after one failed authentication, and if your internal list grows too big, any positive IP gets blocked before the login attempt.
Solution - disable root ssh login, password auth (Score:5, Informative)
SSH keys ensure that you're virtually immune to attacks, since the attack now MUST be brute-force (or break the RSA/DSA algorithms or compromise the server itself rather than an account), and must crack a "password" of over 150 base64 characters representing the 1024 bits of entropy in the key; a completely random printable password of 20 characters has 130 bits of entropy and an 8-word Diceware [wikipedia.org] passphrase has only 120; you're not brute-forcing that.
Preventing root from accessing remotely is just smart (your logs can show who really logged in, your sudo logs show who needed root-level access and when, and you can auto-ban root logins immediately rather than after a set number of failed authentications).
All we're missing is the extension to #3 to handle distributed attack failures (as proposed by the parent post); with the proper protections, this is a bandwidth issue rather than a security issue (unless you're worried about DDoS, but we're talking about low-intensity attacks here).
For those of you stuck permitting passwords, you'll want something like John the Ripper [wikipedia.org] to brute-force users' insecure passwords before the enemies do. This way you can disable their accounts when you find that they are vulnerable and force them to change their password to something more secure.
Re: (Score:2)
As someone pointed out earlier, these attempts are usually doing a dictionary attack of common usernames instead. The general MO here is that for any user name from aaaaaaaa to zzzzzzzz from their list, some number of systems (usually 3-5) will attempt that user name, and then the botnet will mo
Re: Set UsePAM no (Score:2)
Re: (Score:2)
If that product use the recent target, be careful what kernel you use it on. You'll find that after a few weeks the damned target starts matching stuff it shouldn't and you might lock yourself out of your server. IIRC the expiry time winds up becoming infinite.
Don't worry, it's a documented bug somewhere, and recent kernels aren't affected. 2-year-old kernels are for-sure though. I just can't remember the precise details; I've been bit by it trying to throttle SMTP.
Re:Very interesting; this bypasses my auto-banning (Score:3, Informative)
The only solution I can see to this would be to take an approach similar to the centralized spam-fighting solutions; a DNSBL [wikipedia.org] specialized for brute-force botnets.
Damn! I just posted about this as a reply to a previous thread, and it definitely belongs here instead.
Anyway, check out BruteForceBlocker [rulez.sk], it's exactly what you describe, but it's implemented as a plaintext list instead of a DNSBL. Hosts using BruteForceBlocker can report attacks back to the central server. The list of recently reported attackers [rulez.sk] is public.
It's meant for BSD variants using the pf firewall, but I rolled my own implementation to parse FreeBSD ipfw logs (and report back) in a day or two. A da
Re: (Score:3, Informative)
Fail2ban actually bans the offending IP after several failed authentications within a small window of time, and the ban is only for a small window of time ... the purpose is not defensive for secur
Portknocking (Score:3, Interesting)
Like the OP I was getting loads of hits on port 22. I just setup portknocking and it works a treat.. My other system that I use ssh on (its on the a sub domain of my main site) I just moved to a higher port and that has prevented it from getting the hits..
Normally I don't recommend Security through obscurity but in the case of automated attacks it is worth while. Just don't rely on it alone.
Nothing new here: use DenyHosts (Score:3, Informative)
These sorts of attacks are nothing new. If you are running an SSH server directly accessible from the Internet, check your /var/log/auth.log log sometime. You may be alarmed by the surprisingly large number of attacks you get every day, even if it is your home IP with no sort of domain name associated.
I like to run DenyHosts [sourceforge.net] on my machines, which watches this log file and adds suspicious IPs to your /etc/hosts.deny. I generally have several new IPs added daily. Also disable remote root logins, because then the attacker has to guess a username and a password: an extra few bits of security (they try "root", then go on to "tester", "tester1", ... , "guest", "guest1", etc.). And, of course, use strong passwords for SSH accounts. In your logs you will find attackers employing dictionary attacks (which DenyHosts will quickly cut off).
Re: (Score:3, Informative)
Screw that... I went pubkey-only from any directly-exposed hosts awhile ago. Works great. I keep my Blackberry's MidpSSH key on the hosts, then in an emergency I can log in and add a new key if necessary. Plus if people want an account they can just send in a pubkey and I don't have to communicate a password.
Re: (Score:2)
Distributed attacks require distributed defenses. Newer versions of Denyhosts let you synchronize your block lists with other Denyhosts users. It's really quite excellent.
Re: (Score:2)
DenyHosts has a default memory time for failed logins of something like 5 days by default. Are you suggesting that a botnet would have enough members to make a meaningful brute force attack when each member can only make three tries in a five-day span? Seems not so plausible.
Weak SSH keys (Score:2)
Wait until they combine this with Debian's 2^16 weak ssh keys. Do you think that will be easier or harder to crack than passwords?
This attack must balance reward and risk. (Score:2, Interesting)
This is not a game changing tactic. My institution has documented these style attacks on several past occaisions. There was some of this going around near the 4th of July. There was an extended bout this time last year. The attackers only use this tactic a few times a year. We have come to expect it on major holidays.
Economics can not be ignored. This attack must balance reward and risk.
In a normal SSH password guessing attack, the attacker risks a handful of computers. The committed computers do very noisy
Time to switch to SSH keys and ban password auth (Score:2)
I switched to only allowing keys a long time ago. This stops this attack dead, whether it is distributed or not. If I ever lock myself out, or use a computer where I don't have any keys already set up, I have a special, password-encrypted key that I can access over an authenticated https url.
On my VPS I took advantage of SSH's new configuration features to disable password authentication for outside connections, but allow password for connections coming from within my wide-area private network (openvpn ro
I've Noticed It, Too (Score:2)
I long ago installed 'bruteblock' on my box, which plonks an IP address for N minutes after X failed attempts (both configurable). It's very small and efficient. But
Mail Admins like me are used to this already. (Score:2)
For about the last 2 years I Have been getting continuously hit with botnet hosts every 2 minutes trying every conceivable email address@mydomain. I tried writing a rule to autoblock them with iptables but the list grew into the 10s of thousands and slowed down my machine. I put a greylist on it and now they get greylisted but they keep coming and coming and coming. There must have been more than a million greylisted email attempts over the preceding two years. Far more than the amount of legit mail I ge
Lots of poor "solutions" here (Score:2)
Pretty lame, people.
Move sshd to another port?
Obscurity.
Rate limiting?
IP-based bans on failed logins?
Elaborate username based bans?
All reactive solutions.
Portknocking?
A more complex obscurity tactic, but very weak as an extra authentication layer.
TFA mentions ssh public key auth, and disabling password authentication. That would be much better/more effective than anything mentioned here.
If you're serious about security, then you aught to actually add another layer. Firewall off ssh completely and require a
Re: (Score:2)
Firewall off ssh completely and require a VPN connection first
Just another layer of obscurity.
Surprise, surprise (Score:2)
So we are still user password-based SSH authentication?
Re: (Score:3, Insightful)
So we are still user password-based SSH authentication?
The problem is that in any sort of working environment, where you have a very heterogeneous user base, it's really really hard to enforce anything else.
Users - even the most basic of users - can be trained to enter a username and a password. They do it on Hotmail, they do it on Google, they do it on MySpace, they're used to the idea that when they want to login somewhere, they have to enter a username and a password. "That's how the internet works." So when their job functions require that they PuTTY into a
interesting (Score:2)
I was wondering what those hundreds of failed ssh logins were from every day.
I didn't really have any idea what was up, so I just changed my SSH port to 22222 and the problem went away.
I may have found their source for targets... (Score:4, Interesting)
Then it came back last month [slashdot.org] and I paid a little more attention to what I had been doing before. There was one significant thing that I did just before it (re)started:
I placed an ad on craigslist that had a link back to my own server for information on what I was selling.
We all know that of course the spamming botnets tend to troll craigslist looking for valid email addresses to add to their lists. I would say it appears that the botnets are now looking through craigslist for systems to attack as well.
Much ado about nothing (Score:2)
Do you want to bet that the time it takes to brute force a well secured system in this manner is measured in the thousands of years to millennial range?
Re: (Score:3, Insightful)
Re:Non Distributed Botnets (Score:5, Insightful)
Re:Non Distributed Botnets (Score:4, Insightful)
Isn't slashdot basically a big overgrown blog?
Re:Non Distributed Botnets (Score:5, Insightful)
you can read slashdot, but not a blog?
This isn't surprising at all, even less so if he works in IT. Corporate management issues a new policy: "our computing resources are not to be used for [insert a huge list of time-wasting things employees have been caught doing in the office]." But keep in mind who's eventually tasked with implementing the policy. Given such an edict, network admins everywhere will happily block the most prolific productivity killers... Except for their own.
You'll find plenty of enterprises where MySpace, Facebook, Blogger, LiveJournal and friends all resolve to nowhere, yet geekier time pits like Slashdot and TechCrunch are wide open.
Re: (Score:2)
Sh-h-h-h!
Re: (Score:2)
Sh-h-h-h!
It's all good. Everyone likes to ask, "Who watches the watchers?" But without fail, the IT department watches itself, because nobody else knows how to. :)
Re:Non Distributed Botnets (Score:5, Informative)
Actually botnets watch the IT department.
Is this really a surprise ? Not every hacker is a 10 year old that does it for the kick of announcing himself "master of the network".
These days you write a virus, that stays in the back-back-background (exe injection is one hell of a rootkit-like trick that not a single antivirus vendor detects : you startup. You find some dameon process that's sure as hell not going to get terminated any time soon (on winxp you can actually use the "idle" process), you "debug" the process, insert your own code in it's memory, in a freshly allocated piece, use the debugger to jump into your code, which creates a new thread in it's address space. You clean up, and voila, you'd have to be one hell of an admin to realise what happens on boot. You could even infect svchost.exe on disk).
The hacking programs stay very, very, very low key and use covert channels to send information out, and receive answers. (e.g. user logs in with username password -> daemon looks up aes('$username,$password').some.domain.attacker.owns. The remote dns server is what informs the attacker of the username and password. Or have the webbrowser startup in a hidden window going to "yooptube.com?v="+aes('$username,$password'). You get the idea.
In these days of youtube, myspace and such, such a lookup is not exactly a strange occurance (though I use a "question and answers" site), and used sparingly, will evade any detection system.
Use the enemy's tools against him. Use the webbrowser to connect to the web. Use DNS. Use email. Use ... never try to open an outside connection.
Works wonders. 3 years now, and still not discovered.
Re: (Score:3, Interesting)
Fun and interesting theory. I've noticed one of my really old XP installs is "busy (unresponsive or laggy) when it should be idle" for a while now.
I encapsulated it into a virtualbox vm on a linux machine, and created a firewall rule to deny and log all direct internet access requests.
Proxy access to a limit set of sites is available on squid, which also logs all traffic. It's never actually tried to go anywhere but vendor sites
for software updates, but I have my eye on it none-the-less. It could just b
Re: (Score:2)
Re:Old news (Score:5, Interesting)
I've noticed a significantly increased number of brute-force attacks in the last week or so. They're also spacing the number of attempts per IP address out, however I'll get several attempts in a row for the same invalid username from several different IP addresses within seconds of each other. Then all of the addresses will back off for a couple of minutes, and then they'll retry with a new username.
It's gotten to the point where I have finally installed Denyhosts. Prior to this week, I got away with limiting the number of new connections to port 22 per IP address per minute, but with the backoff that they're doing now, that no longer works.
Denyhosts is fantastic, though. Since I last evaluated it, they've added the ability to sync with a centralized server, meaning that I can potentially block attackers before they even hit me. I wish that everyone would use it, now.
Re: (Score:2)
There is a danger though. What stops someone from spoofing a given address with the intention of putting it on 'the list'? Now all your systems have locked you out... what do you do?
(that said, I use denyhosts with it's sync feature)
Re:Old news (Score:4, Informative)
I have always had a select few hosts which are allowed unconditional access to the server, so if I need to, I'll get access.
Another option is to set up a second SSH daemon on a different port, and which only allows logins using public key (and possibly only by a specific user.) If you get blocked out on port 22, you can just use this side door to get in, as long as you've got your key.
Re: (Score:2, Interesting)
Since you've gone that far, why not use the "side door" as the main door and get rid of ssh password access completely?
/etc/hosts.allow and have "ALL: ALL" in /etc/hosts.deny. That, plus key-only ssh access (no passwords allowed) seems to work rather well.
I use static IP addresses listed in
Re: (Score:2)
Because I have users to think of, and most users can't be bothered to keep and carry around SSH keys. Hell, I can't either, so if I need to log in from an unfamiliar computer, I tend to use password-based authentication.
Re: (Score:2)
Users are one thing, but you can put keys on a USB key, plus putty, and access from most any machine you can find.
Also, these "attacks" are about 5 years old.
Frankly, I put them more in the category of the shortwave "number stations" than any genuine attack. The payoff would seem to be way too low to be worthwhile - so the most likely motive is to waste time and resources that might otherwise notice an actual attack.
Re: (Score:2)
Re: (Score:2)
You can only spoof a given source if you're in the same subnet or if you have control over the routing between yourself and the target. The article deals with botnet threats, not insider attacks.
Re: (Score:2)
A half connection would be scored as an attack. You send your half of the connection with delays, and your work is done.
Re: (Score:2)
Re: (Score:3, Interesting)
I don't use the sync feature but do take advantage of the user black list. Grep the logs once a month and add the most popular names to the black list. I set it up to block the IP on the first attempt to login using any of the banned users.
Down to about 5-6 attempts a day now. This isn't even a static IP, can't imagine how bad it is for someone
Re: (Score:2)
Pretty good idea on the user black list. You could probably even do some interesting things to detect common misspellings of your usernames and blacklist anyone using anything else after a single attempt.
Re:Old news (Score:4, Interesting)
> Denyhosts is fantastic, though.
Indeed it is. Here are the RubyForge DenyHosts settings [blogs.com]. The comments on that post have a good suggestion about DENY_THRESHOLD_ROOT; makes sense to have that at 2 vs 1 to avoid blocking someone who accidentally hits the wrong box.
Fail2Ban (Score:2)
I run fail2ban on every Internet-facing machine that I set up and/or manage. The policy I use is that 5 failed logins results in an iptables ban from any access to the box for 24 hours.
Re:Easy was to stop 90% of SSH attacks (Score:5, Funny)
Re: (Score:3, Interesting)
Most of my attackers come from residential services all over the USA and UK, or don't resolve to an address at all. Those domains would be an exception.
Re: (Score:2)
I just block ssh access from anything with .ch .kr or .ru
I would say that in my logs >>99% of addresses don't resolve to anything and show up numeric only.
Re: (Score:3, Informative)
.ssh/config
Host hostname
Port yourport
then you can ssh to hostname and not have to type the port everytime.