Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


GoodHosting VPS & Site Offline
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

GoodHosting VPS & Site Offline

fhnericfhneric Member
edited August 2014 in General

A couple minutes ago it appears that vps's hosted with goodhosting.co, and their main site went offline. Does anyone else have a vps with them that is offline as well? Or is it just on my end?

«1

Comments

  • Bump & Dump .Co

  • Are they getting ddosed? We've been a target as-well if they have.

  • If they are & they're using OVH, traceroute would show the traffic being redirected for scrubbing. The traceroute path looks pretty normal for OVH.

  • goodhosting.co down here

  • MCHPhilMCHPhil Member
    edited August 2014

    black said: If they are & they're using OVH, traceroute would show the traffic being redirected for scrubbing. The traceroute path looks pretty normal for OVH.

    No issues at OVH BHS here.

  • blackblack Member
    edited August 2014

    @MCHPhil said:
    No issues at OVH BHS here.

    That appears to be correct.

    What a traceroute would look like if a server is under DDoS attack http://forum.ovh.co.uk/showthread.php?6884-Anti-DDoS-exemples-of-traceroutes

    Thanked by 1MCHPhil
  • @MCHPhil said:
    No issues at OVH BHS here.

    Well, you know according to @GoodHosting they are in different dc rack :D

  • @black said:
    What a traceroute would look like if a server is under DDoS attack http://forum.ovh.co.uk/showthread.php?6884-Anti-DDoS-exemples-of-traceroutes

    It would also look like that when VAC is turned on permanently

  • nexmarknexmark Member
    edited August 2014

    @black said:
    What a traceroute would look like if a server is under DDoS attack http://forum.ovh.co.uk/showthread.php?6884-Anti-DDoS-exemples-of-traceroutes

    It would also look like that when VAC is turned on permanently

    Also: No issues with OVH in the BHS Datacenter (using ovh myself)

  • @nexmark said:
    It would also look like that when VAC is turned on permanently

    Oh yeah, I forgot about that, thanks for mentioning it.

  • LeoKLeoK Member

    I can ping my server with them, and i do not see any interruptions

  • must be Canada Day.

  • No website DNS entry,

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> www.goodhosting.co
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36037
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;www.goodhosting.co. IN A

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> goodhosting.co
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30487
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;goodhosting.co. IN A

    ;; Query time: 5027 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Sat Aug 2 15:24:11 2014

  • @ElChile said:
    No website DNS entry,

    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> www.goodhosting.co
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36037 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.goodhosting.co. IN A ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> goodhosting.co
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30487
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;goodhosting.co. IN A

    ;; Query time: 5027 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Sat Aug 2 15:24:11 2014

    Again with the DNS Issues, Where is he...

  • Awmusic12635Awmusic12635 Member, Host Rep

    nexmark said: Again with the DNS Issues, Where is he...

    Probably gone for the week again

  • no, this time it's the entire subnet. probably their single leased server ("we have multiple nodes" lol) kernel panicked or something

  • @Fliphost said:

    http://www.timeanddate.com/holidays/canada/

    Maybe he's out celebrating early.

  • Or maybe it's 3AM on a Saturday and OVH decides to "mitigate" an entire account from only a single IP address infringing on the network. They apparently don't know what "nullrouting" is, or how to implement it. Instead they would rather reboot all the machines into rescue-FTP and refuse to hand over credentials, whilst demanding we remove the infringing client with no means to do so.

    Currently on line with some techs about this and dealing with the issue slowly.

    Thanked by 2nexmark Licensecart
  • @GoodHosting said:
    Or maybe it's 3AM on a Saturday and OVH decides to "mitigate" an entire account from only a single IP address infringing on the network. They apparently don't know what "nullrouting" is, or how to implement it. Instead they would rather reboot all the machines into rescue-FTP and refuse to hand over credentials, whilst demanding we remove the infringing client with no means to do so.

    Currently on line with some techs about this and dealing with the issue slowly.

    Oh boy, What was this "Client" doing, If you don't mind telling us all?

  • @nexmark said:
    Oh boy, What was this "Client" doing, If you don't mind telling us all?

    I've got about 40 emails saying he was DDoSing between the hours of 1AM and 3AM, right up until they mitigated the account. Varying rates are reported between 79Kbps to 483Mbps at the peak. I can understand nullrouting an IP when something like this happens, but the entire account?

  • GoodHostingGoodHosting Member
    edited August 2014

    Lots and lots of:

    Dear Customer,
     
    The IP address 192.99.199.xx had to be blocked by our services due to
    the various alerts received.
     
    Please don't hesitate to contact out technical support team so that this situation does not become critical.
     
    You can find the logs brought up by our system which lead to this alert.
     
    - START OF ADDITIONAL INFO -
     
    Attack detail : 26Kpps/1022Kbps
    dateTime                   srcIp:srcPort           dstIp:dstPort           protocol flags       bytes reason               
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13502     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13069     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13479     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13603     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13494     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13504     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13508     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13521     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13491     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13495     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13520     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13509     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13821     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13819     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:14189     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13810     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13618     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13045     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13485     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
    2014.08.02 xx:58:38 CEST   192.99.199.xx:13483     115.230.124.xxx:10009   TCP      SYN            40 ATTACK:TCP_SYN       
     
     
     
    - END OF ADDITIONAL INFO -
     
    King regards,
     
    OVH Customer Support.
    
  • @Jack said:
    Nullrouting wouldn't stop it hindering the network until it goes to leave to carriers?

    OVH themselves could block the IP address from transmitting (reaching) outside of that Top of Rack Switch, thus completely mitigating the attack from its source. They can just stop the IP address from leaving the network, or block all traffic originating from/to it, etcetera.

  • MCHPhilMCHPhil Member
    edited August 2014

    @GoodHosting said:
    OVH themselves could block the IP address from transmitting (reaching) outside of that Top of Rack Switch, thus completely mitigating the attack from its source. They can just stop the IP address from leaving the network, or block all traffic originating from/to it, etcetera.

    That is what they have done in every situation for me. They have never blocked the entire node for 1 random IP behaving badly, in my experience.

    My understanding is this is all automated and no OVH staff intervention is required for this to occur.

  • @Jack said:
    This could then put strain on the distribution switch creating issues for the other ~47 or so ports in that rack.

    You have a fair point, I have no means myself of knowing if they could have blocked it earlier or not, but I don't think my 500Mbps (at peak) attack could have been "jeopardizing the network", especially under 200kpps as I've been told the attack was.

    @MCHPhil said:

    Here I would have thought, until they opened a new subject-less ticket to me:

    OVH HOSTING INC. - http://www.ovh.com
    800-625 av. du Président-Kennedy
    Montréal (Québec) H3A1K2
    Canada
    
    Dear Customer,
    
    The protection of the IP address 192.99.199.xx has been suspended
    by our team.
    
    For more information, please contact our technical
    support.
    
    Regards,
    
    Support OVH
    Phone: 1-855-OVH-LINE (684-5463)
    Email: [email protected]
    
    

    Then proceeded to take the account offline.

  • @MCHPhil said:

    Not just that, but they disabled IPMI to all machines as well:

    An error occurred on attempting to connect to the IPMI module using a Java applet (This function is not allowed for your server)

  • Hello71Hello71 Member
    edited August 2014

    @GoodHosting said:
    Or maybe it's 3AM on a Saturday

    this thread was started at 2:13 PM EDT. let's be generous and say that OP was delayed an hour and 15 minutes or so in making the post (highly unlikely).

    last I checked, Canada's time zones do not include UTC-10. has the company now moved to Hawaii?

    edit: oh, and also, bridging the network connection and/or giving full speed to everyone -- not a brilliant idea.

  • GoodHostingGoodHosting Member
    edited August 2014

    The issue has been settled.

  • raindog308raindog308 Administrator, Veteran

    GoodHosting said: Or maybe it's 3AM on a Saturday and OVH decides to "mitigate" an entire account

    You're hosting with OVH. My sympathy for you is nonexistent.

    Thanked by 1Spencer
  • raindog308raindog308 Administrator, Veteran

    GoodHosting said: The issue has been settled.

    So you've decided to just keep the site down then?

    Because it doesn't work. Neither does ns1.goodhosting.co nor ns2.goodhosting.co.

  • @raindog308 said:

    As you'd understand DNS takes some time to kick back in. The nameservers are resolving on my end (Google DNS, albeit I had to flush the local cache as well as Google's copy via their tool.)

    https://developers.google.com/speed/public-dns/cache

Sign In or Register to comment.