上个月，在单数据包授权系列作品中第一部份中，我描述了叫做单数据包授权（SPA）的下一代被动认证技术的原理，本文不再谈论其原理，而是将精力集中在SPA实用应用程序fwknop和iptables，用它们来保护SSHD，抵御侦察和攻击。在Linux系统上安装后，没人能用nmap扫描后说SSHD正在监听【即用nmap扫描不到SSHD是否正在运行】，只有在经过认证的客户端才能与SSHD进行通讯。

　　开始之前，我们需要一些关于配置和网络结构的信息，本文假设你已经在同时运行了SSHD和iptables的系统上安装好了fwknop的最新版本（写本文时是1.0.1），你可以从http://www.cipherdyne.org/fwknop下载fwknop，也可以通过运行install.pl脚本从源代码tar包安装或通过基于RPM的Linux发行版安装RPM包。

　　网络结构

　　在图1中展示了我们安装的基本网络结构，fwknop客户端在被标记为spa_client(15.1.1.1)的主机上执行，fwknop服务器（与iptables一起）在被标记为spa_server(16.2.2.2)的系统上运行，恶意系统被标记为attacker(18.3.3.3)，它可以嗅探spa_client和spa_server系统之间的所有通讯。

图1 使用SPA保护SSH通讯的样例情景

　　iptables 默认删除策略

　　Spa_client系统的ip地址是15.1.1.1，spa_server系统的ip地址是16.2.2.2，在spa_server系统上，iptables被配置为为内部网络（192.168.10.0/24）提供基本的连接服务、日志记录及丢弃所有尝试从外部网络到服务的连接（通过iptables的LOG和DROP目标），这个策略相当简单，意味着防火墙没有为任何服务（包括SSHD）在nmap扫描下进行宣告，任何真实网络环境下部署将更大更复杂。不管怎样，一个重要的特征需要注意，那就是通过Netfilter提供连接跟踪工具，它在iptables策略中保留状态，最终结果是连接通过防火墙初始化（通过FORWARD链表）然后到达防火墙（通过INPUT链表）并保持打开，而不需要额外的ACCEPT规则来允许数据包保持连接的建立（如TCP确认等），iptables策略是用下面基础的firewall.sh脚本来建立的：

　　[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.10.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 "[+] iptables policy activated"

　　exit

　　[spa_server]# ./firewall.sh

　　[+] iptables policy activated

　　防火墙激活后，我们就可以查看远程访问的内容了，在spa_client系统上，我们使用nmap来查看在spa_server上的SSHD是否可以连接：

　　[spa_client]$ nmap -P0 -sT -p 22 16.2.2.2

　　Starting Nmap 4.01 ( http://www.insecure.org/nmap/ )

　　at 2007-02-09 23:55 EST

　　Interesting ports on 16.2.2.2:

　　PORT STATE SERVICE

　　22/tcp filtered ssh

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

　　12.009 seconds

　　正如预料的一样，iptables阻止了所有尝试与SSHD通讯的连接，以及保留的端口（TCP和UDP端口）也类似地被iptables策略保护起来了，如果一个攻击者拥有一个对付OpenSSH特定版本的0day攻击程序，那对于部署了这个版本的spa_server系统来说有保护策略就很重要了，所有尝试与堆栈的通讯都将被iptables阻止。

　　Fwknop SPA配置

　　确定iptables正严密地保护本地网络后，开始为spa_server系统配置fwknop服务进程（fwknopd），文件/etc/fwknop/fwknop.conf控制了重要的配置参数，如通过libpcap嗅探通讯的接口，fwknop发送警报信息和pcap过滤器语法（被设计为离线嗅探SPA包）的电子邮件地址，默认情况下，fwknop用UDP端口62201发送SPA包，因此在/etc/fwknop/fwknop.conf中pcap过滤器语法被设置为udp port 62201 ，但是SPA包可以通过任意端口和协议（甚至是ICMP）进行发送，过滤器语法必需要更新到能控制在其他端口/协议上的SPA通讯，在fwknop帮助中能找到更多信息，尽管在这个文件中的默认设置对于大多数部署都是行得通的，但对于你特定的安装你需要调整PCAP_INTF和EMAIL_ADDRESSES 变量。

　　文件/etc/fwknop/fwknop.conf是fwknop最重要的配置文件，它管理加密密钥以及访问控制权限（用于来自fwknop客户端有效的SPA包），下面的access.conf文件是本文用到的剩余部分：

　　[spa_server]# cat /etc/fwknop/access.conf

　　SOURCE: ANY;

　　OPEN_PORTS: tcp/22;

　　FW_ACCESS_TIMEOUT: 30;

　　KEY: LJ07p2rbga;

　　GPG_DECRYPT_ID: ABCD1234;

　　GPG_DECRYPT_PW: p2atc1l30p;

　　GPG_REMOTE_ID: 5678DEFG;

　　GPG_HOME_DIR: /root/.gnupg;

　　SOURCE变量定义fwknopd接受的SPA包的ip地址，值ANY表示可以从任意ip地址检查SPA包，但是它也可以受特定的ip地址或子网络限制，支持逗号分割的列表（如192.168.10.0/24，15.1.1.1）。OPEN_PORTS变量告诉fwknopd用来接收有效的SPA包的端口，在这个例子中，fwknopd将打开TCP端口22。

　　尽管上面没有列出，但fwknopd能被配置为允许fwknop客户端通过设置PERMIT_CLIENT_PORTS变量为Y而指定其他端口；FW_ACCESS_TIMEOUT指出了被添加到允许通过OPEN_PORTS 变量定义的通讯的iptables策略中的ACCEPT规则时间长度，因为在上面的firewall.sh脚本中的iptables策略利用由Netfilter提供的连接跟踪能力，一个SSH连接在初始化被fwknopd删除的ACCEPT规则后将继续保持连接。

　　剩下的变量为SPA包加密和解密定义参数，本文将阐述对称和非对称密码的用法，但fwknop只需要一种加密类型。

　　如果有KEY变量的话，所有的GPG_*变量可以被忽略，反过来也一样。KEY变量定义一个在fwknop客户端与fwknop服务端共享的密钥，这个密钥用来加密/解密SPA包，对于非对称加密，GPG_DECRYPT_ID定义本地fwknop服务器GnuPG密钥ID，这个密钥用于fwknop客户端通过一个由GnuPG支持的加密算法加密SPA包（如ElGamal算法）。

　　GPG_DECRYPT_PW联合fwknop服务端密钥一起进行解密，因为密码是以明文的形式放在access.conf文件中的，建议不要为服务器使用一个有价值的GnuPG密钥，应该为解密SPA包生成一个专用的密钥，fwknop客户端用一个在本地密钥环中的GnuPG密钥标记SPA包，用户从命令获取密码。永远不将其保存在一个文件中（下面我们将会看到），因此，任何GnuPG密钥能被fwknop客户端使用，如用一个有价值的密钥来加密敏感的电子邮件通讯。

　　GPG_REMOTE_ID变量定义一个密钥ID列表，fwknopd服务端将接受这个列表，任何用fwknopd服务端公共密钥加密的SPA包必须用一个由GPG_REMOTE_ID变量指定的私钥进行标记，这样就允许fwknopd通过强密码机制来限制人们访问一个受保护的服务（在我们的例子中是SSHD），在http://www.cipherdyne.org/fwknop/docs/gpghowto.html可以找到用fwknop创建GnuPG密钥的介绍。[参加附录A]

　　随着文件/etc/fwknop/access.conf的建立，可以在spa_server系统上开始fwknopd并执行fwknop了：

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

　　* Starting fwknop ... [ ok ]

　　通过对称加密SPA

　　在spa_client系统上，我们用fwknop通过Rijndael算法加密了一个SPA包并将其发送到spa_server系统上，我们想访问SSHD，并在SPA包中用-A参数编码想要的访问，-w参数通过查询http://www.whatismyip.com（如果fwknop客户端在一个NAT设备后面的话这很有用）来解析客户端系统的ip地址，-k参数是目标SPA服务器的ip地址，-v参数是显示运行的详细结果以便于我们查看原始包数据：

　　[spa_client]$ fwknop -A tcp/22 -w -k 16.2.2.2 -v

　　[+] Starting fwknop in client mode.

　　Resolving external IP via: http://www.whatismyip.com/

　　Got external address: 15.1.1.1

　　[+] 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: 7764880827899123

　　Username: mbr

　　Timestamp: 1171133745

　　Version: 1.0.1

　　Action: 1 (access mode)

　　Access: 15.1.1.1,tcp/22

　　MD5 sum: yzxKgnAxwUA5M2YhI8NTFQ

　　[+] Packet data:

　　U2FsdGVkX1+BvzxXj5Zv6gvfCFXwJ+iJGKPqe2whdYzyigkerSp \

　　2WtvON/xTd8t6V6saxbg1v4zsK+YNt53BE8EInxVCgpD7y/gEBI \

　　g8sd+AvU1ekQh9vwJJduseVxDxjmAHx3oNnClo2wckBqd8zA

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

　　从上面的Packet data小节你可以看到，SPA包是完全难以理解的加密数据块，在spa_server系统上，生成了下面的系统日志消息，指示一个为产生SPA包的源ip（15.1.1.1）的ACCEPT规则被添加，注意源ip通过fwknop客户端推送到SPA包，在这个例子中，SPA包没有被欺骗，因此真实的源地址和被嵌入到SPA包中的源地址是相匹配的，SPA包可以通过fwknop加上—spoof-src命令参数进行欺骗（需要root权限）：

　　Feb 10 13:55:44 spa_server fwknopd: received valid Rijndael \

　　encrypted packet from: 15.1.1.1, remote user: mbr

　　Feb 10 13:55:44 spa_server fwknopd: adding FWKNOP_INPUT ACCEPT \

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

　　因此，发送SPA包后的30秒内，在spa_server上的iptables策略允许spa_client系统建立一个SSH会话连接：

　　[spa_client]$ ssh -l mbr 16.2.2.2

　　mbr@spa_server's password:

　　在30秒到期后，knoptm（一个专门删除通过fwknopd添加的iptables规则的后台进程）删除ACCEPT规则并在系统日志中写入下面的消息：

　　Feb 10 13:52:17 spa_server knoptm: removed iptables \

　　FWKNOP_INPUT ACCEPT rule for 15.1.1.1 -> tcp/22, \

　　30 second timeout exceeded

　　在ACCEPT规则被删除后我们的SSH会话仍然保持连接，因为在iptables策略中的跟踪规则状态（查看上面的firewall.sh脚本）没有变，这些规则允许一个已经连接好的的TCP连接的包可以畅通无阻。

　　通过非对称加密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