What do you mean by "humbling lesson"? If anyone finds an unpatched flaw and uses it to exploit some servers, then it doesn't matter who takes care of the servers. It doesn't matter if it's ptacek or a random admin. It's a new, unknown problem (if the claim about a 0day is real).
The experts at Matasano should know better than to leave sshd internet-accessible. That's what is humbling, because exposing the smallest possible attack surface is exactly how you defend against an unknown problem, and there's literally no good reason (besides laziness) to leave sshd exposed to the public internet.
Also they're "hacking" the frontend web server. Is that post really interesting in any way? They didn't get to any sensitive information (or didn't publish it). They also didn't get into any personal system, so I doubt there was any real harm done. (otherwise they would brag about it even more)
Or, they simply didn't bother going further -- owning the front-end web server is fairly embarassing for a company like Matasano.
Quite a few individuals store their credentials on front-end web servers, or even SSH to other servers from the front-end servers. Owning -any- server is often a very big deal.
Agreed on the first point. It's true that minimising the amount of random input will help your security. That will always be true. It was only their fault that they don't limit the access.
OTOH, they have to run public services in an accessible way. Someone could just as well find a bug in their webserver, or mail server. It's bad for PR of course, if their webserver is hacked. But not all servers are equal. (here starts the IMHO part) If you want to spend your time on making everything perfectly secure, you're a full time sysadmin, not a security researcher ;) I think that there are a lot of test, web, mail, etc. servers that people just don't treat as very valuable. Every webserver could be virtualised and the whole system could be checked in a loop by a securely signed checksum verifier which sends (every cycle) results using PKI to a vpn'ed server which sends you an sms if your index.php checksum doesn't match (and snapshot + suspend the machine along with memory, then bring a failover up via a non-lan channel). Is it worth their time though?
People can think that makes the company look bad, I don't...
I'm a bit confused - how are you supposed to ssh in if sshd is not internet-accessible? If you're suggesting only allowing access through a VPN, what's the advantage? Is a VPN significantly less likely to be exploitable than SSH? Or are you saying that you should only be able to SSH in via the local network?
Is a VPN significantly less likely to be exploitable than SSH?
Yes, for a few reasons.
First, a VPN provides defense in-depth -- compromising a server now requires finding two unpatched vulnerabilities:
* You must find a vulnerability in the VPN implementation that allows you to leverage the VPN or the VPN host to forward your traffic.
* You must then find an additional vulnerability to use against the actual secured hosts made available over the VPN connection.
There should be a firewall between the VPN entry-point and your internal networks, to limit access to unapproved services.
As a single point of entry, a VPN is also easier to secure. If all servers are inaccessible except for approved services, then a single server running an unapproved vulnerable service (or an account with a weak password or key) does not open the door to immediate external compromise.
This single entry point also allows you to offset the likelyhood of user failure (such as choosing poor passwords) by using additional two-factor authentication. RSA SecurID or PKCS#11 are often too heavyweight for using every time you want to SSH'ing into a host, but they're far more reasonable for initially connecting to the VPN.
There's also the configuration to consider. Using PSK or aggressive mode for VPNs can be considered bad but are you really going to deploy a full RADIUS solution just to access a web server?
Compare this to using public key based auth on SSH, I know which one I'd rather have for a web server.
Not necessarily. What about exploiting VPN clients?
IPSec is a disaster, one aspect of which is having a client daemon listening on an open port for isakmp/ike key exchange.
There's also the configuration to consider. Using PSK or aggressive mode for VPNs can be considered bad but are you really going to deploy a full RADIUS solution just to access a web server?
Provisionally "yes", but I'd actually use OpenVPN, wired into our existing directory infrastructure.
Compare this to using public key based auth on SSH, I know which one I'd rather have for a web server.
Why do you consider it a net win to reduce the entry barrier to only one exploit, one bad user password, or one misconfigured host?
A common solution is to whitelist IP addresses, or a range of them. This is obviously inconvenient in many cases, but is much more secure than allowing all to connect, especially in situations where there is a new 0 day.
There's nothing wrong with leaving SSH open on a web server - provided it's locked down. How that gets locked down is down to the risk appetite of those responsible.
"there's literally no good reason (besides laziness) to leave sshd exposed to the public internet."
Well, besides the fact that it's a whole lot more convenient to just be able to ssh into somewhere without frigging around with VPN or what not. For most businesses, I would say having accessible ssh (with good passwords, and a properly set up, up-to-date system) is fine.
But yeah, for a "security" business .. it's pretty surprising they let it hang out like that. And on port 22 and the www domain, too .. tsk tsk.
If there is an option between a convenient way to do something and an inconvenient (but much secure) way to do the same thing. You should do it the inconvenient way, specially if you make a living in security.
If you're at home, running OpenBSD on your own computer, then security can be inconvenient as you want it. But if you run security for a business, you have to balance confidentiality and integrity with availability (and sometimes some other concerns). Shell access from the internet could be important to availability--obviously, this was the wrong way to do it, but it wasn't a wrong objective.
I agree with your point, but I do want to point out that mail theft (by postal workers, errant receivers, and malicious thieves) is not so uncommon. I have had a few things mailed without tracking numbers that I strongly suspect were stolen (mailed from post offices with complaints of theft or undelivered mail).
The experts at Matasano should know better than to leave sshd internet-accessible. That's what is humbling, because exposing the smallest possible attack surface is exactly how you defend against an unknown problem, and there's literally no good reason (besides laziness) to leave sshd exposed to the public internet.
Also they're "hacking" the frontend web server. Is that post really interesting in any way? They didn't get to any sensitive information (or didn't publish it). They also didn't get into any personal system, so I doubt there was any real harm done. (otherwise they would brag about it even more)
Or, they simply didn't bother going further -- owning the front-end web server is fairly embarassing for a company like Matasano.
Quite a few individuals store their credentials on front-end web servers, or even SSH to other servers from the front-end servers. Owning -any- server is often a very big deal.