April 2009 Archives

Getting Outahere - Explained

| 1 Comment | No TrackBacks

How do I connect to the Internet?

By putting a network cable into the DSL router, well, most of the time, yes. But sometimes my laptop needs to establish the connection to the Internet using a wireless data modem. Obviously this will change a few things on the machine that are not entirely clear to someone starting on this track for the first time.

In this article we will look behind the curtain to understand the process of dialling into the Internet via a wireless modem.

Let's begin with the basic differences. In using the modem, we have decided that the laptop itself will become part of the Internet, while it was only part of the local area network up to now. First of all, that would require to run a firewall on the laptop if you did not already have set up a firewall before. Protecting your machine while connected to the Internet is indispensable, and you have to make sure, that your firewall is not disabled entirely. Check your firewall rules with the following command:

/sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


The output above shows, that there is no protection and you have to solve this problem first. Anyway, firewall configuration will be covered in a separate post.

Where do all these packets go?

As long as your machine had been using the router an IP number belonging to the router was listed in the laptop's routing table. More precisely, the ethernet adaptor would send every data packet destined for the Internet to the machine with this default address, and for the laptop to be able to establish its own connection, the old default route to the DSL router has to be removed from the network setting. Nowadays we simply click through the network dialog and delete the "default gateway address" there. But if you like to know where to check that setting, please examine the file "ifcfg-eth0" in a directory called "/etc/sysconfig/network-scripts", there should be no GATEWAY line.


It is one of the tasks performed by a process called "pppd" to set up a new default route when the connection to the Internet is successfully installed using the modem and a new network interface "ppp0". Getting the Point-To-Point-Protocol-Daemon (pppd) up and running will be the most important thing to get right, but then, fortunately it is the only thing to do. There was no need for a pppd as long as we had the router, but now this process working in the background is responsible for shovelling all packets back and forth into the Internet for us.

Chatting up the PPP Daemon

Given that everything is well prepared, starting the pppd process is as easy as the following


/usr/sbin/pppd file three.options connect '/usr/sbin/chat -v -f three.chat ' /dev/ttyUSB0

As I am using a THREE data modem there are two files that determine the process of dialling into the Internet, an options file and the chat-script. The last parameter the pppd process depends on is the device file for the hardware used. In most cases running the pppd fails because this special file that represents the wireless modem does not exist. Look around if your Linux system lists the device file, and if not, we cannot proceed unless the hardware is actually accessible through the kernel. The kernel module that is responsible to make the wireless modem visible to the kernel is called "usbserial" and it has to be used with two pieces of information, the vendor-id and the product-id, which are different for every modem you use. For my wireless modem I have to use this command.

/sbin/modprobe usbserial vendor=0x19d2 product=0x0001


You have to check your actual hardware and find out which values are correct for your hardware, using the "lsusb" command for further information.
Now that the hardware is available through the device file "/dev/ttyUSB0" we can define a few options the pppd process should honour while starting up.

460800
noipdefault
defaultroute
persist
noauth
updetach
novj
novjccomp
nopcomp nodeflate
holdoff 5

Apart from requesting the desired baud rate the process tries to get a remote IP address from the ISP's login server (noipdefault), does not require the ISP's end point to authenticate itself (noauth) and establishes the default route in the routing table after setting up the connection.

During this process the pppd process exchanges some information with the ISP's login server on the Internet to get the required IP address. The details of this conversation are lay down in the chat-script.

ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO DIAL TONE"
"" ATZ
OK ATE0V1&D2&C1S0=0+IFC=2,2
OK AT+CGDCONT=1,"IP","3ireland.ie"
OK ATDT*99#
CONNECT ""

This file lists two corresponding pieces of information each line. While reading the modem input the process waits for the appearance of the first part being sent by the server, responding with the second part which is, in most cases of course, an old-fashioned modem AT command. You can watch this conversation between the modem and the ISP's access machine in detail if you display the tail of the logfile "/var/log/messages".
 
/tail -f /var/log/messages


Finally, when the remote IP address is obtained, the interface "ppp0" can be used.

Get a decent Name Service - And Enjoy!

Of course you should be able to surf the web using the new network connection as the default route should be created by the now running pppd process. If you still don't get your Internet applications running there is a last hurdle to overcome. The domain name service (or DNS for short) is always been used by our applications. No matter what kind of program you use, the first step is always the substitution of a domain name by the correct IP address. Because of the fact that this substitution has to be done many times, one or more name servers must be in easy reach for your laptop. I have found some nameservers that work for me and are reliable and fast, but depending on your location, different ones may be better. Try to find the ones that perform best for you and finally record their IP addresses in the file "/etc/resolv.conf" to make sure, that your internet connection is performing well.
 

Now, this is how I connect to the Internet! The following excerpt is taken from the usual suspect file "/var/log/messages"

Have you ever listened to someone who had been fallen victim to a burglary, someone whose home had been broken into by a criminal, entirely ignoring his privacy, snooping around in his personal belongings and making a total mess of everything coming across his way? It is nearly impossible not to feel the pain yourself this person has been through.

And in the online world things are not that different. After all the effort you've put in to getting a Virtual Private (!) Server going, and after furnishing it with something you think is valuable and worth protecting, you can easily get into a similar rage about people starting to break into your VPS the minute you have finished to make it a venerable target for those careless and often thoughtless digital scumbags on the Internet.

A brief look at the file "/var/log/security" shows how your virtual home is under attack right at the moment.

[skipped earier lines ...]
Apr 15 13:25:40 vm829 sshd[15230]: Invalid user admin from 58.151.115.9
Apr 15 12:25:40 vm829 sshd[15231]: input_userauth_request: invalid user admin
Apr 15 12:25:41 vm829 sshd[15231]: Received disconnect from 58.151.115.9: 11: Bye Bye
Apr 15 14:46:01 vm829 sshd[15816]: Did not receive identification string from 210.4.143.55
Apr 15 15:00:28 vm829 sshd[15910]: reverse mapping checking getaddrinfo for 210-4-143-55.inter.net.th failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 15 14:00:28 vm829 sshd[15911]: Received disconnect from 210.4.143.55: 11: Bye Bye
Apr 15 15:00:34 vm829 sshd[15915]: Invalid user fluffy from 210.4.143.55
Apr 15 15:00:34 vm829 sshd[15915]: reverse mapping checking getaddrinfo for 210-4-143-55.inter.net.th failed - POSSIBLE BREAK-IN ATTEMPT!
[skipped following lines ...]


I sincerely welcome any and all attempts possible to counter the disgusting actions of those, who in most cases are not even remotely aware of or capable to understand, what the software does they are (ab)using.

Statistics of a Break-In Attack

Let's have a look at such an attempt to abuse the ssh service at my VPS. It is recorded in the very first hours this machine became visible on the Internet.

Creation of the VPS    Dec 9, 15:00
Begin of Attack   Dec 10, 20:24
End of Attack   Dec 10, 21:12
Duration of Attack    38 minutes
Attacker's IP    58.213.125.25
Number of Break-In Attempts   583
Attempts to login as root  474 (81.3 %)
Valid user names tried  postscript (5) , mysql (2)
Invalid user names tried    102
Usernames tried multiple times    admin (8), george (3), gnax (6), test (2)
Selection of other invalid names   anita, asterisk, dj, email, foo, gv, joe,
   kateroselmau, mythtv, ruby, sales, windywang, wwang
During the best part of an hour the attacker had tried 583 passwords to break into my digital home, nearly every 4 seconds a failed ssh connection was recorded in my logfiles, not unsurprisingly targeting the root account. As it turned out, the IP address was not bound to a registered domain name, so it could even be a innocent user's PC taken-over by the attacker.

Counter-Measures

Some people have suggested trying to play "hide and seek" with the culprits by switching the native port 22 which is used by SSH to something like 51679. Even though that may reduce the rate of attacks, it surely won't deter those who use port scanners to find the port used for SSH.

Others rely on periodically updating their "/etc/hosts.deny" file blocking access from IP-addresses that have proven to be suspicious. This may solve the problem for those attacks that always start at the same hosts, but attackers changing their base frequently will still enjoy an open door, once they are using a freshly taken-over host machine.

I have been taking a different approach, namely to change the response of my firewall to incoming ssh requests. I changed the rules so that only 3 attempts per 2 minute period are being served. This reduced my server's susceptibility greatly, as the automated attacks tend to break off after very few tries and don't return.

The following lines added to my firewall script did the job:

/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 120 --hitcount 4 --rttl --name SSH -j DROP

Bridging Troubled Waters

| No Comments | No TrackBacks
For some reason I tend to forget something in my home office that I just need now. The information I need is sitting somewhere on the server, which is idling away at home, being of not much use to me at the moment. But once there is a network connection to the server there is a cure for this calamity, called sshfs, the secure shell file system.

Using the secure shell file system to lay your hands on data that is stored remotely has one distinct advantage that sets it apart from many other methods, it restricts access to the person that knows the key while the data is mounted on the local computer.

img2.jpg    Normally any remote data source is mounted on the local computer as part of the universal file system, and while file permissions may restrict access for certain users, the superuser (root) is always able to access the data mounted somewhere, no matter which access method is used to transfer the data to the local system.

Well yes, unless the data is encrypted with a user's public key and mounted on a sshfs. Now even the superuser cannot read the data mounted, making this method particularly interesting for all situations in which private data is used on a system heavily in use by many other people as well.

Unlike normal network filesystems like NFS or CIFS that are mounted by a system process during bootup the sshfs is mounted by ordinary users, thanks to the FUSE kernel module.

FUSE is just another userspace program used to provide files under a certain directory that serves as a mount point. This in fact gives any user the opportunity to mount and unmount whole filesystems into his or her home directory at leisure, and whats most important, it provides a means to bring a secure tunnel to another network-enabled computer (at home or in the office) into play which radically changes the picture.

Preparations

Of course you have to prepare the server you intend to access for this scenario, but the necessary steps are pretty much straightforward. Naturally, using sshfs would require to create a cryptographic key pair (public key and secret key) and to store the public key on the server in the appropriate place:

ssh-keygen -t rsa -b 2048

Generating public/private rsa key pair.
Enter file in which to save the key (/home/joe/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/joe/.ssh/id_rsa.
Your public key has been saved in /home/joe/.ssh/id_rsa.pub.
The key fingerprint is:
fa:aa:96:40:9b:35:0e:91:f5:bd:94:8c:d5:9f:43:b8 joe@kerry-linux.ie

Joe's new key pair has now been created. Make sure that you have your secret key (/home/joe/.ssh/id_rsa) at hand when you need to access your server's data.

cp /home/joe/.ssh/id_rsa.pub /home/joe/.ssh/authorized_keys

Of course, this has to be done on the server in order to permit the use of Joe's secret key.

Once Joe knows his server's IP address he is ready to mount his home directory on the server onto a directory "secure" at his local computer. But bear in mind that Joe's secret key also has to be there.

sshfs joe@62.156.44.13: $HOME/secure

Once the remote data is being mounted, Joe is happy to see his data but every other user including root will only see the following when looking at Joe's home directory.

[root@localhost]# ls -l /home/joe
drwxr-xr-x 2 joe users 4096 Aug 6 2008 Videos
drwx------ 3 joe users 4096 Sep 1 2008 mail
drwxr-xr-x 2 joe users 4096 Sep 6 2007 proposals
d????????? ? ? ? ? ? secure

[root@localhost]# ls /home/joe/secure
ls: cannot access /home/joe/secure: Permission denied


And that's exactly how things should be.

How to secure your home

| No Comments | No TrackBacks
One of the many advantages of the Linux operating system is its separation of user data from system files. Traces of your daily use of the system will show up in your home directory located in the home folder alongside other user's playgrounds. Over time various assets will assemble inside your home directory, which are not equally important to you.

Things like your archived email messages, your financial records or outlines of your secret plans are mangled with the latest downloads of music or fresh software versions, all in one place. To secure your home you need to separate your core files (and configurations) from everything else that has been sourced from a public place like the internet and does not need protection.


What we need to do is to separate the sensitive data from everything else in your home directory and put it into a secure container that is left encrypted until access to the data inside is needed.

So this is our plan:

  • Setup an encrypted container with a filesystem to use.
  • Transfer all sensitive data to the container
  • Create links to the container in our home directory
  • Use our new tool with care
As you will expect the second step will be the most challenging, because we will easily miss some of our sensitive data to transfer to the container.

Don't worry about step one and three, I'll lend you a hand to perform these steps without much trouble.
img1.jpg
But why don't we simply transfer all of our home directory to the encrypted container?

This obvious solution is really not the best one. The security of our sensitive data relies on the fact that the container is encrypted almost all the time, when sensitive data is not used. If we'd put our home into the container we would not even be able to log in. Or we had to open up the container for the duration of our entire session, leaving the sensitive data unencrypted for a long time. This is clearly not what we want to protect our core files.

Preparing the safe

Let's go ahead and start preparing our encrypted container that will be a very big file holding all our valuable data. We have to decide where to store the big file (i.e /home/safe) and we need to make sure that whatever backup we make, this file is included. Issue the following commands as superuser (root):

dd if=/dev/urandom of=/home/safe bs=1M count=2000
LOOP=$(losetup -f)
/sbin/losetup $LOOP /home/safe
/sbin/cryptsetup create safe $LOOP
ls -l /dev/mapper

The first command is used to create the file and fill it with pseudo-random data. Feel free to adapt the amount of blocks that are being written to the file to suit your needs, count=2000 will create a 2 gigabyte file. The following commands find out a free loop device, attach our file to the device and finally create a new block device representing the decrypted bunch of data. Make sure that you use a good passphrase for the container.

By now you should have a device file called /dev/mapper/safe that can be treated just like any ordinary disk partition, ie /dev/sda1. So we can create a filesystem on this new device now and can mount it on the mountpoint /safe, which we create for this purpose.

mkfs -t ext3 -c /dev/mapper/safe
mkdir /safe
mount /dev/mapper/safe /safe


Our container is now mounted on the directory /safe and is ready to be filled up with our valuables.

Making life easier

But before we get to the tricky part of deciding which data shall be moved to the safe it's time to make using our safe a little easier. Usually you would not be logged in as the superuser (root) when you need to open up your encrypted safe. Let's set up two simple scripts that help you using the safe while working as a normal user on the system. Apart from knowing the passphrase to unlock the safe there is one more requirement to restore the unencrypted content of your safe. Creating device files and mounting them on directories is a job for root, not for ordinary users. As a consequence the two scripts must change their permissions to run as root, which can be achieved by adding the following two lines to the file /etc/sudoers:

joe ALL = NOPASSWD: /root/safeon
joe ALL = NOPASSWD: /root/safeoff


Joe is now permitted to run the two scripts as root, once he prefixed the script names with the sudo command:

sudo /root/safeon
sudo /root/safeoff


Make sure that the scripts are at their proper place in /root

/root/safeon

#!/bin/bash

LOOP=$(/sbin/losetup -f)
echo $LOOP > /home/joe/loopdevice
/sbin/losetup $LOOP /home/safe
/sbin/cryptsetup create safe $LOOP
mount /dev/mapper/safe /safe
ls -la /safe


/root/safeoff

#!/bin/bash

umount /dev/mapper/safe
LOOP=$(cat /home/joe/loopdevice)
/sbin/cryptsetup remove safe
/sbin/losetup -d $LOOP
rm /home/joe/loopdevice
ls -la /safe

Filling up the safe with valuables

Now that our safe is working well we don't have any excuses not to fill it with data that should be protected. If you know where your email software stores its archived messages move the folder to the safe completely and create a symbolic link to the new destination like this:

mkdir /safe/joe
chown joe /safe/joe
mv $HOME/mail /safe/joe
ln -s /safe/joe/mail $HOME/mail


What makes moving our valuables to the safe so tricky is that we do not exactly know where they are. Seriously, you can expect some of them in obvious places, but be aware that most software store their data in dot-directories like .evolution .ssh .gnupg and so on. So keep on searching. And enjoy your safe.


We have set-up this blog to provide you with information you need to get the most of open source software. Inevitably you'll run into some problems when using Linux and open source, so here are some of the answers to your problems.

Don't give up, we're here to help!

You can also request support using our website at http://kerry-linux.ie/support

Recent Comments

  • Luigie Fulc: Gerade habe ich eine interessante Seite für Tricks auf Linux read more
  • Ralph: There is a page called "Copyright Policy and Terms of read more
  • Windows Icons: Hello! I do not see a condition of use of read more
  • Ezine: A thoughtful insight and ideas I will use on my read more
  • Ralph: Elaborating upon your thought experiment a little bit more and read more

OpenID accepted here Learn more about OpenID

Small Business Blogs - BlogCatalog Blog Directory