5 ms·

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 serve

by ankp 17y ago

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.

sailormoon 17y ago
"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.
- pavs 17y ago
  Security is not supposed to be convenient. 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.
  - gchpaco 17y ago
    So I'm guessing you mail hard drives around, rather than use the net 'cause somebody might have cracked sshd or OpenSSL? Wait, you don't? Gee.
    - jimmybot 17y ago
      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).
  - khafra 17y ago
    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.
defen 17y ago
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?
- apgwoz 17y ago
  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.
  - timf 17y ago
    Or use portknocking.
- deleted 17y ago
  [deleted]
- ankp 17y ago
  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.
iuguy 17y ago
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.
viraptor 17y ago
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...

by ankp 17y ago

sailormoon 17y ago

"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.

pavs 17y ago
Security is not supposed to be convenient. 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.
- gchpaco 17y ago
  So I'm guessing you mail hard drives around, rather than use the net 'cause somebody might have cracked sshd or OpenSSL? Wait, you don't? Gee.
  - jimmybot 17y ago
    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).
- khafra 17y ago
  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.

defen 17y ago

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?

apgwoz 17y ago
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.
- timf 17y ago
  Or use portknocking.
deleted 17y ago
[deleted]
ankp 17y ago
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.

iuguy 17y ago

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.

viraptor 17y ago

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...