Slashdot Mirror
Bug Exposes OpenSSH Servers To Brute-Force Password Guessing Attacks
itwbennett writes: OpenSSH servers with keyboard-interactive authentication enabled, which is the default setting on many systems, including FreeBSD ones, can be tricked to allow many authentication retries over a single connection, according to a security researcher who uses the online alias Kingcope, who disclosed the issue on his blog last week. According to a discussion on Reddit, setting PasswordAuthentication to 'no' in the OpenSSH configuration and using public-key authentication does not prevent this attack, because keyboard-interactive authentication is a different subsystem that also relies on passwords.
two minutes could allow for thousands of retries, which could be enough to guess common or weak passwords using dictionary-based attacks.
I really donâ(TM)t think dictionary attacks are going to work for any serious servers . Just take this random password for example O0k9uehry&6$83
The unofficial official FreeBSD security posture: two layers, where the outer layer has a singular purpose in life.
Protecting sshd using spiped
And embrace Microsoft products and their vulnerabilities of the year
This is about OpenSSH, genius.
On my edge router, I use TCPWRAPPERS to block access to a number of quasi-public services, like SSH. If the attacker isn't coming from the limited number of IP addresses allowed, the attempts get stopped and logged. Too many rejects, and they land in my edge ACL for all services, not just SSH. (Going on the theory that a bad apple hitting SSH probably has other bad habits.)
That feel when you have ChallengeResponseAuthentication set to "no" in your sshd salt state.
Time to leave OpenSSL and its vulnerability of the week behind.
This has nothing to do with OpenSSL other than that OpenSSH uses OpenSSL. This is a bug in OpenSSH itself.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
H and L only differ on the 6th bit. You can't expect from everybody to have all bits right!
However, OpenSSH servers with keyboard-interactive authentication enabled, which is the default setting on many systems, including FreeBSD ones, can be tricked to allow many authentication retries over a single connection, according to the researcher. “With this vulnerability an attacker is able to request as many password prompts limited by the ‘login grace time’ setting, that is set to two minutes by default,” Kincope said.
It is bad, but not so bad. At least the connection resets after 2 minutes by default.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
More than anything else, This is about open source .
Hi sexconker (1179573)! We know its you, because you've forgot to tick the "post as AC" box once:
http://news.slashdot.org/comme...
Jesus christ, are you stupid? Flaws existed in software before microsoft even existed. THis flaw isn't even a mild flaw considering nobody worth a squirt of piss would ever rely on passwords to secure any SSH - be that from microsoft, libre or open.
As always, you should use Fail2ban or a similar tool anyways in addition to all the other security-measures. Fail2ban prevents you from taking advantage of this bug.
Yeah that would be OpenSSH. Just get it on a vendor-supported distro like RHEL and you're golden.
I have a web server at home running openssh, open to the world (for reasons that are not critical here). I regularly have various idiots trying to hack in to it, which I find amusing.
The majority of attempts are done on root. It is not unusual to have thousands of attempts in 24 hours. They'll never get in that way; not because the root password is difficult (it is difficult enough that a few thousand guesses would not likely be sufficient) but rather because like any sane person I don't allow root to log in through ssh.
Occasionally I see "white pages" attempts, going through long lists of common names. They make usually no more than 3 attempts at each name (I presume one attempt is blank, haven't bothered to see what the others are). The problem with that strategy is that they pretty well never hit a valid name. Being as my ssh server won't respond any differently to a valid name than to an invalid one, they never get any useful feedback on that endeavor.
Now, important systems (say at large corporations) are probably targeted by more dedicated attempts than what gets directed at my server. I mostly see script kiddies from China who give up after 24-36 hours. These kids certainly won't benefit from this bug.
That said, I will still patch my server.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Why would they want to destroy something that they support?
He was referring to SSL; the topis is SSH, an unrelated remote shell/tunneling package. Seems there's plenty of "stupid" to go around, huh?
trying to move away a bit from the open source stuff just to avoid nasty surprises like this.
You don't know if there are more or fewer bugs in proprietary stuff since most bugs and vulnerabilities aren't made public and as such I do have to ask if this is really an informed decision on your part and not just bias -- you're seeing a lot more exposed bugs and vulnerabilities in F/OSS - stuff because they're more openly publicizing such details, thus you start to believe that there are more bugs and vulnerabilities in F/OSS - stuff to begin with.
Re-using the existing connection is of course useful to fend off the traditional killing techniques for rapid-fire password guessers (such as http://home.nuug.no/~peter/pf/... and similar), but you still have to come up with the set of bytes that will let you authenticate. Which leads to the other thing --
The clowns I have been writing about ("The Hail Mary Cloud" -- http://bsdly.blogspot.ca/2013/... and links therein) used a totally different approach, but the general advice re passwords and other issues given in the conclusions apply here too.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
Every computer exposed to the internet should have an account lockout policy in place. For example, pam_tally can limit speed between password attempts and also lock the account on X number of bad passwords. Furthermore, some sort of intrusion detection should be in place. Fail2Ban, for example, is an exceptional added layer of security which will ban the IP upon failed attempts.
In short, "yawn" over this security bulletin. This is non-news.
I'd recommend a decent admin. An admin who, having to leave password authentication enabled for whatever reason, fails to secure his machines with good passwords (which is what this bug exploits) isn't competent to administer such "mission critical" hardware.
the project denyhosts could help with that, by blocking the IPs that have too many fails. ref: http://denyhosts.sourceforge.n...
Be or ben't
I see this all the time too. PubKey authentication only, Fail2Ban and no root logins help to keep the log clutter to a minimum.
After finally weening myself off of using the root account locally I now just lock root completely. "sudo passwd -l root". Doesn't disable root so "sudo su -" still works but you can't login directly as root when the password is locked.
Although there is less traffic in the logs now I still get some entries before F2B kicks in and I find some of the non-root attempts very amusing... oracle, admin, ftp, PlcmSpIp, zhangyan
Some are obvious service user account attempts and some are just weird!
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Mod parent up. Too cheap to pay for a good admin, get hacked and ask dumb questions about what to do.
Moooooo.
cows
From his denial there it sounds like serious mental illness may be at play - schizophrenia perhaps. Somebody is probably going to doxnswat him now, thinking it's for his own good, but really it isn't. The cries for help were good, but fellas - guns are never the answer to medical problems.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I gave him all 5 of my "troll" points...
The ssh.com people are still selling theirs as I recall. Go ahead and ask them for indemnification against breaches, though - I'm sure they could use a good laugh on a Wednesday.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
>Microsoft starts "supporting" open source and then all of the sudden there are security holes popping up everywhere.
Yeah, just like git is super vulnerable now that they added world-class git support to Visual Studio...
It's appears to be a non-issue for CentOS 6/7 as ChallengeResponseAuthentication is set to "no" by default, which also sets KbdInteractiveAuthentication to "no" (the suggested work-around).
Some very simple tests based on cut and paste from http://arstechnica.com/securit... indicate that on a default install of OpenBSD with a randomly picked username, you'll get 3 tries only before the connection shuts down.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
Note to exploit this would require that you used a dumb password on that critical server, connected it's management ports directly to the internet, and failed to use any monitoring software like fail2ban.
In such a scenario, so sshd is going to save you. Any will have some imperfection. On our critical servers, sshd runs on a non-standard port, so script kiddies never find it, we use good passphrases they wouldn't guess anyway, we installed fail2ban so they'd get blocked when they started trying, and recently we starting putting ssh behind an openwrt vpn. So there are four reasons we're not worried. Try using at least two of these four protections:
Good passphrases (not "qwerty" or "admin")
Non-standard port
Fail2ban
If you're really serious, vpn first
Didn't MS's OpenSSL support come after the the issues from the show-stopper vulnerabilities from last year? Before the big names started putting money into the project, it was pretty much maintained on a shoestring by volunteers who were earning nothing, and who really don't deserve the wrath poured on them.
MS is a good guy here.
No one reads the stupid source anyway. At the end of the day I just want shit that works.
What you describe are automated attacks, yes the majority are from China... they are only looking for low hanging fruit which is why the attempts don't look very clever, but they don't have to be. They don't care about your server, they care about getting as many servers as easily as possible, and you do that by automation and wide spread attacks.
It's still good to stop these attempts from littering your logs and taking up resources so you can spot directed attacks by an actual person, not using default ports is the first step, fail2ban or other attempt limiting utilities as mentioned by others here are the next step.
Don't be so cocky with your massive log of failed access attempts, everyone gets those, you should consider what happens when something with a brain tries to hack your server with a modicum of effort.
And what happens when you go into recovery mode when the system fails to boot? Does the lock on the root account just get ignored?
written by paid experts
OpenSSH and its forks are.
and tested with professional quality assurance?
They are being, especially with the latest bugs found. This is why the bugs are being discovered after years of everyone assuming the QA has already been done.
We have some mission critical UNIX boxes and cannot take risks like this.
In that case they should not have SSH exposed on the internet. Allow SSH access only from an administration VLAN. Use VPN access to access the VLAN. Multiple levels of security based on multiple implementations adds more security as both must be exploited at the same time which is harder than exploiting either one on its own.
Lately we have been trying to move away a bit from the open source stuff just to avoid nasty surprises like this.
You have no guarantees with closed source. Their QA might not catch everything (it almost certainly won't). Published source code means more people can do the QA, who may have different/better tools and expert knowledge. Open source doesn't mean it's amateur, most open source projects are heavily contributed to from companies including some very large names.
OpenSSL's problems aren't from Microsoft. Honestly, Microsoft isn't nearly as bad as they used to be, security wise. It's a relief, really - I've been UNIX only for almost two decades, but I still have to maintain a few Windows machines for family members.
There's an excellent talk by one of the LibreSSL developers at BSDCan 2014 that explains a lot of what OpenSSL's problem was (and still is, although there's been a lot of work done since to improve matters). Basically, it boils down to poor project management; the primary maintainers were focused on expanding capabilities rather than maintaining "working" code, and it eventually turned into a horrible mess that no one wanted to tackle. After all the security issues (culminating in the Heartbleed vulnerability), several people "had enough" and started trying to fix it - LibreSLL, BoringSSL, etc.
I highly recommend the LibreSSL Valhalla blog if you're interested. The early posts are pretty funny, if you're into that sort of thing.
Those who can't do, teach. Those who can't teach either, do tech support.
They don't care about your server, they care about getting as many servers as easily as possible, and you do that by automation and wide spread attacks.
I should have been more verbose, I am fully aware that they don't care about my server specifically. Indeed they would almost certainly try a lot harder if they did.
Don't be so cocky with your massive log of failed access attempts, everyone gets those
I am aware that it is quite common. I was not intending to come across as "cocky", I'm not sure why you came to that conclusion.
you should consider what happens when something with a brain tries to hack your server with a modicum of effort.
If someone wants badly enough to get in, they will get in. Indeed as you said most of the Chinese attempts are just looking for highly vulnerable systems that they can easily get in to. I have my system open in the way it is open for a reason, and I accept the risks that go with it. So far it has worked out for me; nobody has felt it was worth the effort to get in (and if they did get in, they would likely conclude afterwards that it wasn't worth the effort!). I know a lot of the script kiddies are doing this to try to build botnets; if my server suddenly started going apeshit in the middle of the night, it would be time to power it down and reinstall the OS from scratch.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
I used to have an openssh port opened to the world and I loved looking at the logs! Tons of root attempts, some popular names like John and some I wouldn't expect but don't remember now.
More than anything else, This is about open source .
how so? are you saying that vendor or closed code doesn't have similar errors?
Limited use of connections, tar-pitting, etc. are only for really bad passwords and provide only limited protection even there. Anybody that understands security already has passwords that are not guessable in practice.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
What are you even responding to here? You're just adding to the level of stupid.
Compile without OpenSSL support. I'm not sure why OpenSSH depends on OpenSSL anyway - X.509 certificates, maybe?
The faster they can blow through their dictionary the better. If 24 of these Advanced Persistent Chinese crackers get born every day going after me, and they can blow through their dict. in an hour I'll have 24 of them to deal with a day. If I make them spend 2 years doing it, then I'll have to deal with over 9000 knocking on my door.
It uses the crypto funtions in OpenSSL, not the SSL parts.
Have you considered a rate limiting system like fail2ban which blocks servers for a set time after a set number of failed logins?
Most of the time I see IP addresses come in, try root with a few password combinations and disappear back into the ether. But a few times I've seen bots attempt full dictionary attacks filling up my log files with useless SSH login errors. Fail2ban stopped that in its tracks and with a 15minute penalty for 3 login attempts I now see the number of logins reduced to the hundreds rather than the 10s of thousands.
Even better vpn to vpn to ssh.
Actually scratch that. vpn all the way down is the best.
THis flaw isn't even a mild flaw considering nobody worth a squirt of piss would ever rely on passwords to secure any SSH - be that from microsoft, libre or open.
The majority of servers running SSH rely solely on username and password authentication.
A strong, unique password known only to a single user is the most secure protection available.
Certificates don't add shit on top of that in terms of actual security.
No, it's not me.
I've mimicked the cows thing a few times, because I find it funny. I've only once copypastad it exactly.
I don't post as AC when I'm trolling or spamming (because who gives a shit?).
This one wasn't me. I wish it had been, though.
Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop]. More on this logger and my security config below.
Apparently, the keyboard interactive problem has been known [by Redhat] since at least July 2013, see https://access.redhat.com/solu... and it sets ChallengeResponseAuthentication to "no" to specifically disable keyboard interactive.
I added a line to /etc/pam.d/xsshd with pam_exec.so so I could invoke a custom logger I wrote. I also have CRA set to "no" [I can't remember where I found this originally]. The logger also adds a random delay, to slow down the script kiddies. Although not required, I've patched sshd to post the real bad password to the logger. The default action is to use a standard junk one if the username is invalid [to prevent timing attacks]. Since I add a random delay, the pw obliteration isn't required.
I've also use /etc/security/access.conf [used by PAM] to allow password logins from the local console or virtual terminal, X11, and local LAN. All else is denied.
Thus, ssh can only use pubkey authentication, so even if a valid login/pw combo is presented, it will fail.
From what I've seen in the logs, it isn't just common/simple passwords that get tried. It becomes obvious that some systems have been hacked, the /etc/passwd and /etc/shadow files have been taken, and the passwords cracked offline [e.g. via rainbow tables, etc.]. They are now being replayed from a database of known/valid combos. I've seen certain user/pw combos from years ago that show up again recently. Not just a single combo, but an entire sequence of them in the same exact order.
This actually provides a signature of the attacker that can be tracked. It appears there is some black market for these databases as they're too specific to be just "let's come up with a list of most probable common passwords". They're hoping that person A (using password B) created a login on system C and the person reused the login/pw on other systems (e.g. D)
The [Chinese] script kiddies are getting dumber [or smarter]. My logger used to do random delay of up to 40 seconds. This slowed them down and because they can only attack so many systems in parallel, this helped the victim community at large. It also prevented them from trying thousands of passwords/second on my system [which they did by having hundreds of separate ssh sessions].
Eventually, the "replay" list gets exhausted and the attacker moves on [possibly showing up years later, sometimes from a different IP address]. But, lately, if the delay is over a certain amount, the request gets timed out by the attacker and they will repeat the same login/pw in an infinite loop. This prevents them from progressing through their list, but it also means they will never stop hammering my system [because the list never gets exhausted]. So, now, I've set the delay to a smaller value, that still delays, but doesn't trigger the infinite loop.
Like a good neighbor, fsck is there
THis flaw isn't even a mild flaw considering nobody worth a squirt of piss would ever rely on passwords to secure any SSH - be that from microsoft, libre or open.
The majority of servers running SSH rely solely on username and password authentication.
Do you have an authoritative citation for that? I'm surprised that so many have deliberately changed
the sshd policy.
A strong, unique password known only to a single user is the most secure protection available.
Do you have an authoritative citation for that?
And no, MOO is not authoritative.
Certificates don't add shit on top of that in terms of actual security.
Is a certificate what a cow calls encryption? Why would humans put "a certificate" "on top of" passwords?
The solution (if you don't haven't deployed port knocking
Because DragonFly defaults to public key only operation. No passworded access is allowed unless the user explicitly enables it, and we've recommended against enabling it for years now.
-Matt
A strong, unique password (aka a secret) is the only thing that matters.
Certificates are nothing but long passwords that people can't remember and thus need to store in plaintext.
Encrypted certificates are nothing but long passwords that people can't remember and store in an encrypted form, thus requiring a separate password.
Encryption of a connection is done using a password. Whether you call it a password, a pre-shared key, or a certificate, it's all the same. It's a secret known only to the legitimate user.
The password is the be all, end all of networked computer security. There's a reason every single attempt to replace passwords has failed - either they reduce security or they're simply dressing up a password as something else - a smart card, an RSA clock, etc.
The problem is you don't realize what a password actually is in relation to security. It's simply the secret.
Retards who don't know what they're talking about like to prattle on about "something you are", "something you know", and "something you have".
"Something you are" is your username.
"Something you know" is your password.
"Something you have" is your cell phone or your little hardware token (nothing but an RSA clock with a seed stored on the device and on the server).
If your "something you are" is a secret username, or a hash of a fingerprint, then it merely becomes "something you know", and is effectively part of your password. If you authenticate remotely using a fingerprint scanner, the server you're authenticating into has NO IDEA whether or not the bits are coming from the fingerprint scanner or not, whether it has been tampered with or not, etc. It's all "something you know".
Similarly for "something you have", a text message code or an RSA clock or whatever else are all "something you know" when you're presenting them over the wire. Unless someone is PHYICALLY INSPECTING your shit, it's ALL "something you know", and thus all effectively pointless if you already have a strong, unique password.
People think that codes sent via text message or the seeds in their RSA clock keep them safe. They don't. If your host or connection is compromised to the point that you're leaking your password (such as a keylogger or a MITM attack), these codes are available to any attacker working in real time because you invariably send them over the same fucking channel. It's a joke!
The ONLY thing you can do to protect yourself with networked authentication is to know a secret and keep it secret. It should be astronomically expensive to crack. Use that secret to authenticate, encrypt, whatever. But adding more secrets on top of it doesn't do SHIT.
That secret is called a password. What you call it is irrelevant.
Port knocking is one way to avoid being a target of ssh attacks, but legacy port knocking has its own shortcomings. SPA (Single Packet Auth) has solved most of those problems. Fwknop is the only maintained spa implamentation that I know of. More info at https://www.cipherdyne.org/fwk...
I've read through almost all the comments on Slashdot; I did not care to read the Reddit thread, so if someone explained this there, I apologise for repeating myself.
The workaround for this problem is to disable keyboard interactive authentication permission in sshd. The sshd_config(5) man page documents how to do this, but given all the different options that seem to control different things while confusing the administrator (ex. PasswordAuthentication vs. AuthenticationMethods vs. KbdInteractiveAuthentication), it's very easy to misunderstand which one does what, where, and how.
The workaround is to set KbdInteractiveAuthentication no in /etc/ssh/sshd_config and send a SIGHUP to your main sshd process (do not use killall -HUP sshd -- sending a SIGHUP to existing sshd children causes them to exit/close cleanly, i.e. all your ssh connections will drop. You just need to send it to the master). Alternately you can use ChallengeResponseAuthentication no (which sets KbdInteractiveAuthentication no), but you need to read about the ramifications of that depending on how you have your environment/systems set up. KbdInteractiveAuthentication no is the correct workaround for the time being.
The biggest problem here is the misunderstanding of "where" the bug actually lies, so I'll do my best to explain it: the problem is that the SSH client can send to the server a list of authentication methods it wishes to use (including more than one, in which case it will be used however many times specified by the client). The bug is that OpenSSH sshd allows for basically an infinite number of authentication methods, so *in a single SSH session* an attacker can attempt a ton of interactive authentication requests (password guesses) -- sshd itself will "sit and spin" (loop) working on however many the client specified. This type of problem could apply to any type of daemon, quite honestly, and the only way I can see to alleviate it is to add a configuration open to sshd that allows you to limit the number of provided authentication methods as specified by the client (and rejecting the negotiation if the client asks for more).
Now to debunk shit I've read on Slashdot:
* Issue is not specific to FreeBSD -- it's specific to any system (which I suppose includes Windows?) where OpenSSH sshd is running and keyboard interactive authentication is enabled in /etc/ssh/sshd_config. It's that simple. Some Linux distros, and DragonflyBSD, default to not permitting interactive-based authentication, but my point is that it's not specific to FreeBSD.
* Changing sshd port number (from 22 to something else) does not solve this problem, nor does it have anything to do with this problem. The belief that switching to a non-standard (or high-numbered (e.g. userland)) port "provides security" is hogwash -- for several years now people have been portscanning the entire 1-65535 range across 0.0.0.0/0 on a regular basis, looking for identifier banners (hint: telnet to port 22 sometime).
* TCPWrappers does not solve this problem, nor does it have anything to do with this problem. All that's going to do is slow down the rate at which a person can issue a bazillion authentication requests *in a single SSH session*. TCPWrappers will help "limit" or "slow down" repeated TCP connections from a single source address -- see the above paragraph for the nature of the problem to understand why this does not solve the issue. It may allow you to stop the person from doing it after a smaller sample of attempts (e.g. say they ask for 10,000 interactive methods per connection, and your TCPWrappers config blocks an IP for 1 hour if 3 failures occur; thus they're allowed 30,000 password guesses). In general, TCPWrappers is nearly worthless in this day and age because it still has to handle witnessing the inbound TCP SYN even after someone has been blocked -- use a firewall instead and save CPU time in userland.
* Fai
Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop].
I am comfortable stating that the script kiddies are most likely attacking my system by IP address alone, not by its domain name. I say this because I have yet to see a single one of their IP addresses show up in both my system and httpd logs. Of course, they may have seen the website and then attacked it by name from another system but that seems like more effort than it would be worth. I have also searched for their IP addresses before and found other blog entries from other people online - generally people not hosting web pages at all - which also suggests these kids are just going through IP address ranges and running their scripts on any system that responds.
I do like your approaches, I may keep them in mind in the future. For now, I actually view the failed attempts as amusement. My ISP doesn't seem to care at all (even though I have a residential cable modem) and it doesn't hinder my ability to do what I need to do, so it doesn't really make a difference to me at present. I could certainly see that changing in the future, though.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.
For a while, I've been considering paring down and packaging up my scripting environment for this and publishing it on github. The sshd patch and setup/modification of the config files [including changing the selinux attributes :-(] is all done by a perl script (as is the logger).
The only wrinkle is that all users have to have set things up to use pubkey via ssh-keygen. For example, the public keys for my laptop and smartphone are entered into my .ssh/authorized_keys file on my desktop [and vice-versa]. Easy for me, since I'm the only user. Harder, if you've got an installed user base that may not have done this.
My desktop system uses two dictionary words for the password to my personal account and root account. I've grepped the log, and the kiddies never even came close. However, because I am using these words, that's why I added pubkey only for ssh access--just to be safe.
I had to firewall ssh because I just went from fedora 20 to 21 and would have been running an unpatched sshd. I just completed a reposync, so now I have the correct openssh sources and can rebuild/reactivate
Interestingly, although the kiddie attacks can come from anywhere in the world, they are predominantly from China. The whois info for non-Chinese IP's is somewhat spotty, but the ones in China have full/accurate information. Seems like the Chinese government wants to track everything back to a name.
I was considering adding automatic whois lookup, with abuse@blah.com scraping, and then send the applicable part of the logs automatically [with a copy to the FBI :-) :-) :-)]
Like a good neighbor, fsck is there
More than anything else, This is about open source .
how so? are you saying that vendor or closed code doesn't have similar errors?
of course not but it is about challenging that old open source adage about it being more secure because people can see the code but how long as this vulnerability (that is ~8 years old) been exploited for? many eyes is great, but there are almost never enough eyes.
A strong, unique password (aka a secret) is the only thing that matters
A secret matters. A secret password is not the only thing that matters. The modern default for sshd is already protected against the attack in the story - I put the relevant default setting in the post you didn't read when replying id_rsa.pub is stored on the remote system (as ~/.ssh/authorized_keys) - the only way an attacker can have access to that is if they already have access to the remote system. If they have access to the system the game is already over.
Certificates are nothing but long passwords that people can't remember and thus need to store in plaintext.
Certificates are nothing but long and complex, far more than any password could be, that people can't remember so they don't make the common mistake of using weak passwords bruteforced by the attack in the main story (which only works if you've fucked with default sshd) , and thus need to store in plaintext if you stupidly don't use a passphrase
TFTFY.
If an attacker can read the public key stored in ~/.ssh/authorized_keys on the remote machine it's game over because they have access. If they have access it's still game over if you used a password.
If the attacker has access to the local system and you use passphrases to protect your ssh keys - it's still likely game over, just as it is if you use passwords only (because they can install spying processes).
The longer and more complex the secret string is the harder it is bruteforce - regardless of whether it's a password you type or one that supply by and encryption process. To say that one you type is more secure is just silly.
Claiming that good security is based on using authentication you can remember just shows how poor your understanding of security is. That's the most common failing - not a strength. Maybe if you read and understood Bruce Shneier's articles and forums instead of regurgitating sections you clearly don't understand, you'd have more credibility (you have none on his forums either).
Why do you think Bruce recommends using encryption keys for authentication? (Hint: he's a cryptographer)
Why do you think Bruce recommends people use a password manager rather on relying on the weakest link in the chain of security (the meatbag at the end)? He wrote a password manager for that reason. If you can remember the password it will be broken.
The problem is you don't realize what a password actually is in relation to security. [...]
You've posted the same sort of babble on Bruce's forum before - it's been debunked many times, you've been called out as a dangerous fool there. And I'll call you the same here.
What are you even responding to here? You're just adding to the level of stupid.
Sex Conkers - is that you, or one of your equally stupid friends who can't work out how to follow a thread.
OpenSSH has little to do with OpenSSL, but is made by the same people that write LibreSSL.
Ha, shit that works.
Like Windows, where for the last 20 years you give away administrator access (no password needed) just by reading a webpage, or opening a document, or running an app.
This kind of "shit that works"?
https://technet.microsoft.com/en-us/library/security/ms15-078.aspx
I'd certainly take working open source that just lets someone try and fail to guess my password, than your shit that doesn't work that gives it away no password required.
Eh? That font vulnerability was quickly fixed in KB3079904, although I still don't see how it's related to passwords.
you sure about that?
I mean, the point of the entire bug(more like a feature tbh) is that it gets around conventional checks for multiple failures(which is why you wouldn't be able to do this much of bruteforcing on normal connection because you would be banned).
the original blog post is unclear about that.
world was created 5 seconds before this post as it is.
I was seeing the same behavior on my SSH server. I was not worried that these guys would ever get in but the failed attempts filled the log files, making potential real issues hard to spot.
I then simply moved the SSH service away from port 22 to a non-standard port. I have never seen any break-in attempt since.
I guess that the scripts that these guys use focus on the basic use cases (e.g. keyboard-interactive root login on port 22 with nothing, "root" or "admin" as password) and if that does not work they move on to the next target.
OpenSSH commonly defaults various authentication methods to "yes", meaning you need to specify each thing that you *don't* want to allow authentication with. WTF?
>No one reads the stupid source anyway. At the end of the day I just want shit that works.
One would think that having the source available makes it easier to verify things works as intended, not harder...
Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.
It is nice to see someone not calling me crazy over doing such things. I wouldn't do this in a production environment, and suspect you likely wouldn't either. Sometimes free entertainment is a funny thing in what some people find entertaining, I guess :)
I was considering adding automatic whois lookup, with abuse@blah.com scraping, and then send the applicable part of the logs automatically [with a copy to the FBI :-) :-) :-)]
Have you had any luck getting responses from Chinese ISPs when you report abuse? I used to do it fairly regularly but for years now it seems like I might as well just send the report to /dev/null instead. While the lack of response doesn't mean they aren't doing anything, it doesn't support any notion of the email being read by a human being, either.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
That's a good question and I honestly can't say it's come up. My guess is that if you are in single user mode then the lock is ignored. But that is just a guess, I'll have to experiment with sometime.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
OpenSSH does not depend on OpenSSL.
Good passphrases (not "qwerty" or "admin")
I don't do passphrases. All accounts on my systems have lock-out passwords ("*"). If you want to log in, you need to use an SSH key.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Honestly, Microsoft isn't nearly as bad as they used to be, security wise.
And here we are with Font vulnerabilities
This is broken so badly, that no popular (modern) browser can protect you against it. (Excepting, of course, console/text-based browsers, if any on Windows.)
What's relevant here is the password/passphrase you'd use if you were at the console, using a keyboard attached to the machine. So ssh keys, while a good idea, don't apply in this instance.
If it was sexconker, the conversation would have been more LOW brow. (moo)
undoing a bad mod.
OMG facts!
I never did post anything back to an ISP. I assumed the result would be what you saw in practice. Also, if it were "state sponsored", they would ignore it. If it were somebody trying to find a portal that would circumvent the "Great Firewall of China" [which I'd be in favor of], posting back might just "out" them [to the government].
I just got sshd patched/reinstalled. I just reverified that it disallows login/pw from public IP but allows login from local LAN on accounts that have no pubkey. So, I opened the firewall for sshd [it had been firewalled for two days]. It took exactly five hours for the first script kiddie to show up.
No, you're not crazy. If you are, then I am, too. People that say that are usually uninformed/unaware of what truly constitutes good security. IMO, security is relative to what you're trying to protect. Good security should be minimally intrusive to authorized users. People who bandy about the "crazy card" are most likely to implement systems that regular users try to circumvent (e.g. mandating a 30 character password with funky chars will just cause users to put the password on post-it notes). Note that for website logins, I use a different login for each site, and different funky password. Most of the time, the browser password manager takes care of the pain.
I have [being a systems/kernel programmer] have worked on some "security" projects, and some of the people I worked with were "crazy". By that I mean, they locked down the development environment to the point where it was almost unusable and productivity suffered. In addition to genuine security, they also subscribed to the "security through obscurity" doctrine. This seems to be typical, based on my experience, and what I've read about what Linus [Torvalds] has to say about them.
OTOH, I worked on a realtime broadcast quality realtime H.264 encoder. While everybody had a personal login, the lab encoders' root password were "password". We made this decision from day one that the test encoders were "test equipment", just like an oscilloscope. This was fine, because the entire lab subnet was triple firewalled and even if somebody had logged into root on the encoder, it would let them roach it, but not get access to anything that mattered like the CVS server, etc.
Here's a different type of "crazy" ...
Ironically, the only place where we had to use high security was in product shipments to our principal customer. Updates had both software changes and firmware changes [to custom hardware], which were QA'ed as a unit. But, this customer felt that software updates were okay, but that firmware updates were too "risky" [and that they knew better than we did]. So, they would apply the software changes but not the firmware ones, and then complain to customer support that "things were broken".
We were providing "enterprise grade" customer support [including onsite visits] and even after telling the customer to update the firmware they wouldn't do it. To solve this, we [engineering] made it [had to make it] impossible to do a piecemeal upgrade [with a nearly impossible to remember root password and disabling any override to the boot process].
Also, we had a rev numbering scheme that was X.Y.Z where Z was for simple/minor bug fixes. That same customer balked, thinking any change to Z was "a major change" [based on number of "dots"]. We solved this by shipping them the revs as 1.X.Y.Z and they were happy once again [blissfully unaware].
I'm probably going to be labelled crazy for what I say below. It's a rant about selinux in "targeted" mode, so you can skip it if you want.
selinux was designed [by the NSA] to provide security for gov't systems that have multiple levels and classifications. Confidential, secret, top secret, most secret, etc. And, need to know classifications like "noforn" [no foreign], "five eyes" [US, Canada, England, Australia, ???], etc. This is useful. An example would be applyi
Like a good neighbor, fsck is there
In ten years you've not had any servers with any kind of network problem, firewall issues, or "won't boot" kind of issues? Clearly any of those would prevent you from using SSH, so would have to be fixed from the console (possibly with a KVM extending the console physically).
I suppose if you only manage one server and never touch it, it might never have any network problems or boot failures.
Nope. I have not seen a single physical server in a decade, and at this point, I run everything in AWS. If an instance has a problem, I just snapshot it, kill it, and launch a new one. Once that's done, I can take my time reviewing the logs and state from the failed instance's snapshot to try to avoid future faults.
I literally have every password in /etc/shadow set to *. There is not a single account on any system with a valid password hash in shadow (as is the default on most AWS images). This is why I give zero hoots about brute forcing passwords.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock