Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:A plea to fuck off. (Score 1) 327 327

That was a very long post with very little content and attempted to retort my comments by talking about admins failing to enforce password policy, and missplacing trust in fail2ban.

So I invite you to re-read my post above. If you don't want to let me highlight the critical parts of my post: ... the passwords are strong ... ... before any talk of login limits ...

So if we take talk about admins enforcing strong passwords and the use of fail2ban out of your post above explain to me again why I am so very vulnerable? Even bouncing through proxies you're not brute forcing a local file. You can't do millions of attempts per second, and with a simple 8 character with capital and number password you have 220 trillion possible combinations.

I'm pretty sure even the dumbest and most incompetent system administrator would notice the high bandwidth / CPU utilisation of brute forcing SSH long before it's broken.

Oh and since we're talking humans and intuitions, what makes you think that someone who can't enforce basic password security is capable of securing their private key?

Logic clearly escapes you. I responded to all your previous points. You ignored them and now resort to leaping from bank to bank astride the horse of desperation.

I've never wrestled a pig before and I don't intend to start with you. I'd just wind up covered in shit and you'd just enjoy it.

Comment Re:Does BP follow best practices? Someone didn't. (Score 1) 327 327

Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment)

[Unbalanced parentheses.] Which guide to configuring keys in popular SSH clients does your documentation link to?

We don't provide one. Support refers users to the official security guides for the appropriate distro, general questions are answered using this as the main source. Documentation for users is almost identical to that on Digital Ocean (they target the same market segment). We don't write subject documentation for users. They do, if we approve it we pay them and publish it (it's the low cost end of the market, minimal SLA).

Internally we follow NIST procedures and are audited to meet several ISO 27K standards (mainly for insurance purposes). We don't own any data centres, or control the hardware. That's a very common practise, with all but the high-end hosting providers (usually).
Our internal procedures are more stringent with the main (non-hosting) business as most of the clients are Defence related (this is Canberra, the majority of work here is Defence related).

However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP.

Because BP got hacked by Chinese? Naaah.

[smile] where following BP means jumping in a tug and telling the captain to "follow that slick".

Comment Re:A plea to fuck off. (Score 1) 327 327

Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?

Because the odds of cracking a strong password via SSH on a server with root logins disabled and a 3 attempt before a long temporary ban are so infinitesimally small that I'm more worried about the sun not rising tomorrow.

There's nothing inherently insecure about a password based login providing the passwords are sent over an encrypted channel, the passwords are strong, and neither machine is compromised, and that even before any talk of login limits.

That belief is common, and incorrect.

Bear with me and I'll demonstrate why that's the case, and explain why it's a common belief.

It's complex, and most people won't invest the time to consider and understand the reasons why it's incorrect.

Many people believe it because many people believe it (a form of circular authority).
And because they over-invest in an emotionaly based opinion (which they won't test because they worry about where the results will lead - to further testing of their beliefs). It's foolish because they expend more time and energy defending their beliefs than it takes to test them, and change them when they prove wrong.
Note that those people get very angry when that emotional investment in "gut instinct" is challenged. Hence the title of this thread (it's a form of "la la la I can't hear you")

If it was correct there wouldn't be so many instances of attackers gaining access to password protected SSH.

The most common attacks (which your fail2ban logs will be full of) try a list of common passwords. That does have a low probability of success - but there are a lot of boxes allowing password SSH access. Sadly, most of those allow root logins.

fail2ban does limit attempts - by source. IPv4 only. Unless you enforce strong complex passwords dictionary attacks will succeed in a large number of cases.

Most admins do not enforce strong passwords. Key based authentication enforces the equivalent of very strong passwords - far stronger than the login buffer allows.
There's no need to guess - you can test the complexity of user passwords. Or simply enforce it by setting the default to key authentication only.

The default of encryption for a SSH connection is not relevant - it's the default. It doesn't render password access more secure than key authentication. In short it's a red herring. (there is no "providing" about it)

tl;dr your belief in the security of fail2ban is misplaced. An attacker can make unlimited attempts by just changing proxy every 3 attempts. There is a high-probability of them doing that. The more desirable access to your box, the higher the probabability.

The vast majority of unauthorised attempts you'll see in your logs are brain-dead bots looking for low-hanging fruit. Those attacks will only get smarter. Best to stay ahead of that curve.

Good security is about reducing risk as much as possible. Doing so is not about whether you "feel" it's secure, it's about whether it can be mathematically demonstrated it's safe. The point of the lead summary, and the article it references, is that it's been well demonstrated that poor passwords lead to poor security. The same big-brains that proved that also strongly recommend the banning of remote logins as root, and passwords for SSH access. There's a reason why the default SSH setting for all recent Linux and BSDs does just that - it's not to make your life hard, or the remote clients - it's to make life hard for attackers.

On the one hand as techs we want (proven) facts, on the other we are human and want to trust our intuitions, and we are lazy. It's that biased hand that is the cause of most security failures.

Comment Re:A plea to fuck off. (Score 1) 327 327

Why do you allow password logins for SSH?

I imagine that hosting providers default to password logins because it reduces support costs. Their customers tend to be unfamiliar with SSH public key authentication and especially with synchronizing these keys across multiple devices including mobile ones.

Sadly - that's the case with some VPS hosting providers, though I suspect you are being to optimistic about their motivations.

Most of the ones I'm familiar with do promote keybased ssh logins - e.g. it's the default in the images they provide. In the case of the low-cost VPS hosting company in which I have a proprietary interest, all the images we deploy (Ubuntu, Debian, and CentOS) default to no remote root login, no remote password authentication. Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment. TFA for the web management console is available - but not the default.
We don't stop users from weakening their direct access to their VMs (it's the low-end box market sector) - nor does the (bare minimum) SLA cover "shoot-own-foot".
Where I deal with hosting providers that do high-level SLAs (e.g. obsessive) BP SSH configurations are mandatory.

Why the hell don't you have port knocking enabled for SSH?

I imagine that hosting providers default to not requiring port knocking because it reduces support costs. Their customers tend to be unfamiliar with port knocking.

Again sadly that is the case - they like to keep the bar low to allow drunk toddlers drive Ferraris as long as they enter valid credit card details.

However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP. That's distinct from why some businesses allow their clients to shoot-own-foot, that's just servicing a demand.

Comment Re:On LUKS (Score 1) 111 111

No, this isn't true. Depending on the encryption mode, a corrupted bit should mean one or two blocks being lost (typically 256 bits).

Could you expand on that? Do you mean - "it isn't true that if encrypted data is modified it can still be unencrypted and the information recovered"? It does sound like a self-defeating encryption scheme (see further down as to why your user case may significantly differ). If the point of encryption is to "prevent modification or access to information at any point in time" rather than "to prevent the reading of the drive at one, known, point in time".

Recovering data from a dm-encrypted disk which has damaged sectors is possible (trickier with SSDs) - even if it's LUKS (BP is to backup the headers and the key-stripe area in addition to the information). dm-crypt does block level encryption, I assuming you are referring to the discussion in context - dm-crypt.

tl;dr you are correct, it is possible to recover data from a disk if sectors have been damaged. Whether that will result in information being reconstructed depends on the the encryption schemes employed.

Which is why backups are kept (typically 3 if that information is important to retain), and damaged disks destroyed. If someone encrypts a partition and doesn't do that I can only presume that information is not something they value as much as they don't want others to know that they have it.

I "assume" that your interest in encryption is focussed on hiding information - in which case information integrity may be less important. I have no firm opinions on that subject, and the conflicts between obscurity and security aspects of being able to detect injected malware make it too complex for me to even hazard guesses.

LUKS OTOH has a feature called "anti-forensic stripes" that is deliberately designed to *maximise* the data loss if bits are corrupted on disc. One of the worst/best examples of a mis-feature ever.

If you use encryption and want to be able to recover information if that information has changed in any way by an unauthorised process - you're doing it wrong.

Comment Re:A plea to fuck off. (Score 1) 327 327

At this point, I see more attacks against SASL than SSH and root usually has password based logins disabled.

All remote logins as root should be disabled whether they require a password or TFA. AFAIK that's the default in all current release Linux and BSD distros - as is enforcing key based authentication instead of passwords. Those things won't reduce the amount of brainless brute-forcing attempts at gaining SSH access - but will reduce the likelihood of any of them succeeding to almost zero.

Changing the default port that SSH runs on will greatly reduce the traffic you'll see. Using some form of portknocking will reduce the stupid attack attempts even further.

In no way do any of those measures replace actual security. They do reduce the chances of dumb attacks succeeding. And in many instances I'm familiar with they allow service as normal. i.e. military contractors that get so many attacks per second that no one can login until the SSH port is reassigned. That still leaves logging as a problem - hundreds of port scans a day as slightly more intelligent attacks try and find the SSH port. The addition of some form of portknocking removes most of the noise from logs leaving mostly serious attack attempts - which makes monitoring and responding easier.

Reducing the number of SASL attacks is much harder. It's relatively easy to change client settings for SSH as it's rarely baked into programs. I don't have any opinions on how to deal with that, it's something we don't deal with.

Comment Re:A plea to fuck off. (Score 1) 327 327

"Why the hell don't you have port knocking enabled for SSH?"

Because http://www.giac.org/paper/gsec... maybe.

Have you even read it? Or did you "think" no one else would?.

Was that the only thing you could find about portknocking in your Google rush?

It only says three "bad" things about portknocking:-

  • Portknocking is bad because malware might install some form of portknocking
  • portknocking is bad because it's security through obscurity - which is stupid as saying running ssh on a non-standard port is security through obscurity. i.e. obscurity is only bad if it's the only security.
  • . Which is irrelevant because not installing portknocking doesn't affect in any way whether malware might install it's own portknocking.

  • Knowing the knock can open your system. If it's the only system authentication you use. It shouldn't be.

There are other, more valid risks with port knocking which your "security powerslide presentation for n00bs from 2004 overlooked":-

  • The knock sequence could be captured. Only if you don't enforce sequence rotation. Or better, use SPA
  • It's another piece of software that could go wrong. Maybe, it's pretty well time tested and audited.
  • It's hard to log. Not really. But if you find it hard you can do the same thing with iptables or authpf.

Portknocking is not a perfect solution - it's a way to lower your profile, just like using a non-standard port, which it very effectively does - which is why it's one way of meeting the mandatory requirements for ASD privileged networks. Keeping the hordes from the gates is just as important as securing the gates.
Employ it using default settings is not recommended, I'd increased the time outs (port knock fails, the port is locked out for a few minutes).

There are alternative solutions (I've already mentioned using iptables to achieve the equivalent of kernel level portknocking, and authpf) but there are also others. But you're the expert.

Allowing ssh passwords is certainly not Best Practise security. TFA is.

fail2ban? It works with IPv6 does it? (try sshguard it does). With passwords enabled, your ssh port visible and protected from bruteforce attacks only by fail2ban you must chew a shitload of bandwidth and log space. Given that, and your earlier post, you're definitely not in a position to decide whether I'm a security professional. I don't claim to be - that'd be a full-time job in itself, but the people who work for me are, as are the clients. Just about every client here is defence or directly connected, failing an audit would be to costly to rely on the sort of citations you supply to justify using well documented Bad Practice security.

Comment Re:Lazy and Stupid (Score 1) 327 327

"Do you have a citation for that Mr. Scraps of Bad Security on Paper?"

Every fucking government agency that uses a fucking AIR GAP like a REAL PROFESSIONAL.

That's not a citation - that's just stupid. Hint: you can't use an air gapped machine on the internet you moron.

Comment Re:A plea to fuck off. (Score 1) 327 327

My server logs disagree with your assumptions. Fail2ban is running constant blocks on botnets trying to guess passwords on SSH, FTP, SASL and webesites and this goes for my day job, my personal server and my evening contracts.

Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?

Comment Re:Never seen them blocking CNTRL-C CNTRL-V (Score 1) 327 327

Blizzard's Battle.net does this. Or at least to, I haven't checked recently. I did contact them about it and they just scoffed it off as a "security measure."

It's a bullshit excuse on their part. See my earlier post earlier in thread for some javascript that may get around that.

Comment Re:Scripts that interact with passwords fields aws (Score 3, Interesting) 327 327

Your argument has one flaw - just because someone uses a password manager doesn't mean he will pick strong passwords...

The flaw you see is not where you think it is. The OP never said a password manager requires strong passwords. That would require idiot proofing - that's a whole other subject.

Using a password manager does not necessarily enforce good passwords - or prohibit the reuse of them.

Writing passwords down means you have to read them out, and type them in to use them - a practise that also does not necessarily enforce good passwords - or prohibit the reuse of them.

Writing passwords down means you have to read them out, and type them in to use them - a practise that encourages bad passwords and the reuse of them.

Using a password manager does not encourage bad passwords and the reuse of them.

The reason for the difference is in ease of use and amount of effort involved. People cut corners because they are lazy or in a hurry.
I touch type - most people don't, I make mistakes typing in complex passwords that have been written down. The more I use those passwords, and the more passwords I need to keep, the greater the incentive to practise bad security. Given that most people can't touch type - they have an even stronger incentive than me to practise poor security - the evidence from all the password list dumps and all the security tests on password usage just proves the same thing. People use dumb passwords, people reuse passwords. When they are asked why they do so they say it's because it's too hard to remember them - or to write them all down, keep control of the pieces of paper, and to type them back in each time.

The other risk with using either method for storing password is loss of the passwords. Passwords managers have to be backed up. Paper records of password needed to be backed up and secured. Password manager use passphrase protection so they are secured. (or should be - see my previous comment about idiot proofing)

Comment Re: Scripts that interact with passwords fields aw (Score 1) 327 327

And why not?

Some script/program having access to a password field is totally irrelevant from a security standpoint. Heck, even browsers most of the times can't even tell that some html field is THE password field (because there's no standard...often they just guess).

That's interesting. Which browsers guess which form field takes a password please? It'd save me some time if you could tell me the function is used to guess it - but I can just dig through the documentation if you don't remember precisely.

I know how Iceweasel/Firefox finds a password form field - and it's not "guess" work.(it remembers the form field positions from when you hit the Submit button - if you have autologin enabled).
The password manager I use knows nothing of form fields - it handles password request from applications. When I'm not using Iceweasel I just copy and paste from the password manager (which I use to hold additional information relevant to each password).

A stock page login form field:-

<form id="bridgeForm" action="#" target="loginframe" autocomplete="on">
<input type="text" name="username" id="username" />
<input type="password" name="password" id="password"/>
</form>

<iframe id="loginframe" name="loginframe" src="$foobar.html"></iframe>

Refs: Firefox password debugging, the login manager

Comment Re:Scripts that interact with passwords fields aws (Score 1) 327 327

IMHO, this is a browser problem, not a website problem. Browser shouldn't allow scripts to interact with a password field. Period.

[Disclaimer: I'm not the GP AC.]

I'd have to disagree with that opinion. I would reconsider if someone showed me good reason. Typing password manually lead to password reuse and insufficiently complex password use.

Comment Re:How much is an AG these days? (Score 1) 243 243

IOr maybe, if I have to skirt the issue, a "working girl/guy".

Dishonest politicians that will sell their services to the highest bidder despite the fact their job requires that they serve their constituents - that'll do nicely. Or scum.

There are all sorts of people who sell their services. Some have absolutely no scruples about what they sell - or to whom. Some lobbyists are scum. And some marketers. Some prostitutes are scum?

Prostitute is a term that gets it's negative connotations from the dishonest and morally bankrupted self-righteous who like to blame people who sell their sexual services for the guilt their own desires brings them. And to perpetuate the myth that when the sex part of the brain wants something that they believe is wrong, they can act on those desires and dishonestly dodge the responsibility - because it's not the fault of the person the who owns the brain. (quick cover the table legs or grandpa will hump the table, no, grandpa needs a smack on the peepee with a birch).

Comment Re:Lazy and Stupid (Score 2) 327 327

It's not a difference that I would rely on; but there likely are some differences: it's typically easiest to get some sort of cross-site-scripting malice to work,

In which case your passwords are toast no matter whether you typed them in by hand or they were injected by a password manager.

less easy but far too common to escape from the browser and poke around with the user's permissions,

Do you have a citation for this common occurrence?

I can't seem to find one - though I only did a quick google and a search though the last decade of email from the Full Disclosure mailing list.

Also could you expand on how such an exploit would not be able to result in key logging that also result in a typed password being captured?

more difficult again to escalate privileges above the user's context; and potentially quite tricky to get a kernel driver in without either compromising some vaguely respectable OEM or mucking with the system's certificate store.

I agree with what made sense. You lost me with the "vaguely respectable OEM" bit. Could you expand on that please. I can be a bit thick.

Mechanisms that touch the browser too closely will probably fall to a good XSS exploit, basic browser-stores-passwords arrangements should fall over with nothing more than your security level

Sound good - a bit theoretical. How does that get past a passphrase and encrypted password storage?

; actually getting a keylogger, especially a persistent one, in there should be more demanding.

I'd disagree there - if I have that much access I can download what I need - if I'm too lazy to use what's already on the system.

Weekend, where are you?

Working...