Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Compromised SSH Keys Lead To Linux Rootkit Attack

timothy posted about 6 years ago | from the bad-childhoods-keep-on-giving dept.

Security 79

Tech Groupie writes "The US Computer Emergency Readiness Team (CERT) has issued a warning for what it calls 'active attacks' against Linux-based computing infrastructures using compromised SSH keys. The attack appears to initially use stolen SSH keys to gain access to a system, and then uses local kernel exploits to gain root access. Once root access has been obtained, a rootkit known as 'phalanx2' is installed."

cancel ×

79 comments

Sorry! There are no comments related to the filter you selected.

As usual... (3, Informative)

koh (124962) | about 6 years ago | (#24765043)

Change your keys regularly, and revoke the key as soon as you have the slightest doubt it's been compromised.

Re:As usual... (3, Funny)

Westech (710854) | about 6 years ago | (#24765493)

Change your keys regularly, and revoke the key as soon as you have the slightest doubt it's been compromised.

/me gives Redhat a dirty look.

Re:As usual... (0)

Anonymous Coward | about 6 years ago | (#24766489)

Slightest suspicion it's been compromised, or slightest doubt it's secure. Hopefully you have more than the slightest doubt that it's been compromised when you create the key...

Re:As usual... (-1, Flamebait)

Anonymous Coward | about 6 years ago | (#24769637)

Or switch to a real operating system. Solaris or *BSD.

How is this news? (4, Insightful)

Shade of Pyrrhus (992978) | about 6 years ago | (#24765071)

The attack appears to initially use stolen SSH keys to gain access to a system

Ok...so if you get the key to a machine you can get in and abuse an old vulnerability, assuming the machine in unpatched. The rootkit that they discuss is from 2005, so where's the news here? Be careful about your SSH keys and passwords?

Seriously, if there's more to this I'd like to know. The article hardly has more information than the summary.

Re:How is this news? (4, Insightful)

Goaway (82658) | about 6 years ago | (#24765155)

The news is that this is probably fallout from the Debian OpenSSL fiasco, and that people should take it seriously pretty damn quick and get their keys changed.

Re:How is this news? (1)

SanityInAnarchy (655584) | about 6 years ago | (#24765723)

Do you have any evidence for that?

I know that Debian handled that pretty aggressively. Too bad for anyone who somehow missed the memo.

Re:How is this news? (2, Informative)

Goaway (82658) | about 6 years ago | (#24765829)

No, I just actually read the article.

Details on the attacks â" and targets â" remain scarce but itâ(TM)s a safe bet this is linked to the Debian random number generator flaw that surfaced earlier this year. A working exploit for that vulnerability is publicly available.

Re:How is this news? (2, Insightful)

mvdwege (243851) | more than 5 years ago | (#24777479)

So you don't have any evidence. The quote you give is as much speculation as your original post.

Mart

Re:How is this news? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#24770947)

*I* don't have evidence for this, but the weak version wasn't just weak but RIDICULOUSLY weak -- 65536 keys. An exaustive scan can be done against these!

Re:How is this news? (2, Informative)

ozphx (1061292) | more than 5 years ago | (#24774431)

It was worse. The only entropy was the process ID.

That means the *likely* seed for longer running system processes was in a subset of the low couple of thousand.

For user processes, well starting low and ending higher would eat up keys like no tommorow. One researcher successfully made an exhaustive scan in around 48 hours on a small cluster :S

Debian & the GNAA (-1, Troll)

Jizzbug (101250) | about 6 years ago | (#24769885)

Is it any coincidence that last year's Debian Project Leader is an active member of the GNAA [encycloped...matica.com] ?! I think not!

If you can't make money selling botnets to Russian mobsters, then maybe:

You, too, could be a hundred-millionaire with the Moore-Otsuka-Helkenberg prime number sieve and integer factorization algorithm, solving for [p, q] where n = p*q! I made $200,000,000 in 45 seconds M.O.H.'ing down RSA! RSA is D.O.A.

Gay Nigger maths for all:
http://jessicalogsdon.com/page5/page5.html [jessicalogsdon.com]

Re:Debian & the GNAA [NOT OFFTOPIC] (0, Offtopic)

Jizzbug (101250) | more than 5 years ago | (#24773041)

The GNAA is a hacker group that runs botnets.

Only lamers and trolls think GNAA is a trolling group. (All hackers are trolls, but not all trolls are hackers. Put that in your Venn Diagram and smoke it!)

Wake up, retards!! DURRR

"Hello, my name is Sam Hocevar, I run botnets and Debian."

Re:How is this news? (1)

rtb61 (674572) | more than 5 years ago | (#24773875)

At a guess, some government systems that are not updated as often as they should be, not as well maintained as they could be or even not as securely configured as they should, say, banking and finance Linux, ISP, etc. install, were successfully attacked. As such a warning has to be issued to remind other slack admins to update their systems.

As for where the stolen SSH keys were originally obtained, a certain Olympic event springs to mind, so the effort might be fairly wide spread and a concerted attack to pick up as many poorly configured and maintained machines as possible.

Parallel networks might become all the rage, two completely separate systems. One internal with absolutely no external network connections, strictly hard wired and no unlogged file uploads and the other in the wild for internet and email, wireless, feeding cheap UMPC's, compromised, meh, take two aspirins and I'll look into it tomorrow ;).

and (5, Informative)

extirpater (132500) | about 6 years ago | (#24765091)

change your ports other than 22, this won't stop a full port scan but good against lamers scanning for port 22.
And you ip restriction. if you don't have static ip at least block connections outside of your connected isp.
you may also use port knocking protection.
these are not panacea but better than nothing.

Re:and (1, Funny)

Anonymous Coward | about 6 years ago | (#24765315)

I placed a condom between my ethernet cable and my NIC. This seems to have blocked all incursions.

Re:and (4, Funny)

MarkTraceur (1329579) | about 6 years ago | (#24765835)

Dude, that's like building an electronic voting machine and putting anti-virus software on it.

No, wait...

Re:and (2, Funny)

Nick Ives (317) | about 6 years ago | (#24765897)

Condoms are only effective at reducing relative risk vs unprotected connections by about 70 to 85% - source [wikipedia.org] . As always, the only safe way is abstinence! Not that anyone around here will listen to that; I bet most /.'ers are in promiscuous mode...

Re:and (1)

mikkelm (1000451) | about 6 years ago | (#24765977)

What, peeking in on others in the neighbourhood having sex?

Re:and (2, Insightful)

RiotingPacifist (1228016) | about 6 years ago | (#24766453)

However abstinence is 90% less fun - source [youporn.com]

not that this has anything to do with the topic but 70-85% indicates they are doing it wrong, with proper usage, assuing that you get actual sex education not abstinence bullshit, that figure should be up to 90-95%

Re:and (1)

mhall119 (1035984) | about 6 years ago | (#24767713)

I think he was saying that it provides 70% to 85% _more_ protection against (infect|pregnancy)? than using nothing. However, using nothing isn't a 100% guarantee of becoming (infected|pregnant)?, so if unprotected leaves you with, say, a 50% risk, then protected would leave you with between 7.5% and 15% at risk (85% to 92.5% safe) .

If my math is right, which I won't vouch for.

Re:and (1)

renegadesx (977007) | more than 5 years ago | (#24774041)

It's ammusing that its the christains say "abstainance is the only way" yet their own beliefs say otherwise. Dont they have some adaption of the Isis virgin birth myth?

Re:and (0)

Anonymous Coward | more than 5 years ago | (#24774925)

I'm Christian, you insensitive clod!

Re:and (0)

Anonymous Coward | more than 5 years ago | (#24787247)

Pointing out hypocricy is never insensitive, what I think he pointed out was Christians are ones who push this "abstainance only" properganda saying "its the only way to ensure pregnacy doesnt occur" yet Christian theology says this is actually not the case in the form of Mary

It was kind of insensitive about calling it a rip off of the Isis virgin birth... correct but insensitive.

Re:and (1)

StikyPad (445176) | about 6 years ago | (#24768663)

As always, the only safe way is abstinence! Not that anyone around here will listen to that

You're joking, right? Our userbase are the poster children for abstinence. "Abstinence through disciplined self-stimulation," that's our motto. Hell, I'm married and I've been abstinent for as long as I can remember. (Which actually isn't that long thanks to a rigorous diet of beer.) What was I saying?

Re:and (0)

Anonymous Coward | about 6 years ago | (#24767237)

Murderer! Don't you know that preventing the fertilization of an egg or the implantation of a zygote is MURDER?

Re:and (2, Funny)

mhall119 (1035984) | about 6 years ago | (#24767751)

Does that make abstinence preconceived murder?

Re:and (0)

Anonymous Coward | about 6 years ago | (#24768929)

Only if you've authored your own file system and named it after yourself.

Re:and (1)

mhall119 (1035984) | about 6 years ago | (#24769027)

What do you have against Bobby Ext?

Re:and (0)

Anonymous Coward | about 6 years ago | (#24767621)

Or, instead of utilizing security through obscurity, you could just firewall off your SSH ports so that others can't connect to it at all.

Re:and (0)

Anonymous Coward | about 6 years ago | (#24767649)

change your ports other than 22, this won't stop a full port scan but good against lamers scanning for port 22.

Or install ssh-faker (http://www.pkts.ca/ssh-faker.shtml). It as well is not perfect, but it does add another layer that someone has to get through before they ever get to try to exploit your sshd directly. And it will stop 100% of all script-kiddie tests.

Re:and (2, Insightful)

cbiltcliffe (186293) | about 6 years ago | (#24767869)

SSH is not available remotely on any of my servers. The only way to access SSH is to VPN in, using OpenVPN.
All SSH traffic is blocked at the firewall.

Re:and (1)

mi (197448) | more than 5 years ago | (#24788473)

change your ports other than 22, this won't stop a full port scan but good against lamers scanning for port 22.

That's as good an argument as the one, that a heavier car protects their occupants better in case of an accident, and that we should thus all drive SUVs and other heavy vehicles...

Once everyone (or just noticeable number of people) put their sshd on a different port, nmap-style quick scanners will become part of the toolkits and quickly proliferate among "the lamers". Oh, and you'll be forced to remember one more aspect of each machine — not just the hostname, but also the ssh's port-number. It would have to be randomly-assigned, BTW, by the OS installer, would not it?

Talk about temporary security at the cost of essential convenience...

This just in: (5, Funny)

Cocoronixx (551128) | about 6 years ago | (#24765123)

Stolen login credentials leads to unauthorized access of computer resources!

Re:This just in: (1)

meist3r (1061628) | about 6 years ago | (#24765221)

Breaking News: Burglar steals key to gate, breaks fence, now faced with front door lock and armed owner.

Re:This just in: (0)

Anonymous Coward | about 6 years ago | (#24766023)

Yes, because with computers, the owner is generally keeping an eye on every packet that gets routed in and can accept/deny them on a case-by-case basis?

Re:This just in: (2, Insightful)

cduffy (652) | about 6 years ago | (#24766605)

The point is "defense in depth".

If you don't accept SSH connections that aren't coming over your trusted, separately-keyed VPN, for instance, this is pretty moot.

If you've disabled loadable modules, remounted your root filesystem read-only and dropped capabilities to remount read-write (and otherwise hardened against rootkits), this can be pretty moot on that account too.

If you aren't doing those things, maybe you should think about it.

Re:This just in: (1)

twistedcubic (577194) | about 6 years ago | (#24770113)

How do you drop "capabilities to remount read-write"? What does this mean? Will you never be able to update your root filesystem again? I would use a VPN, but many public places offering wireless internet block all outgoing ports except tcp 80 and 443, so I have to run ssh servers on these.

Re:This just in: (1)

cduffy (652) | more than 5 years ago | (#24770549)

How do you drop "capabilities to remount read-write"? What does this mean? Will you never be able to update your root filesystem again?

google linux capabilities

Will you never be able to update your root filesystem again?

Not without a reboot.

I would use a VPN, but many public places offering wireless internet block all outgoing ports except tcp 80 and 443, so I have to run ssh servers on these.

OpenVPN supports sharing a port with a more conventional SSL server in TCP mode.

Re:This just in: (1, Funny)

Anonymous Coward | about 6 years ago | (#24766647)

I only eyeball the packets that have the evil bit set.

Oh noes!!1! (1)

corbettw (214229) | about 6 years ago | (#24765169)

You mean if someone steals my SSH key, they can then use it to log into my account??? And if that SSH key is in the authorized_keys file for root, or if I have sudo set not to prompt for a password, they could install a rootkit?!?!? Why didn't someone tell me this earlier?!?!?!

Re:Oh noes!!1! (4, Informative)

Goaway (82658) | about 6 years ago | (#24765209)

If you generated that key with Debian within the last two years, anybody can figure it out in minutes, remotely.

Re:Oh noes!!1! (1)

narcberry (1328009) | more than 5 years ago | (#24775167)

Sounds a little exaggerated. Unless you mean "minutes" in the loosest sense, as in anywhere from 0 to 10^3000 minutes.

Re:Oh noes!!1! (1)

Goaway (82658) | more than 5 years ago | (#24776835)

Sadly, it is not. Read up on the Debian OpenSSL fiasco to see why.

Re:Oh noes!!1! (1)

rew (6140) | more than 5 years ago | (#24776113)

The good thing is that besides generating better keys after the patch, patched debian systems will refuse to authenticate on a broken key!

Thus, your broken keys become useless, and you're forced to generate new ones. Moreover, if there are "old" users on a system that no longer actively login on a system, they wouldn't notice the key no longer working. However, the patched system will refuse to authenticate the broken key.

Hmm. come to think of it, there remains a risk of people copying bad debian keys onto other not-patched Unix systems, and the bad guys figuring that one out...

Re:Oh noes!!1! (5, Informative)

GiMP (10923) | about 6 years ago | (#24765379)

What it means is that there are apparently some administrators not running Debian that have naively thought that the issue didn't affect them. However, if they haven't blacklisted those keys, they will undoubtedly have some users that generated their keys on Debian, which are vulnerable.

The worm will exploit this to obtain local non-root user access, and through local privilege escalation exploits will obtain root. Then, they will steal the keys stored on the host that might be used to connect out to other hosts. The last part of this is the deadly part, because those keys are not blacklisted, and will thus connect to and infect the hosts that don't have vulnerable-old-debian keys.

What this means for me, as the administrator of a web hosting company that has patched their servers, is that we will undoubtedly see illicit login attempts. With some really bad luck, one of those login attempts might work, despite our patching. Then, we are at the whim of how well we're secure against local privilege escalation.

Re:Oh noes!!1! (2, Insightful)

MMC Monster (602931) | about 6 years ago | (#24766085)

How does the worm know what username to try to break into prior to escalating to 'root'?

Re:Oh noes!!1! (4, Informative)

Chatterton (228704) | about 6 years ago | (#24766493)

With the exploit, breaking the key is a matter of minutes. The worm could try to crack them all hoping to find one generated on a debian box and not updated.

Re:Oh noes!!1! (1)

GiMP (10923) | about 6 years ago | (#24767959)

I know know what this worm is doing exactly, but it could try random usernames, or simply usernames identical to that the key was stolen from (if stolen from local user eric, try remote user eric). A really smart worm would even check the known_hosts file, to direct its attack to the most likely hosts to contain a matching public key.

Re:Oh noes!!1! (1)

GiMP (10923) | about 6 years ago | (#24767987)

Sorry, I meant to write, "I don't know what this worm is doing exactly".

Re:Oh noes!!1! (1)

mzs (595629) | about 6 years ago | (#24770117)

It is a worm so the trick is spreading. It can get very far by trying the same username for all the hosts in the known_hosts file even if it cannot get root. It can also look at /etc/passwd for other users and try to spread that way to other hosts. If it can get root with a local exploit, it can look at everyone's known_hosts for more places to try and spread to. Also with root it can look in the comments of the keys and log files for more targets and usernames. Basically if it can get to 1% of the hosts that is still huge.

Re:Oh noes!!1! (0)

Anonymous Coward | more than 5 years ago | (#24786837)

The worm begins using _stolen_ login credentials.

Re:Oh noes!!1! (3, Interesting)

RiotingPacifist (1228016) | about 6 years ago | (#24766497)

so in an ironic twist people using debian are in the safest position.

Re:Oh noes!!1! (1)

mzs (595629) | about 6 years ago | (#24770063)

No if you have a user that logs in via ssh keys and that user generated the keys on an affected Debian box, an attacker can get in. Then they use a barrage of local root exploits to gain root, not a passwordless sudoer.

New attack vector! (2, Funny)

betterunixthanunix (980855) | about 6 years ago | (#24765651)

This new attack relies on an attacker compromising login credentials. Then, the compromised login is used to install a rootkit on the target system.

This may rival the DNS vulnerability.

Debian compromise: probably related... (5, Interesting)

daveewart (66895) | about 6 years ago | (#24766385)

Even the openssh guys don't seem interested in including blacklist support for probably-compromised keys: see https://bugzilla.mindrot.org/show_bug.cgi?id=1469 [mindrot.org]

This means that, since the compromise arose, Debian and Ubuntu distros are safe once patched with the blacklist code. However, for keys generated on Debian/Ubuntu but uploaded to non-Debian/Ubuntu servers, those non-Debian/Ubuntu servers will still be vulnerable unless manually checked. This means: OpenBSD servers, Fedora servers etc.

Have any distros apart from Debian/Ubuntu provided blacklist-like tools for this issue? Any of the *BSDs?

Re:Debian compromise: probably related... (0)

Anonymous Coward | about 6 years ago | (#24767035)

A package called openssh-blacklist seems available on RHEL5 as well.

Re:Debian compromise: probably related... (0)

Anonymous Coward | about 6 years ago | (#24767091)

"OpenSSH now has a blacklist feature for weak Debian-generated ssh keys."

From:
http://www.dragonflybsd.org/community/release2_0.shtml

Please do just a LITTLE bit of research before posting.

Re:Debian compromise: probably related... (2, Interesting)

daveewart (66895) | about 6 years ago | (#24769449)

"OpenSSH now has a blacklist feature for weak Debian-generated ssh keys." From: http://www.dragonflybsd.org/community/release2_0.shtml [dragonflybsd.org] Please do just a LITTLE bit of research before posting.

Please do some research before telling someone else to do research before posting.

DragonflyBSD is a fork of FreeBSD and not exactly mainstream so you can hardly accuse me of not being aware of what it said. Further, apart from that remark on the page you linked-to claiming that "OpenSSH contains a blacklist feature", there's nothing to suggest that OpenSSH itself actually contains any such blacklist management.

My research: There's nothing in the OpenSSH ChangeLog at ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/ChangeLog [plig.org] which mentions blacklisting and there's nothing in the source tarball either. I've looked (both the core distribution and the portable version).

It may be that DragonflyBSD includes blacklist management, but if so, they didn't get it from OpenSSH.

I raised the bug https://bugzilla.mindrot.org/show_bug.cgi?id=1469 [mindrot.org] because I thought that such a feature should be included. If the OpenSSH developers were interested in supporting this, I'm sure they'd have (a) commented on the bug and (b) written the code or used some of the contributed code. They may well have good reasons for not including this, but they haven't commented either way.

Re:Debian compromise: probably related... (1)

mzs (595629) | about 6 years ago | (#24769997)

Not really it looks like the DragonflyBSD folks added the Debian patches and these are not to be found in the OpenSSH sources. But that is sort of a joke actually. The tool is called ssh-vulnkey, and you can find a patch for it here:

http://people.debian.org/~cjwatson/openssh-blacklist.diff [debian.org]

There is a man page for it, here is an online version:

http://www.tin.org/bin/man.cgi?section=1&topic=ssh-vulnkey [tin.org]

What it does is a binary search of key files against /etc/ssh/blacklist.TYPE-LENGTH files. It can be used to hunt for bad known weak keys. You can download the blacklist files here from debian:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz [debian.org]

The README describes it better (I had to trim the junk characters):

This package contains a set of default SSH keys that were known to have
been generated during the time when the Debian OpenSSL package had a
broken Random Number Generator.

The source package contains the full fingerprint of the vulnerable keys
in blacklist.RSA-2048 and blacklist.DSA-1024. The installed package uses a
partial fingerprint for identifying the keys by stripping off the first 12
bytes of the fingerprint.

Also there is a new feature of the patched sshd that searches the blacklist files for matches. It can be disabled by the 'PermitBlacklistedKeys' option to sshd.

So the reason that this is funny is that how this works is that there is a list of known weak keys. If some user generated a ssh key pair on an affected Debian box, you're affected and the blacklist won't do you any good.

Re:Debian compromise: probably related... (1)

mzs (595629) | about 6 years ago | (#24770271)

I just realized that what was done is that all plausible Debian DSA 1024 bit and RSA 2048 bit weak keys were hashed and some bytes stripped away into a more than 7 MB of files. Ouch!

I don't think that is comical anymore just not practical. What if someone had a key of a different size for example? Also what about someone with a valid key but when you strip away the 12 bytes of the hash now it matches? What about servers with time/space constraints?

Re:Debian compromise: probably related... (0)

Anonymous Coward | about 6 years ago | (#24768711)

Remind me again, why in the world would I be running my OpenBSD server with the keys to it's SSH sever generated on a Debinin/Ubuntu machine?

Re:Debian compromise: probably related... (1)

daveewart (66895) | about 6 years ago | (#24769023)

Remind me again, why in the world would I be running my OpenBSD server with the keys to it's SSH sever generated on a Debinin/Ubuntu machine?

That's not the problem. The problem is user keys (not server keys) generated on a Debian/Ubuntu machine which are then uploaded to a server. Any server. Running any distro/OS which is capable of running sshd.

GNAA & Debian (0, Offtopic)

Jizzbug (101250) | about 6 years ago | (#24770051)

Last year's Debian Project Leader, Sam Hocevar, is a senior member of the Gay Nigger Association of America. Sam can be found, along with several Pakistani terrorists, on IRC in #gnaa on NiggerNET (SSL on irc.gnaa.us port 6697).

See here:

http://commons.wikimedia.org/wiki/Image:Gnaa-logo.png [wikimedia.org]

Not only does the GNAA seek to destroy Slashdot and Wikipedia (honorable goals), but they are very experienced with using botnets for fun and profit.

NEVAR 4GET: The Aliens come from France!

Re:GNAA & Debian (Offtopic WHAT?) (0, Offtopic)

Jizzbug (101250) | more than 5 years ago | (#24772975)

How is Debian being led by a GNAA member off-topic?!

Let me spell out the scenario for you:

"Hello, I'm Sam Hocevar. You might remember from such movies as Gayniggers From Outer Space. I am running for Debian Project Leader. I am from France. I work for the GNAA, we sell botnets to Russian gangsters."

A year later...

"Somehow a predictable pseudo-random number generator crept into our SSL/SSH packages, and Debian boxen can now be taken over by botnets. We are working to remedy the situation. My name is Sam Hocevar, and I approve this message."

Now do you get it? See how on-topic that is?

Hey! Who WOULDN'T trust their operating systems to botnet operators??!?

I am invulnerable to this attack! (2, Funny)

Anonymous Coward | about 6 years ago | (#24767557)

I have sucessfully computed a easy and 100% affective plan to stop this attack I have cleared the cookies, defragmented the memory drive, emptyed the recycle bin and set the Internet security zone to 'high'. Last off all I downloaded the latest Linux Kernal and extracted it to C drive.

Now it will not affect me i advice everyone else just follow these simple steps and you will be safe to.

And the news is? (1)

gweihir (88907) | about 6 years ago | (#24767883)

This is a standard attack. The only thing SSH specific is that many users set up their accounts to be able to do password-less ssh login. Incidentially I do this to, since I am running mostly identical installations at both ends anyways. The only additonal risk (if any) is that an attacker does not need to wait until you do a login (ans sniff your password), but can go ahead immediately.

Side note: I do not think this has anything to do with the recent debin vulnerability. For that one you do not need to steal credentials.

Re:And the news is? (1)

Ant P. (974313) | more than 5 years ago | (#24773319)

If an attacker can sniff your login password during an SSH connection, you're already fucked anyway.

How can I figure out if a key is affected? (1)

Bananenrepublik (49759) | about 6 years ago | (#24768463)

See subject, all this talk about checking if keys could be affected, but how does one do that? E.g. gcc.gnu.org should be very interested in this, as all access is handled by ssh keys, and getting every gcc contributor to change their key sounds like an uphill battle, whereas forcing the few affected should be easy enough.

Re:How can I figure out if a key is affected? (1)

mzs (595629) | more than 5 years ago | (#24771013)

Debian put together a patch:

http://people.debian.org/~cjwatson/openssh-blacklist.diff [debian.org]

There is a tool in there called ssh-vulnkey and you can get the blacklists from debian here:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz [debian.org]

You need to run the install script as some bytes get stripped from the provided blacklist files.

Re:How can I figure out if a key is affected? (1)

Bananenrepublik (49759) | more than 5 years ago | (#24783837)

Thanks for the pointer!

Deny-hosts (3, Informative)

johndmartiniii (1213700) | about 6 years ago | (#24768667)

I've been using a package called DenyHosts for about 2 months now. It's in the Debian repos. It just reads the auth.log file and blocks ssh login attempts based on the parameters that you set. It's cut back on my login attempts by about 40% since I started playing with it. It helps a great deal even if you are doing password-less logins, because it will block based on the user, whether it is valid or not, root login attempt, et al. denyhosts.sourceforge.net [sourceforge.net] It's worth looking into as an extra layer of security.

Re:Deny-hosts (0)

Anonymous Coward | about 6 years ago | (#24770155)

I too have been using DenyHosts for ages. It pretty much stops all brute force attacks; with the side benefit that you can ban that particular IP from your entire server. Hell, its even set up with a master server that can propagate attacks to other users.

Re:Deny-hosts (1)

WuphonsReach (684551) | more than 5 years ago | (#24777281)

Easier tricks for us...

1) Move the external SSH port to some other port number. Easy change. A minor road-block, but one that works well at cutting out about 99% of the attack attempts. Plus, if they have to port scan the server to find the SSH port, it gives you an opportunity to detect the scans and shut them down.

2) Don't allow root to login over SSH. You'll still see a lot of people who haven't disabled that...

3) Force users to use SSH keys to authenticate (no password-based authentication). Yes, it doesn't address this particular issue of stolen SSH private keys, but it does put a pretty large roadblock in the way of brute-force attacks.

4) Limit the # of accounts on publicly available servers.

We haven't tried deny-hosts yet. I keep meaning to, but haven't had time to go digging into it yet.

Always use a new kernel (1)

jessedorland (1320611) | about 6 years ago | (#24770237)

Whenever I install a new distro, I compile a new kernel on it. The default kernel is normally very bloated -- most of loaded modules are not even used by hardware,and it is also weak on security. Atleast this has been the case with Ubuntu. Finally, custom kernel is be very strong on security.

Re:Always use a new kernel (0)

Anonymous Coward | more than 5 years ago | (#24772513)

wow seems like a lot of work to just make the system usable.

Use DenyHosts (2, Informative)

metallurge (693631) | more than 5 years ago | (#24770529)

DenyHosts [sourceforge.net] is a handy little script that watches your ssh port, looking for brute force/dictionary attack attempts. Then it blacklists those IP addresses. You can also set it up to share your blacklist with others, and/or to update your own blacklist with what other users have found.

New Huge Linux Security Hole! Linux Under Attack! (1)

kwabbles (259554) | more than 5 years ago | (#24771833)

U.S. Computer Emergency Readiness Team (CERT) has identified a potentially disastrous new security flaw in the 2.6 branch of the Linux operating system. This flaw, if exploited, can allow a machine to be compromised completely and a new rootkit called "Ubuntu LiveCD" can be used to make whatever changes the attacker wishes to the Linux operating system.

We've found that if an attacker can gain physical access to the computer they wish to compromise, they can insert this rootkit CD into the drive and press the reset button on the computer. They can then boot from this CD and use this new rootkit to do whatever they wish to the system. After a reboot, the Linux operating system comes back online and is completely compromised.

CERT is currently investigating new means to fix this rather serious flaw in the Linux operating system.

SSH should be locked down in any case (1)

jonnyt886 (1252670) | more than 5 years ago | (#24857635)

Any SSH daemon listening on the public network should already be locked down to a basic level (denyhosts, changed port, IP-based access controls) in any case. I guess some installations will not be able to implement all of these but they are in the minority.

I'd take an educated guess at the vast majority of SSH daemons being used for remote administration; at the very least the controls mentioned above should be in place! Sure, this won't make you invulnerable, but the default denyhosts configuration alone (iirc) will limit the number of keys an attacker can try before he is locked out and an admin is notified.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>