08 November, 2008
Recently on the fwknop mailing list,
Mark V asked whether Single Packet Authorization
is compatible with virtual Linux instances in Amazon's
Elastic Cloud (EC2) computing
service. After signing up for an account and running a few tests, it turns out that
fwknop can function properly on an EC2 instance and wrap an SPA hardening layer around SSHD.
The Amazon online documentation on how to
access Linux instances
over SSH recommends adding new rules for each IP source address you want to
use to access SSHD, which can become tiresome if you are on a network running DHCP. With
fwknop, you don't need to do any such thing - you can access SSHD via SPA from anywhere,
and anyone else scanning for SSHD on the instance can't even tell that it is listening.
To re-create the steps listed in this blog post, it is necessary to have
signed up
for an EC2 account and to have created an
SSH keypair
so that instances can be launched from the command tools provided by Amazon. For
this post, all commands on the fwknop client side are executed on an Ubuntu 8.04
system to gain access into the Amazon cloud.
First, let's launch a new virtual instance of Fedora 8 (the command
ec2-describe-images -o self -o amazon can be used to find instance identifiers
for Fedora 8 systems):
[ubuntu]$ ec2-run-instances ami-abcd1234 -k cdyne-keypair
RESERVATION r-abcd1234 111111114274 default
INSTANCE i-abcd1234 ami-abcd1234 pending cdyne-keypair 0
m1.small 2008-11-07T20:18:43+0000 us-east-1c aki-abcd1234
ari-abcd1234
[ubuntu]$ ec2-describe-instances i-abcd1234
RESERVATION r-abcd1234 111111114274 default
INSTANCE i-abcd1234 ami-abcd1234
ec2-70-100-249-20.compute-1.amazonaws.com
domU-12-31-00-00-00-00.compute-1.internal running cdyne-keypair 0
m1.small 2008-11-07T20:18:43+0000 us-east-1c aki-abcd1234
ari-abcd1234
Now, we allow SSH access temporarily from the Ubuntu IP address (which will be
managed by fwknop after we get it installed and set up instead). We also allow
all UDP packets over port 62201 through from any IP since this is the default port
and protocol used by fwknop to send SPA packets, and we need such packets to reach
far enough into the cloud so that it will be seen by the fwknopd sniffer running
on the Fedora 8 instance:
[ubuntu]$ ec2-authorize default -p 22 -s 123.1.1.1/32
GROUP default
PERMISSION default ALLOWS tcp 22 22 FROM CIDR 123.1.1.1/32
[ubuntu]$ ec2-authorize default -P udp -p 62201
GROUP default
PERMISSION default ALLOWS udp 62201 62201
We can now log into the instance as root:
[ubuntu]$ ssh -i cdyne-keypair root@ec2-70-100-249-20.compute-1.amazonaws.com
The authenticity of host 'ec2-70-100-249-20.compute-1.amazonaws.com
(70.100.249.20)' can't be established.
RSA key fingerprint is 2a:aa:aa:c9:6f:aa:aa:aa:a0:48:7d:db:d6:aa:aa:aa.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-70-100-249-20.compute-1.amazonaws.com,
70.100.249.20' (RSA) to the list of known hosts.
__| __|_ ) Fedora 8
_| ( / 32-bit
___|\___|___|
Welcome to an EC2 Public Image
:-)
Base
--[ see /etc/ec2/release-notes ]--
We have a shiny new EC2 instance running Fedora 8. For fwknop to run properly, we'll
need the
perl-devel and
libpcap-devel packages installed, and then we'll
install fwknop (some output below has been abbreviated) and configure the
/etc/fwknop/access.conf file for SPA access to SSHD. We also add
iptables rules to allow packets that are part of established connection through, and
drop all other attempts to communicate with SSHD. Finally, we start fwknopd:
[root@domU-12-31-00-00-00-00 ~]# yum install perl-devel libpcap-devel
[root@domU-12-31-00-00-00-00 ~]# cd /usr/local/src/
[root@domU-12-31-00-00-00-00 src]# wget http://www.cipherdyne.org/fwknop/download/fwknop-1.9.9-pre7.tar.gz
[root@domU-12-31-00-00-00-00 src]# tar xfz fwknop-1.9.9-pre7.tar.gz
[root@domU-12-31-00-00-00-00 src]# cd fwknop-1.9.9-pre7
[root@domU-12-31-00-00-00-00 fwknop-1.9.9-pre7]# ./install.pl
[...]
[+] It appears that the following network interfaces are attached to the
system:
eth0
lo
Which network interface would you like fwknop to sniff packets from? eth0
[root@domU-12-31-00-00-00-00 ~]# cat > /etc/fwknop/access.conf
SOURCE: ANY;
OPEN_PORTS: tcp/22;
KEY: thisisatestkey;
FW_ACCESS_TIMEOUT: 30;
[root@domU-12-31-00-00-00-00 ~]# iptables -F
[root@domU-12-31-00-00-00-00 ~]# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[root@domU-12-31-00-00-00-00 ~]# iptables -A INPUT -p tcp --dport 22 -j DROP
[root@domU-12-31-00-00-00-00 ~]# /etc/init.d/fwknop start
Starting fwknopd: [ OK ]
In the installation of fwknop above, we selected eth0 as the Ethernet interface
that fwknopd sniffs for SPA packets, and then we configured the
/etc/fwknop/access.conf
file with a symmetric key for SPA access to SSHD over TCP port 22. Also, with
iptables now deployed to drop SSH communications, we cannot even see that SSHD is
listening under an nmap scan:
[ubuntu]$ nmap -P0 -p 22 -sT ec2-70-100-249-20.compute-1.amazonaws.com
Starting Nmap 4.53 ( http://insecure.org ) at 2008-11-08 01:33 EST
Interesting ports on ec2-70-100-249-20.compute-1.amazonaws.com
(70.100.249.20):
PORT STATE SERVICE
22/tcp filtered ssh
This is where fwknop comes in. After running the fwknop client and typing
the shared encryption key, we can now access the Fedora 8 instance with SSH:
[ubuntu]$ fwknop -A tcp/22 -a 123.1.1.1
-D ec2-70-100-249-20.compute-1.amazonaws.com
[+] Starting fwknop client (SPA mode)...
[+] Resolving hostname: ec2-70-100-249-20.compute-1.amazonaws.com
[+] Enter an encryption key. This key must match a key in the file
/etc/fwknop/access.conf on the remote system.
Encryption Key:
[+] Building encrypted Single Packet Authorization (SPA) message...
[+] Packet fields:
Random data: 9189958885117496
Username: mbr
Timestamp: 1226119984
Version: 1.9.9-pre7
Type: 1 (access mode)
Access: 123.1.1.1,tcp/22
SHA256 digest: EPOjHE2ANS3Fe3MHxDpok13qHDGbYziFiohv6CyHQXs
[+] Sending 161 byte message to 70.100.249.20 over udp/62201...
[ubuntu]$ ssh -i cdyne-keypair root@ec2-70-100-249-20.compute-1.amazonaws.com
__| __|_ ) Fedora 8
_| ( / 32-bit
___|\___|___|
Welcome to an EC2 Public Image
:-)
Base
In his original post, Mark had suggested a tighter level of integration with
Amazon's EC2 service by building in some notion of instance identifiers into
SPA communications. With the basic network access now validated and SPA in
its raw form demonstrated to be compatible with EC2, additional integration
points can be achieved. Incidentally, port knocking would also be compatible
with the EC2 service, but I would not recommend using it because port knocking
would
look like a port scan to any IDS that Amazon may have deployed to
monitor the cloud network. With SPA, only a single packet with an encrypted
payload is involved, and this is unlikely to trigger an IDS alarm.
Every few months it seems that there is a new variation of a password guessing botnet.
This time around, as reported by the SANS ISC
and also by malwarecity.com,
a botnet called "dd_ssh" has been built up around a vulnerability in phpMyAdmin.
(Here is the vulnerability announcement
from the Debian security list.) Once a vulnerable webserver has been compromised, the
botnet starts scanning random IP addresses for SSH servers and attempts to brute force
passwords for those systems that accept an SSH connection. Although software like
Fail2ban and DenyHosts can offer detection and mitigation by applying thresholds to
the number of failed login attempts in the SSH log and communicate offending source IP's
to a set of interested users, a fundamental problem is that the targeted SSH daemons
are reachable in the first place from arbitrary source IP's. A more powerful
solution is to hide your SSH daemon behind a default-drop firewall policy and only
grant access through Single Packet Authorization.
Any botnet that is scanning for SSH servers will not be able to guess any
passwords or even exploit a zero-day vulnerability in an SSH daemon that is protected
in this way.
