Turnabout

My home firewall runs an ssh server. Every few days, I go through my logs and find that someone has been attempting to guess account names and passwords on that server. For a while, I just allowed it to continue because I found it interesting to see what usernames were being guessed. After a few months of getting guess attempts every couple of seconds with almost no interruptions from dozens of ip addresses, I decided I didn't want to take the risk of somebody actually getting in and set up iptables rules to blackhole any ip address that sent more than ten SYN packets to ssh in less than two minutes. A friend pointed me to denyhosts, a tool to watch your logs for failed ssh attempts and put the offending host into your /etc/hosts.deny for a certain period of time. This is effectively the same as the iptables rules. Both of these methods are very effective but not as interesting as seeing all the usernames tried. So I downloaded the source for openssh-4.4p1 and made a few modifications. My new sshd:

• Logs all connections
• Logs usernames and passwords
• Never opens a shell no matter what

If you'd like to set this up yourself, you can download the complete source, or if you already have the source for openssh-4.4p1, and don't want to download the whole thing just for a few modifications you can get just the diff. Then run the following commands:

tar xzvf openssh-logger.tar.gz
cd openssh-logger
./configure --prefix /usr/honey/ \
  --with-privsep-path=/usr/honey/chroot \
  --with-pid-dir=/usr/honey/var/run
make

The purpose of putting it in a strange directory is that we don't want to hose your real ssh server. If that went well, run:

su
make install
touch /usr/honey/chroot/sshattacks.log
chown sshd:sshd /usr/honey/chroot/sshattacks.log

Remember: if you run a real ssh server, you'll want to change the port it listens on in your /etc/ssh/sshd_config. You can add section to your ~/.ssh/config like this:

Host <hostname>
  Port <real server's port>

so your client will connect to the correct server. Now everything should be set up and you should start seeing brute force attacks in /usr/honey/chroot/sshattacks.log in no more than a couple of days.

Output will look something like this:

host: 10.0.0.100 port: 45677
user: root pass: root
user: root pass: t00r
user: root pass: r00t

Happy hunting!

Nastier tricks with ssh

In my daily blog reading a week or so ago, I stumbled on Jon Hart's blog. In it, he notes the facts that root can read any file whatsoever on a *nix system and that ssh agent forwarding is accomplished using unix sockets. The corollary to this is that root (or someone with access to your account) can steal your password-protected ssh keys after you decrypt them.

Having used key-based authentication on a regular basis myself, this got me to thinking about other possibilities for an unrestricted user. As it turns out, if a user can read someone else's private key file, one can authenticate with it. Long story short, I've modified Jon's code to also search out non-password-protected keyfiles and attempt to abuse them.

On ssh and timeouts

It turns out that ssh by default doesn't like to stay connected forever. If you setup a port forward as described below and don't connect to it right away one end or the other will timeout (not sure which, but it doesn't really matter). To circumvent this issue, I've taken to setting up the forward, connecting to the remote box, then connecting through the port forward in a screen session, and detaching screen (or not, depending on my mood). Now ssh won't be able to tell that there's no interaction and will stay connected indefinitely.

Incidentally, if you love the power of the command line and haven't heard of screen, you should install it at the earliest opportunity. Thank me later.

Tricks with SSH

Do you want to ssh to your NATed box at home? Want to connect in to your machine at work that drops SYN packets at the perimeter? Tired of having to live without tab-completion and other handy features when an exploit sends a shell back to netcat? SSH to the rescue.

First, from the firewalled machine (call it BoxA) run:
ssh -nNT -R 2222:localhost:22 user@boxb.example.com &
then on BoxB.example.com:
ssh user@localhost -p2222

So what exactly does this do? Let's take a look at the relevant sections from ``man ssh'':

-n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background.

-N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only).

-T Disable pseudo-tty allocation.

-R [bind_address:]port:host:hostport
Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.
...
By default, the listening socket on the server will be bound to the loopback interface only. This may be overriden by specifying a bind_address.


``-nNT'' means we aren't going to give ssh any input, so don't execute a shell and don't allocate a tty. -R is a little trickier; it says start forwarding port 2222 of the remote machine (BoxB) to port 22 of the machine you're running ssh from (BoxA). Now when you run ssh localhost -p2222, you're connecting to the port forward that you just set up which sends your connection through an encrypted tunnel to BoxA, bypassing the firewall rules because the tunnel is already connected.

Caveats:

• You're connecting to localhost from BoxB but the traffic is actually going to BoxA. This will confuse ssh who thinks that localhost should have the same fingerprint each time. To get around this, you'll likely have to delete the line beginning with ``localhost'' in your ~/.ssh/known_hosts.


• If you're using an exploit you'll have to know the account's password (or steal an ssh key)


• Don't complain to me if your sysadmin gets mad and blocks outbound ssh. =)

I love open source. They've really thought of everything.