Tamranda said:
One of our domain that is pointed to your very server ns1.Tamranda.com, ns2.Tamranda.com must be working then.
Click on that domain, http://i7s.net/english , does it work?
Any other excuses, the one that at least appears to be true?
-
Howdy! Welcome to our community of more than 130.000 members devoted to web hosting. This is a great place to get special offers from web hosts and post your own requests or ads. To start posting sign up here. Cheers! /Peo, FreeWebSpace.net
Tamaranda.com is DOWN
- Thread starter Jun Luzon
- Start date
One of our domain that is pointed to your very server ns1.Tamranda.com, ns2.Tamranda.com must be working then.
Click on that domain, http://i7s.net/english , does it work?
Any other excuses, the one that at least appears to be true?
Dayu said:
None of the websites hosted on the server will work until the main IP on which HTTPD enteries are made works.
You can login into your WHM & cpanel here :: http://207.150.164.71/cpanel or http://207.150.164.71/whm which i think is enough to prove that the server is absolutely fine.
Dayu said:
I belive you have no idea what a Distributed Denial of Service attack is.
Our response started with 10 minutes after the attack started. 14 hours was the time taken to fully resolve the issue. Please keep in my that a third party ie the datacenter was also involved in the issue.
In my view, 14 hours was a short time to resolve such an issue. Just to let you know, in many cases it even takes weeks to fully resolve such issues & identify the sender of forged packets.
Even companies like google have faced such problem on even LARGER scale & it was not due to our fault that this attack originated.
Tamranda said:
Are you going to convince me with your beliefs just like when you said,
More than a year in business and you haven't anticipated things like that?
Short time response to corrupt apache: 6 hrs 39 mins DOWNTIME.
Short time response to DDoS attack: 14 hrs 39 mins DOWNTIME.
How's that for one week? Not to mention your everyday downtime glitches: 1min-60mins downtime, 2-5times a day.
And you're telling a costumer who paid you for 99.8% uptime to be calm?
Dayu said:
1. If you noticed in my previous replies, Apache was not the only thing which got corrupt. There were some other softwares aswell. Once installations were done, we also had to check EACH and EVERY software & account on the server to insure everything is fine & it does take time.
2. Regarding the DOS attack, yes you can consider that our respose time is 14 hours & I feel it was good if not fast. MIND you that the server was accesible on secondary IPs. Just to let you know, Datacenters are very strict regarding such issues & in many cases, they would null route the destination IP of DOS attack for 24 hours Straight.
One more thing, the server did become irresponsive 2-3 times a day, a couple of days before the real big DOS attack. This was because some small scale attacks were launched at that time but they were not distributed, hence our technical team nulled them with 30 minutes of occurence.
Im very sorry for all this but i would like to remind you again that we have NO control over such dDOS Attacks & it was not our fault that it originated.
Tamranda said:
Never did I mentioned that you take control of any DDoS attack. I keep on asking your anticipation about such attacks and your time to respond. Or shall I start lecturing you about what are the softwares other techniques to prevent such attacks?
Tamranda said:
Let me remind you again that we are not paying for your pages to be accessible. We are paying for OUR pages to be accessible. Is that too hard to understand?
Last edited:
We do anticipate such attacks & had proper firewall rules to block such attacks BUT the attack was so huge that the speed at which new connections were made was far more greater then the speed at which the server blocked those IPs itself. In such situations, even the best softwares can't do anything. I belive this would clear most things upDayu said:
I never said that your sites were accessible since if it had been so, it wouldn't had been a downtimeDayu said:
. All im saying is that the server was accessible on the secondary IP which could have been used to access WHM, Cpanel, webmail & all such applications.Dayu said:
There is nothing you can do to anticipate a DDOS attack. No firewall is designed to handle DDOS attacks.
A serious DDOS attack will saturate your uplink making the entire network unavailable. We've have around 2 attacks each year, although we are normally able to get things up and running within 30 to 45 minutes.
Our worst DDOS attack had 100s of attacking ips and pushed network usage above 300mbps, which triggered a network cut-off from our tier-1 supplier InterNap (to save us from being billed). We had to go through router logs and ask our tier-1 to block major offending IPs, took about 1 hour in total before we had our network up and functional (but attack continued). Took another 2 hours to have every single IP blocked.
So depending on how major the attack tamranda faced, it could take a few hours to resolve. I am suspecting it took longer because a 3rd party handles it for them (a server provider) and server providers usually are much slower and prefer to take the quick option of null routing the destination IP and then taking their own sweet time to resolve the issue.
Of course, tamranda is responsible for the end hosting product to their customers. But typically such issues are not due to inaction by the shared host, but inaction or slow action by the server provider.
JodoHost said:
Actully, one of my Server admin has setup a rule on the server which Blocks an IP using APF which tries to open Too many connections to the server. It does work in small scale cases which are triggered by a few IPs but in a Distributed Attack as the one which we faced had 100s of IPs which caused it.
Moreover, the IPs kept changing in intervals of time which was the MAJOR reason for the downtime. Otherwise our server would have started working within 2 hours. Once Each set of IPs were banned, the attack originated from a new Set of IPs.
Our Datacenter also prefers to check the sniffer logs in detail before placing any null route for any IP which causes an addition of time.
Last edited:
