Stopping Plesk Panel attacks with OSSEC

During the past few weeks I’ve noticed increased brute forcing activity on various servers that I manage and run Plesk Panel. Most of the entries look like this:

189.205.227.115 - - [30/Jan/2011:07:14:19 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:19 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:19 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:21 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:21 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:23 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:23 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852

The side effect of all these attacks is increased server load.

Since I already have ossec monitoring these servers the solution was quite simple. I just added a couple more rules to ossec in order to stop these attacks.

Two steps are necessary to stop these attacks:
1) Add plesk panel https log to monitor list in /var/ossec/etc/ossec.conf

  <localfile>
    <log_format>apache</log_format>
    <location>/opt/psa/admin/logs/httpsd_access_log</location>
  </localfile> 

  <localfile>
    <log_format>apache</log_format>
    <location>/opt/psa/admin/logs/httpsd_error_log</location>
  </localfile>

2) Create some custom rules to block (and notify me) of these attacks.

<rule id="100144" level="1">
    <if_sid>31100</if_sid>
    <id>200</id>
    <url>/login_up.php3</url>
    <description>Plesk Login.</description>
  </rule>

<rule id="100145" level="12" frequency="3" timeframe="60">
    <if_matched_sid>100144</if_matched_sid>
    <same_source_ip />
    <description>Attack on plesk panel.</description>
    <group>attack,</group>
  </rule>

That’s it. Ossec now monitors these files and blocks through iptables any attacks with active-response.

Example notification mail:

Received From: foo->/opt/psa/admin/logs/httpsd_access_log
Rule: 100146 fired (level 12) -> "Attack on plesk."
Portion of the log(s):

189.205.227.115 - - [02/Feb/2011:20:19:56 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [02/Feb/2011:20:19:55 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [02/Feb/2011:20:19:54 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852

Upgrading Plesk’s phpMyAdmin to the latest version

phpMyAdmin is a great tool but a constant headache (xss, sql injections,etc) as well. Every now and then there are new security holes discovered that need to be fixed ASAP. On the other hand, Plesk doesn’t seem to follow these security fixes, so if you want to keep yourself a bit more secure than Plesk thinks you should be, then you have to upgrade phpMyAdmin by your self. This procedure isn’t very straightforward due to the way Plesk uses PMA so I’ll post here some notes/guidelines on how to achieve that.

My notes are based on Plesk 8.6, so I am sure newer Plesk versions are way easier to upgrade than this.

Step 1: Download new phpMyAdmin
# wget http://downloads.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.3.8/phpMyAdmin-3.3.8-all-languages.tar.gz
Step 2: Extract into /opt/psa/admin/htdocs/domains/databases/

# mv phpMyAdmin-3.3.8-all-languages.tar.gz /opt/psa/admin/htdocs/domains/databases/
# cd /opt/psa/admin/htdocs/domains/databases/
# tar zxf phpMyAdmin-3.3.8-all-languages.tar.gz

Step 3: Rename old PMA and symlink the new
# mv phpMyAdmin phpMyAdmin.old
# ln -sf phpMyAdmin-3.3.8-all-languages phpMyAdmin

Step 4: Copy old config file
This step depends on your old PMA version. Since my version was 2.8.2.4 I had to:
#cp phpMyAdmin.old/libraries/config.default.php phpMyAdmin/config.inc.php
If you have newer versions of PMA just do:
#cp phpMyAdmin.old/config.inc.php phpMyAdmin/config.inc.php
Step 5: Edit necessary files
Substep a: edit phpMyAdmin/libraries/session.inc.php
When the first comment block finishes and before line 14: if (! defined('PHPMYADMIN')) {
add the following snippet:
// Close Plesk's session.
$proxy_session_id = session_id();
@session_write_close();
unset($_SESSION);

Substep b: edit phpMyAdmin/libraries/common.inc.php around line 190 and change:
    'error_handler',
    'PMA_PHP_SELF',
    'variables_whitelist',
    'key'
);

to
'error_handler',
    'PMA_PHP_SELF',
    'variables_whitelist',
    'key',
    // from Plesk
    'PHP_SELF',
    'db_host',
    'db_port',
    'db_user',
    'db_pass',
    'db_name'
);

!! Mind the “,” after ‘key’ !!

That’s about it…you should now be able to use your new PMA version through Plesk.

AAAA records with Plesk

Plesk is surely not ready for IPv6. Despite that fact, many people – me included, have the DNS records of their favorite domains managed by Plesk and still want to be able to add some IPv6 records to those.

Some time ago I had posted on my twitter account a link to another blog that had a “hackish way” to add AAAA records to Plesk. I have written a slightly more elegant shell script (to be run by root only) than the one provided by experimentalworks.

First of all you _need_ to alter dns_recs table of the psa database to allow AAAA records:

# mysql -u admin -p psa 
mysql> alter table dns_recs modify column type enum('NS','A','AAAA','CNAME','MX','PTR','TXT','SRV','master','none') NOT NULL default 'A'; 

Then download my plesk-AAAA.sh script and use it like the following example.

To add www.foobar.gr to point to 2001:db8:1001::1

Usage: ./plesk-AAAA.sh [zone serial]
#./plesk-AAAA.sh foobar.gr www 2001:db8:1001::1
#./plesk-AAAA.sh foobar.gr ipv6 2001:db8:1001::1 12

Known bug/feature:
If you add a record without adding a serial, for the soa record, at the end, it will add the serial of the domain in the form:

YYYYMMDD10

So if you add two ipv6 hosts in the same day for the same domain you _have_ to manually add a serial >10 for the second host (and so forth).

For the ones who don’t like downloading but would like to see the script source, here it is:

  1 #!/bin/sh
  2 
  3 usage () {
  4         echo "Usage: $0 <domain> <hostname> <v6 IP> [zone serial]"
  5         echo "Usage: $0 foobar.gr www 2001:db8:1001::1"
  6         exit 1
  7 }
  8 
  9 if [ $# -lt 3 ]; then
 10         usage
 11 fi
 12 DOMAIN=$1
 13 HOSTNAME=$2
 14 v6IP=$3
 15 INPUT_SERIAL=${4:-10}
 16 FULLHOST="$2.$1."
 17 
 18 ADMIN_PASS=`cat /etc/psa/.psa.shadow`
 19 MYSQL_BIN_D=`grep MYSQL_BIN_D /etc/psa/psa.conf | awk '{print $2}'`
 20 PRODUCT_ROOT_D=`grep PRODUCT_ROOT_D /etc/psa/psa.conf | awk '{print $2}'`
 21 SERIAL=`date +%Y%m%d${INPUT_SERIAL}`
 22 mysql="${MYSQL_BIN_D}/mysql -N -uadmin -p${ADMIN_PASS} psa"
 23 
 24 query1="SELECT dns_zone_id FROM dns_recs where host like \"$DOMAIN%\" LIMIT 0,1"
 25 ZONE_ID=`echo "$query1" | $mysql`
 26 echo "ZONE_ID=$ZONE_ID"
 27 query2="INSERT INTO dns_recs (displayHost, host, displayVal, val, type, dns_zone_id) VALUES ('$FULLHOST', '$FULLHOST', '$v6IP', '$v6IP', 'AAAA',$ZONE_ID)"
 28 echo "$query2" | $mysql
 29 
 30 query3="UPDATE dns_zone SET serial=\"$SERIAL\" WHERE id=$ZONE_ID LIMIT 1;"
 31 echo "$query3" | $mysql
 32 
 33 echo "REBUILDING zone file for $DOMAIN"
 34 $PRODUCT_ROOT_D/admin/sbin/dnsmng update $DOMAIN

The script has been tested with bash and zsh. I have no idea whether it works under any other shells.
The script probably won’t delete your databases, but…use it at your own risk :) I hope someone finds it useful.

Epic fail from a hosting company involving bad customer support and a critical security issue

To cut the story as short as possible let’s say that someone rents some dedicated servers somewhere in a big hosting company. I occasionally do some administrative tasks for him.
A server stopped responding and was unbootable on October 1st, one disk had crashed, then the hosting company did a huge mistake, I notified them about it and then they did another even bigger mistake (security issue) on the next day, October 2nd. I re-notified them about it…
So you can either read the whole story or if you are only interested on the security issue, skip the first day and go straight to October 2nd.

Some details, the server had 2 disks, sda with the OS (Debian 4.0) with Plesk control panel and sdb which had some backup files.

October 1st 2009:
10:10 I got a telephone call to help on that server because it looked dead and it couldn’t even be rebooted from the hosting’s company control panel.
10:15 I contacted the company’s support by email and notified them of the problem.
(more…)