csant/log

Running a machine with an open ssh port will lead, sooner or later, to annoying log entries in your system log:

sshd[24592]: Invalid user pi from x.x.x.x
sshd[24598]: Invalid user wf from x.x.x.x
sshd[24600]: Invalid user fj from x.x.x.x

or possibly even

sshd[53704]: Failed password for user from x.x.x.x port z ssh2

They rarely pose a serious threat if you are running with good enough passwords - and this is a reminder to all to please use strong passwords. But the risk for successful attacks is still present (I never feel too confortable when reading the logs of intrusion attempts), and furthermore these attempts awfully clutter your system log.

So I set off looking for various ways of avoiding brute force hammering - and found a quite neat solution in sshdfilter, a wrapper to run sshd and create iptables rules on the fly to throttle access to the ssh port.

A first measure to already lower the chances of brute force login attemtps is to simply run the ssh service on a higher port than 22 - it certainly does not help when a full portscan is made, but, as simple as it sounds, it already avoids those idiots running blind attempts on port 22 across the net. You might also consider not allowing remote root login, and allow ssh access only to a restricted number of users - make sure to have the following two lines in your /etc/ssh/sshd_config:

PermitRootLogin no
AllowUsers user

Next I set up sshdfilter and restarted sshd via sshdfilter: any login attempt with an invalid username will be immediately banned and failed passwords for valid users are treated the same way.

Update 1

Thomas, with whom I had been talking about throttling ssh brute force attacks, has posted his solution to the problem - nice and elegant!

…to your Linux box.

v9fs, the 9P file system support for Unix/Linux/*BSD, has entered the main Linux kernel tree as per version 2.6.13. 9P is the resource sharing protocol developed originally for Plan 9. It presents a unified distributed resource sharing protocol that will be able to distribute devices, file systems, system services, and application interfaces. It was revised for the 4th edition of Plan 9 under the name 9P2000.

The operating system Inferno is based on Plan 9, but both the original and the derivative product do not have a broad audience. Implementing the underlaying key concept on other UNIXes seems to be a very promising project, though, and likely to meet a much broader audience.

Setting it up on my Linux box was not too difficult. Here a little HowTo.

Setting it up

Step 1: enabling the client in the kernel

1. Grab a recent kernel source - I myself used a vanilla 2.6.15.4;
2. Enable CONFIG_9P_FS=m in the kernel .config file - unless you don't want it built as a module and need it directly in the kernel;
3. make and install your kernel as usual;
4. load your new module with `modprobe 9p2000`.

Step 2: installing the server

1. Download the UNIX 9P server, aka u9fs - there is ongoing work to implement the server into the kernel module as well;
2. make the server, and then
3. copy the binary executable to /usr/sbin/u9fs; you might also want to copy the file u9fs.8 in your source code directory to /usr/share/man/man8/ and read `man u9fs`;
4. one way to start the server is via xinetd - add the following to a new /etc/xinetd.d/u9fs file:

   service u9fs
   {
        disable         = no
        socket_type     = stream
        wait            = no
        user            = root
        group           = root
        protocol        = tcp
        port            = 564
        server          = /usr/sbin/u9fs
        server_args     = -m 65560
   }

5. and the follwing to your /etc/services:

   u9fs     564/tcp       9fs  # Plan 9 fs

6. there are three ways for authentication, none, the default rhosts and p9any; use rhosts only on very safe and controlled networks; none obviously turns off authentication altogether. Personally, I have not yet managed to get p9any working - so I have, for the time being (my network is safe), added the hosts of my internal network to /etc/hosts.equiv;
7. now `/etc/init.d/xinetd restart`.

Step 3: get it going!

1. `mkdir /mnt/9`
2. `mount -t 9P 10.0.0.1 /mnt/9` - make sure you replace the IP address with your own address; a warning: do not use a hostname, but a numeric IP address, the DNS lookup has been biased to work with NFS, but not with other distributed filesystems.
4. `ls /mnt/9/`

There are other ways to start the server and mount the filesystem in userspace only, but this is still new ground to me. At the moment the security model is still rudimentary - a safer alternative is to tunnel through ssh and call your own instance of the u9fs.

This is all not very exciting as long as the machine with the server is the same the client is running on - but becomes far more interesting when you mount remote machines. Currently I have only been able to access the filesystem, and this only in read mode, but as far as I have understood accessing devices and process resources shouldn't be too far off. And at that point 9P will be unleashed to its full potential.

What is the big deal about it?

Quoting from the main paper [PDF] :

9P2000 support provides a nice alternative to NFS for distributing static files. It can be configured in such a way that users can export and mount their own file system resources. Its synchronous mode of operation and optional caching make it ideal for situations where the cache models and delayed writes of other file systems cause problems. Many utilities, such as CVS and various e-mail servers, discourage the use of NFS repositories due to concerns with data corruption resulting from bad cache behavior and lack of transaction semantics.

However, as mentioned several times before - distributed file service is not the only benefit of 9P2000. It can be used to share networking stacks and block and character devices between members of a 9P2000 cluster. It can be used to manipulate Linux synthetic file systems, such as /proc and /sys providing distributed control and management. It also can be used as an infrastructure to implement distributed applications.

Userspace applications

Unfortunately there are not many applications in userspace yet - the main collection being Russ Cox's Plan 9 from User Space, aka plan9port or p9p, a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems. My somewhat biased perspective cannot but smile when reading the `man web` page - a sample quotation:

web, wmail - handle web page, mail message for plumber

[…]

The supported browsers are Opera, Mozilla Firefox, Mozilla Firebird, and Mozilla.

wmii is a very interesting dynamic window manager based on 9P.

Plan 9 and 9P is a new universe to me; it might be worth exploring it more, and following development of the v9fs. Once we get so far as to really share resources on Linux as well, a huge step forward will be achieved. I am looking forward to it.

Oh, and did I mention that Glenda, the Plan 9 bunny, is really cute?

Update 1

Interestingly enough, as soon as I have started digging into this project, some significant changes get announced. The v9fs site moves to a new location and u9fs is going to be replaced by npfs, the Linux-based set of libraries and servers that soon will find distribution in various packages, to be pushed out to distros.

Just a quick note to (finally ) point to our latest final version currently being uploaded - stay tuned, it's a busy week!

As you may have noticed, Opera 9 Technical Preview 2 is out, with many Unix specific fixes. This is a very important release on Unix - several things got fixed that have been troublesome to many users in the past.

In particular, we would very much appreciate feedback on printing and plug-ins.

Happy testing, and have fun

One of the bigger annoyances Opera users on Linux have been struggling with is the dependency on Motif for plug-ins to work.

A recurring question is which of the Motif flavours should I use? - we have a full page to document installation thereof; there are some detailed instructions on how to get it up and running, and how to deal with conflicts, on forums of some distros; our own my.opera forum is full of people looking for help…

Well - there is good news!

Opera is getting rid of this dependency: Opera 9 will make life much easier to all those Linux users, and plug-ins will not require the presence of Motif in any of its flavours to be installed.

And there is more: this is just one of the surprises you can expect to see in the next public version