Protecting SSH Servers with Single Packet Authorization

Suppose that the SPA packet from the first example above was sniffed off the wire en route by a crafty individual on the system labeled attacker in the network diagram in Figure 1. The SPA packet always can be placed back on the wire in an effort to gain the same access as the original packet—this is known as a replay attack. There are several ways to acquire the packet data and replay it. One of the most common is to use tcpdump to write a pcap file (in this case tcpdump -i eth0 -l -nn -s 0 -w SPA.pcap port 62201 would work) and then use tcpreplay (see tcpreplay.synfin.net/trac) to copy the SPA packet back onto the wire. Another method, after the packet has been captured, is to use the echo command along with netcat:

[attacker]$ echo "U2FsdGVkX1+BvzxXj5Zv6gvfCFXwJ+iJGKP \
qe2whdYzyigkerSp2WtvON/xTd8t6V6saxbg1v4zsK+YNt53BE8EI \
nxVCgpD7y/gEBIg8sd+AvU1ekQh9vwJJduseVx \
DxjmAHx3oNnClo2wckBqd8zA" |nc -u 16.2.2.2 62201

On the fwknopd server, the duplicate SPA packet is monitored, but because the MD5 sum matches that of the original SPA packet, no access is granted, and the following message is written to syslog on the spa_server system:

Feb 10 14:14:24 spa_server fwknopd: attempted \
message replay from: 18.3.3.3

Single Packet Authorization provides an additional layer of security for services such as SSHD, and this layer strikes at the first step that an attacker must accomplish when trying to compromise a system: reconnaissance. By using iptables in a default-drop stance and fwknop to sniff the wire for specially constructed (that is, encrypted and non-replayed) packets, it is difficult even to tell that a service is listening, let alone communicate with it. The end result is that it is significantly harder to exploit any vulnerabilities a protected service might have.