pitter patter on the keyboard

Wireshark is a powerful and popular packet capture and analysis suite that runs on Windows and most flavours of UNIX. Often one finds one’s self in need of its GUI’s abilities on remote, headless servers without X windows (and who wants to install X on a server if they don’t have to?). One has three options: use a text/ncurses based packet capture system like ettercap to analyze the traffic on the server itself, save packet capture files and move them to your Wireshark host or pipe the output from tshark – Wireshark’s text interface – to your client in real-time. The last option suits me best; I don’t want to have to learn two packet capture suites if I can only use one and it is often useful to see the packets fly by as they come.

To compile Wireshark without the GUI, and therefore all of its X windows dependencies, on Gentoo:

# USE=”-gtk” emerge wireshark

Or disable the GTK use flag in your /etc/make.conf.

The next step is to establish passwordless root ssh access to the target machine. This should only be temporary as it is best practice to disallow any form of remote login for the root user. Please read my previous article, Passwordless or Single Password SSH with Key Exchange but be sure to use a blank passphrase for your key and disregard the part about restricting root access. Once this has been completed and you are able to log in to the target server by simply typing ssh hostname you are ready to begin your packet capture.

On the client which runs the GUI version of Wireshark, open up a shell as root and run the following:

wireshark -k -i < ( ssh -l root xxx.xxx.xxx.xxx /usr/bin/tshark -i eth0 -w - )

Be sure to change the path to tshark if this does not reflect your installation. Adjust the interface (-i flag) to match your target.

Plain FTP suffers from a number of problems, foremost is transmission in cleartext. Unless SSL is used (I have come across very few occurrences of its use in the wild) usernames and passwords, as well as the files being transmitted, are sent over the wire unencrypted. This means anyone with a well-placed sniffer or man-in-the-middle setup between the client and server can intercept or mutilate the data without much skill or resource cost. FTP also suffers from NAT issues, in that some users must forward ports or use passive transfer mode – words most of the users who will be using your hosting service have probably never heard, don’t want to hear and have no idea how to implement.

Enter SFTP: file transfer over Secure Shell. Not to be confused with FTPS, or “FTP Secure” (FTP with SSL), SFTP shares nothing in common with FTP other than its purpose: moving files around the network. SFTP uses a single, wholly encrypted tunnel from the client to the server to send and receive files. This avoids the problems associated with NAT and FTP’s dual-connection implementation, provides a relatively secure means of authentication and prevents third-party manipulation of the data in transit. SSH also warns users when a server’s RSA keys change so diligent users can identify and avoid potential man-in-the-middle attacks. SFTP is not, however, a perfect solution. OpenSSH, the implementation which we will be dealing with in this article, can be found on most Linux and BSD servers. Due to its ubiquity it is a prime target for 0-day exploits on one hand, and well hardened against known exploits on the other (you do keep your software patched and up-to-date, right?).

SSH, like any service that uses a username-password authentication scheme – including FTP, is vulnerable to brute-force or dictionary cracking attacks. This problem can be virtually eliminated by disabling user-pass authentication altogether and using on shared keys (please my article Passwordless or Single Password SSH with Key Exchange for instructions on implementing this configuration) however this is probably not an appropriate solution for your public hosting project as the process is difficult for regular users to implement, particularly if they are using a Windows client such as FileZilla. One solution which I highly recommend is fail2ban, it will read your sftpd logs and temporarily block an IP address associated with a specified number of failed attempts over a given period of time. I have provided simple instructions for implementing fail2ban for SSH in my article Stifling Brute Force Attacks with fail2ban. Because we are dealing with a situation where users are prone to forget their password you may wish to use fairly loose criteria in configuring fail2ban, enough failures should be tolerated that a forgetful user won’t be quickly blocked but an automated attack should be picked up. You might also wish to block access to sftpd rather than all ports as affected users might understand sftp disappearing after several failed attempts but could think the server is down if they are unable to access their website (assuming it is hosted from the same server).

The “chroot jail” concept is as old as the hills and has provided a way for us to separate vulnerable services from the filesystem-at-large by faking them into thinking a certain directory is the absolute root (/) of the filesystem. In this article we’re going to apply this concept to regular users using OpenSSH’s built-in functionality available since version 4.9. Before then it was a royal pain to implement whereas most popular FTP daemons had supported the feature out-of-the-box for years, now SFTP can finally be considered a complete and suitable replacement.

One probably does not wish to restrict SSH access for ALL user accounts, since one probably needs remote administrative access to the machine. Therefore one shall create a group to which users who must be chroot jailed will be added. For the purposes of this article we shall call the group hosted but you may call it anything:

# groupadd hosted

Next add users to the group, if you want to make sure these users do not get regular shell access (the ability to log in and run commands etc) be sure to specify a dummy shell, such as /bin/false or /sbin/nologin (Gentoo):

# useradd -G hosted -s /bin/false demo-user
or
# usermod -G hosted -s /bin/false demo-user

Don’t forget to give your test account a password if it is a new account.

# passwd demo-user

Now open your sshd config file (most users: /etc/ssh/sshd_config) and go to the very bottom. If there is a Subsystem sftp line already delete it. Add the following:

Subsystem       sftp    internal-sftp

Match Group hosted
        ChrootDirectory %h
        ForceCommand internal-sftp
	AllowTcpForwarding no

The Match Group directive tells sftpd to use the proceeding settings for any user in the group hosted. Now you must change the owner (and optionally group) of the user’s home directory to root:

# chown root: /home/demo-user

Due to these permissions the user will not be able to create new files at the top level of their directory tree, which to you looks like /home/demo-user and to them /. That’s fine because we’re going to give them a directory for the site they want to host with appropriate ownership, then they can do whatever they want in that. I typically set users up thus:

# mkdir ~demo-user/demo-site.com
# mkdir ~demo-user/demo-site.com/htdocs
# mkdir ~demo-user/demo-site.com/log
# mkdir ~demo-user/demo-site.com/cgi-bin
# chown demo-user: ~demo-user/demo-site.com/ -R

Restart your sshd (/etc/init.d/ssh(d) restart) and try logging in as your jailed user via sftp. If it works, congratulations. If you chose to restrict regular SSH access you may need to include /bin/false (or /sbin/nologin etc) to your /etc/shells valid shells list or the user may not be able to log in at all. Try logging in via SSH to ensure access has been blocked.

In the last two articles we have covered in detail the main flaw of any username-password authentication scheme and how to defend against attacks by increasing their time/resource cost. Unfortunately this does nothing to eliminate the problem but key-exchange authentication – while not unbreakable – changes the shape of the playing field and it’s becoming an increasingly favoured authentication scheme for a myriad of applications including SSH and VPN protocols. This article will show you how to quickly generate and exchange keys with remote hosts and disable traditional password authentication.

First you will need to generate a key pair:

ssh-keygen -t rsa

You are going to have to decide here whether you want to encrypt your private key with a passphrase and enter one password every time you use key exchange or make login instant at the expense of a more vulnerable key. You need to consider the possible damage that could be done if a given machine with unrestricted shell access to other hosts is compromised.

The least level of protection you can apply is exchanging only lesser-privileged accounts as a first step toward higher levels, i.e. by using su. Key exchange suffers from this weakness only when the private key is stored locally and unencrypted. One could keep the private key (~/.ssh/id_rsa) on a USB stick, however your key is vulnerable when the device is mounted. Even when using an encrypted key if the file is intercepted it can eventually be cracked. Smart cards (themselves) do not share these weaknesses and will be the topic of an upcoming article.

Never allow root to directly shell into a machine regardless of the authentication scheme you choose to use, make sure your target’s sshd_conf includes:

PermitRootLogin no
AllowUsers user1 user2 user3

Where user1,2,3 are the names of specific users permitted to login. This may not be practical for larger or public installations.

If the target account on the remote host has not yet used ssh you may have to create ~/.ssh. Add the new private key to the remote host’s authorized keys list:

cat ~/.ssh/id_rsa.pub | ssh xxx.xxx.xxx.xxx "xargs --null echo >> ~/.ssh/authorized_keys"

If you have not already shelled into the remote host from this account you will be prompted to accept its public key. You may then be prompted for your password. If the copy was successful you will be returned to the command line without a message. Try logging into the remote host, if you are not asked for a password or you are asked your private key’s passphrase you have successfully performed the key exchange.

Once you’ve finished exchanging keys with all of the hosts which should have access to the target you might proceed to disable password based authentication. The previous command will no longer work to import new keys, you will have to transfer them via other means (i.e. a host that has already exchanged keys with the target). Edit /etc/ssh/sshd_config to reflect:

ChallengeResponseAuthentication no

and restart sshd. Try logging in from a machine that has not exchanged keys with it. You should see something like:

Permission denied (publickey).

In an ideal world you wouldn’t run management services (SSH, webmin, snmp etc) on public address space. One can keep SSH from being exposed in the first place by making it listen on a private subnet and connecting to it via VPN. The only time I can see someone wanting to expose SSH in particular is to provide sftp and chances are you’ll be dealing with a number of users where key exchange isn’t practical. You can address this by keeping password authentication and enabling a chroot jail, which I’ll cover in a future article. If an attacker does manage to break into an account despite your fail2ban setup they will at least be confined to their own little slice of the filesystem.