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

　　上个月，在单数据包授权系列作品中第一部份中，我描述了叫做单数据包授权（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连接的包可以畅通无阻。