After some more time they managed to resolve this and I'm again a happy DO user but I wish that they take a look at their policies. Just the fear of knowing that they can shut you down by mistake for a day or two is bad enough to not use them. They should have a policy where they at least call you and talk to you before they do anything.
Stop Using Digital Ocean Now: The Aftermath
31–40 of 102 posts
Re: Stop Using Digital Ocean Now: The Aftermath
#32Sorry but I must be blunt... What do people expect for Something has to give. Yes we've all built and sold products and believe in providing an impeccable service worth far greater than the sum of its parts. Because we're in it to please everyone and build a reputation. But hosting is different. There are real costs for not taking action (upstream null routing, blacklisting, chargeback fees, fraud, abuse, etc). I'm d…
It was the same thing the budget dedicated providers did before 'cloud' and 'vps' became popular/viable technologies. I do think DO's business plan does make sense tho, many of those budget providers are large, profitable business today.
Re: Stop Using Digital Ocean Now: The Aftermath
#33Earlier quoted context omitted.
I ran into the same problem just last week when I tried to make an account to try it out. I added a credit card to my account without a promotion code, but later on found out about the new promotion they are doing (free $10). I realized that you cannot enter a promo code if you didn't do it the first time you add payment to an account, even if the account is otherwise still new (I didn't do anything with it after add…
They have really quick customer service; they probably would have added the promotion to your account if you had contacted them.
Another thing is their ToS. I admit I didn't read their ToS prior to registration (most people don't I assume, but I won't use that as an excuse), but I did go back and read it afterwards, and it said:
"Users are restricted from registering multiple accounts with the same billing details without first notifying DigitalOcean of that intent to ensure that accounts aren't automatically flagged as possibly fraudulent and without notification accounts may be treated as abuse and/or fraudulent which would lead to suspension of service."
And I thought, even if I did read this I would've reasonably assumed that since my other account has been de-activated, I'm free to make a new one with the same billing information. Unfortunately I was wrong.
Re: Stop Using Digital Ocean Now: The Aftermath
#34Re: Stop Using Digital Ocean Now: The Aftermath
#35Re: Stop Using Digital Ocean Now: The Aftermath
#36On the other hand, here's my experience with Linode. Another host company claimed that one of my machines was doing port scan on their network. Linode opened a ticket and preemptively blocked all outgoing connections to the SSH port from my machine. I had enough time to see what's going on and chatted with a very responsive support. The aftermath is that I moved all my data to a new linode, waited to for the DNS prop…
Re: Stop Using Digital Ocean Now: The Aftermath
#37Earlier quoted context omitted.
The thing is that they wanted to stay private when i posted this so i immediately removed and now waiting for them. By the way i received that response after 2 hours of the topic opening. They weren't answering me at all before HN post
So did your server get owned? Or was the DDOS attack a result of a bug in your code? Also, why do you delete your posts on HN? Do you only keep posts that make your viewpoint look favorable?
Re: Stop Using Digital Ocean Now: The Aftermath
#38None of those reasons excuse putting services offline while this validation is happening - first try validation, give it some reasonable timeframe, and only then cut or don't cut the service depending on results. Is it really so complicated?
Re: Stop Using Digital Ocean Now: The Aftermath
#39-----
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:
def upload_file(file_name)
client = DropboxClient.new(@access_token)
file = open(file_name)
puts 'Uploading file!! Please wait.'
response = client.put_file("/#{file_name}", file)
puts "uploaded:", response.inspect
end
From the dropbox SDK here is where it sets the destination for the file transfer: def build_url(url, params=nil, content_server=false) # :nodoc:
port = 443
host = content_server ? Dropbox::API_CONTENT_SERVER : Dropbox::API_SERVER
versioned_url = "/#{Dropbox::API_VERSION}#{url}"
target = URI::Generic.new("https", nil, host, port, nil, versioned_url, nil, nil, nil)
#add a locale param if we have one
#initialize a params object is we don't have one
if @locale
(params ||= {})['locale']=@locale
end
if params
target.query = params.collect {|k,v|
CGI.escape(k) + "=" + CGI.escape(v)
}.join("&")
end
target.to_s
end
The code that actually transfers the file from the dropbox sdk: def do_put(url, headers=nil, body=nil) # :nodoc:
assert_authorized
uri = URI.parse(url)
do_http_with_body(uri, Net::HTTP::Put.new(uri.request_uri, headers), body)
end
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.
Re: Stop Using Digital Ocean Now: The Aftermath
#40Isn't that a major violation of their SLA? Have you consulted with a lawyer?