Security

Protect SSH from brute force password-cracking attacks


In the midst of ensuring you don't have any unnecessary services running while securing a Unix-like system from outside attacks -- whether a proprietary UNIX system, a free BSD Unix system, or a Linux distribution -- one of the services you'll almost certainly come across is the SSH daemon. In most cases, this will mean OpenSSH, and you'll want to make sure you can access a server remotely, particularly in cases where your servers are running "headless" (without monitor and keyboard).

There are automated systems out there running 24/7 that are attempting to access any computers on port 22 via brute force attacks to get past SSH password protection. If you check your /var/log/auth.log file on any system connected directly to the Internet, or perhaps connected to an open wireless access point in a coffee shop, before long you'll likely start seeing entries at the end of the file that look something like this:

Oct 30 19:07:33 local_host sshd[6906]: error: PAM: authentication error for root from remote_host

There are a number of things you can do to cut down on the incidence of that and to reduce the likelihood of getting your system compromised by these blind attacks. For instance, a sufficiently complex password is essentially uncrackable at current technology levels. Oh, sure, any password can be cracked "eventually," but that eventuality may take more than a century to complete with the computing resources at your fingertips today.

Another example is to simply configure SSH to listen on a port other than 22. For instance, you might assign it to listen to port 1138 (in honor of George Lucas' 1967 movie, THX 1138 4EB). To do so, simply change the Port line in the /etc/ssh/sshd_config file to show the new port number you want to use -- and be sure to use that port number when connecting from a remote system. After editing, that line in sshd_config should look something like this:

Port 1138

Port knocking can be used to provide an additional layer of security and keep the common malicious security crackers from even finding out you have an open SSH port. OpenSSH allows use of key-based authentication instead of password authentication, which can further restrict attempted attacks, as can a firewall configured to deny SSH connection attempts from all but a whitelisted set of clients.

Perhaps the most universally usable, and in many cases the most effective, means of restricting access to brute force attacks is to simply deny root access via SSH. Yes, I know -- you want to be able to log in remotely and perform administrative tasks that require root access -- but you also want to ensure that someone who stumbles across your machine and has the right pieces in place (such as using the correct connection port number) cannot directly gain root access to your box with a brute force, password-cracking attack.

You can still allow other accounts to access the machine via SSH, of course. With either sudo or su, you can then gain root access. Since automated attacks are even less able to guess both an unknown user account name and its password (especially if the password is sufficiently complex) -- and, in fact, most never bother to try for any account other than root because of this -- the security of your system from automated SSH attacks will be greatly increased by taking this simple measure. That is particularly true if you do not allow the general user accounts to use sudo or su to gain root access. You may designate a special administrative account with greatly restricted privileges on the system, but with one privilege that no other non-root accounts have: the ability to perform administrative tasks with root privileges via su or sudo.

However you choose to arrange for administrative access, once you have disallowed direct root access over SSH, it's a very rare circumstance where you should allow remote root access at all. To disable direct root logins via SSH, edit the ssdh_config file again so that there is a PermitRootLogin line that is uncommented and set to "no":

PermitRootLogin no

Some operating systems, such as FreeBSD, have this set as a default. Others, such as most Linux distributions, do not. Check out your particular choice of OS to determine its default PermitRootLogin setting before deciding it's safe enough as-is.

edit: As TR user eldergabriel pointed out in a comment to this article, more information about securing the OpenSSH daemon can be found in the sshd_config manpage. Most Unix-like OSes with OpenSSH installed should have that manpage as well, and you can read it with the command man sshd_config or via whatever Unix manual interface you prefer and have available (such as the xman documentation browser).

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

26 comments
TG2
TG2

and, in fact, most never bother to try for any account other than root because of this . Oh contrary to your statement.. every machine in our networks is scaned very frequently (different sources) and they use users and password files. . One of our customers was hacked some time ago (windows) and the perp couldn't finish laying their seed and attacking (caught in the act) so I had a chance to see what their exploit used. They had a FOUR MEG User file, and an EIGHT meg password file. . think on that a second.. 8 bits to a byte, user names are 3 to 8 bytes on average (some maybe 10 to 15 bytes if the system accepts it), and then passwords were 3 to 14 bytes long. . That's a lot of users and passwords, and when you think on what they could do, add two individual words together, so if you have hat and black in the password file you could try a set { black, hat, hatblack, blackhat} etc... . so.. 12 megs of user and password data all aimed at trying to go through vunlerable users. Real passwords by the way.. some were just the basic 1 111 1111, while others were combinations (customer was using "l33tpass" and it was in the password file!!) . they were going after users like bob, tom, tim, harry, ...etc . and anyone that looks at their logs, should quickly spot root, administrator, bob, oracle, brian, cjohnson, etc.. (see output below) . -T . . . Failed password for invalid user webmaster from xxx.xxx.xx.xxx port 34386 ssh2 Failed password for invalid user user from xxx.xxx.xx.xxx port 35138 ssh2 Failed password for invalid user username from xxx.xxx.xx.xxx port 35339 ssh2 Failed password for invalid user username from xxx.xxx.xx.xxx port 36104 ssh2 Failed password for invalid user user from xxx.xxx.xx.xxx port 36856 ssh2 Failed password for invalid user admin from xxx.xxx.xx.xxx port 38330 ssh2 Failed password for invalid user test from xxx.xxx.xx.xxx port 39060 ssh2 Failed password for invalid user danny from xxx.xxx.xx.xxx port 42708 ssh2 Failed password for invalid user sharon from xxx.xxx.xx.xxx port 43489 ssh2 Failed password for invalid user aron from xxx.xxx.xx.xxx port 44211 ssh2 Failed password for invalid user alex from xxx.xxx.xx.xxx port 44955 ssh2 Failed password for invalid user brett from xxx.xxx.xx.xxx port 45607 ssh2 Failed password for invalid user mike from xxx.xxx.xx.xxx port 46303 ssh2 Failed password for invalid user alan from xxx.xxx.xx.xxx port 47038 ssh2 Failed password for invalid user data from xxx.xxx.xx.xxx port 47846 ssh2 Failed password for invalid user http from xxx.xxx.xx.xxx port 49212 ssh2 Failed password for invalid user httpd from xxx.xxx.xx.xxx port 49933 ssh2 Failed password for invalid user info from xxx.xxx.xx.xxx port 52778 ssh2 Failed password for invalid user shop from xxx.xxx.xx.xxx port 53499 ssh2 Failed password for invalid user sales from xxx.xxx.xx.xxx port 54199 ssh2 Failed password for invalid user web from xxx.xxx.xx.xxx port 54927 ssh2 Failed password for invalid user www from xxx.xxx.xx.xxx port 55659 ssh2 Failed password for invalid user wwwrun from xxx.xxx.xx.xxx port 55877 ssh2 Failed password for invalid user adam from xxx.xxx.xx.xxx port 56588 ssh2 Failed password for invalid user stephen from xxx.xxx.xx.xxx port 57323 ssh2 Failed password for invalid user richard from xxx.xxx.xx.xxx port 58035 ssh2 Failed password for invalid user george from xxx.xxx.xx.xxx port 58753 ssh2 Failed password for invalid user michael from xxx.xxx.xx.xxx port 59366 ssh2 Failed password for invalid user john from xxx.xxx.xx.xxx port 60100 ssh2 Failed password for invalid user david from xxx.xxx.xx.xxx port 60841 ssh2 Failed password for invalid user paul from xxx.xxx.xx.xxx port 33351 ssh2 Failed password for invalid user angel from xxx.xxx.xx.xxx port 34979 ssh2 Failed password for invalid user pgsql from xxx.xxx.xx.xxx port 36432 ssh2 Failed password for invalid user pgsql from xxx.xxx.xx.xxx port 37183 ssh2 Failed password for invalid user adm from xxx.xxx.xx.xxx port 38629 ssh2 Failed password for invalid user ident from xxx.xxx.xx.xxx port 39223 ssh2 Failed password for invalid user resin from xxx.xxx.xx.xxx port 39935 ssh2 Failed password for invalid user info from xxx.xx.xx.xxx port 3055 ssh2 Failed password for invalid user info from xxx.xx.xx.xxx port 2646 ssh2 Failed password for invalid user info from xxx.xx.xx.xxx port 2343 ssh2 Failed password for invalid user info from xxx.xx.xx.xxx port 2519 ssh2 . . Failed password for invalid user test from xxx.xx.xx.xxx port 3631 ssh2 Failed password for invalid user test from xxx.xx.xx.xxx port 4962 ssh2 Failed password for invalid user test from xxx.xx.xx.xxx port 2987 ssh2 Failed password for invalid user test from xxx.xx.xx.xxx port 4175 ssh2 Failed password for invalid user upload from xxx.xx.xx.xxx port 1570 ssh2 Failed password for invalid user upload from xxx.xx.xx.xxx port 3376 ssh2 . . Failed password for invalid user apple from xxx.xxx.xxx.xxx port 36824 ssh2 Failed password for invalid user brian from xxx.xxx.xxx.xxx port 37192 ssh2 Failed password for invalid user andrew from xxx.xxx.xxx.xxx port 37560 ssh2 Failed password for invalid user newsroom from xxx.xxx.xxx.xxx port 44267 ssh2 Failed password for invalid user magazine from xxx.xxx.xxx.xxx port 44621 ssh2 Failed password for invalid user research from xxx.xxx.xxx.xxx port 44982 ssh2 Failed password for invalid user cjohnson from xxx.xxx.xxx.xxx port 45363 ssh2 Failed password for invalid user export from xxx.xxx.xxx.xxx port 45734 ssh2 Failed password for invalid user photo from xxx.xxx.xxx.xxx port 46109 ssh2 Failed password for invalid user gast from xxx.xxx.xxx.xxx port 46469 ssh2 Failed password for invalid user murray from xxx.xxx.xxx.xxx port 46825 ssh2 Failed password for invalid user falcon from xxx.xxx.xxx.xxx port 47193 ssh2 Failed password for invalid user fly from xxx.xxx.xxx.xxx port 47542 ssh2 Failed password for invalid user gerry from xxx.xxx.xxx.xxx port 47874 ssh2 Failed password for invalid user guest from xxx.xxx.xxx.xxx port 48940 ssh2 Failed password for invalid user test from xxx.xxx.xxx.xxx port 49091 ssh2 Failed password for invalid user test1 from xxx.xxx.xxx.xxx port 49214 ssh2 Failed password for invalid user teste from xxx.xxx.xxx.xxx port 49354 ssh2

eldergabriel
eldergabriel

Since you did mention the PermitRootLogin keyword in the article, it probably would also be worth mentioning the (rather self-explanatory) DenyUsers, AllowUsers, DenyGroups, AllowGroups keywords. For example, a non-privileged (i.e. non-root/admin) account could be specified in the sshd_config as the only user to be allowed ssh login via the AllowUsers keyword, or have a dedicated ssh_users group consisting of all the non-privileged accounts you want to grant ssh access to via the AllowGroups keyword. Once logged in via one of these non-privileged user accounts, then it's easy enough to sudo or su to escalate one's account privileges and perform administrative tasks. This effectively forces a user to authenticate twice, before they could do any serious damage. The difference between what i'm saying here and what the article mentions about sudo/su rights is that when using AllowUsers/Groups, only those accounts or groups specified in sshd_config will be able to ssh in, and then any sudo/su restrictions would apply. As you mentioned elsewhere in this thread, you don't want to cram too much stuff into one article, but i thought these keywords would be worth mentioning. I strongly encourage anyone interested to refer to the sshd_config man page at http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config .

THX-1138
THX-1138

It is interesting that you picked port 1138... but I may have guessed that one right off :-) Great article, Thanks

steven.macfarlane
steven.macfarlane

Don't allow password authentication at all. I am amazed at the number of attempts made to brute-force my SSH servers. I try to not feel smug knowing no matter how many attempts are made, there just won't ever be a password that will grant access. You are asking for trouble if you have an outward facing SSH server and you allow root access. Not a big enough deal to su once you get in with your normal creds. Of course if you are doing work as root anyway, you are asking for it.

george.r.boyce
george.r.boyce

First, don't use plain text passwords in the first place. Use either a challenge/response system like OPIE, two factor authentication like securid, or PKI like ssl certificates. Second, don't allow ssh connections from the world. You know where you access the system from most of the time so lock it down to those internet networks. If you use iptables for example, it can also be trained to react to breakin attempts and automatically block the attacker after a few failures. You can also set up a system, e.g. a special email message, that unblocks the network you need access from.

apotheon
apotheon

A single data point does not prove the converse. There are such attacks out there -- but most of them attack the root account. That has been my experience for years, over a number of different networks and across a great many desktop, laptop, and server systems, including everything from open wireless access points at coffee shops to managing the server network for one of the world's highest traffic websites. Brute force attacking accounts other than root tends to be something someone tries only after exhausting similar methods against the root account, if at all -- in part, because the root account is generally the ultimate goal of gaining access to the system, so the direct route is preferred when possible. If you experience [b]more[/b] attacks against non-root accounts than against root accounts, chances are good that you are on the receiving end of carefully, individually targeted attacks rather than the randomly targeted attacks we all get. That being the case, you might want to pay special attention to the, err, "special attention" you're getting, because that would probably indicate that your security threat situation is in some way abnormal.

DanLM
DanLM

My auth.log has shown lines like that more then once. And this is a home BSD box. I just removed all password authentication and use only public/private keys. Screw it, I'm tired of fighting the battle. Dan

DanLM
DanLM

My auth.log has shown lines like that more then once. And this is a home BSD box. I just removed all password authentication and use only public/private keys. Screw it, I'm tired of fighting the battle. Dan

apotheon
apotheon

. . . and thank you for the kind words. I'm glad you approve of the port number.

apotheon
apotheon

"[i]Of course if you are doing work as root anyway, you are asking for it.[/i]" I can only assume you mean things like using a web browser or checking email when you say "doing work". These are not the sorts of things anyone should be doing as root, of course. On the other hand, there's some "work" that [b]must[/b] be done as root, such as many system administration tasks (updating system-wide software with security patches, for instance). You aren't very clear about what you mean by "doing work as root", but one must reasonably assume you don't mean sysadmin tasks that require root access. If you did mean that, it would be, well, [b]unreasonable[/b].

williamjones
williamjones

check it out here: http://denyhosts.sourceforge.net/ DenyHosts is a package that can work with PAM to protect against attempts to breach SSH. The system adds IP addresses that have too many login failures to a block list. Where I think DenyHosts actually makes its bones is in the capability to update your blocked hosts list with IPs that have attacked other DenyHosts users. The developer has built-in a central updating system that allow DenyHosts users to share information about hosts that have exhibited aggressive behavior. You can prevent a malicious host from connecting preemptively, without having to restrict SSH permission to known IP ranges, or limit it to specific accounts!

apotheon
apotheon

. . . but it also all assumes certain things about the circumstances on the network that you're protecting. Sometimes one option is usable but another is not, because of the necessary functionality you must provide. Sometimes, the other is usable, but the first one is not. I mostly tried to focus on some basic fundamentals in this article that are of key importance, and usable in at least 98% of instances. It's good to bring up one-time password systems and multi-factor authentication, of course, but it's also important to realize that these are not always feasible given the business needs. There are great multitudes of options available to you: one cannot list them all in a single article, or even in a handful of comments on the article. For maximum security without unnecessarily limiting functionality, everyone's going to have to research some options for himself or herself. After all, sometimes allowing SSH connections from "the world" is exactly what you need. By the way, PKI solutions are by and large a scam. A certifying authority doesn't guarantee something is secure: it just defers your own good judgment and decision making, laying it off on the CA instead of keeping it where it belongs -- in your own hands. You might as well just put all your trust for security in the hands of the OS vendor, at that point. Who needs antivirus? You can trust Microsoft to protect you!

TG2
TG2

Still disagree .. these aren't carefully crafted .. they go after any SSH, they scan whole ranges, and when they get an SSH response they launch trying to take over.. its nothing more than worm traffic. Yes .. most attacks include root accounts, but root itself? no.. how about admin? administrator? FTP is the same way .. the attacks come in for far more than just the administrator and root accounts, any known user/pass they have will be tacked on, hoping to find user X has moved their account to some other server, or that by chance user X on one machine has the same name as on another.. and again brute force the password. Additionally ... what install now a days doesn't automatically disallow root login for the ssh config? BSD does it, Redhat, Mandrake, Debian, so which ones don't disallow root by default?

eldergabriel
eldergabriel

I've also had great success with denyhosts. Talk about a killer app; it absolutely rules.

george.r.boyce
george.r.boyce

I'd argue that if you need ssh access from the world, and you have something worth protecting, and you lack the skills or time to implement two factor authentication, then serious consideration should be made to hire a consultant to implement it. But in these days of $5/month websites, such a consulting bill may be hard to swallow. But then that (cheap technologies and inexperienced admins) is why there are so many easy targets out there. In that case, just disabling root ssh access is the best suggestion. IMHO, it should be the default for all hosting services.

TG2
TG2

Nevermind, your not worth the aggrivation you attempt to stir. /end thread

apotheon
apotheon

"[i]Look, I've just gone back, and re-read the article, and your first counter to mine ... I'm right in what I've said. 1) root is not the only account tried[/i]" Perhaps you weren't paying attention as closely as you thought. I never said that root was the only account anyone ever tried. What I said was (a direct quote): "most of them attack the root account" See that? "Most." I thought it was pretty clear. Apparently, you disagree. In your eyes, it seems, "most" means "all". "[i]you suggested the networks I monitor must be targeted[/i]" I see your inability to distinguish between a statement qualified by a mitigating term and an extreme, unqualified statement, is not limited to the difference between "most" and "all". You also seem to have problems with the difference between "must" and "chances are good". You claim I said your network(s) [b]must[/b] be targeted, but what I actually said was: "[i]chances are good[/i] that you are on the receiving end of carefully, individually targeted attacks". The words "chances are good" are key to the meaning of that sentence. Please take note of them. "[i]I'm not alone in seeing the same types of activity[/i]" I don't imagine you would be, if things are as you say in your case. As I think I pointed out already, the larger the network, the more likely someone will try non-root accounts -- both because a targeted attack is more likely against bigger assets, and because drive-by attacks are more likely to be able to succeed against large networks with random user account names. See, when I said things like "most" and "chances are good", I was speaking of majority case statistical trends. In situations like this, there are always statistical outliers -- and even though they're more rare, those statistical outliers are typically not unique cases. "[i]The same 'attacker' may try several times over a few days[/i]" That brings up a very good point -- but perhaps not the point you were hoping for. Someone attacking nonroot accounts is more likely to spend more time attacking each target (in part because, unlike with root attacks, the brute force attack against passwords is multiplied by the number of user names being tried). This means that if there are a hundred people attacking root accounts and one person attacking a hundred nonroot accounts, assuming equivalent password cracking attempts per account, you're going to see numbers of attacks in your logs that work out to about an even split between root and nonroot account names. Thus, if you happen to be the lucky target of an attack against nonroot accounts, a superficial analysis of your logs may make it appear that you're getting attacked by more people with an interest in nonroot accounts than root accounts, even if the opposite is true. "[i]Truely random ip guessing wouldn't work well, because for each ip you attempt, you have nothing better than a 50/50 chance.[/i]" I'm not sure you're clear on how things work for malicious security crackers. They generally don't give a damn about the per-IP chance of cracking security. They tend to care about how long it takes for them to find and compromise a system that would provide what they need. Since many SSH servers do not differentiate between an attempt to log into a nonexistent account and an incorrect password for an existing account, that means that in many cases trying to access nonroot accounts in a brute-force attack increases the likely time spent per host by orders of magnitude. It's usually much quicker to hit a root account and move on. Only when one has a specific need to access a specific system does one generally spend the time necessary to attack a bunch of random account names -- and if they aren't random, but actual existing account names on a given system, we're talking about a specifically targeted attack rather than the usual random scans. "[i]It seem you think root is all its about[/i]" I don't think you've been paying attention, then. I just think that, since pretty much every Unix/Linux machine has a root account, it requires far less time to find existing accounts when you attack root (since you can pretty much guarantee the account exists). I imagine you aren't much of a programmer (if a programmer at all), nor a mathematician (neither am I, but it offers the same understanding of increasing difficulty for increasingly complex possibilities on target systems that an understanding of programming does), or you'd probably understand more easily how your arguments that someone somehow has a greater chance of success by increasing the complexity of the brute force attack would likely lead to counterproductive results. "[i]I suppose next you're going to say that a hacker/cracker or even worm wouldn't be bothered by trying to record usernames and their passwords, I mean according to your school of thought, what purpose would that serve, they only want root ... right?[/i]" I wonder where you get these ideas. By the way, I'm not in the habit of responding directly to people who send me private messages for the sole purpose of continuing to tell me how I don't know anything. Why would I want you to have any of my personal email addresses?

TG2
TG2

Again? Look, I've just gone back, and re-read the article, and your first counter to mine ... I'm right in what I've said. 1) root is not the only account tried, the spoils of getting onto a box through a commonly used name, and then exploiting a program *on* the box which gets them privileged / super user access OR being able to get on the box and run ANY program of their choice that doesn't need root access, are what more of the attacks are about. 2) you suggested the networks I monitor must be targeted, again, they aren't, and the data from larger networks show I'm not alone in seeing the same types of activity. The same "attacker" may try several times over a few days, their ip's usually show up as being open relays, listed in RBL's, etc 3) someone else tried to backup this "random" ip idea, but again, that's not necessarily true either. A worm, written well, would account for "commonality" of machines and builds. Truely random ip guessing wouldn't work well, because for each ip you attempt, you have nothing better than a 50/50 chance. But, if you scan a range looking for (in this case) ssh, and find one, then the chances are good, that if you continue in that range you may be in a datacenter, rather than scaning a residential IP block, and find other machines in a farm that would be running SSH. And while the first box may not have root enabled, or may not have a "bob" account, the next box in that range might. This would be why the "knock once" principle doesn't work. now if you, were personally going to attack a range of ip's looking to compromise someone's servers, you might try that approach, knocking once and then going away for a long enough period of time to not be so easily noticed. Or you might try coming in through a bot net, scripting the attack to have one machine in the bot net trying one ip, a different machine in the botnet trying the next ip in that netblock, etc.. but even that isn't as common an occurance. More often the attacks are in sequence (ip order), are for multiple attempts from the same source (different user accounts and passwords), and aren't really "targetted" at anything other than trying to find a machine running SSH; that responds to user/pass combinations that the worm/script has available to its attack code. It seem you think root is all its about, and on systems that have been compromised that I've seen, I can tell you, their biggest desire appears to be for them to run their own code, lately most of that has been IRC Relays (which don't require root access), with backdoors and hacked SSH daemons (which would require root) that record the user names and passwords that later; connect to that hacked machine. I suppose next you're going to say that a hacker/cracker or even worm wouldn't be bothered by trying to record usernames and their passwords, I mean according to your school of thought, what purpose would that serve, they only want root ... right?

apotheon
apotheon

That was a comically bad argument. 1. You're trying to make a case for malicious security crackers wasting their time screwing around with nonstandard user account names when it would be easier to just move on to a different network to attack and try root again. 2. You start by talking about how many SSH port scans and attacks there are. 3. You ask if they're all targeted attacks. 4. You point out that it would be absurd for them all to be specifically targeted attacks. 5. You pretend that proves that all those attacks must be wasting time screwing around with nonstandard user account names. Where did you learn logic -- at a beautician's school? edit: The following quote from you is actually worse, in terms of the failed attempt at a logical argument, than anything I've addressed above. "[i]It comes back to your original statement that seemed to say the user ROOT was the bulk of what attackers were going after, to which I disagree, its not just root[/i]" At what point did you decide that "the bulk of what attackers were going after" was equivalent to "just root"? There's a difference between root being the only target and being the most common.

TG2
TG2

If you don't understand, then perhaps you should start here... http://isc.sans.org/port.html?port=22 Sans tracks the type of exploits and volume from reports collected from admins across the net, etc. As you can see from the common graph, there are anywhere from a few hundred to 1300 sources of port 22 scans on any given day, with targets ranging from a few hundred thousand, to a maximum in the past 30 days of nearly 3.5 million destinations. Now, would you argue that someone out there is specifically targeting 3.5 million destinations? Or, would it be more likely the bulk of those are probes. And if they are probes for 22 / ssh, and they carry any payload (a worm for instance which would look for another machine to infect) would it be they are targeting a network? Or that they are looking for just *any* target they could compromise, and part of those payloads include common user names and passwords. Common user names, again these would be root, toor, bob, alex, apache, oracle .... names that are commonly set up on boxes by services that run on them (ie, an oracle user created during the install of oracle to a server) Next, networks. When I mention /8 /18 /19 etc, I mean networks that are real routable ips. Networks that are announced with upstream and possibly downstream routers. Routers that are with other providers (transit or peers) and other routers that belong to customers of us or the ISP my friends work for. In referring to monitoring /8 or /18 etc.. I mean that I could get to our border router, and watch traffic coming in from the internet at large, coming through one of our transit or peers, and destined for some IP space within our company's control. When I say 20 firewalls with /24's behind them, I mean 20 firewalls that lead to blocks of servers and workstations, that I can directly monitor without having to go intrusively to our border routers. Again, this all means I'm able to gather information from a view point on anything to 5000 destination ip's easily, and more if I wanted to go into monitor on the border. With that large a range of destinations to view, and with friends in places that are easily able to see larger blocks of networks, and could if they wanted view their ISP's entire /8 from different border routers, a summary of the types of SSH traffic appear more frequently that of worm like traffic. Scripted traffic looking for machines to propagate to, and infect, and then scan for even more machines from the newly infected machines. Targeted attacks, ones where there is a person or group behind them, to usurp a single company, or customer from our point of view, are less of an occurrence than are the random source, common exploit seeking worm. Within those contexts, rarely do we see an ssh worm that is solely going after the account "root" on a server. Most of the time we see the attacks going after, again, those common names that the worm has included and passwords to match, that have been seen/found/extruded from other boxes and for which this worm now looks to find additional hosts using the same users passwords, or attempting to brut force attack the password of the common user name, or names. It comes back to your original statement that seemed to say the user ROOT was the bulk of what attackers were going after, to which I disagree, its not just root, but a larger range of common user names that have been seeded into the wormed attack. The person/group/machines launching these attacks have no information about the destination other than an IP address or range of ip addresses, to scan; and in the case of purely wormed traffic, are machines often going after sequential IP Addresses as the destination. as in: x.x.x.1 (ssh *not* found) x.x.x.2 x.x.x.3 -> ssh found, start trying different users and passwords x.x.x.4 x.x.x.5 ...etc... If you really can't understand this.. then I give up, as its not worth my time to keep repeating reality to you.

apotheon
apotheon

1. "[i]'targeted attack' is presumed to mean targeting by a human to get other human's or entities devices (servers, machines, routers, etc)[/i]" Actually, it means "attack more specific than the usual pan-and-scan approach of people just looking for extremely simple, low hanging fruit sorts of compromises", in the context in which I brought it up. Such could involve impersonal processes of narrowing down the field of targets further than simply by checking for open ports. For instance, any time that someone chooses to add the known IP ranges specifically of a set of corporations that all work in the same industry, that is to some degree a targeted attack. In other words, as I was using the term, "targeted attack" means using more information than can be found strictly through the use of automated tools over the Internet prior to having compromised security on the target(s) in question. 2. If your anecdotal experience differs from my own experience, research, and otherwise gathered knowledge of the subject, all I can say is that the case of you (and a few of your friends, apparently) appears to be a statistical outlier from where I'm sitting. 3. At this point, we're just telling each other "No, you're wrong, because I've seen different things." You're not going to change my mind about the likelihoods without providing hard evidence, and since I don't know you well enough to trust you there's little chance I'll accept your word for it. 4. The large network sizes (measured in numbers of IP addresses) that you're discussing may in fact be part of the criteria for targeted attacks of the sort I suggested, so your examples may actually be a biased sample. 5. Has it occurred to you that a /8 network can be created by simply changing the configuration of your router? It's not difficult. Whether or not there are actually enough physical nodes behind the router to justify such an address range is not immediately evident to someone scanning the network from the outside. I doubt this is particularly relevant to the numbers you're throwing out there, but I think it's worth mentioning because the way you've presented information about network sizes is less than entirely clear. Finally, I have a comment about your post that is a bit off-topic. This isn't a personal attack -- it's just an explanation: Your grammar and sentence construction in the message to which I'm responding is poor enough that it interferes with my ability to quickly ascertain your meaning. As such, it takes somewhat longer to read and digest your post than many other posts of similar size and technical complexity. I fear that future examples of the same are unlikely to have my full attention, because the barrier to entry is just too high when I have to try to decipher poorly composed posts like this one.

TG2
TG2

In my other post, I've also mentioned, this isn't just an attack at my one machine, nor the 20 plus firewalls I have access to as "single ip destinations". I point out, that these firewalls are not just "20 destinations" these are firewalls with a minimum of 128 ip's behind them, one or two like that, with the rest of the firewalls having a /24 (253 possible hosts, yes 253 ... when discounting network, broadcast, and gateway ip's) Here I will contrast this with three friends I chat with on a regular basis, one of which is capable of seeing the results from a /8 (ie. netmask of 255.0.0.0) and in all these cases from four separate points of network view, the majority of traffic we "collectively" see is similar, non-targeted vulnerability based attacks. Are there targeted attacks? Certainly... Who's doing them? any of a number of possible sources (gov't, competitors, black hat wannabes, etc) And in the grander scheme? In the bigger picture, I see more attempts to compromise systems at random (even a sweeping range of every host ip in any given ip block), to use them for relay (smtp, irc, proxy, etc) than there are attacks based solely with the intent of compromising a system because its "my" machine or my company's resource.. and in those attacks, I see any attempt to get access to a machine not as just a "root user" but more frequently as **ANY** user. Those attacks when successful get the foot in the door, and then the real compromise happens next, usually within the scripted worm, that once it does get a foot in, it immediately tries to gain *privileged* root (root as core not 'root' as a user name) access to the box to finish off laying their payload and doing their setup (clearing logs, renaming executables, hiding in the registry ) and then becoming active in their intended duties. but again far more of this is not targeted solely at any one machine, its a sweep .. and I may see the same source ip today, tomorrow or next week, unless I contact that ISP, give them the proof that they have an ip spewing this kind of traffic, and request that the ISP take action.. etc.. Its more analogous to spam, and open relays (either on purpose -- that is someone that configured the server as an open relay ... or more frequently from compromised windows machines)... the spam could easily be stopped, if everyone communicated and dealt with the problem immediately, rather than take the slow path to solution. Even in my own dealings.. I had a customer who had an infected machine it was relaying spam, he closed the firewall to disallow outbound SMTP except from the office email server.. 4 weeks later he was on spamcop's list again, I got notified and then notified the admin there.. the admin wanted to swear on everything he had that I was wrong ... as it turned out, when that admin went back, he suddenly remembered that he disabled his SMTP outbound rule because a user was having problems with their blackberry and thought maybe the rule was the cause... in the end he had forgotten to re-enable that rule. Even though the original machine behind that office's firewall had been cleaned of its relay trojan, someone else in the office now was infected and they had started relaying and gotten out because the admin forgot to re-enable the smtp rule. In the real world where I have 5000 or more ip's to see active logs for, and with three other friends in similar situations to see anything from a few /24's through a full /8 (technically I could monitor traffic to a /18 and a /19 myself) and these networks not being at similar locations (virginia x 2, arizona and california) with ip's in vastly different ranges (none of us having common first octets in the ip address) we see far more worm vulnerability scripted traffic than hard core targeted attacks, and even in the targeted attacks, its more often DoS that we'd see, rather than One individual or group there of, coming after any one machine via SSH. Granted, not one of us has Microsoft, Yahoo, or Google, in our mixes, so we don't have the extremely high profile companies, we we have had some that could be targets for amateurs.. like I said more often DoS based against a particular ideal that a client espouses rather than attempts to compromise those machines that have web or any other content on them.

TG2
TG2

First, blind generalities on linux source .. big deal.. you know mandrake from mandriva, redhat 7 versus fedora 8... etc.. the idea was sound, that which ever currently sets root allowed for telnet and ssh, is by common security concepts, wrong. I too recently installed Debian, base, and it was without ssh. When I installed SSH the default was with root disallowed. Thus, it suggests that installation scripts aren't universal, and there-in lay a problem for those people who create those install scripts, to resolve ... so too, we should forward that kind of information, since it has been widely regarded as a "no no", and yet *still* someone left it enabled (bad scripters!) As to what the user needs to know for an attack.. an individually targeted attack isn't just going to go after one service, nor is it going to solely go after one user name. The primary argument against that, is because 50 or 60 hits on "root" with bad password is easy to spot. Granted you have to be looking. But if you look, just like the snippet of log I provided, root wasn't the only name, there were multiples, the attacker in this case knew *nothing* about my system other than it had an IP that responded on port 22. That's all that was desired.. if I compare the logs for the SSH server, with the logs from my firewall, and then from any one of 20 others in my area, I would see that same source IP address, trying repeatedly to access each ip address in a range, when it gets a response on port 22, it then attempts however many users are inside its scripted attack. Root is only one of them. And I'm not alone in the traffic I see .. so its not someone targeting my company, my company's datacenter, or anything remotely like that. (and fyi, these firewalls have a minimum of a /25 behind them, with most of them having /24 of real routable ips, no natting involved, so I'm not talking about just 20 destinations but more like 5000 destination ip's) The intent of the attack is to gain root control of the box and install itself (worm) or install a trojan (to allow remote access) and then move on. Nothing more than scripted "here's an ip to use and abuse oh master of mine".... The real targeted attack, also doesn't need to know anything about a destination other than its IP. Because a real targeted attack can start with nothing and learn about its intended victim. Take a company for example... if you wanted to attack a company office, you'd try to learn more about what ip range they have. Send an email to an INFO@ or find someone's name and try different combinations John.Doe j.doe ... johnd ... @company.com ... looking for non-responses (like looking for email addresses that don't bounce) in the email you could include a common URL that you can monitor, even a dot bot, and thus you'd get an ip ... to look into... from that one ip, you'd query to find the range of ip's its in (is it swipped to an ISP's customer so the range is smaller than /18 maybe its down to a /27 ?) and then you'd make assumptions.. mostly windows based pc's, maybe a couple of windows servers, maybe a few linux/*nix boxes (unless its a ISP, or Mac or *Nix house) and with that you would be further refining your attack scripts.. these are the elements of a targeted attack. And I guess the one thing left is to say, is that "targeted attack" is presumed to mean targeting by a human to get other human's or entities devices (servers, machines, routers, etc) rather than .... the malicious worm traffic ... which is trolling the underworld looking for machines to propagate to. And even with machines that are attacked with the intention of putting trojans on to it and report back to the mother ship that pc number 500 is now available for her to remote through... even those machines, are more unintended victims than would be a "targeted" system, because the exploits used were not chosen specifically because you knew what to expect.. the methods of attack were chosen solely based on a vulnerability, and the hopes that you could have machines you could use, rather than going after Johnny's PC down the hall, with the owner of which (Johnny) you've been having a pissing contest with...etc... Could there be a targeted SSH attack? Sure.. I'm brand X and I put out a version of SSH... I find OpenSSH is competing against me.. I could then look for flaws, when I find one.. I could craft a worm, to seek out and infest machines running OpenSSH's brand (version) of SSH.. I could even call myself "a vigilante" for trying to make the world a safer place getting openssh's implementation secured because of soo many infected machines.. maybe then it could be a targeted attack and have very specific parameters to it.... ... but then how often is *that* really happening?

TechExec2
TechExec2

. Apotheon is right. Most, but not all, brute force SSH attacks "randomly" select IP addresses to attack, bang on the root account via SSH for a while, and move on to the next IP. Some may try a few other accounts or protocols such as FTP. But, they don't spend a lot of time on a single server. They are looking for the "low hanging fruit" ... the easy break-in, just like many other criminals. You know ... if you put clearly stronger locks on the doors and windows of your home, it makes most burglars move on to your neighbor's house. You understand this, don't you? Your log shows something different. Your attacker is spending valuable time on you. For some reason, your attacker thinks you're vulnerable. Or, he wants to attack ... YOU. Many different user names. Many different ports. This "burglar" is lingering on your "house" and not moving on to the neighbor's house even though he has not had any success. You would be wise to take some action. If I found a burglar loitering around my home every night trying to pick my locks, I wouldn't ignore it just because it is still possible he doesn't have a special interest in my home. I would take a "special interest" in him and take care of the problem.

apotheon
apotheon

"[i]any known user/pass they have will be tacked on[/i]" Of course that's the case. It's also the case that root is the most likely account to exist on any system -- and to be sure a given account name exists, the attacker has to know something more about the target than just the IP address and the existence of an SSH daemon on the machine. Thus, my comment about "carefully, individually targeted attacks" (which is [b]not[/b] the same as "carefully crafted"). "[i]BSD does it, Redhat, Mandrake, Debian, so which ones don't disallow root by default?[/i]" What do you mean by "Redhat"? Do you mean RHEL or Fedora? Mandrake isn't a distro these days. Do you refer to Mandriva? When did Debian start setting PermitRootLogin to "no" by default? As recently as last week, installing Debian Etch (the current Stable release) resulted in an sshd_config file that included the line "PermitRootLogin yes" by default.

apotheon
apotheon

You're thinking too small, or in too limited a manner, for considerations of what "access from the world" might mean. Check out this example of a valid use case: http://sdf.lonestar.org/index.cgi Are you going to try to enforce a multifactor authentication system for free shell accounts under such circumstances?

Editor's Picks