thorduri

Rewrote my previous comment, as muddling up both cases as a single obtuse analogy was a mistake on my part.

But can't we say that we have both a moral and an ethical obligation to protect our nontechnical users or our fellow developers from mistakes, lack of training or in the worst case maleficence ?

The business decision of using an externally hosted backend services, what ever they may be must take into account what data goes into it, out of it and how it's computed on by both you and the provider w.r.t. who the real end user is and how the data is going to live on.

And here I think is the crux of the problem, those questions and their solutions are generally very hard when put into practice (I dont have a silver bullet, or even a something vaguely resembling a mold for it) so it's not very conducive to being a "Fast" company.

For example, being European, it scares me a great deal that companies, schools and the public sector are increasingly punting the business decision of "how to handle email" to "let's use gmail".

That in no way takes into account my concerns (and often I do not have a choice in the matter of using these services) since my mail, and by extension a large part of my life is being handed to a for profit US corporation who "does no evil".

I use gmail privately though, since I did this particular cost/benefit and decided that i dont really care if google reads my mailing list traffic...

That's not really a solution.

The problem falls into two categories, on one hand you have non technical end users, and it takes a non trivial amount of time to train them to roll their own crypto if you will, and it's also hard to convince them it's worth it (This is a fair point, as security is a cost/benefit between ease of use and not getting caught with your ass in the wind).

On the other hand, you have companies using outsourced services, and with SaaS/PaaS/aa becoming all the rage, it's very important in my opinion that those service providers shoulder some of the responsibility to not let their users, serve their users etc in a manner that's not conducive to security/privacy etc...

Punting this problem up the stack, with it most often ending on the end users desks, is IMNHO a bad idea, since then, as it is now all those good things crypto promises are the exception, rather then the norm.

This is obviously much much much more complicated in practice, but I at least see this problem reflected in the "to the cloud!" mentality.

EDIT: Complete rewrite.

Projecting? Unsure in which direction you mean, but fwiw I'm pushing 30 my self (26) and use apple products.

But I agree with you, the medical records argument is kind of boring. But, not everything needs to be outsourced; There is value in keeping things on site, if not for anything besides job creation!

My pet-peeve in this is that it has been now for a while (and is trending upwards, fast) that we don't see any problems at all, long or short term with simply "shipping it to the cloud", where it is everything from medical records, to phone contact lists to personal communications with our other significant other.

We as a community are quickly eroding any expectation of privacy and security all in the name of being agile. I guess it just rubs me the wrong way.

I should tweet about it, on my iphone and then copy it to a file for prosperity and upload it to my google drive...

Yes, the foolish neckbeards who aren't agile and dynamic, don't use git and aren't iterative but care deeply obeying regulations and not sending data to the /dev/null that mongodb on US-EAST is.

This mindset screams "I AM IN THE VALLEY AND EVERYONE WHO ISNT UNDER 30 AND USES APPLE PRODUCTS DOESNT GET WEB2.0" (also caps lock is cruise control for cool).

Apologies for the negativity, I think I get it, I want my data to be in the cloud, and easily accessible and all that jazz, but I want to keep it secrete and safe and most importantly I want to be mine.

Says the guy who just signed up for the iCloud today... ;-)

> A future bulk-scan may leverage a new SSH-exploit before you know it exists.

Sure, this is true. I consider this a "minor" issue, truth be told (I didn't want muddle up the conversation) I don't tend to run sshd faced towards the 'public' internet and in the cases where I do, ssh access is restricted to certain hosts/networks, and is enforced by a firewall.

> The rest of your recommendations is security theatre

Can you state why? I think they all provide measurable/real benefit, if this isn't the case I'd welcome some education.

Hm. I will give you that AllowUsers,AllowGroups is not a very good benefit in this case, I mainly enforce the usage of those directives to protect against problems such as bogus user account creations (exploit created or something simple as a admin mistake).

>An attacker dedicated enough to find your SSH-port

And Now for Something Completely Different.

Protecting against a dedicated attacker is a totally different ball game then protecting against drive-by's.

If undirected bulk scans are a serious threat to your security, something is up.

Properly configured (AllowUsers, Disable root, no clear text passwords only keys etc), I'd say that the undirected bulk scans pose no security risk at all, they are only a nuisance in terms of spamming your logs, which is easy enough to deal with.

What I'm really trying to say is that each "trivial way to reduce your attack surface" has both cost and benefits.

I'm contending that moving the ssh port around gives you the benefit of less log spam with no security gain, and costs in terms of documentation and maintenance.

When I do this Cost/Benefit analysis, I conclude that moving the port around has more costs then it does benefits, so I don't bother.

Sure.

> "Port knocking by definition is an extra layer of security through obscurity"

Security through obscurity is not security, it's at best theater.

> "It protects against 0 day attacks on OpenSSH"

You substitute one problem for another, 0 day attacks on the SPA. Your model isn't safer, it's just different.

And personally, I trust the OpenSSH guys way more then any SPA vendor simply because they have a very good track record.

>> 2. As long as you're customizing the firewall you should block pings entirely.

Why?

I've never seen a threat model where filtering icmp doesn't end up being more trouble then it's worth. Then there is even the maintenance headache when basic but powerful tools like ping and traceroute are rendered useless.

It's the same BS as with fail2ban, thankfully the OP wasn't spreading the gonorrhea of port knocking/single packet auth. Lock down your sshd like everything else: Disable root, disable tunneled cleartext passwords, enforce proper key usage, use AllowGroups/AllowUsers.

EDIT: The BS with fail2ban is moving the ssh port around. I understand this being a problem, but surely iptables has something similar to OpenBSD pf's:

block in quick from <brutes>

pass in log on $if_ext proto tcp from any to ($if_ext:0) port ssh keep state \ (max-src-conn 3, max-src-conn-rate 4/32, overload <brutes> flush global)