Servers running litespeed doesn’t support php.ini for user accounts. Fortunately, we can enable this.
Go to WHM>>LiteSpeed Web Server Plugin>>Lite speed configuration>>WebAdmin Console>>Configuration>>External App >>lsphp5Â >> Edit >>Â Environment Add this line
PHPRC=$VH_ROOT
Fix :
To block a single IP :
ip route add blackhole XX.XX.XX.XX
To block a network range :
ip route add blackhole XX.XX.XX.XX/16
To remove the block :
ip route del XX.XX.XX.XX
ip route del XX.XX.XX.XX/16
======================
Internal Server Error
500
No response from subprocess (/usr/local/cpanel/base/3rdparty/installatron/index.cgi): subprocess exited with status 199
solution: do the steps below..
rm -fr /usr/local/installatron/lib /usr/local/installatron/etc/php.ini
curl -OÂ http://dal01.installatron.com/installatron-plugin.sh
chmod 755 installatron-plugin.sh
./installatron-plugin.sh -f –edge
Save the below given bash script in a sh file like blockwplogin.sh and exexute the same from the shell. The script will find and block only attacking Ip’s.
vi blockwplogin.sh and add the below script
Chmod 755 blockwplogin.sh
Execute it
./ blockwplogin.sh
Sit back, relax 🙂
========<<>>=========
#!/bin/bash
#
# Save all requests to any wp-login.php file on the server, to a temporary log
#grep -R “wp-login” /usr/local/apache/domlogs/* > /tmp/wplogins.txt
egrep -R “wp-login|wp-includes\/css” /usr/local/apache/domlogs/* > /tmp/wplogins.txt
# Find IP addresses which sent a POST request to any wp-login.php file
for i in `tac /tmp/wplogins.txt | grep POST | awk -F: ‘{print $2}’ | awk ‘{print $1}’ | sort | uniq`;
do
results=0
exists=0
# Check if this IP address sent a request for CSS files
results=`cat /tmp/wplogins.txt | grep “$i” | grep css | awk -F: ‘{print $2}’ | awk ‘{print $1}’ | sort | uniq | wc -l`
# If not, it is an attacking IP. Add it to a deny rule in /home/.htaccess (if not already exists there)
if test $results -lt 1
then
csf -d $i
fi
done
=========<<>>=========
An outdated wordpress version can cause hacker to trespass the server.The below script will find the wordpress versions for sites runni g in server.
locate version.php | xargs grep wp_version |grep -v “global\|backup\|virtfs”
If you are seeing a lot of access to wp-login.php , you can conclude it as a wordpress attack. The below script will show you the sorted list of accessing ip’s to wp-login
《《《》》》
egrep ‘wp-login.php’ /usr/local/apache/domlogs/* | grep -v ftp_log | awk -F : ‘{print $2}’ | awk ‘{print $1}’ | sort | uniq -c | sort -n
《《《》》》
The result will be shown as below:
2545 69.56.xx.xx
Here the first parameter is the number of hits and second one is the .You can block these ip on firewall to get rid of this.
Also, you can use the below command to get the result for a particular date.
《《《》》》
grep wp-login.php /usr/local/apache/domlogs/* grep “16/Jan/2013:03″|awk ‘{print $1}’ | cut -d: -f2 | sort | uniq -c |sort -n | tail
《《《》》》
If the problem occurs continously,
drop all wordpress login through port 80
————
whille allowing the wp-login again ,please remove this rule
iptables -I INPUT -p tcp –dport 80 -m string –string “wp-login.php” –algo bm -j DROP
If its a xmlrpc.php attack,just replace wp-login.php with xmlrc.php for all the commands like below.
iptables -I INPUT -p tcp –dport 80 -m string –string “xmlrpc.php” –algo bm -j DROPThats all.. 🙂
SuPHP and you
SuPHP is probably one of the first steps to hardening a PHP installation. It doesn’t really add security in the fact that it makes the code less vulnerable but on machines with multiple sites it makes it so that a compromised site can’t take advantage of other user accounts without a lot more work.
What Is SuPHP?
SuPHP does a few things. First and foremost it causes a system to run PHP code called via Apache as the user who owns the account. Why is this important? Normally a user called “nobody” whom is a generic catch all user is used to run PHP scripts for the web server. This means that it needs to have the ability to read and execute those scripts as well as the ability to write any temporary files and directories it may need to. If an attacker gets on the system through one account running poor or out of date code, it will let them be able to alter data on other accounts. The fact that PHP scripts were run as this catch all user violates the reason Unix style permissions are a great thing for security. SuPHP causes these permissions to be back into full swing again.
SuPHP also has a secondary function. It will make it so that files which are globally writeable are not allowed. This means any web site with “777” permissions or any directory with “666” permissions will cause SuPHP to give a 503 error. These can be traced using the Apache log, or you can use find to check for these permissions. “777” PHP is a bad idea and should be avoided unless temporary (as example setting a site up requires the files as 777 and then they are changed back)
Installation
For CPanel/WHM machines, this is as simple as checking and seeing what handler you’re using. There is a very good chance you’re using DSO or FastCGI. Change the handler to SuPHP if it’s there and you’re good to go. If not you’ll have to rebuild Apache using Easy Apache, and then enable SuPHP at the end. Not a biggie but it will result in about 30 minutes of down time.
Configuration
There are a few things that need to be done. The first is a full backup. Sed/find and other utilities listed below are dangerous. You can break things easily if you’re not clear on what you’re doing. The second is that your .htaccess files need to have any php directives removed. How I find what files contain such directives are:
find /home/* -name .htaccess -exec grep php {} -ilr \;
As an example this is my test box, I added a few myself.
[root@FS01 roboto]# find /home/* -name .htaccess -exec grep php {} -ilr \;
/home/network/tms_backups/public_html/smf/attachments/.htaccess
/home/network/tms_backups/public_html/smf~/attachments/.htaccess
/home/roboto/test/test2/.htaccess
/home/roboto/test/.htaccess
We should take the variables that we strip, and then put them in a respective php.ini in the same directory. If we don’t sites could break. To dump the contents of this to a file we would run:
find /home/* -name .htaccess -exec grep php {} -ilr \; > file.txt
and we have a nice list of stuff to go through and add php.inis. If there’s demand for it I will add steps on automation of the creation of these files as well.
If I wanted to see what these are I would remove the i from the -ilr in grep. As an example:
[root@FS01 roboto]# find /home/* -name .htaccess -exec grep php {} -i \;
RemoveHandler .php .php3 .phtml .cgi .fcgi .pl .fpl .shtml
RemoveHandler .php .php3 .phtml .cgi .fcgi .pl .fpl .shtml
php_variable
php_variable
If you notice I have a few handlers removed from the directories, this is likely for security reasons. Not a bad idea it prevents people from putting code in directories it shouldn’t be in and running it.
Back on topic though, there are also two php_variable flags here. php_variable and php_value are normal to see in .htaccess files. Since we know that “php_” is unique in this case, actually editing these files is easy. We just use sed combined with find. As an example:
find /home/* -name .htaccess -exec sed -i ‘s/php\_/\#php\_/’ {} \;
We run it and then check again:
[root@FS01 roboto]# find /home/* -name .htaccess -exec grep php {} -ir \;
RemoveHandler .php .php3 .phtml .cgi .fcgi .pl .fpl .shtml
RemoveHandler .php .php3 .phtml .cgi .fcgi .pl .fpl .shtml
#php_variable
#php_variable
This is how we successfully strip the php variables and flags out of our .htaccess files in as complete of a way as possible.
Lastly we need to find and change any permissions that are not SuPHP friendly. This is simply done by running find with a -exec that changes the permissions of insecure files and directories.
find /home/* -perm 777 -type c -exec chmod 755 {} \;
As an example I made some test files that are 777 permissions.
[root@FS01 roboto]# ls ./test/ -lh
total 8.0K
-rw-r–r– 1 root root 0 Jun 22 02:28 fila.example
-rwxrwxrwx 1 root root 0 Jun 22 02:28 file1.tx
-rwxrwxrwx 1 root root 0 Jun 22 02:28 file1.txt
-rwxrwxrwx 1 root root 0 Jun 22 02:28 file1.txtas
-rwxrwxrwx 1 root root 0 Jun 22 02:28 file1.txtasfhg
-rwxrwxrwx 1 root root 0 Jun 22 02:28 file1.txtasfhgasghadf
drwxrwxrw- 2 root root 4.0K Jun 22 02:18 test2
drw-rw-rw- 2 root root 4.0K Jun 22 02:32 test3
In cases like these it is best to try and make a non destructive evaluation first. This means running it without changing permissions. If there is internal stuff at this point I would stop what I was doing and regroup rather than change permissions of it. This would include anything for Plesk, CPanel or the server its self.
[root@FS01 test]# find /home/roboto/* -perm /766 -type f
/home/roboto/test/test2/.htaccess
/home/roboto/test/file1.txtasfhg
/home/roboto/test/.htaccess
/home/roboto/test/file1.txt
/home/roboto/test/file1.txtas
/home/roboto/test/fila.example
/home/roboto/test/file1.tx
/home/roboto/test/file1.txtasfhgasghadf
Since everything looks good for me in this case, I’m going to go ahead with my execution.
[root@FS01 test]# find /home/* -perm /766 -type f -exec chmod 755 {} \;
[root@FS01 test]# ls -lh
total 8.0K
-rw-r–r– 1 root root 0 Jun 22 02:28 fila.example
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.tx
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txt
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txtas
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txtasfhg
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txtasfhgasghadf
drwxrwxrw- 2 root root 4.0K Jun 22 02:18 test2
drw-rw-rw- 2 root root 4.0K Jun 22 02:32 test3
If you notice all the 777 files are now 755. The reason I use 766 is I want the files to be owner writeable only.
After this we just repeat the process for the directories:
[root@FS01 test]# find /home/roboto/* -perm /766 -type d
/home/roboto/test
/home/roboto/test/test3
/home/roboto/test/test2
/home/roboto/test/subdir
If you notice we have some subdirectories here that are set up for this test. Notice how -type f has changed to -type d in this case because we are dealing with directories this time. After this we just check the test dir and find out we are SuPHP ready:
[root@FS01 test]# ls /home/roboto/test/ -lh
total 12K
-rw-r–r– 1 root root 0 Jun 22 02:28 fila.example
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.tx
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txt
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txtas
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txtasfhg
-rwxr-xr-x 1 root root 0 Jun 22 02:28 file1.txtasfhgasghadf
drw-r–r– 2 root root 4.0K Jun 22 02:36 subdir
drw-r–r– 2 root root 4.0K Jun 22 02:18 test2
drw-r–r– 2 root root 4.0K Jun 22 02:32 test3
Hopefully this will provide some automation tricks to simplify your migration to SuPHP. If you are managed and want us to take care of it for you, drop us a ticket. We’ll be happy to schedule it
If database size is showing 0 MB then, execute the below command from shell
==
/usr/local/cpanel/bin/setupdbmap
==
If you are experiencing a high volume of graceful restarts in Apache due to log file rotation you may want to enable the Piped Log feature as follows:
You must have root access to enable this feature.
You must be running Apache 2.0 or later to enable this feature (not supported for Apache 1.x)
Only available on 11.25.0 and later.
Login to WHM
Click /Service Configuration/
Click /Apache Configuration/
Click /Piped Log Configuration/
Check the box labeled /Enable piped Apache logs/
Click the Save button
This will cause your Apache configuration file to be rebuilt and Apache to be restarted.
More complete information about Piped Log can be viewed here:
http://forums.cpanel.net/f5/cpanel-11-25-log-processing-145417.html
An additional requirement for our enhanced log file processing is a larger disk space requirement inside of the /var partition. Upon upgrading to 11.25.0 if cPanel detects that your /var partition is too small it will disable bandwidth stats processing until the space requirement is remedied. If there is inadequate space in /var, notification is set to the level 1 notification targets as specified in WHM’s Contact Manager
Make sure you have free disk space in /home and /var/lib/mysql or where ever your mysql databases are stored. This guide assumes they are in /var/lib/mysql.
FOR CPANEL
Step 1: Disable tailwatchd (chkservd on 11.23) to prevent mysql from being restarted. Stop any other processes that may access mysql including munin, backups, and the webserver if possible.
killall -TERM tailwatchd
Step 2: Add
innodb_force_recovery = 3
to /etc/my.cnf
Step 3: Restart mysql
/etc/init.d/mysqld restart
Step 4: Verify mysql is up
Step 5: Put this script in ~/recover.pl and run it
======================
#!/usr/bin/perl
BEGIN { unshift @INC, ‘/usr/local/cpanel’; }
use Cpanel::MysqlUtils        ();
mkdir(‘/home/innodb_dumps’,0700);
chdir(‘/home/innodb_dumps’) || die “Could not create /home/innodb_dumps”;
my $pwd = `pwd`;
chomp($pwd);
my $hasinnodb = 0;
my $dbdir    = Cpanel::MysqlUtils::getmysqldir();
my $dbcheckok = -d $dbdir . ‘/mysql’ ? 1 : 0;
if ($dbcheckok) {
opendir( my $sql_dh, $dbdir );
while ( my $db = readdir($sql_dh) ) {
next if ( $db =~ m/^\.+$/ );
next if $db eq ‘mysql’;Â Â Â # mysql db should never have InnoDB on
next if $db eq ‘horde’;Â Â Â # Horde session table is the only one that uses InnoDB, so this is not a problem
next if ( !-d $dbdir . ‘/’ . $db );
my $ms = sqlcmd(“show table status from `$db`;”);
if ( !$ms ) {
$dbcheckok = 0;
last;
}
elsif ( $ms =~ m/\s+InnoDB\s+/m ) {
print “Saving to $pwd/$db.sql…”;
system “mysqldump -c $db > $db.sql”;
print “Done\n”;
}
}
closedir($sql_dh);
}
sub sqlcmd {
my ($cmd) = @_;
my $result;
my $mysql = Cpanel::MysqlUtils::find_mysql();
my $pid = IPC::Open3::open3( \*WTRFH, \*RDRFH, “>&STDERR”, $mysql, ‘-N’ );
print WTRFH “show status like ‘uptime’; $cmd\n”;Â Â Â #make sure we already get something back so we know mysql is up
close(WTRFH);
while () {
$result .= $_;
}
close(RDRFH);
waitpid( $pid, 0 );
return $result;
}
======================================
If the script fails, remove your backup attempt in /home/innodb_dumps, increase the innodb_recovery_level in /etc/my.cnf, restart MySQL, and rerun the script. Repeat until you complete a backup without errors
Step 6: Stop MySQL
Step 7: Do this:
mkdir /var/lib/mysql/INNODB_BACKUPS
mv /var/lib/mysql/ib* /var/lib/mysql/INNODB_BACKUPS
Step 8: For each database that was dumped to /home/innodb_dumps move (do not copy, completely move, or the database may not be properly recreated from the backups you made) the /var/lib/mysql/DBNAME folder to the /var/lib/mysql/INNODB_BACKUPS directory
Step 9: Create folders for each database that was moved in /var/lib/mysql and chown them to mysql:mysql
Step 10: Remove the following from my.cnf and start mysql:
innodb_force_recovery = 3
Step 11: Start mysql and restore all databases in /home/innodb_dumps to their respective database
Step 12: Check the mysql server logs to ensure there were no errors
Step 13: Restart mysql and party.
FOR ALL OTHER LINUXES
Step 1: Add
innodb_force_recovery = 3
to /etc/my.cnf
Step 2: Restart mysql
/etc/init.d/mysqld restart
Step 3: Verify mysql is up
Step 4: Dump all innodb databases to a directory i.e /root or /root/recovery
Step 5: Stop MySQL
Step 6: Do this:
mkdir /var/lib/mysql/INNODB_BACKUPS
mv /var/lib/mysql/ib* /var/lib/mysql/INNODB_BACKUPS
Step 7: For each database that was dumped move the /var/lib/mysql/DBNAME folder to the /var/lib/mysql/INNODB_BACKUPS directory
Step 8: Create folders for each database that was moved in /var/lib/mysql and chown them to mysql:mysql
Step 9: Remove the following from my.cnf and start mysql:
innodb_force_recovery = 3
Step 10: Start mysql and restore all databases in /home/innodb_dumps to their respective database
Step 11: Check the mysql server logs to ensure there were no errors
Step 12: Restart mysql and party
System Engineer's Diary 