You are on page 1of 8

rdiff-backup is an utility capable of maintaining a back-up mirror of a file or directory over the network, on another server.

It stores incremental rdiff deltas with the back-up, which allows you to recreate any back-up point. The back-up is encrypted through the SSH protocol, thus no one will be able to read the data being transferred. Moreover, rdiff-backup is saving bandwidth by making incremental back-ups. Prerequisites As for all back-ups, you should be planning what you want to do, before actually doing it. Next, you should make sure that both computers are reachable from the Internet (or at least the computer you want to back-up) and whether both computers have SSH (client and daemon) installed and configured properly. As an example for this guide, I'll back-up a directory on my work computer, to a directory on my home computer. Installation - First of all, you'll need to install rdiff-backup on both computers. This is a very popular utility so it's most likely to find it in your distribution's repository so use your package manager to install it. Eg: Fedora: CODE
# yum install rdiff-backup

Debian/Ubuntu CODE
$ sudo apt-get install rdiff-backup

- Now for the tricky part. Because rdiff-backup is using SSH, which asks for a password upon logging in, it will require human interaction during the actual back-up process. And because we are trying to setup an automated process, this is not what we want. Fortunately, this problem can be easily skipped by using SSH public keys. So, we'll need to create a pair of keys on the home computer, one of which will be saved on the work computer. Basically, these keys will tell the work machine that the home machine is allowed to login through SSH. Generate a DSA key pair on the home computer: CODE
$ ssh-keygen -t dsa

Hit enter when you are asked for the target directory and for the passphrase. Send the public key to the work computer: (The work computer has to have used the ssh client, otherwise, the .ssh directory won't exist) CODE
$ cd $HOME $ scp .ssh/id_dsa.pub work-user@work.computer.IP:~/.ssh

Log in to work PC and add the key to the list of authorized keys: CODE
$ $ $ $ ssh work-user@work.computer.IP cd .ssh cat id_dsa.pub >> authorized_keys2 rm -rf id_dsa.pub

- Test if everything is ok: Log out and log back in, this time, you shouldn't be asked for a password. Actual back-up process - What we want to do here is back-up the scripts/ directory on the work PC to the home PC. To do this, type the following command on the home machine: CODE
$ rdiff-backup -v4 --print-statistics workuser@work.computer.IP:://home/work-user/scripts/ scripts/

Automating the process with crontab - On the home machine, type the following command to open the crontab editor: CODE
$ crontab -e

It will open vi. If you don't know how to use it, I? try to explain shortly. Once it started, press ll INSERT key to start writing into it. Now, add the following line: CODE
30 4 * * * /usr/bin/rdiff-backup work-user@work.computer.IP:://home/workuser/scripts/ scripts/

Now press ESCAPE key, then SHIFT + ; and finally, wq As of now, every night at 4:30, the scripts directory from the work PC will be saved to /home/home-user/scripts directory and will be updated if any scripts are added to the work directory.

One of the things I like most about Linux is that everything going on inside it is being logged. Whether a user logs in through ssh or a new visitor is passing through your website, everything is being logged in detail. However, the events related to the system are logged by a tool called syslog, which should be present on all Linux systems. Unfortunately, if a hacker breaks into your system, the first thing he'll probably try to do is cover all traceable tracks, rendering the logging tool useless. Basically, if the hacker is any good, you won't find any incriminating traces through the log files. You might even have a backdoor installed and not know anything about it. But this is where the syslog's remote reception feature comes in handy. You can set a syslog server on a safe,

unused computer that will act as a central logging system for other computers (public computers that are more likely to be targeted) from the local network or even Internet. This way, all computers will immediately send any system-related events to the syslog server, ensuring that your logs will be completely accurate and un-tampered with at all times. This article will describe in detail how to set up a syslog server for one or more Unix systems, on Fedora Core and Ubuntu/Debian. However, it *should* work for just about any Linux distribution. Configure the syslog SERVER I'm sure most, if not all, Linux systems already have syslog installed so I'll skip this step. - First of all, you'll need to stop the syslog service: Fedora Core: CODE

service syslog stop

Ubuntu/Debian CODE
/etc/init.d/sysklogd stop

If you're running another distribution and these steps fail, also try: CODE
/etc/rc.d/rc.syslog stop

and if it fails again, go for the old-school kill command: CODE


ps axfu | grep syslog

copy the PID (number from second column) from the syslog line and: CODE
kill -9 PID

Example: CODE
root:core][~]# ps axfu | grep syslog root 12699 0.0 0.1 3884 668 pts/0 S+ 10:16 0:00 _ grep syslog root 12688 0.0 0.1 1692 576 ? Ss 10:12 0:00 syslogd -rm 0 [root:core][~]# kill -9 12688

- Next, you'll have to either edit the syslog start-up script to start syslog daemon with the "-r" flag, or manually start it with that flag. "-r" will enable remote reception feature, which will allow incoming logs. Fedora Core: - Open /etc/sysconfig/syslog with your favorite text editor - Find the line:

CODE
SYSLOGD_OPTIONS="-m 0"

- Replace it with: CODE

SYSLOGD_OPTIONS="-rm 0"

- Restart the syslog daemon: CODE


service syslog restart

Ubuntu/Debian: - Open /etc/init.d/sysklogd with your favorite text editor - Find the line: CODE
SYSLOGD="-u syslog"

- Replace it with: CODE


SYSLOGD="-ru syslog"

- Restart the syslog daemon: CODE

/etc/init.d/sysklogd restart

On BOTH distributions you should see a message similar to "syslog restarted (remote reception) when executing the command: CODE
tail /var/log/messages

On other distributions you should either find the RC syslog file, edit it and add the "-r" flag to the syslog options or, if you've used the old-school kill command, simply start syslog manually: CODE
syslogd -r

- In the final step, you'll have to make sure the firewall isn't blocking any incoming packets. Simply run this iptables command so any rule will be overridden: CODE
iptables -I INPUT -p udp -i eth0 -s 192.168.1.2 -d 192.168.1.1 --dport 514 -j ACCEPT

This rule will ensure that the syslog server (192.168.1.1) will receive UDP packets (containing log events) from the CLIENT (192.168.1.2). You MUST replace these IP addresses with the correct ones. Also, you will have to re-execute this command for every other client PC you may have (192.168.1.3, 192.168.1.4 etc). Then add this line (or lines) to rc.local so it will be executed every time the system boots. Configure the CLIENT computers - The client computers are configured to send any logged event to the syslog server, immediately

as the events occur. To do this, edit the file /etc/syslog.conf on every client computer and add this line AT THE TOP of the file: CODE
*.* @192.168.1.1

Again, replace the example IP address with the syslog server's correct IP address. - Next, restart the syslog on every client you've edited: CODE
service syslog restart # or /etc/init.d/sysklogd # or /etc/rc.d/rc.syslog restart # or ps axfu | grep syslog kill -9 PID syslogd

- Finally, make sure the client machine is allowed by the firewall to send UDP packets. Again, you can easily override any rule by running the iptables command: CODE
iptables -I OUTPUT -p udp -i eth0 -s 192.168.1.2 -d 192.168.1.1 --dport 514 -j ACCEPT

Also, add this line to rc.local so it will be executed on every system boot. This is it. If everything was done correctly, you should start receiving log events to the syslog server. To view them, run: CODE
tail -f (CTRL + tail -f (CTRL + /var/log/messages C to escape) /var/log/secure C to escape)

KEEP IN MIND that the machine running the central syslog MUST be secured to the fullest extent. If possible, use a machine that doesn't do much on your network so it won't capture attacker's attention, otherwise the whole purpose will be defeated. Domain names have been made available to allow people to easily remember Internet sites, while the IP addresses enable computers to communicate and transfer data between them. A DNS server turns domain names into IP addresses that are usually provided by the same firm that provides the Internet access but you can, if you want, set up your own DNS server. This is, however, a more difficult process to complete. Moreover, if your ISP provides a rather slow DNS server, you can solve both problems with one solution: dnsmasq. dnsmasq is an easy to configure DNS forwarder, also known as a DNS cache application. This application will speed up the domain names look-up process with about 30-60ms per request by listening to the sent requests and saving the responses locally. This way, the next time a past request will be sent, dnsmasq will provide the response in a much shorter time than an usual DNS server.

dnsmasq can also be used for a small network. You can do this by using the computer's running dnsmasq IP as the DNS IP for all computers in the network. Installing dnsmasq is a rather popular application, so you might find it in repositories for many distributions. To install it, you should first try using your distribution's package manager. The package used for caching nameserver lookups is called simple, dnsmasq. For Ubuntu: CODE
sudo apt-get install dnsmasq

(If you can't find it, make sure you have Universe in your repositories list.) For Fedora: - Login as root and type: CODE
yum install dnsmasq

Others: - Download the latest source package from SOFTPEDIA. - Uncompress the archive: CODE
tar xfz dnsmasq-version.tar.gz

- Compile and install dnsmasq: CODE


cd dnsmasq-version make install

Configuring The basic configuration method that will quickly get dnsmasq up and running is: - Open /etc/dnsmasq.conf with your favorite text editor. - Search for the line: CODE
#listen-address=

- And replace it with ( also remove the "#"): CODE


listen-address=127.0.0.1

(for a single computer) CODE


listen-address=write.computers.network.IP.here

(for a small network) NOTE: The secret for DNS caching to work is the /etc/resolv.conf file which must contain a nameserver 127.0.0.1.or.network.IP. However, if you're computer gets its IP address using DHCP, the /etc/resolv.conf file will be overwritten and dnsmasq will no longer work properly. If you enter your network IP addresses manually, you can skip this next step. To make sure that specific line will be automatically added to /etc/resolv.conf, you should: - Ubuntu: Open the /etc/dhcp3/dhclient.conf file in your favorite text editor, remove all its contents and paste these directives: - Fedora: Create a new file called dhclient.conf in /etc/ directory, open it with your favorite directory and paste these directives: CODE
prepend domain-name-servers 127.0.0.1; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name; require subnet-mask, domain-name-servers; timeout 60; retry 60; reboot 10; select-timeout 5; initial-interval 2;

NOTE: If you're setting dnsmasq as a DNS server for a small network, you should replace the 127.0.0.1 IP with the computer's network IP. Starting - First of all, if you're not using DHCP or you do but your computer hasn't gotten a new lease since you've installed dnsmasq, you have to manually add the following line to /etc/resolv.conf CODE
nameserver 127.0.0.1

(again, replace this IP with the computer's network IP if you're running dnsmasq for a local network)

- Start dnsmasq (start this command with sudo for Ubuntu): CODE
/etc/init.d/dnsmasq restart

Testing - Open a terminal and type this command for a domain name you haven't visited since dnsmasq's installation: CODE
dig yahoo.com

The first time you'll see something like: ;; Query time: 72 msec but if you run a dig again for the same domain name, you'll notice that the Query time has decreased to 1 or 2 msec. Multiply that difference by the number of websites you visit per day and you'll get an estimated speed improvement.