A nice and easy solution which works best for me is to use sudo. This will allow to run rsync via ssh and sudo. To get it running you have to add an entry into your sudoers config file:

/etc/sudoers

backup_user ALL=(root)NOPASSWD:/usr/bin/rsync

This will allow the user backup_user to run the command rsync as root.

Next step is to add an rsync-path parameter to the remote rsync call:

rsync --rsync-path="sudo rsync" backup_user@myhosttobackup.net:/root /backup_directory

Finally rsync will automatically do an sudo to root on the remote server and all to backup all files owned by root as well.

Links:

• Rsync and sudo over SSH

The message appears every time rsync or just ssh is called. In my case the reason is that ssh tries to connect via IPv6 first and afterwards with IPv4. Since I’ve not setup IPv6 on my NAS the connect fails and the message above appears. It’s not a big harm but it’s nicer to remove this message.

Removing the message is esay, just add -4 as command line parameter to ssh:

-4 Forces ssh to use IPv4 addresses only.


For ssh or rsync the usage looks like:


ssh -4
rsync -e "ssh -4"


And the message disappears.

cd /root
wget --passive-ftp ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
tar xvzf chkrootkit.tar.gz
cd chkrootkit-0.49/
make sense
./chkrootkit

Check the output, if you get output indicating “INFECTED” then you should re-install your server and do everything to avoid further infects.

He recommends to protect your wp-admin area using the Apache .htaccess file. Here in detail access is only allowed from IP addresses from where you are logging in. It’s definitely a good way to protect you blog, but often people don’t have a fixed IP address. The DSL provider assigns a different IP address on every dial in. Unfortunately there is no easy way to obtain the network addresses of your DSL provider which can be entered in your .htaccess file.

Another important recommendation: Always keep your server software and WordPress software up to date!

Also remove the following line from your header.php which will show hackers your WordPress version:

<meta name=”generator” content=”WordPress <?php bloginfo(’version’); ?>” /> <!-– leave this for stats please -->

So let’s concentrate on the restricted access in the wp-admin area. It’s a little bit tricky to get the address list of your DSL provider. I’ll explain and show an example script below. First let’s have a look at the video from Matt Cutts.

As step one you have to find out your own IP address. Let’s assume your IP address assigned from your provider is 213.168.95.20 (this is just an example!). Next do a whois lookup:

server:~# whois 213.168.95.20
...
inetnum:        213.168.95.0 - 213.168.98.255
netname:        NC-DIAL-IN-POOL

Have a look at the netname NC-DIAL-IN-POOL. Usually provider assign  a common name for all DSL dynamic address. But we want to add all IP addresses or better all network ranges into our .htaccess file. Ok now we need to get all address ranges with this netname. This can be achieved using the Linux whois tool:

server:~# whois -h whois.ripe.net NC-DIAL-IN-POOL
...
inetnum:        194.8.209.0 - 194.8.209.255
...
inetnum:        194.8.205.0 - 194.8.205.255
...

Fine we get a list with all network ranges from our provider now, but still not the correct netmask format and a lot of other output which we don’t need. Basically it’s possible to manually generate the .htaccess file now. Not big fun… So I’ve created a small perl script which does the job. As small bonus it creates the needed format for .htaccess file which means you are able to directly add the output to your .htaccess file in the wp-admin folder.

Important: Before usage you have to add the netname of the dial-in pool of your provider. How to find it out is described above. Below is only an example. The output will look like:

server:~# ./gethtaccessranges.sh
allow from 194.8.209.0/24
allow from 194.8.205.0/24
allow from 195.14.226.0/24

Finally generate a .htaccess file in your wp-admin/ folder with the content:

order deny,allow
deny from all

and add the output of the script gethtaccessranges.sh below the two lines. That’s it! Now access to wp-admin is only allowed from dynamic IP address from your provider. Sure it’s not the perfect solution but I’ll prevent you from many other hack attempts from all over the world.

At the end of the script there is also an example in case providers use number in their netnames.

#!/usr/bin/perl -w
# gethtaccessranges.sh
# Harald Kraemer 08.08.2010
# www.technnitip.net
#
# NET::CIDR and NET::Whois is need to run this script.
# On debian you can install using apt-get:
# apt-get install libnet-cidr-perl libnet-whois-perl
#
# Important: Replace the netname "NC-DIAL-IN-POOL" at the end of the
# script with the dial-in netname of your provider! Use the command
# whois <my-ip-address> to find out the netname.
use Net::CIDR;
use Net::CIDR ':all';
use Net::Whois::Raw;
use strict;
sub getRanges
{
  my($netname) = @_;
  my $whois;
  my @whois_array;
  my @ranges;
  $whois = whois( $netname, 'whois.ripe.net' );
  @whois_array   = split( "\n", $whois );
  @ranges        = grep( /inetnum:/, @whois_array );
  foreach ( @ranges )
  {
    s/inetnum://g;
    s/ //g;
    s/ - /-/g;
    foreach my $item ( Net::CIDR::range2cidr( $_ ) )
    {
      print "allow from " . $item . "\n";
    }
  }
}
getRanges('NC-DIAL-IN-POOL');
#for( my $i=1; $i <= 30; $i++)
#{
#  getRanges('DTAG-DIAL' . $i);
#}

No related posts.

Recently I found a nice online tool which checks the health and configuration of your domain. The online check is available on intoDNS.com. To use it just browse to this site and enter your domain name and you will get many useful checks and information about your server settings.

Links

• intoDNS.com

No related posts.

Read more on Apache Software Foundation Blog.

In my case mdadm is used to configure the software RAID and mdadm –detail /dev/md1 can be used to show the rebuild status:

[root@hxxxxxxx ~]# mdadm --detail /dev/md1
/dev/md1:
Version : 00.90
Creation Time : Thu Nov  9 18:57:15 2006
Raid Level : raid1
Array Size : 159726144 (152.33 GiB 163.56 GB)
Used Dev Size : 159726144 (152.33 GiB 163.56 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sun Feb 14 19:45:21 2010
State : active, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Rebuild Status : 31% complete
UUID : be29700c:083d0c62:67a9c130:e044323b
Events : 0.3626065
Number   Major   Minor   RaidDevice State
0       8        3        0      active sync   /dev/sda3
1       8       19        1      active sync   /dev/sdb3

In my case 31% of the rebuilt process are finished. We still have to wait a little bit..

Links

• The Software-RAID HOWTO: Detecting, querying and testing
• The Software-RAID HOTWO

No related posts.

The reason seems that the IP address of my server has been added to a bot network which tries to hack servers using SSH brute force attacks. As far as I know such bot networks are built up  with Viruses and Trojans. I think there is no reason why your server may have also been added to such a list, somehow IP addresses seem to added.

But the question is how to defend against such brute force attacks from bot networks?

Known Methods

• Install a tool like denyhosts
• Always keep the SSH daemon up to date!
• Move the SSH port from 22 to some other port
• Disable password authentication and use key authentication
• Slow down the amount of connections from the same IP using iptables and module “recent”
• Open the SSH port after a trigger on a different port using iptables

I think there is one additional easy method to defend against such attacks. Why I think so? Read on..

Another Simple Method

When checking the auth.log we see that the user names of the attacks are taken from a dictionary:

Failed keyboard-interactive/pam for invalid user aderes from 195.xxx.xxx.xx port 39566 ssh2
Failed keyboard-interactive/pam for invalid user aderyn from 203.xxx.xxx.xx port 44099 ssh2
Failed keyboard-interactive/pam for invalid user adi from 78.xxx.xxx.xx port 42748 ssh2
Failed keyboard-interactive/pam for invalid user adia from 89. port 51028 ssh2
Failed keyboard-interactive/pam for invalid user adiel from 217. port 33861 ssh2
Failed keyboard-interactive/pam for invalid user adila from 77. port 52867 ssh2
It seems that the bots are not adding digits to the user names. So I think one easy method to defend against such attacks is:

• add at least one digit to user names on your server if you have the possibility

And definitely never ever add a user “admin”. In my logs the user “admin” is always used for brute force attacks:

Failed keyboard-interactive/pam for invalid user admin from 203.xxx.xxx.xx port 39711 ssh2
Failed keyboard-interactive/pam for invalid user admin from 203.xxx.xxx.xx port 55493 ssh2
Failed keyboard-interactive/pam for invalid user admin from 220.xxx.xxx.xx port 34502 ssh2
Failed keyboard-interactive/pam for invalid user admin from 80.xxx.xxx.xx port 51846 ssh2
Failed keyboard-interactive/pam for invalid user admin from 80.xxx.xxx.xx port 53934 ssh2

The example below shows a sample measurement between to servers connected with a 100 MBit ethernet card and located at two different providers.

On one machine NETIO is started as server:

machine1:~/netio/bin# ./linux-i386 -s
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP server listening.
UDP server listening.
TCP connection established ...
Receiving from client, packet size  1k ...
Sending to client, packet size  1k ...
Receiving from client, packet size  2k ...
Sending to client, packet size  2k ...
Receiving from client, packet size  4k ...
Sending to client, packet size  4k ...
Receiving from client, packet size  8k ...
Sending to client, packet size  8k ...
Receiving from client, packet size 16k ...
Sending to client, packet size 16k ...
Receiving from client, packet size 32k ...
Sending to client, packet size 32k ...
Done.
TCP server listening.

On the other machine NETIO is called e.g. with -t option for TCP and the name or IP of the other machine:

machine2:~/netio/bin# ./linux-i386 -t machine1.mydomain.de
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size  1k bytes:  7309 KByte/s Tx,  7645 KByte/s Rx.
Packet size  2k bytes:  7276 KByte/s Tx,  7724 KByte/s Rx.
Packet size  4k bytes:  7291 KByte/s Tx,  7737 KByte/s Rx.
Packet size  8k bytes:  7276 KByte/s Tx,  7723 KByte/s Rx.
Packet size 16k bytes:  7286 KByte/s Tx,  7719 KByte/s Rx.
Packet size 32k bytes:  7291 KByte/s Tx,  7725 KByte/s Rx.
Done.

We take a rough average of the result can multiply it by 8: 7,5 * 8 = 60 MBit/s. This is a acceptable value for a connection between two servers located at different providers within Germany.

For sure a useful tool! Also check Network Bandwidth Performance Measurement with Iperf