1. curl -I www.google.com

2. w_get -S --spider www.google.com

3. HEAD www.google.com

4. telnet www.google.com 80
HEAD / HTTP/1.0
Host: www.google.com

From my point of view the only benefit for instance store is that it has

better IO..though if you build a RAID using several EBS volumes.

Anyway steps are : 

1. create 1 EBS volume
2. attach this volume to your EC2 instance store 

3. format it as ext3
mkfs.ext3 /dev/sdf

4. mount it
mkdir /mnt/ebs
mount /dev/sdf /mnt/ebs

5. sync the instance with the volume
rsync -avHx / /mnt/ebs
rsync -avHx /dev /mnt/ebs

(you can edit /mnt/ebs/fstab and delete the reference towards the /mnt partition)

6. sync && umount /mnt/ebs

7. create a snapshot of that volume

8. register the ami based on that snapshot

ec2-register -s snap-ID -name "EBS instance" -description "EBS instance" -architecture i386

 -ramdisk ari-d23cd6bb -kernel aki-c43cd6ad

As a result it should show something like:

IMAGE   ami-newID

mysql -uadmin -p`cat /etc/psa/.psa.shadow`

and then:

SELECT REPLACE(sys_users.home,’/home/httpd/vhosts/’,”) AS domain, sys_users.login,accounts.password FROM sys_users LEFT JOIN accounts on sys_users.account_id=accounts.id ORDER BY sys_users.home DESC ;

# Distributed Account Attack. This option will keep track of login failures
# from distributed IP addresses to a specific application account. If the
# number of failures matches the trigger value above, ALL of the IP addresses
# involved in the attack will be blocked according to the temp/perm rules above
LF_DISTATTACK = Default: 0 [0-1]

# Set the following to the minimum number of unique IP addresses that trigger
LF_DISTATTACK_UNIQ = Default: 2 [2-20]

This time I did not find any modified file..but still the sites were being reported to contain malware. Then I’ve checked in the database and seems there were some iframe entries to redirect  to some malware sites. Truncating and reimporting the affected tables solved the issue.

Question remains : is there any malware scanner for databases? What if instead of a iframe some hardcoded strings are set..most likely I would have missed those.

WARNING: mismatch_cnt is not 0 on /dev/md1

The /dev/mdX can vary depending on how many raid partitions you have. This mismatch_cnt value is the value of the blocks,

that are not synchronized between RAID-1 (mirrored) drives.  On my server it looked something like :

[root@ns ~]# cat /sys/block/md1/md/mismatch_cnt
4910080

To fix :

echo repair >/sys/block/md0/md/sync_action
watch cat /proc/mdstat

And after the repair is completed:

echo check >/sys/block/md1/md/sync_action
watch cat /proc/mdstat

Then check to see what this returns:

cat /sys/block/md1/md/mismatch_cnt

https://localhost.localdomain:8443/relay

To fix:

/usr/local/psa/bin/sso -g

/usr/share/plesk-billing/update-hostname –new-hostname=
/usr/share/plesk-billing/repair-integration –command=repair-all –idp-url=https://:8443

Though I don’t understand why does it need uid 0 and why the “OwN3D” word. This does not look too professional.

Anyway to get passed this you can run :

sed -i ‘s/$user ne \”planetbackup”/$user ne \”toor\” \&\& $user ne \”admin\”/g’ /scripts/hackcheck; echo “/scripts/hackcheck” >> /etc/cpanelsync.exclude

This is the full email warning:

IMPORTANT: Do not ignore this email.
This message is to inform you that the account planetbackup has user id 0 (root privs).
This could mean that your system was compromised (OwN3D). To be safe you should
verify that your system has not been compromised.