I think I have to agree with a comment someone else made in the previous thread about this, with the rise of cheap VPS services we're seeing an influx of people unqualified and unprepared to run their own internet routable servers and things like this are the outcome of that. When you choose to stand up a VPS with a service like DO you take on the responsibility of keeping it secure and preventing it from engaging in malicious activity. If you fail at that task, the consequence is your servers will be shutdown for the good of the internet as a whole. If you are either unprepared or incapable of dealing with that responsibility you should be paying for a hosting service that's prepared to offer those services for you.
I say this as someone that currently has accounts with a number of VPS providers where I do take the responsibility of managing my servers seriously, as well as previously helping to administer a server that was compromised and taken offline until such a time as we had performed a full audit and verified our code on a new instance.
You should be prepared to treat a compromise of your servers the same as any other form of disaster. Treat it the same as if a flood happened and took out the facility you were hosted out of. You should have a backup plan in place so you can roll over to your backup until such time as you can fix the "broken" server, or else accept the downtime.
Maybe if you guys charged more you wouldn't get these ultra-cheap customers who think they should get 24/7 support for paying $5 a month.
Locking the account when the explanation given is inconsistent with the observed behavior it was supposed to explain and the system is again engaing in an apparent DDOS is also a perfectly reasonable action.
It also seems from your posts that both times you were notified of the action by DO, so "not notifying the customer" is not an issue.
I don't see any evidence you were accused of being a "cheap liar", either.
The fact that services now make it cheap and easy to set up servers doesn't mean that you have no responsibility for what the servers you set up do. If you are really running a service with 25K active users, you probably ought to be able to respond to your VPS hosts questions about unusual UDP activity with either an explanation that holds water, or an up-front admission that you don't know where it is coming from and will take action to prevent it, rather than claim it comes from a database dump script that doesn't use UDP.
""" We informed the customer that it may be a good idea to check through the virtual server to see if there were any signs of a compromise just in case """
In fact from the dates listed, it looks like you had over two weeks to check for compromise. Even then, it seems like they tried to talk to you before just closing your account;
""" A second UDP pattern was detected on 2013-09-24 12:27:09 and a ticket was opened 2013-09-24 12:27:14 to request more information from the customer. Because this was already a second occurrence we had to do a more thorough follow up. Discussing the matter with the customer, he informed us that it was a mysql db dump script that was pushing data to dropbox. """
I know this can be difficult, but it's important to understand the difference between calling someone a liar and pointing out that what is being claimed does not match reality.
DO has to take action to protect their reputation, their other customers, and whoever is the target of the potentially malicious attack. If they have empirical evidence of this attack, then they must take action. When you attempted to explain what you thought was the source of the traffic, they took the time to show (in detail) why that was not the case. This is not the same as calling you a liar. It is calling you incorrect, but these are two very different things.
You can be incorrect and not be a liar. That's a valuable lesson to learn if you intend to work in a technical field. If I were you, I'd try to take a step back. Take a couple of days off and come back to the issue. Try to understand why everyone is siding with DO on this, and resist the urge to immediately believe that everyone is against you.
Had you chosen a VPS like amazon, you probably wouldn't even get notified. The first time you'd notice a problem is when you get your $1000 bandwidth bill from amazon.
You're like the customer that shows up at a restaurant and complains publicly about the food and demands a refund. When you make it a public issue, the company will move mountains to help you, but you're still an asshole for doing it.
If DigitalOcean's support wasn't clear about their reasons for suspending the account, or if you feel that you weren't getting a helpful response from them, then post the communications you had with them to prove it.
Your explanation of the events only mentions a single occurrence, at which time your account was locked in addition to the server being shutdown.
In either case, a server engaging in malicious activity, is normally taken offline as soon as the malicious activity is discovered to prevent further damage from occurring. You'd get a similar response from just about any other hosting provider you care to name. If you're lucky, and they're feeling generous, they might work with you to find the problem prior to taking the system offline, but normally standard procedure is to take the system offline immediately. The fact that you seem surprised about this shows you don't have much experience administering your own servers.
The standard response usually goes something like:
1) Server is discovered doing something malicious
2) Server is taken offline/shutdown
3) Administrator is notified
3a) Read only copy of the old server HD is brought online on a new server to allow administrator to perform forensic and backup work*
4) Administrator must bring up new server to replace old compromised one
*Sometimes the provider will provide you the old HD image, sometimes not, really depends on the provider.
a.) pretty good evidence that DO did their due diligence and
b.) way more thorough investigation than I would have expected from a "value" vps provider.
Locking the user out of their account seems...odd, tho. I've never had that happen, personally, at any host.
Blocking UDP would have stopped the attack, it would have given you a time window to contact the customer (allowing for time zone differences) and would have given both parties a chance to resolve the issue in private and with much less drama.
(speaking as a current customer of DigitalOcean, using UDP (thru collectd) to monitor my droplet and starting to have uneasy feelings).
The customer is lying in this case?
May I ask what about the UDP traffic made it appear abusive?
Other than that i've no other activity or script that can generate that much traffic. Haven't you even considered that my droplet may be compromised or being attacked ?
Instead of letting me know what exactly happened or which processes were running at that time you just locked the account and accused me.
Couldn't you even look at the access logs or so to see which IPs login into the droplet and then take your action later instead of closing it instantly?
I think they did consider your droplets to be compromised.
I think at issue here is that they have to assume that the droplet owner is the malicious party, if they don't lock your account, they can't stop you from creating more droplets.
I think you may have a point that they did not clearly explain to you why your account was locked.
However, this incident makes me more likely to continue using Digital Ocean. With the new private networking they have in NYC2, I for one am thrilled that they do this kind of proactive monitoring.
I got my server down with DO many times at first. It was a problem with the CentOs package; but it was indeed my responsibility to fix it.
You are responsible of securing your server.
>Our monitoring picked up a malicious UDP traffic pattern on 2013-09-08 00:58:23. A ticket was then opened with the customer at : 2013-09-08 01:05:55 roughly 7 minutes later.
Also, you should do a better job securing your server. It seems like the server was compromised.
What proper reasoning do you need? If your server is hacked, it makes sense to shutdown the server, or disconnect it from the network completely. You can extract the data at a later time.
What if your server was hacked, then started serving up child porn? Would you be okay with having the server continue running?
-----
All times are UTC.
Our monitoring picked up a malicious UDP traffic pattern on 2013-09-08 00:58:23. A ticket was then opened with the customer at : 2013-09-08 01:05:55 roughly 7 minutes later.
The customer informed us that it was a script that was crawling in the background.
We informed the customer that it may be a good idea to check through the virtual server to see if there were any signs of a compromise just in case.
The droplet was unlocked at this time.
A second UDP pattern was detected on 2013-09-24 12:27:09 and a ticket was opened 2013-09-24 12:27:14 to request more information from the customer.
Because this was already a second occurrence we had to do a more thorough follow up. Discussing the matter with the customer, he informed us that it was a mysql db dump script that was pushing data to dropbox.
He provided us a link to a github project that he wrote, we asked further questions. Specifically if you are writing a mysql dump remotely why are the packets being sent as UDP? Additionally if the final destination is dropbox that would be an SSL encrypted connection and again why would that transfer go over UDP?
We reviewed the code of the dump-to-cloud project and it was using the dropbox sdk, here is where the file transfer is initiated:
From the dropbox SDK here is where it sets the destination for the file transfer: The code that actually transfers the file from the dropbox sdk: The file is transferred via HTTPS since it is going to a secure service and HTTPS would rely on TCP for the data transfer, again to ensure that all packets are delivered.Given that it was the second incident that a UDP traffic pattern was observed in less than 30 days and that the information the customer provided regarding the traffic did not match up, we made a determination that in fact it couldn't be this script that was generating the traffic.
All of this information was relayed to the customer that we did not believe that the traffic in question was related to this script because it would not rely on UDP, an insecure protocol to deliver files to a secure endpoint where data integrity was of the utmost importance.
Unfortunately, we could not unlock the account at this time because the information we received was not clear and we already had two incidents of outbound UDP traffic that appeared to be disruptive and abusive in nature totaling 1Gbps as if it were a denial of service attack, typically associated with UDP packets.