Skill Level : Beginner

In this post, I will explain how to convert an add-on domain to a primary domain. Considering a complex case, lets consider the primary domain should be a different one from the one that holds the Add-on domain.

Pre Requisites

Server Platform : Linux

User requires     : cPanel and SSH access (root)

This is a Site transfer. Also both the sites I’ve mentioned here is on same server.

Case

The Add-on Domain under a website has to be converted as its Primary Domain. If you have a Full backup, its another case. I’ll explain it in another post.

Solution

Lets consider the Add-on Domain is addon.com under the user admin and the document root of the add-on domain is :

/home/admin/public_html/addon

Now it should be transferred as the Primary Domain

* Using WHM Create a New account primary.com, the document root is then say /home/primary
We’ve to transfer the whole data from /home/admin/public_html/addon.com to /home/primary/public_html first.

* The Steps will be :

root@server [/home/admin/public_html/addon]# cp -r ./* /home/primary/public_html

This will recursively copy everything inside the PWD to the specified location

Don’t forget to copy .htaccess too

root@server [/home/admin/public_html/addon]# cp .htaccess /home/primary/public_html

* Thats it, the contents are moved, but there is a database too which has to be moved eventually.
* I’ll site some type of websites like CMS and Blog :

For a Magento website, the database configuration is specified inside the local.xml file which is placed inside the /app/etc directory inside a domain. For example

root@server [/home/admin/public_html/addon]# cd /app/etc
root@server [/home/admin/public_html/addon/app/etc]# cat local.xml

* Watch for these lines in the local.xml file

<username><![CDATA[admin_user]]></username>
<password><![CDATA[password]]></password>
<dbname><![CDATA[admin_db]]></dbname>

Lets call the old Master node as ‘x’ and the server to which Solusvm Master has to be migrated(new Master) as ‘y’

Login to the server ‘y’:

Install SolusVM Master:

wget http://soluslabs.com/installers/solusvm/install

chmod 755 install
1./install

Choose the option ’1′ and hit ‘Enter’

Choose Option ’2′ and continue with the installation.

This will now automatically finish the installation and once this is completed, you can access the new master admin page from here :

http://newmasterip:5353/admincp/login.php and login using [Default]

Username : vpsadmin

password : vpsadmin

We are now done with the new master server setup. We can now proceed with the migration. Login to the server ‘x’ via SSH. The master node saves all added vps/container informations on a database. We could find the database username and password from the file /usr/local/solusvm/includes/solusvm.conf

eg :

SolfGhcMZ8zjyx:SolfsfgDl13IQ:7qb7Tdo6fZS2CQoLfjfjhrDOYNvb8:localhost:4LJ3ddew285TfW3EE0Z9G5YZK7ROR74AT7WVJEDSIZ

The four field consists of <databasename>:<use>:<password>:<host>:<the key> Here the database name and database  are SolfGhcMZ8zjyx and SolfsfgDl13IQ respectively.

We now need to backup the database and restore it to the new Master.

To backup the database :

mysqldump SolfGhcMZ8zjyx > SolfGhcMZ8zjyx.sql

Now copy the database backup SolfGhcMZ8zjyx.sql to the new server. (SCP/FTP)

Login to the server ‘x’/new master:

Find the database name and user of the new server and restore the old back to it.

Find the database name and user from /usr/local/solusvm/includes/solusvm.conf. We new need to restore the old back to the new database here.

/usr/bin/mysql --user=newuser --password=newpassword  newdatabasename < SolfGhcMZ8zjyx.sql

Verify the migration by login to http://newmasterip:5353/admincp/login.php and check whether you are able to list the VPS of old master server. Make sure that you update the master IP on all slaves to the new master IP from /usr/local/solusvm/data/allow.dat

IFS or Internal Field Seperator holds the value which seperates the various entities. This can be file names, values read into a script by read etc. It is the character or characters designated as whitespace by the operating system.

The IFS is set to the newline and space character. The global variable $IFS stores the value. To view the exact value stored in IFS execute:

echo "$IFS" | cat -vTE
 ^I$
$

Running echo “$IFS” will not give you any visible output (after all, you are going to see a space and a newline). cat -vTE displays non printable characters , tabs as ^I and ends each line with a $ sign.

In a script which utilises filenames (with spaces), it is always preferable to change the IFS to include only the newline character opposed to the default space and newline character. Lets check out one such script which accepts filenames wih spaces. This scripts simply prints the file names in your current directory. (Remember to create some files in your currenct directory which has spaces. You may try the same script removing the lines with the IFS variable in reference to see the difference)

#!/bin/bash
OIFS=$IFS # Original IFS

IFS=$(echo -en "\n\b") # New IFS

for fil in $(ls -1 $PWD); do
	echo $fil
done

IFS=$OIFS # Restore earlier IFS

IFS can also be used to read files with lines sepearated by a special character. For example in the /etc/passwd, to store the various entries like username, homedirectory etc.

The following script uses the while construct to determine the users who have the shell portion as /bin/false

#!/bin/bash

OIFS=$IFS
IFS=':'

while read username password userid groupid comments homedir shell_avail
do
	if [[ $shell_avail == /bin/false ]]; then
                echo "$username has no shell"
        fi

done < /etc/passwd
IFS=$OIFS

In the above script each of the 7 portions of the /etc/passwd file is assigned to the 7 variables
username password userid groupid comments homedir shell_avail with the read command. The if portion in the script compares the seventh variable – shell_avail to /bin/false to determine the username and outputs it.

From now on you can use the IFS variable for all those files with spaces and extracting values separated by a special character.

Attackers after getting access to a server, will install a rootkit to hide their identity and run desired scripts anywhere within the server. It makes the life of a hacker easy once installed. Rootkits are not easily detectable. Sometimes, if the rootkit is one of the latest ones without a diagnosis, the server will have to be rebuild from scratch.

A rootkit will have multiple applications for cracking the entire server, some of them are:

Server Access Applications (Back door application)
These applications will create a backdoor to log in to the hacked system without using the exploit again.

Log clearing Applications
These applications clear the logs of the events performed by the hacker or the applications used. They all the associated log files in the server.

Packet sniffing Applications
These applications monitor the data through the various interfaces in the server at particular ports.

Malicious Scripts
Many scripts will be installed like IRC bots, ddos daemons, spam servers, trojans, worms etc.

There are mainly two kinds of root kits. The application rootkit and the kernel rootkit.

Application rootkits
These rootkits mimic a particular application and will hide the attackers files/processes from being revealed by the original application. To illustrate, a rootkit ls application will perform all the task of a normal ls but will not display any of the files of the attacker. Other application rootkits will create backdoors for unauthorised access, packet sniffers etc which go undetected or are hidden by renaming. Application rootkits are the most common.

Kernel rootkits
Kernel rootkits modify the kernel and apply patches to the kernel and device drivers. They also hide the applications and files of the attacker. As antivirus and other applications run beneath the kernel, they are the most undetectable rootkits.

‘Prevention is better than cure’ – as this saying goes, it is always better to keep the system secure and updated when ever possible to stop these installations. There are some applications which help detect any known rootkits running in the system. One such is the chkrootkit.

chkrootkit is one of the popular rootkit detectors (an anti-rootkit) and it is know to detect common rootkits on unix/linux servers. chkrootkit relies on basic string processing techniques to determine the presence of rootkits. It scans specific sytem files and binaries targeted by rootkits for known signatures.

The following are the instructions to install chkrootkit version 0.49 in a server.

cd /usr/local/

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5

md5sum -c chkrootkit.md5 # to check if the downloaded file is intact

tar -xzf chkrootkit.tar.gz

cd chkrootkit-0.49/

make sense

./chkrootkit

chkroootkit will check all the files and display the status of the files analysed. This information may be logged for future reference. For this a cron job may be setup to be run at least once a month.

Inserting an entry like the one below into the systems cron tasks (executed atleast once a month) will send the report of the chkrootkit vulnerabilities to the administrator conserned.

/usr/local/chkrootkit-0.49/chkrootkit | mail -s "chkrootkit report $(date +%d/%m/%y)" "admin@domain.com"