

Cautionary Tale for Entrepreneurs: Hacked & Database Whacked, Thruzt Interview - r3b3lang3l
http://www.networkworld.com/community/blog/cautionary-tale-entrepreneurs-hacked-database-whacked-thruzt-experience

======
lsc
>Marcus Hirn: We had multiple scans and intrusion attempts from malicious
attackers using automated software and hunting for vulnerabilities to exploit;
this time they were targeting the server's IP. The first attack came on the
5th day and lasted for half a day. The Thruzt team blocked their IPs which
appeared to be coming from China and Salt Lake City, Utah. After some battle,
they dropped the attacks. But after we blocked, he or she came back and
attacked again for four days, brute forcing SSH, brute force password attacks
that attempted to get root user access. It slowed the server down. We had to
reboot the server to force a new IP in order to get access and be able to
block him.

This is really, really common. Look in your ssh logs on almost any internet-
connected host with an open port 22 and you will see hundreds, if not
thousands of ssh connect attempts per day.

Now, my general strategy is to simply disallow all password authentication,
and I force everyone to use ssh keys to login to the infrastructure I manage.

Even so, while this prevents brute force compromises, you can still be fairly
easily brute-force DoS'd. OpenSSH allows a certain number of connections in
pre-authentication state; I've had people bombard my servers with login
attempts faster than OpenSSH could fail authentication. In my case, I've got
my own serial console server, so it's easy to login and block the offending
IP; but that's what things like fail2ban are for.

Of course, this just prevents ssh logins, it doesn't, say, kill your webserver
(and if OpenSSH is configured correctly, e.g. if the last guy didn't crank up
the number of users that can be in the pre-authentication state to "solve"
this problem last week, it's not going to cause high system load.)

I mean, I just don't see how any of this has anything to do with hosting on
amazon; There are programs searching almost all IPs on the web for known
vulnerabilities; when these programs infect a new computer, that computer
joins the botnet; there are a huge number of computers dedicated to this
search for vulnerable computers, so it's really not uncommon for servers
running known-vulnerable software to be compromised within days, hours, or
even minutes of connecting to the public internet.

Ah. I see what it has to do with hosting on amazon:

"Marcus Hirn: I think many people believe it's like a normal web host where
you create an account and then there is a cPanel where you click to install
WordPress, or to setup a firewall, or to access FTP, etc. But on a cloud
server you have to not only do all configurations yourself, but you also need
to know what software to get and run. For a tech geek, it's a dream as you
have 100% control of your own server with easy added scalability. Yet to get
to that point, it requires days, if not weeks, of learning the Amazon system."

He's comparing amazon to shared or managed hosting. And he's right, but
everything he says about amazon or "the cloud" is true of any situation where
you manage your own server.

------
ironchief
They don't know how the hacker deleted their database, but they claim it won't
happen again.

Yeah I totally trust these guys with my username/password...

------
zetadog
that was a huge hit thruzt took then.

