用单数据包授权保护SSH服务器

　　通过非对称加密SPA

　　要使用GnuPG加密和标记一个SPA包，你可以使用下面的fwknop命令，在这个例子中，fwknop服务器的密钥ID通过在命令后加上--gpg-recipient参数来指定，通过参数—gpg-signing-key来用密钥ID给SPA包做上标记（下面的输出经过简化处理了）：

　　[spa_client]$ fwknop -A tcp/22 --gpg-recipient ABCD1234 \

　　--gpg-signing-key 5678DEFG -w -k 16.2.2.2

　　[+] Sending 1010 byte message to 16.2.2.2 over udp/62201

　　正如你所看到的，SPA包的长度已经增长到超过1000字节了，而Rijndael例子中只有150字节，这是因为GnuPG密钥的长度（在本例中是2048 bits）和非对称加密密码的特性倾向于在加密后增大小数据块的大小，在明文和密文之间数据没有严格的一致限制。

　　在spa_server系统上，fwknop为我们添加了ACCEPT规则，此时fwknopd报告显示SPA包已经过GnuPG加密，并为密钥ID 5678DEFG提供了一个有效的数字签名：

　　Feb 10 14:38:26 spa_server fwknopd: received valid GnuPG

　　encrypted packet (signed with required key ID: "5678DEFG")

　　from: 15.1.1.1, remote user: mbr

　　Feb 10 14:38:26 spa_server fwknopd: adding

　　FWKNOP_INPUT ACCEPT rule for 15.1.1.1 -> tcp/22 (30 seconds)

　　阻止重放攻击

　　假设上面的第一个例子的SPA包被攻击者在图1中标识为attacker的系统上嗅探到，SPA原始包是可以被替换并重新放回线路上的—这就是著名的重放攻击，有多种办法获取包数据并进行重放，最常用的方法之一就是用tcpdump产生一个pcap文件（在本例中tcpdump –i eth0 –l –nn –s 0 –w SPA.pcap，端口62201），然后用tcpreplay（查看http://tcpreplay.synfin.net/trac）将SPA包重新放回通讯线路上，另一个方法，在包被捕获后，用netca与echo命令一起：

　　[attacker]$ echo "U2FsdGVkX1+BvzxXj5Zv6gvfCFXwJ+iJGKP \

　　qe2whdYzyigkerSp2WtvON/xTd8t6V6saxbg1v4zsK+YNt53BE8EI \

　　nxVCgpD7y/gEBIg8sd+AvU1ekQh9vwJJduseVx \

　　DxjmAHx3oNnClo2wckBqd8zA" |nc -u 16.2.2.2 62201

　　在fwknopd服务器上，复制SPA包是被监视的，但是MD5校验和值与原始SPA包是一致的，访问是不会被允许的，并且在spa_server系统上会写入下面的系统日志：

　　Feb 10 14:14:24 spa_server fwknopd: attempted \

　　message replay from: 18.3.3.3

　　结论

　　单数据包授权为服务如SSHD提供了一层额外的安全保护，当攻击者在尝试攻击的第一步（侦查）就收到了打击，用默认删除策略的iptables和fwknop嗅探特定构造的数据包（加密且非重放的）线路，这会非常困难甚至不能弄清楚是什么服务在监听，最终结果是要给受到保护的服务开发一个漏洞攻击程序更困难了。

　　附录A

　　如果你想使用GnuPG来加密fwknop客户端与fwknopd服务端之间的通讯，你首先要在客户端和服务端创建GnuPG密钥，如果你已经有一个用于电子邮件加密的GnuPG密钥，你可以在客户端使用它，用它通过fwknop给消息进行标记，但是在fwknopd服务端你必须创建一个为fwknop通讯专用的GnuPG密钥，因为用于解锁这个密钥的密码实际上是存储在/etc/fwknop/access.conf文件里的，fwknopd必须解密fwknop客户端用服务器公钥加密后的消息，因此，在服务器上使用一个高度个性化有价值的GnuPG密钥不是个好主意，一旦你创建了必需的密钥，你需要将每个密钥导入并标记到它对立的系统，如：导入并标记服务器密钥到客户端GnuPG密钥环，反过来也一样。

　　注意：因为SPA包消息必须填充在一个单独的ip包里，建议为fwknopd服务器GnuPG密钥选择密钥大小为2048 bits或更少。

　　下面概述了客户端和服务器端产生GnuPG密钥的过程，我们首先生成GnuPG密钥然后将它们导出到ascii文件：

　　[spaserver]# gpg --gen-key

　　[spaserver]# gpg --list-keys

　　pub 1024D/ABCD1234 2006-05-01

　　uid fwknop server key

　　sub 2048g/EFGH1234 2006-05-01

　　[server]# gpg -a --export ABCD1234 > server.asc

　　[spaclient]$ gpg --gen-key

　　[spaclient]$ gpg --list-keys

　　pub 1024D/1234ABCD 2006-05-01

　　uid fwknop client key

　　sub 2048g/1234EFGH 2006-05-01

　　[client]$ gpg -a --export 1234ABCD > client.asc

　　接下来，我们将ascii文件传输到两个系统上，在这个例子中，我们使用scp（在fwknop部署后将可能被防火墙阻隔），但是其他传输机制（ftp，http等）一样可以。

　　[spaclient]$ scp client.asc root@serverhost:

　　[spaserver]# scp server.asc user@clienthost:

　　然后导入并标记每一个密钥：

　　[spaserver]# gpg --import client.asc

　　[spaserver]# gpg --edit-key 1234ABCD

　　Command> sign

　　[spaclient]$ gpg --import server.asc

　　[spaclient]$ gpg --edit-key ABCD1234

　　Command> sign

　　在服务器端，我们需要增加几个配置指令到/etc/fwknop/access.conf文件，因此fwknopd使用GnuPG来校验和解密用GnuPG加密并标记的SPA包，注意服务器端密钥ID是ABCD1234，客户端密钥ID是1234ABCD：

　　SOURCE: ANY;

　　OPEN_PORTS: tcp/22;

　　DATA_COLLECT_MODE: PCAP;

　　GPG_REMOTE_ID: 1234ABCD;

　　GPG_DECRYPT_ID: ABCD1234;

　　GPG_DECRYPT_PW: ;

　　GPG_HOME_DIR: /root/.gnupg;

　　FW_ACCESS_TIMEOUT: 60;

　　上面access.conf指令更多的信息可以在fwknop帮助页面找到，查看fwknop(8)和fwknopd(8)。

　　最后，要查看fwknop在GnuPG模式下的作用，在客户端我们执行下面的fwknop命令来获取在fwknopd重新配置本地Netfilter策略后访问SSHD的权限，首先我们显示了nmap不能检测到sshd是否在监听：

　　[scanner]$ nmap -p 22 -n

　　Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2007-01-06 10:21 EST

　　Interesting ports on 71.127.x.x

　　PORT STATE SERVICE

　　22/tcp filtered ssh

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

　　然后执行下面的命令获取访问sshd：

　　[spaclient]$ fwknop -A tcp/22 --gpg-recip ABCD1234 --gpg-sign 1234ABCD -w -k

　　[spaclient]$ ssh -l mbr

　　mbr@host's password:

　　在服务器端，类似下面的fwknopd消息将被写入系统日志：

　　Jan 14 20:12:37 host fwknopd: adding FWKNOP_INPUT ACCEPT rule for

　　72.x.x.x -> tcp/22 (10 seconds)

　　Jan 15 10:13:09 host fwknopd: received valid GnuPG encrypted packet

　　(signed with required key ID: 1234ABCD) from: 72.x.x.x, remote user: mbr