利用 openSSH 和 Linux 隧道化数据库流量

简介

我们将介绍如何确保数据库服务器所在环境的安全，如何通过数据库服务器本地的客户机访问远程数据库，以及如何保护多层的客户机服务器访问。特别地，我们还将探讨如何加密和隧道化（tunneling）从一台 Windows 客户机发出并穿过防火墙的 JDBC 连接。

我们将通过一些简单的步骤，使用从 www.openSSH.org 得到的 openSSH，利用 openSSH 中的端口转发（port forwarding）功能，来隧道化通过端口 22 的数据库流量。端口转发使得那些缺乏知识或者 SSH 二进制文件的客户机仍然可以隧道化它们的数据库请求。是的，Linux 再一次帮助了那些在功能上受到挑战的桌上电脑。

什么是 openSSH？
www.openSSH.org 网站的说法是：“OpenSSH 是网络连通性的 SSH 协议套件的免费版本……”。因此，openSSH 是“开放源代码安全 shell”（open source secure shell），逻辑上讲是从命令 shell 和 rsh 发展而来的。Linux 的 shell 比您想像的还要多。比如 ksh、bsh、bash、csh、ash、tcsh，如果这里没有列举出您所喜欢的 shell，那么敬请原谅。rsh shell，或者说远程 shell，提供了到另一台机器的无加密访问。如果您可以信任网络上的每一个系统的话，那么这个 shell 的确不错。OpenSSH 可以加密在不同系统之间传输的数据包，因而包嗅探器就无法偷看到您所发送的信息。如果仅仅是一份杂货目录表受到损坏，或许您并不是很在乎，倘若他们得到了您的信用卡号，您就会痛苦不堪了。

那么，一个 shell 必须如何处理数据库包呢？您可以在数据库服务器所在系统的本地打开 shell，但是这将不支持客户机-服务器应用程序。后面我们将更详细地考察这两种情况。

确保服务器系统的安全
说说我的体会吧：且不说我们担心网络上的数据库流量，即使是服务器本身也需要确保安全。 http://www.spitzner.net/linux.html上的“Beginner's guide to armoring Linux”为此提供了一个很好的入门点。此文有一点过时，例如这里引用的还是 IP 链（ipchain），而不是 IP 表（iptable），不过此文仍然不失为一个很好的入门点。尽管此文主要关注的是 Linux，但它与其他 Unix 操作系统仍然是紧密相关的。此文还是这样一个例子，即 Linux 社区对一个复杂问题给出了清晰的解释并给出了解决问题的步骤。

您还将需要一个良好的防火墙环境，而 Building Internet Firewalls, 2 ndEdition , Zwicky, Cooper, Chapman ( http://www.oreilly.com/catalog/fire2/index.html) 正是一份极好的参考资料。

同时具有数据库和客户机的远程服务器：对 telnet 说“不”
在图 1 中，有一个访问远程服务器上数据库的工作站。用户在主机“saam”上打开一个 shell，并运行客户机数据库软件。由 telnet 所导致的安全性暴露包括对用户 id、密码和所有数据包的明文传输。

因此，根本就不应考虑在称作“poh”这样的系统下工作以及使用： [poh/home] $ telnet saam 。用户 id、密码、每一条查询以及所有返回的数据对于窥探您网络的任何包嗅探器来说都是可见的。

SSH 前来拯救：telnet 的替代者

SSH 为这种环境提供了一个简单的解决方案。用户可以不使用 telnet，而运行 ssh 来访问远程主机。对于这个例子，我们将使用 Postgres 数据库（请访问 www.postgres.org）。用户登录到服务器 poh 并运行以下命令：

[marty@poh home] $ ssh saam -1 myuserid The authenticity of host 'saam.biz (192.168.1.65)' can't be established. RSA key fingerprint is b2:...yada, yada, yada...a:f1. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'saam.biz,192.168.1.65' (RSA) to the list of known hosts. [email protected]'s password: Last login: Mon Nov 17 16:35:35 2003 from 192.168.1.103 [myuserid@saam tmp]$ psql mypsqldb

SSH 端口转发：Linux 再当救世主
对于客户机服务器应用程序，用 ssh 作为 telnet 的替代者并不适合。我们需要一种方法来保护 JDBC、ODBC 和本地数据库客户机。这些客户机直接连接到数据库服务器的侦听端口，因此没有机会从命令行来运行 ssh。有些客户机为加密提供了 Secure Sockets Layer (SSL)，请参阅题为 确保流量安全的其他选择的小节以了解更多信息。

那么 Linux 如何拯救世界，或者至少拯救世界的一小部分呢？SSH 端口转发可以加密服务器之间的流量。当客户机软件以为它正在连接本地防火墙之后的本地服务器上的数据库时，实际上它是被隧道化至一个远程防火墙之后的远程服务器。图 2 展示了其实现，往后我们将对此进行详细研究，这次我们使用 DB2 Version 8.1 作为服务器。

数据库客户机应用程序仍然运行在服务器 poh 上。数据库也还是驻留在远程服务器 saam 上。这个解决方案真正漂亮之处就在于，客户机完全不知道连接到远程服务器 saam 实际上要通过三步。

端口转发的配置细节
下面是图 2 中展示的每个系统的详细配置步骤。端口转发命令是在“tuxpoh”上输入的，客户机被配置为连接到“tuxpoh”。

“tuxpoh”上的 SSH 转发

我们希望通过“tuxsaam”将“tuxpoh”上的端口转发到“saam”。ssh 手册页提供了以下语法：

[tuxpoh/home] $ ssh -g -L 9090:saam:50001 tuxsaam

标志（flag）很重要。-L 选项指定端口转发，-g 选项规定“tuxpoh”上的侦听端口对其他系统（例如本地网络上的“poh”）是可用的。如果您想使用有优先级的端口，则需要以 root 身份来运行转发命令。

要找到 DB2 正在使用的端口号，可在“saam”系统上发出以下命令：

 $ db2 get dbm config | grep SVC TCP/IP Service name (SVCENAME) = db2c_DB2 

 $ grep db2c_DB2 /etc/services db2c_DB2 50001/tcp

C:\WINNT\system32\drivers\etc>grep db2c_DB2 services db2c_DB2 50001/tcp

系统“POH”上的客户机配置
为了访问系统“tuxpoh”某端口上的数据库服务器，需要配置客户机。客户机存在着很多不同的可能，这个例子是针对 JDBC 的。DB2 带有大量的示例，请在 sqllib/samples/java/jdbc 目录中查找。如果查看 Util.java 程序，就可以发现其中有很多用于连接 URL 的选项。按照上述说明创建了通道之后，下面的语法将使用 TutRead.java 程序和一个 openSSH 通道来查询“saam”上的数据库。

 dbc>java TutRead tuxpoh 9090 dbuserid yourpasswdhere THIS SAMPLE SHOWS HOW TO READ DATA IN A TABLE. Connect to 'sample' database using JDBC type 4 driver. ---------------------------------------------------------- USE THE SQL STATEMENTS: SELECT TO PERFORM A BASIC SELECT. Perform: SELECT deptnumb, deptname FROM org WHERE deptnumb < 40 Results: DEPTNUMB DEPTNAME -------- -------------- 10 Head Office 15 New England 20 Mid Atlantic 38 South Atlantic Disconnect from 'sample' database.

这个方法也适用于其他数据库，比如可以参阅 Postgres 文档，网址是： http://www.postgresql.org/docs/7.4/static/ssh-tunnels.html。此方法也不局限于数据库流量。在 2003 年 8 月那一期的 LinuxJournal 中，第 80 页有一个使用此方法进行邮件访问的例子。

确保流量安全的其他选择
openSSH 通道并不是保证数据库流量安全的惟一选择。在某些选择中，ssh 转发是安全隐患，请参阅 Zwicky et al，第 503 页。取决于客户机软件，可能还有安全套接字层 SSL 支持，但是这样配置起来可能会比较有挑战性，请参阅： http://www.postgresql.org/docs/7.4/static/ssl-tcp.html。

保证流量安全的另一种方法是 SOCKS （不要与 Sox 混淆，Sox 是大约 2003 年 10 月在我所在城市发生的一件令人难于接受的事情）。最后 ssh 内建了 SOCKS 支持，请参阅手册页和 -D 标志。在 Zwicky 的第 233 页详细论述了这个主题。

结束语
对信息的保密正成为强制性的，未经加密而在网络上传输的数据包乃是一个巨大的暴露。我们考察了利用低成本的 Linux 方案加密这种流量的几种方法。希望本文可以成为您用来加强网络安全的有用工具。

Marty Lurie 撰写的其他文章

• Web Click Stream Analysis using Linux Clusters
• 在 Linux 上模拟大规模并行数据库处理！
• 联邦 － 数据库互操作性（第 1 部分）
• 联邦 － 数据库互操作性，继续大胆尝试（第 2 部分）
• Winning Database Configurations: An IBM Informix Database Survey