A few things site owners should know.

**NOTE**
Please do not reply to this thread here, please goto
http://forums.hostnine.com/showthread.php?t=2352 and put your replies there, It is very important we keep this thread information only.

Thanks
Greg


Hey guys,

I bet most of you all are confused sometimes when we say the server is under an attack, and I'm going to write this post to help explain a couple of different types of attacks and what they really mean.


First thing: The difference between a dos attack and a DDos attack.

Well, this one is probably the simplest of explanations. A dos attack is when one or a few systems make Many connections to the server, the average user stays below 10 connections to a server, but a dos attack is when they make continual connections to the server, like 50 or more would be a possible start.
It's when they hit 200 each ip, that it really becomes a problem, and they use bots and programs and such, which connects very quickly.

So, A dos is a few ips connecting WAY too many times.

A ddos is about the same thing, the difference is, a ddos uses a few connections and a lot of ips. meaning it's very hard to stop these due to the fact that each ip only connects a few times, so we cant determine who is an offender and who is a regular visitor(but even this can be mitigated, it just takes longer).

Now, we've gone through the 2 basic types of attacks, that occur on the site in General. Lets look at some other attacks that are account or domain specific.


Most common e-mail attacks:

dictionary attacks, these are when you use what is called a catch-all. In short, when your default e-mail (in cpanel) is set to your cpanel username or another e-mail, then your open to this.

When you set a default address to anything real, it means that any e-mail that goes to your domain that doesnt exist, then your default e-mail WILL except it.

So, if I wanted to attack a domain, I'd get the domain name and send to a bunch of e-mails using words and such I find in a dictionary, a program runs through a list and simply sends to all the words@domain.com
For example, if my list contained the alphabet, my program would send to:
a@domain.com
b@domain.com
c@domain.com
d@domain.com
......


So now, the catchall e-mail is getting all those e-mails(AHHH!!!) so the mail system uses tons of resources to process all these e-mails which slow down and sometimes stop every other service on the system.

The way to completely stop these attacks dead in their tracks, is to set the default e-mail to :fail:, which can be done from cpanel, and says, that any e-mail that ISNT created fails right away. Which puts an end to this whole attack.

Other forms of e-mail attacks are pretty much a dos or ddos specific to the e-mail ports.

Lastly, for now, is the difference between being hacked and getting exploited.

This is one of the hardest things to explain to customers when something happens to their site, they immediately think hacked and come to us demanding an explanation how we let their site get hacked. Telling them it was exploited, not hacked, doesnt sit to well, because they dont know what to do with an exploited site, they just want it back to normal.

Here, I will explain the difference and what you should do in either case.

First off, hacked means someone gained access to your ftp, cpanel, or some other service that is not related to your sites content, and uses that to alter your sites content. In this case, we can tell by checking certain logs to see how they got in and block them from future access.

Now, exploited means they used your sites content in a way that the script was never intended to, and they use the script on your site to actually change the look, but instead of making the script do what it's supposed to do, they make it do what they want it to do. Well, this means you either havent kept upto date with your scripts latest version, or, there is an exploit out that your script developers havent had a chance to patch.

A few things to help you tell a good script from a bad script:

register_globals being on, is a VERY bad thing, unless the script is coded by a very good developer, which is not always the case. Register_globals is the most common reason for php exploits. So in the event you are looking for a script to use, please try to use one that doesnt require this.

As for being hacked, Please always set your cpanel/ftp passwords to something with symbols, numbers, lowercase letters and uppercase letters. making them this complicated maybe hard to remember but it prevents a lot of hackers from cracking your cpanel password, which prevents a lot of hacks and such.


I hope you find this information usefull, remember, keep your scripts upto date and let us know if we can help you.

This continues, I will be building off this thread, so stay upto date.

Guys, I want to try to give you information you will need in the future, or you already need it.

Domain's resolving:

First, I wanna say, there are tons of clients that put Non-TLDs on their account, and the DNS doesnt update world wide as they normally would with a TLD.

TLD stands for Top Level domain, for example: .com .net .org
These are TLDs

TLDs update within 48 hours world wide, because they've been around long enough that their DNS servers around the world are told to pull updates from them.

Non TLDs dont update the same, because their new, and the DNS servers around the world need to pick up the zone and store it, with these types of domains, you could wait as long as a week, Also, not all ISP's DNS servers are configured to store zones for non-TLDs

Example of common problem extensions:
.us(non top level, because it's actually serving a .com domain--very hard to explain)
.info(same
co.uk(been around long enough, that for the most part, this one isnt a problem).

.com.my (Very New).
.cn
.com.cn
.net.cn
.org.cn
.mobi
.info
.co.uk
.org.uk
.tv
.ws
.ca
.eu
.cc
.jp
.de
.co.nz
.net.nz
.org.nz
.tw
.com.tw
.org.tw

These extensions are new, and will take longer to update rather then the TLDs

There is absolutley nothing hostnine can do to change that, So Please be patient. I know it's frustrating, but we dont control the worlds DNS servers.



Support tickets

Guys, one ticket per issue please.

If you have an e-mail issue and your site isnt resolving, Please dont create 2 different tickets, Your site not resolving, and your e-mail having your domain in it is not a coincidence. If your site doesnt resolve, your e-mail wont work, you just dont know how much other stuff isnt working either, lol.

I'm just saying please dont create 5 tickets for the same issue in a row, hoping we will respond faster. No, we wont, we work on tickets as they come in, per priority. We get very busy at times, but we are not infact forgetting you, we're just tied up in other things.

Also, if you notice that we have an outage(we write a forum post when we can), We stop everything to get that server backup, that server being offline is our top priority, if your not on that server, your probably thinking, great, but I have an emergency. I'd like you to ask yourself, what type of reaction would you like from us, if it was your server going down.

We react accordingly, you might get mad that we dont respond in time, but we offer things to you, that very few other hosts do, We install a lot for you, right off the break, WHMCS, RC, you cant find RC anywhere else, we make it. SSH access(there are a lot of hosts that will simply tell you know, because they dont want to take the time to install security on their servers, RVsitebuilder, there are a lot of hosts that dont offer you anything more then fantastico, mailing lists, I cant count the number of hosting companies that refuse to hosts these, multiple php versions, not hard to impliment, but hosts get so many support requests, they just dont want to offer it, because of the # of tickets for it, SSL install, A lot of hosts will tell you to go into your cpanel, and good luck, We install it for you.Windows and Linux, as well as quick migrations and transfers, all of these services are hard to find elsewhere.

Guys, these are just the services I could think of off the top of my head, We get a ton of requests to fix all these things, and I would like to make sure you are aware, that the more we offer, the more things can go wrong.

We've worked extremely hard to get all these things working without issue, So please, be patient and give us time to react to your ticket. We get very tied up sometimes with other clients and issues, but we will respond.


Finally, Abuse issues:

Guys, we will NOT notify the reseller and request that they tell the client to stop a script, when it's overloading the server. We immediately suspend, then we notify, this is part of our terms of service. We will not be changing this, and the thing I would like you all to think about is this: would you like us to let another clients scripts kill the server your on, making your site inaccessible, just so we can politely ask the reseller to notify the client and stop them? No you wouldnt, So please dont ask us why we didnt notify you, before suspending, to avoid the downtime.It's this simple: we wont chang your files, thats actually your property, and we will NOT alter it or delete it.

Just some things I think you all should know.

HAHA, it continues:

Blocked from the server, but you were just uploading your site right?

This is because, When you upload through your ftp client, you actually create a connection with every single file you upload. But that wouldnt hurt anything, IF you have an FTP client that actually closes the connection as it should.

But almost all connections linger, just for a few seconds, even after the work is done.

So you get this:

file1--done---
file2-done---
file3--done---

So, file1 connects, uploads, then it's done, but there is still a connection. And if you look at this right, there are at one point in time 3 active connections, the first dies an instant after the 3rd began. BUT this is just a general overview, the timeouts and such are not so cut and dry as my example.

So, you upload a hundred files at once, guess what, it's gonna cause you to open 100 connections, and I guarantee, you will find atleast 25 of those connections are simultaneous at some point, This is just rough guessing.

So, now you know, why your getting blocked, what can you do about it?
Compress it all, using something like Winzip, which turns it into a zip file. Then upload 1 files(longer upload time then just one of the smaller files, but only 1 connection), then through Cpanel, or Plesk, you can uncompress the file inside your directory, in a matter of seconds, I personally find this method not only to be faster, but also keeps you from being banned, the zip file is not as large as all the files added together, cutting down in upload time, and it only makes one connection.

This is frequently the case when people get banned from our servers, I thought you all might like an explanation as to why, and instead of explaining it each and everytime someone gets banned, I'll give you the heads up now, to prevent you from being banned.

Keep an eye here, I'll keep this thread updated, and Make it a Sticky

[H9Travis]

Many popular clients also allow you to set the number of connections it will make concurrently. Check with the documentation of your particular application to find out how to make those changes, if you aren't already familiar.

Excellent point Travis, I had completely forgotten about that option.

btw guys, the example should look like this:
file1--done---
----->file2-done---
----------->file3--done---
------------3


Looks like our forums stripped my spaces, but as you can see, 3 concurrent connections at once, at one point in time. Remember, this is generalized and not specifically accurate.

If you need to know an exact figure to keep your ftp client from banning you, stay below 20 concurrent connections, as Travis mentioned, some FTP clients have this option available to them. Read up on the software you use.

Editing a DNS zone, what you should know, this will be a long one, so read it CAREFULLY. This also doesnt explain everything, but our support staff will be more then willing to help explain this further.

Zone file, looks a lot like what you would see when editing it in WHM.

; cPanel 11.23.3-NIGHTLY_25254
; Zone file for domain.com
$TTL 900
@ 86400 IN SOA ns1.nameserver.com. root.server1.yourhost.com. (
2008062306 ; serial, todays date+todays
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
86400 ) ; minimum, seconds

domain.com. 86400 IN NS ns1.nameserver.com.
domain.com. 86400 IN NS ns2.nameserver.com.

domain.com. IN A 203.211.139.161

localhost.domain.com. IN A 127.0.0.1

domain.com. IN MX 0 domain.com.

mail IN CNAME domain.com.
www IN CNAME domain.com.
ftp IN CNAME domain.com.
subdomain 14400 IN A 203.211.139.161
www.subdomain 14400 IN A 203.211.139.161



The first thing you will notice is the first 2 lines begin with ; That means comment, like / in php.

Now, this whole section here:

$TTL 900
@ 86400 IN SOA ns1.nameserver.com. root.server1.yourhost.com. (
2008062306 ; serial, todays date+todays
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
86400 ) ; minimum, seconds

This is called your SOA section, the ns1.nameserver.com is your Primary nameserver, the root.server1.yourhost.com is your dns admin e-mail, it actually translates to: root@server1.yourhost.com. the $TTL is your Time to Live, meaning how quickly with the DNS server recognize your zone, when it's new. The 86400 is the refresh rate, how soon will it refresh the SOA record.

The @ really means the domain the file is associated with, do not use this on any other records.

The IN, is just that, domain.com IN SOA ns1..... so it's pretty self explanatory.

Serial is a record in which the DNS server will store a marker letting it know that the zone is loaded, when you edit the zone, you need to change this number, plus 1 will work. The refresh, is just that, how often to refresh the whole Zone. retry, same thing, if the zone fails to load, how long to wait until it loads it again. Expire, if the named server cannot reload the zone, and it keeps the cache, how long until it simply expires. The minimum, is the refresh rate for any of the parts of the zone. That means how ofter, even if the refresh or TTL is higher.


The next part is this:

domain.com. 86400 IN NS ns2.nameserver.com.

Ok, let's break this down. first part is the domain name. Then you have the refresh rate, then in NS, NS stands for Nameserver, this does NOT assign nameservers, it only points out the nameservers that should be calling it. the refresh rate is how long until it refreshes that entry, that SINGLE line is an entry.


The next part:

domain.com. IN A 203.211.139.161

Same thing, the only difference is, that this line uses the minimum entry from above, meaning it doesnt HAVE to have the refresh rate, it's ok if it does. but A is for the IP.

I'll explain ips and all that at the end of this.

The next part I'll show you is:
subdomain 14400 IN A 203.211.139.161


Notice subdomain, so subdomain.domain.com will work, it doesnt require the rest of the domain name. It's ok if the rest is there, but it doesnt require it. refresh rate, then IN A as I said before, A is for the IP.



Ok, now, lets go over the other points, like where to place a period and where not to.

periods go after fully qualified domains. ns1.nameserver.com is a fully qualified domain. So it needs a period immediately after it's entry.
But subdomain is not a fully qualified domain. It doesnt need a period. If I typed subdomain.domain.com, that would need a period.



NS, require nameservers after the entry NS.
CNAME requires a fully qualified domain name, this domain will resolve to the ip when it resolves the entry.
A requires an ip after entry.

For CNAME:

ftp IN CNAME domain.com.

This basically makes ftp.domain.com point to the same ip as domain.com

You cannot interchange these, CNAMES cannot have ips after them and A cannot have full hostnames after them.

So for ftp, I could do the same thing 2 different ways.

ftp IN CNAME domain.com.
ftp IN A 203.211.139.161

Would do the same thing.

As for MX, this one is a bit more complicated.

Syntax:

domain.com. IN MX 0 mail.server.com.

MX CANNOT have anything other then a fully qualified hostname, ip's will not work.

MX basically means Mail exchanger. The 0 is priority. so if I do this:

domain.com. IN MX 0 mail.server.com.
domain.com. IN MX 5 mail2.server.com.

Means that mail will first try mail.server.com, if that doesnt work, it will then goto mail2.server.com, after trying mail.server.com for 5 seconds, roughly, as each mail system is different.

Now, onto Routing issues.

Alot of our clients have this problem and dont understand what it means. So I'll try to explain it.

Routing is very simple. But it can cause a LOT of problems, if it's bad.

Lets say you have a site with us, Great, Go H9 *Greg dances* lol.

When you connect to your site, in ANY way, this means telnet, ssh, ftp, viewing the site, ANYTHING, here's what happens:

Your computer connects to your ISP's router, then that router shoots your signal to another server, that then routes your request to another server, and so on until it actually hits your server. This is why we ask you all to run a traceroute, it tells us every server your request hits, and the response time of that server.

For example:

traceroute to node7.myserverhosts.com (208.43.106.11), 30 hops max, 38 byte packets
1 b1.ac.5546.static.theplanet.com (70.85.172.177) 17.319 ms 5.152 ms 24.193 ms
2 vl2.dsr02.dllstx5.theplanet.com (70.84.160.162) 0.378 ms 0.371 ms 0.409 ms
3 po52.dsr02.dllstx3.theplanet.com (70.85.127.109) 0.404 ms 0.383 ms 0.378 ms
4 et3-1.ibr03.dllstx3.theplanet.com (70.87.253.21) 0.355 ms 0.320 ms 0.329 ms
5 e2.7e.5546.static.theplanet.com (70.85.126.226) 0.683 ms 0.735 ms 0.647 ms
6 ashbbbrj02-ae0.0.r2.as.cox.net (68.1.0.221) 36.406 ms 34.315 ms 34.102 ms
7 border1.te7-1-bbnet1.wdc008.pnap.net (216.52.127.36) 40.296 ms 39.951 ms 39.875 ms
8 te1-1.cer01.wdc01.washingtondc-datacenter.com (66.151.100.66) 39.614 ms 39.473 ms 39.451 ms
9 po1.fcr01.wdc01.washingtondc-datacenter.com (208.43.118.134) 40.470 ms 39.954 ms 39.900 ms
Now, we leave our server(I did this from another server on our network), and we hit other servers on our way out of the planet. We route through 5 different servers/routers before we leave the datacenter, this means our signal literally bounced off 5 different servers then finally left and hit one of the ISP's that the planet uses.

Then that ISP, found a close server for the destination to route through, and it did, it routed the request through those closer servers and made the request go that way, then inside that datacenter, we hit 2 routing servers and our traceroute doesnt extend to the point that it tells us if we made it or not.

So when you have bad routing, it will show in a couple of forms. The thing you will notice with the traceroute is it gives the response times. 3 sets to be exact. IE:

et3-1.ibr03.dllstx3.theplanet.com (70.87.253.21) 0.355 ms 0.320 ms 0.329 ms

First part is the hostname(ussually looks randomly thrown together, the hostname is chosen by the DC. Then the ip. Traceroutes send out packets that the server then responds to. here's the breakdown:

{PC} --Sends packet to server.
{SR1} --Server gets the packet
{SR2} --Server responds to the packet
{PCG} --PC gets the response from the server.

Timeline:
{PC}-------{SR1}--{SR2}----------{PCG}

So your PC might send out a packet, the server gets it, 5 seconds after you send it out(seriously exaggerated). It marks the time in the packet, so that is how it takes.

So the packet starts out with the date and time it was sent, then the server marks it with the date and time it got it, then the date and time it was able to respond to it, then it shoots it back. The first 2 are the entries the server makes, but the last one is the entry that your PC makes, it shows the time it took for the packet to come back to it.


So, what happens when your PC takes too long to get a response? Well, if the packet is taking so long to get back to your PC, that means that your system is not going to be able to read it right. Ussually bad routes mean Your system will get missed data and therefore will give you errors.

What can we do about these? Well, until you hit our network, it's out of our hands.

If you can reach the DC we host your server in, then we can change the route from that point on, if you cannot, only your ISP can change this.

Now I made this because a lot of people dont understand routing. routings should take no longer then 100 m/s, anything longer, is bad and should be rectified. If you see us asking for a traceroute, it's to see where your requests are dying, if it's not in our network, it means it's dying before we can do anything about it. If it is within our network, we can get you unblocked.

Traceroutes are invaluable tools, you should use it to understand the routing to your site, use it to determine where you are getting blocked.

Alternatively, please understand that we cannot ask your ISP to unblock an ip, they do not accept our requests, only their clients can request such actions. It's why we ask you to contact your ISP when we cannot resolve blocking issues.

Bad routing can lead to sites appearing down(even if your not blocked but there is a request between you and the server that takes a long time to respond), slow loads, other services seem down. All because your computer is designed to kill off replies that take too long.

Yes, if the routing is bad, it means that it's going to take that long to respond.

If you have a bad route, try pinging the server, pings send out packets and see how many come back, ping it for a bit, then get out of the ping.

PING node5.myserverhosts.com (64.34.169.117) 56(84) bytes of data.
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=0 ttl=52 time=35.0 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=1 ttl=52 time=35.2 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=2 ttl=52 time=34.5 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=3 ttl=52 time=34.9 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=4 ttl=52 time=34.7 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=5 ttl=52 time=43.4 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=6 ttl=52 time=35.1 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=7 ttl=52 time=34.9 ms
64 bytes from node5.myserverhosts.com (64.34.169.117): icmp_seq=8 ttl=52 time=35.2 ms

--- node5.myserverhosts.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8010ms
rtt min/avg/max/mdev = 34.507/35.921/43.489/2.690 ms, pipe 2

Notice the last part, 9 packets sent, 9 received, 0% packet loss, and the time.

8010, is the overall time, no server in the route took that long to respond, it's the overall time. This is a good thing, bad routes may let a few packets through but the time will be much higher. Also, you will lose packets. Dropped packets are like losing data, and your computer cant recover from those, it tries to resend it, but if the routing is bad, it will take that much longer to get a response anyway, so your computer will eventually say, this is taking to long and it will stop the request.

I really hope this helps you all understand routing and DNS, I worked hard to put everything I could think of into this.

Internal 500 errors, if you got them, I'll show you why:

First thing you need to know, is in our environment, we Run Suexec.

This means that if your script has to write to any files or directories, permissions do not need to be 777 or 666.

A lot of exploits(refer to the above posts for the difference between exploits and hacks) used against sites were only useable because the script demanded some directories and files be those permissions.

In Suexec, you cannot have those permissions, but dont worry, a permission of 644 for files and 755 for folders allow the files and folders to be written to, but they are written as the user and therefore, cannot be exploited the same way

But when you do make a folder 777 or a file 666, you end up breaking your site, because we do not allow those permissions(trust us, it doesnt risk the server security, only your site). So we do this to protect your sites, we used to get a lot of tickets about sites being exploited and these permissions were why.

Public html, that's a weird one, you should never change the permissions or ownership to public_html.

They should be 750 for permissions and cpuser for user and nobody for group, that's ownership. Otherwise you will break your whole site.

These 2 are common reasons for 500 errors.

Other reasons include:

Invalid lines in .htaccess, remember, no php directives should be in .htaccess, you should create a php.ini and put your directives there.

Also, any invalid rules in the .htaccess will break it as well, to test this, simply rename your .htaccess and see if your site loads then.

Perl/cgi scripts, These need to have permissions of 755 or they will not work at all.

Finally, you can check your error_log in Cpanel, and see the errors that apache is outputing when it tries to read your files.

The 500 error is an apache service error that says something is misconfigured. And it will write the reason to it's error log.