Knock, Knock, Knockin' on EnGarde's Door (with FWKNOP)

Source: Linux Security.com - Posted by Eckie Silapaswang

Introduction

Secret knocks have been used for purposes as simple and childish as identifying friend or foe during a schoolyard fort war. Fraternities teach these knocks as a rite of passage into their society, and in our security world we can implement this layer of security to lock down an SSH server.

The FireWall KNock Operator (fwknop) is an excellent port knocking implementation that combines encrypted port knocking with passive OS finger- printing. This makes it possible to define specifically which Linux systems are allowed access to your SSH server. fwknop combines its functionality with iptables rules and log messages to grant or deny access to the SSH daemon.

This article will walk the reader through an EnGarde Secure Linux implementation of fwknop, from the initial iptables rules setup to the deployment of fwknop on both the server and client side. By the end of the article, the user will be able to explicitly shutdown all access to the EnGarde Secure Linux SSH daemon to only those with fwknop credentials.

Prerequisites
You will need:

A machine to do your development on. These commands should NOT be run on a production server since the example firewall implementations shut down all access to your SSH daemon!
A separate client machine to actually connect to the server. To keep everything in sync, this could also be another EnGarde Secure Linux machine.
EnGarde Secure Community 3.0.18 or above

Once you have all the above you may log in as root, transition over to sysadm_r, and disable SELinux:

[spa_server]# newrole -r sysadm_r
Authenticating root.
Password:

[spa_server]# setenforce 0

Throughout the HowTo, the server will be referred to as spa_server and the client as spa_client.

Install fwknop

EnGarde Secure Linux makes the installation of fwknop a breeze due to its Guardian Digital Secure Network (GDSN). You can install the package through the command line:

[spa_server]# apt-get install fwknop

...or login to WebTool and install the package from the WebTool GDSN interface.

This should be repeated on the spa_client machine as well.

We shall get around to the setup of fwknop after we configure our iptables policy...

iptables Rules Setup

Since iptables is installed out of the box on EnGarde Secure Linux, we will provide you a simple shell script to execute to turn on your firewall. Keep in mind that this script will shut down access to your SSH daemon.

[spa_server]# cat firewall.sh

#!/bin/sh
IPTABLES=/sbin/iptables
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -X
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
$IPTABLES -A INPUT -i ! lo -j LOG --log-prefix "DROP "
$IPTABLES -A INPUT -i ! lo -j DROP
$IPTABLES -A FORWARD -i ! lo -j LOG --log-prefix "DROP "
$IPTABLES -A FORWARD -i ! lo -j DROP
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "[+] EnGarde Secure Linux iptables policy activated"
exit

Be sure to change the addresses to those of your public network interface.

Before running this script, be sure you make it executable:

[spa_server]# chmod +x firewall.sh

We can then run an Nmap scan on the server to see what we have open on the system:

[spa_client]# nmap

...
PORT STATE SERVICE
...
22/tcp open ssh
...

Nmap finished: 1 IP address (1 host up) scanned in 0.474 seconds

As you can see, there will be a set amount of open ports by default including the SSH port.

Run the firewall script on the spa_server...

[spa_server]# ./firewall.sh
[+] EnGarde Secure Linux iptables policy activated

From your client, you can run an Nmap scan and now see that all ports are closed:

[spa_client]# nmap

Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 3.012 seconds

At this point you have configured your firewalls to block all access to your SSH daemon. We can now set up fwknop to allow you access through port knocking in the next section.

Sssh, I want to tell you a secret... (setup fwknop and access)

Back on the server side, use your favorite editor to modify the /etc/fwknop/fwknop.conf file. We're interested in the following tunables:

EMAIL_ADDRESSES
HOSTNAME

The EMAIL_ADDRESSES should be whichever email addresses you wish to have the fwknop server send feedback to. This feedback includes error messages and other logging variables that can be specified elsewhere in the configuration file. The HOSTNAME variable would be the hostname of the spa_server machine.
Next, we edit the /etc/fwknop/access.conf file and change the KEY variable:

KEY:

This is the key you will be prompted for when attempting to access the fwknop server from the client. For security purposes, this key should be at least 8 characters long and be a combination of alphanumberic characters, no spaces.

Examples of such keys include:

fBs1(q^rV%)*
mY^&k3#3egT9
b!r3@kPh@3T^

You can now start up the fwknop server:

[spa_server]# /etc/init.d/fwknop start
[ SUCCESSFUL ] fwknop Daemons

Knock knock...who's there??? (spa client)

Now, from the client server, we can attempt to access the fwknop server. In the example below, replace 1.2.3.4 with the address of your spa_client machine, and the 5.6.7.8 with the address of your spa_server machine:

[spa_client]# fwknop -A tcp/22 -a 1.2.3.4 -k 5.6.7.8
[+] Starting fwknop client.
[+] Enter an encryption key. This key must match a key in the file
/etc/fwknop/access.conf on the remote system.

Encryption Key:

...at this point enter the key you had specified in the /etc/fwknop/access.conf file on the spa_server machine.

[+] Building encrypted single-packet authorization (SPA) message...
[+] Packet fields:

Random data: 9469687736864299
Username: root
Timestamp: 1196458361
Version: 1.8.2
Action: 1 (access mode)
Access: 1.2.3.4,tcp/22
MD5 sum: THfoIDCAPeWZBjoh0JMPaA

[+] Sending 171 byte message to 1.2.3.4 over udp/62201...

You now have only a 30 second window to connect via SSH to the server:

[spa_client]# ssh root@spa_server root@spa_server's password: Last login: Fri Nov 30 15:38:12 2007 from spa_client [root@spa_server ~]#

Congratulations! You've successfully implemented fwknop on both the server and client side!

Keep in mind this is one of the more basic setups for fwknop. You can go even further and implement GPG keys, change port settings, etc. by modifying the /etc/fwknop/fwknop.conf. A great resource for fwknop research is 'Linux Firewalls' by Michael Rash. Rash includes several chapters on fwknop covering theory and implementation. He even includes advanced setups for anyone looking to truly fine-tune their port knocking implementation!

Have fun in implementing a new secure layer for your SSH daemon!

Next time we will go over the EnGarde Secure Linux implementation of psad - here we will give you an inside look at how you can use psad to detect port scans against your server!

Comments

nice work

Written by anonymous on 2007-12-04 14:09:04

What's the benefit over strict ssh pub/priv keys method, fail2ban and non default port? (all I see is the port being open to the public, but keys are used so mitigation is very great to begin with...)

just curious.

Open ports increase security risk

Written by Michael Rash on 2007-12-06 18:38:25

In response to the question in the previous post, sure, taking steps such as using fail2ban and strict ssh pub/priv keys method help, but what happens when there is a new zero-day exploit against sshd that these measures do not protect against? It is only a matter of time (just search on OpenSSH in http://www.securityfocus.com/bid), and if the port is open you present sshd as a target for anyone to try and exploit such as vulnerability. Anyone running nmap against your system can see that sshd is listening (and running it on a non-default port is not much protection), so they will find you. By using fwknop with a default-drop iptables policy, nmap cannot even tell that sshd is running; it doesn't matter if someone has a new exploit or not because they can't talk to userspace. More information can be found in the paper "Single Packet Authorization with fwknop": http://www.cipherdyne.org/fwknop/docs/SPA.html

Written by anonymous on 2008-01-29 08:01:40

I see/know the logic. Please show me where there's been a remote exploit to the private/public key exchange process of sshd. Not a DOS, but a shell giving exploit - I know of not one, doesn't say much, mostly curious... Out of 65535 ports, your gonna be hard pressed to find a autorooter that will stumble on that
high misc port you choose - autorooters are up to 90% of the garbage we see in our logs. Unless your a really important target, that high port isn't gonna be found by a script kiddie or automated 0day. So the worry at this point is a 0dayexploit - but doesn't this exist with all internet facing services...Honestly, this is a great idear I first started playing with in sadoor, I loveit, but it does seem a little over kill for most people to implement when other less complex, native methods exist in sshd to give the same fuzzy feeling. Super coolprogram, high on geek points for sure, but until it's native to ssh, it's kinda overkill compared to alternatives. Tell ya what, I'll give ya my key password, my ip address and my high as all high port number, and lets see if ya can find that 0day?

Oh just thought of something else, stack protection :)

Written by Michael Rash on 2007-12-06 22:47:28

I'm not claiming I know a zero-day in sshd. What I'm claiming is that security is enhanced by minimizing the number of functions that an attacker can interact with. Every function has a non-zero probability of containing a vulnerability, and I'd rather not advertise functions to the world for anyone to freely interact with. Also, fwknop is not limited to applying a default-drop stance to sshd; it can be used for arbitrary services (with obvious constraints surrounding chatty protocols). Suppose there is a new custom server application that you have developed and would like to communicate with over the open Internet, but you don't know what IP address your client will be? Having something like fwknop allows you to wrap a strong authentication layer around such a service and thwart Nmap at the same time. I'm trying to enhance security by making the target acquisition phase itself as difficult as possible. And, yes, stack protection is a good idea. Nothing prevents that from being used too.

Only registered users can write comments.
Please login or register.