Phine Solutions web work notes

Using a third party DNS have some great benefit:

1. By outsourcing the DNS look up the load is reduced on your own server, especially like a VPS or dedicated box which runs everything: Apache, MySQL, Named.
2. Well know DNS operates on a backbone and provide each DNS request with complete redundancy.
3. Taking the Named service off  from your server not only reduces load but also reduces the open port and maintenance work.
4. An external DNS server will provide better control. This really applies to the domain or sites on shared hosting service and the capability of updating the DNS zone info such as TTL is limited. When it comes to changing the hosting provider, the delay of switching hosting DNS can be unpredictable.

I tried out dnsmadeeasy.com for one of my site and the result was great.  It was amazingly simple to create domain name record in dnsmadeeasy account and the change was propagated in a matter of minutes. Another site dyndns.com also provides this kind of service with the similar fee structure. Using the free DNS check service from intodns.com (dnsstuff.com requires fee now) is also recommended to make sure everything is in order.

Just some iptables cheatsheet :

show the current iptables:

iptables -L

check firewall service:

service iptables status

enable iptables service:

chkconfig –level 345 iptables on

save iptables

iptables-save

save iptables to /etc/sysconfig/iptables

service iptables save

Ban an IP:

iptables -A INPUT -s a.b.c.d -j DROP
# using a netmask:
iptables -A INPUT -s x.y.z.0/24 -j DROP

To delete a rule:

iptables -D INPUT -s a.b.c.d -j DROP

APC stands for “Alternative PHP Cache”. It’s one of the 3 PHP accelerators out there (the other 2 are Zend and eAccelerator).

The installation package can be found here: http://pecl.php.net/package/APC

Follow the installtion guide in the package, the apc.so is installed under:

/usr/local/lib/php/extensions/no-debug-non-zts-20060613/

This path will probably varies in different systems.

Now modify the php.ini:

1. extension_dir needs to be modified to the path above.

2. add the extension=apc.so to activate it.

3. tweak a few settings:

apc.shm_size=30 <– 30m is the default value. If up it to something like 128m, I would think the Linux system shared memory setting will also need to be increased more than that. It is 32 by default, which can be found in this file: /proc/sys/kernel/shmmax

I leave the shm_size to 30 for now.

apc.ttl=7200
apc.user_ttl=7200

4. restart the httpd service. Copy apc.php to the webserver. Check phpinfo(). Watch the Apache error_log.

To increase the APC  shm_size, the kernel’s  max shared memory size will also need to be increased since it is set to a very low value by default.

Add kernel.shmmax=134217728 to /etc/sysctl.conf, and run sysctl -p to make the setting take effect. This will increase the max shared memory size to 128MB.

It is quite easy to create web server access restriction using the Cpanel. There is a configuration setting for "Password Protect Directories" in Cpanel for setting up a user name and password for directory access. What this really does is to create a password file and refer it in the .htaccess.

In stead of using Cpanel, one can always run the process through the command line and it may actually be easier.

Create the passwd file

htpasswd is an Apache utility command to create and update the flat-files used to store usernames and password for basic authentication of HTTP users. Since it will create name and password pair(s) in a flat file, the password is encrypted either using a MD5 version from Apache or crypt() system call.

The following command line can be used to generate a file name passwdfile:

htpasswd -c /home/user/etc/passwdfile admin

his will create a NEW passwdfile and add user "admin" in it. The command will also prompt for the password that you wish to give to this user.

To add a new user, the "-c" option cannot be used.

To remove a user, simply open the htpasswd file and delete the line.

Modify .htaccess

To turn the password into effect, you can add  the following lines in the .htacess file:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile "/home/user/etc/passwdfile"
require valid-user

This will allow anyone in the .htpasswd file to have access.

Besides the flat text password file, one can also use alternate password storage such as DBM or DBD format according to Apache document.

Group the users

There maybe situations that there are a lot of users and they are granted access to different resources. It maybe easier to group the users instead of creating a bunch of .htpasswd files.

A group file is simply a flat file that contains some user names. An admin group file (let's call it admingroup) may look like this:

Admin: admin jdoe mjones

And the .htaccess should include the following:

AuthType Basic
AuthName "Admin Group Only"
AuthUserFile "/home/user/etc/htpasswd" "/home/user/etc/.dmingroup"
Require group Admin

As specified in .htaccess, this is really just a "basic" way for authentication. It is most suitable for a small group of users to access some resource and there is no need to create more sophisticated authenticated method.

If you own a Linux box and use ssh to access it over the internet, chances that it will be under unauthorized login attempt or even brute-force attack. Even you have a strong password for your account, the constant poking from people or evil-bot is some kind of a nuisance to say the least.

Messages like below in /var/log/secure shows how annoying they can be:

Nov 25 23:13:21 —- sshd[21529]: input_userauth_request: invalid user test7

Nov 25 18:13:21 —- sshd[21523]: reverse mapping checking getaddrinfo for h63-210-66-233.seed.net.tw failed - POSSIBLE BREAKIN ATTEMPT!

Nov 25 23:13:30 —- sshd[21607]: input_userauth_request: invalid user test8

Nov 25 18:13:30 —- sshd[21602]: reverse mapping checking getaddrinfo for h63-210-66-233.seed.net.tw failed - POSSIBLE BREAKIN ATTEMPT!

To fully utilize the capability that ssh offers, we should always use public/private key access to a *nix box that is running OpenSSH. Below are some simple steps I used to implement this methodology.

Since I am using PuTTY, the setup and testing are done using putty.exe and puttygen.exe that are downloaded from here.

1. Create public and private key pair.

This can be accomplished using PuTTYgen. Once the program is started, click on the "Generate" button and keep moving your mouse. You can't be lazy here because the it will not proceed until you make your move.

2. save the public and private keys

Once the keys are generated, you need to create a key comment and your private passphrase. The passphrase is tied to your keys so without it your keys are useless. The public key is basically plain text that shows in the box. The private key is in binary form and should be stored with a .ppk extension.

3. place the public key

The public key needs to be stored in the Linux server as $HOME/.ssh/authorized_key2. Since it is plain text you can copy the key from the previous screen and paste them in a Linux editor and save it. An IMPORTANT step is to set the right permission on $HOME, $HOME/.ssh or $HOME/.ssh/authorized_keys so they aren't more permissive than sshd allows by default, which means they can only be read and write by the current account.

The following command can be used to achieve this: $ chmod go-w $HOME $HOME/.ssh $ chmod 600 $HOME/.ssh/authorized_keys

4. place the private key

In PuTTY, you will need to load the private key to your PuTTY session and save the session:

After this step, yu should be able to try the newly configured ssh access. You should be asked to enter the passphase this time, instead of the password. Once this is verified, you can proceed to next step.

 
5. turn off the password authentication on OpenSSH

In the /etc/ssh/sshd_config, there is an option called "PasswordAuthentication", just set it to "no".

Restart sshd and you should be running more secured ssh now.

Even you are running more securely after these measures, you still can't stop people from scanning port 22 and trying to get authenticated repeatedly using a list of user name and password. To reduce this kind of noise, you can also change the running port of sshd. The port configuration is the first parameter in the /etc/ssh/ssh_config file.

There are several parameters in httpd.conf file that I pay attention to. Although the default values normally work out for me, sometimes they need to be tweaked for better performance.

HostnameLookups off 

Apache can look up the visitor's ip and come up with the hostname. And this process will likely slow down the server a bit. 

MaxClients

The max number of child process to spawn. Each Apache child process will take up some memory so this count should be determined on the available memory (total memory - allocation for other processes) and normal Apache child process size.

KeepAlive On

Whether to re-use the connection for multiple HTTP requests. Opening socket is an expensive process. The KeepAlive option can help reduce the overhead of frequent connections.

KeepAliveTimeout = 15

The number of seconds to keep a socket alive waiting on other request. Setting this number to high can cause the too many connections linger and evetually no more connections are available when the MaxClients is reached.

Timeout 300

Disconnect when idle time reaches this value. Depending on the average page loading time it can be lowered to reduce the hanging request.

SendBufferSize

The size of the ouput buffer. Normally I don't mess with this setting as far as it's a reasonable value and big enough for most of my web page sizes. 

Directory settings - The <Directory> tag for the web server root 

AllowOverRide All - tells Apache to pick up the .htaccess setting from each individual directory if available. For better performance this needs to be set to none since Apache will attempt to open .htaccess for each file name request.

Options Index - tells Apache not to perform directory listing when there is no default pages like index.htm(l)… 

Options FollowSymLinks - Apache sever will follow the symbolic links.

Options SymLinksIfOwnerMatch - do not set this. 

Allow directive - If there is need to control which hosts can access the server, use the ip address as much as possible. For example, "Allow from 10.1.2.3" is better than "Allow from allowedhost.com". When the server sees a hostname, it will perform a reverse DNS lookup on the ip to get the hostname, and then do a forward lookup on the hostname to assure the ip addresses match. And this is an expensive process.

Modules 

Only enable the necessary ones to keep the server lean and mean.

This is a great post about writing secure PHP code and part 2. The articles pretty much cover all the points we need to look at to write secure PHP code.

Additionally this post talks about how hackers can use Google code search and a simple sitemap to gain access to your system.

I have several hosting accounts ranging from shared hosting to VPS. Besides their hosting duties, I also assigned them some additional tasks.

Install cron jobs on a shared hosting account to ping the other servers for uptime. A simple PHP script like this can do the job:

<?php

$url = "http://www.domain.com";

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_HEADER, 0);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);curl_exec($ch);

if (curl_errno($ch) != 0) {

  $subject = "Site is down";

  $message = "Site is down at " . date("Y-m-d H:i:s");

  mail("webmaster@domain.com", $subject, $message);

  echo date("Y-m-d H:i:s") . " $url is down \n";

} else {

  echo date("Y-m-d H:i:s") . " $url is up \n";

}

curl_close($ch);

?>

Also, there are several sites that offer free domain monitoring like:

SiteUptime Website Monitoring

Montasitic 

Both of them are pretty solid based on my experience. SiteUptime also offers pinging from west coast server or east coast server. With the combination of the free service and your own monitoring, you can get a decent idea about the stability of the domain you are trying to keep an eye on.

Use one account for CVS code repository.

CVS is developer's friend to maintain code.

On server side, to create a CVS repository we can run this command:

cvs init -d ~HOME/project_cvs

On client side, there is a pretty nice tool we can use for CVS utility: Tortoise CVS.

Most shared hosting services are loaded utilities; with a little additional SSH can be available too. So why not use them.

DNS stands for Domain Name Server (or System). It provides a "directory" like service to map a domain name to a IP host. The setup and configuration of DNS is critical since it can make a website "invisible" on the internet if not done correctly. Understand the basic stuff can make this process a lot easier.

First, some terminologies and tools that can check for DNS setting

DNS uses has different record types to define a domain. The most used one are as follows:

A - stores the host ip address CNAME - alias record, for example, www.phinesolutions.com is the alias for phinesolutions.com

MX - mail exchange record which tells mail server how to route emails.

CNAME - Canoical name: Used to assign aliases to existing A records, for example, a domain.com can have other alias such as www.domain.com, ftp.domain.com…etc.

Once the basic meanings are clear, you shouldn't have too much trouble to read the report from www.dnsreport.com , where you can spot the DNS problems with your server and make changes.

If you have access to a *nix system, the "dig" command can be very helpful too:

dig www.phinesolutions.com tells me the A record for the domain.

dig phinesolutions.com mx tells me the MX record.

Notice we lose the "www" part because we really need to check the domain name without it. People use email address like email[at]phinesolutions.com, instead of email[at]www.phinesolutions.com.

dig is a powerful command and you can certainly dig out a lot more information than above. A look at dig man page should make a nice guide on this.

Next, is an example of using BIND to run a DNS service.

BIND - Berkeley Internet Name Domain

BIND is an implementation of DNS protocols. It includes a set of components that are necessary to run and maintain a DNS server. The BIND package is installed on the vast majority of the DNS server machines on the internet.

Named

Named it part of the BIND package and will run as a Daemon process to handle the DNS requests.

/etc/named.conf

This file serves as a name server configuration file. It provides the settings for named to run. Most of the settings do not need to be changed. But to add a domain name to a name server, a "zone" setting has to be added into this file, like the one below:

zone "phinesolutions.com" { type master; file "/var/named/phinesolutions.com.db"; };

This basically tells named that it should handle the request for domain name "phinesolutions.com" and the zone file for this domain is /var/named/phinesolutions.com.db.

A "zone" is not necessarily mapped to a domain name, it can also be mapped to a sub-domain name like "my.phinesolutons.com".

zone file

A zone file, for example "/var/named/phinesolutions.com.db" in the above example, tells the DNS server HOW to keep this zone record. For example, how often should the server updates other DNS servers about the whereabout (IP) of this domain. Here is what is looks like:

To understand this, we need some explanation:

1. Throughout the file, there are numbers like 14400 and 86400, they are the Time To Live (TTL) value. It defines the length of time, in seconds, a particular zone info is valid. As you can see in the beginning of the file, "$TTL 14400" sets the default value. And the individual records have their own and can overwrite.
2. SOA - Start Of Authority. This specifies the primary name server for this domain name and a set of values that are related to the name server. I am going lazy here, if you need to understand what they are for you can find it from this RedHat documentation.
3. NS records. Again they define the primary and secondary name servers for this domain. 
4. A record, like explained in the previous section, shows the IP that this domain is pointing to.
5. MX record points to the same sever since I have the mail server running on the same server. Multiple MX records indicate the multiple mail servers for the domain. And the number 0 shows the priority of the server.
6. My CNAME records include www, mail and ftp. So if a user tries to access www.phinesolutions.com, ftp.phinesolutions.com or mail.phinesolutions.com, the name sever knows where to point them to.

Once you have one working zone file in place, it can be used as a template for the others. The zone file has some special format, such as the "." following each domain TLD. They have to be there or it won't work.

With a host management tool such as Cpanel, all these can pretty much configured through a friendly UI without getting down to the dirty work of file editing. However, knowing these simple concepts can help you better understand the process and know where to look into when needed.

Pick the right MTA is an important step for a webmaster. For a *nix system, the most popular ones are Exim, Postfix, Qmail, and Sendmail. Here is a very good article talking about their differences and how to compare them:

MTA comparison