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.
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.)
Dictonary doesn't really mean English Dictonary, but a sorted list of common passwords and variations. Then just cycling through all of the entries. https://en.wikipedia.org/wiki/.... The dictonary may well be based of stats and possible characters not used in english grammer.
Momento Mori
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
yes yes exactly . .. .. Ry&z89*oPl
By then my dear, we are gonna be in the quantum world.
More than anything else, This is about open source .
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.
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?
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.
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)
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)
The first entry in my dictionary is now 'O0k9uehry&6$83'. Check and mate.
Most linux users don't know this, but the man pages were named after Chuck Norris. Chuck Norris fsck'ing hates noobs!
The classic dictionary attack is a way of figuring out what a password is from a hash. "You keep using that word ...."
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
My question is, how does this apply to DenyHosts?
My guess would be that I'm still safe... try root at all, instant ban. Try an invalid account, grace one time (even I make a typo sometimes). Try a valid account more than 3 times? Banned. Unless, of course, this attack somehow bypasses the mechanism DenyHosts uses to detect those invalid logins... but I don't know that I saw enough information in the article to answer that question.
Life has many choices. Eternity has two. What's yours?
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.
Denyhosts depends on login failures being logged to /var/log/auth (or similar) and it only checks those logs periodically (maybe once a minute?) The article indicates this bug allows a large number of attempts per *connection*. Does ssh even log the failure if the connection is not closed? I don't know the answer to that. In any case, it can make a lot of attempts in the interval between checks of the log.
Ignorance killed the cat. Curiosity was framed.
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.
My current count for blocked hosts is 19432: sudo egrep '(^ALL|^SSHD)' /etc/hosts.deny |cut -d" " -f2 |sort -n |wc -l
[clippy]It looks like you're trying to save your file and quit using vim![/clippy]
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.
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.
My password is 'gullible', so it should be safe.
Escher was the first MC and Giger invented the HR department.
Is that perl code?
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.
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.
Sent from your iPhone?
Faster! Faster! Faster would be better!
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...
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
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.
You shift with your left hand and are right handed. Not really all that random. Decent CPUs can use deterministic algorithms to guess probable outcomes and create a dictionary based attack that would, eventually, find your password quicker than you might think. Not that I am an expert or anything but I have been cramming a bunch of articles on the subject into my head in an effort to pass time.
"So long and thanks for all the fish."
You have no idea how many people I have told that there is no such word as gullible who have then gone on to look it up in a dictionary. It is sad and glorious all at the same time. I had a dictionary in my office and used it way too frequently for this joke. I used it a number of times while interviewing candidates. It was not a deal breaker but it was close. "No, really. It is not a word. Look it up..." It was far too easy to get the word gullible into a conversation. If you get bored and have a dictionary or a web browser handy then try it sometime.
It is sort of like my favorite joke...
"Do you want to hear my favorite joke?"
"Sure..."
"Okay, but I must warn you - it is my favorite joke and you won't like it much."
"Umm... Okay..."
"Ask me if I am an orange."
"Are you an orange?"
*look at them like they are an idiot* "Nooooo....?" *pause* "I love that joke." *meander off laughing*
"So long and thanks for all the fish."
You jest, but that's the exact purpose of many "How strong is your password?" websites.
They get a nice dictionnary of real-life uncommon passwords.
On a related note :
https://xkcd.com/792/
Only another 2^64 - 19432 to go, then you'll have an unhackable server.
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.
no.
Dictionary or brute-force has nothing to do with the kind of attack (against a hash or against a live service)
maybe you're mixing it up with rainbowtables.
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
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.)
Rainbow tables is a way to optimize a dictionary attack.
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.
591 chars, with up-to 3,891 bits of entropy. Estimate maximum size of the Universe, 10^113 cubic meters. Volume of a cubic Planck, 10^105 cubic meters. Cubic plancks in the Universe, 10^218. About 2^724. That many characters is enough address 2^3,167 Universes worth of cubic planck. Of course the Universe is mostly empty, but at would only be a few magnitude's difference, not enough to matter. On average, you would need to consume 2^3,166 Universes worth of energy to break that long of a password.
A bit overkill.
undoing a bad mod.
OMG facts!
Not so random. Found a FreePbX phone system that requires ssh for phone traffic to pass to the VoIP provider. VoIP provider calls once a month saying a quarter of their total bandwidth comes from one number on the clients phone system and changes the private key used to authenticate. VoIP doesn't require ssh, so after figuring out all calls are being routed to a man in the middle, ssh gets disabled and phone quality improves, VoIP provider is happy. If the hackers only knew how to maintain good call quality, they would have never been discovered.
I have a friend who likes to opine that his connection to his ISP has been much more stable since the NSA started getting involved. I'd point out that it may be due to technical improvements but it is more amusing to hear him go off on his rant. He jokes about giving control of the whole infrastructure to them. At least, I hope he is joking.
"So long and thanks for all the fish."
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
You can configure F2B to do an action on a ban. A desirable action to is kill all existing firewall states for the offending IP address. This may take a brief moment, allowing more than 3 failed password attempts, but it will not take too long, reducing the window for failed attempts to only a few seconds at most after the 3rd failed attempts. More than likely it would be milliseconds.
no, they are a way to optimize a hashbreaking attack. A Dictionary attack against a webservice cannot be done with rainbowtables.
A coworker just tossed her copy of Merriam Websters at another coworker. While this was obviously a dictionary attack, it's not the classic dictionary attack where a hashed list of passwords and the associated user names is stolen and the passwords are reversed using a dictionary of common passwords, in the hope (or knowledge) that a user of interest will have credentials that will be revealed in this way.
A repetitive attack against a service is so easy to prevent it's not even worth talking about.
Dictionary Attacks are just a class of attacks, which use dictionaries instead of brute-force (a-z aa-z ba-z, ...).
So they can be either online or offline.
Or in real life apparently. HR is counselling her now.