Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2097243
  • 博文数量: 414
  • 博客积分: 10312
  • 博客等级: 上将
  • 技术积分: 4921
  • 用 户 组: 普通用户
  • 注册时间: 2007-10-31 01:49
文章分类

全部博文(414)

文章存档

2011年(1)

2010年(29)

2009年(82)

2008年(301)

2007年(1)

分类: LINUX

2008-03-29 08:52:14

对于黑客来说,TCP/IP网络上的客户机服务器流量是一个极具吸引力的攻击目标。Linux 和openSSH为加密这种流量提供了一种简单而有效的方式。Linux 和ssh还可以利用这里给出的方法来保护 Windows 客户机。
第1章 简介
对于怀有恶意的包嗅探器(packet sniffer)来说,数据库流量是极具吸引力的攻击目标,因为数据包中可能包含高度敏感的信息。对于这种流量的保护不再是可有可无的了,一些保密方面的 法律使之必须强制实施。抵抗这种攻击的方法是,对于暴露在网络上的流量,如果不对全部流量加密,至少也要对数据库流量加密。Linux 为在 TCP/IP 环境中保护数据包免受外人窥探提供了一种非常经济而有效的方法。
本文介绍的几个方面:确保数据库服务器所在环境的安全,通过数据库服务器本地的客户机访问远程数据库,以及保护多层的客户机服务器访问。特别地,还将分析加密和隧道化(tunneling)从一台Windows客户机发出并穿过防火墙的JDBC连接。
我们将通过一些简单的步骤,使用从得到的openSSH,利用 openSSH中的端口转发(port forwarding)功能,来隧道化通过端口22的数据库流量。端口转发使得那些缺乏知识或者SSH二进制文件的客户机仍然可以隧道化它们的数据库请求。
第2章 什么是openSSH
网站的说法是:“OpenSSH是网络连通性的SSH协议套的免费版本……”。因此,openSSH 是“开放源代码安全 shell”(open source secure shell),逻辑上讲是从命令shell和rsh发展而来的。Linux的shell比想像的还要多。比如ksh、bsh、bash、csh、ash、tcsh,等等。rsh shell,或者说远程shell,提供了到另一台机器的无加密访问。如果可以信任网络上的每一个系统的话,那么这个shell的确不错。OpenSSH可以加密在不同系统之间传输的数据包,因而包嗅探器就无法偷看到用户所发送的信息。如果仅仅是一份杂货目录表受到损坏,或许并不是很在乎,倘若他们得到了信用卡号,用户就会痛苦不堪了。
那么,一个shell必须如何处理数据库包呢?可以在数据库服务器所在系统的本地打开shell,但是这将不支持客户机-服务器应用程序(即改变了C/S结构)。后面将更详细地考察这两种情况。
第3章 确保服务器系统的安全
且不说用户担心网络上的数据库流量,即使是服务器本身也需要确保安全。还将需要一个良好的防火墙环境。
同时具有数据库和客户机的远程服务器:对 telnet 说“不”。
在图 1 中,有一个访问远程服务器上数据库的工作站。用户在主机“saam”上打开一个shell,并运行客户机数据库软件。由telnet所导致的安全性暴露包括对用户id、密码和所有数据包的明文传输。
因此,根本就不应考虑在称作“poh”这样的系统下工作以及使用:
[poh/home] $ telnet saam
用户id、密码、每一条查询以及所有返回的数据对于窥探您网络的任何包嗅探器来说都是可见的。
第4章 SSH 前来拯救:telnet的替代者
SSH为这种环境提供了一个简单的解决方案。用户可以不使用telnet,而运行ssh来访问远程主机。对于这个例子,将使用Postgres数据库。用户登录到服务器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.
myuserid@saam.biz's password:
Last login: Mon Nov 17 16:35:35 2003 from 192.168.1.103
[myuserid@saam tmp]$ psql mypsqldb

通过使用上述方面,整个会话得到了加密,加强了安全性。
第5章 SSH 端口转发:Linux 再当救世主
对于客户机服务器应用程序,用ssh作为telnet的替代者并不适合。我们需要一种方法来保护JDBC、ODBC和本地数据库客户机。这些客户机直接连接到数据库服务器的侦听端口,因此没有机会从命令行来运行ssh。有些客户机为加密提供了Secure Sockets Layer (SSL)。
那么Linux如何拯救世界,或者至少拯救世界的一小部分呢?SSH端口转发可以加密服务器之间的流量。当客户机软件以为它正在连接本地防火墙之后的本地服务器上的数据库时,实际上它是被隧道化至一个远程防火墙之后的远程服务器。图2展示了其实现,往后将对此进行详细研究,这次使用DB2 Version 8.1 作为服务器。
数据库客户机应用程序仍然运行在服务器poh上。数据库也还是驻留在远程服务器saam上。这个解决方案真正漂亮之处就在于,客户机完全不知道连接到远程服务器saam实际上要通过三步。
5.1 端口转发的配细节
下面是图2中展示的每个系统的详细配置步骤。端口转发命令是在“tuxpoh”上输入的,客户机被配置为连接到“tuxpoh”。
5.1.1 “tuxpoh”上的SSH转发
希望通过“tuxsaam”将“tuxpoh”上的端口转发到“saam”。ssh 手册页提供了以下语法:
[tuxpoh/home] $ ssh -g -L 9090:saam:50001 tuxsaam

该命令将打开主机“tuxpoh”(“本地”)上的端口9090,以便进行转发。这是“tuxpoh”上的一个本地端口,数据库客户机将连接到此端口。远程目标是主机“saam”,“saam”主机上的端口是 50001。DB2 运行在“saam”上,并侦听端口 50001,以建立客户机连接。“tuxsaam” 主机上的ssh进程将提供到“saam”的ssh转发。有趣的是,“poh”和“saam”系统可能有ssh,但也可能根本就不存在ssh!所有的加密/隧道化工作都是在“tuxpoh”和“tuxsaam”上进行的。
标志(flag)很重要。-L选项指定端口转发,-g选项规定“tuxpoh”上的侦听端口对其他系统(例如本地网络上的“poh”)是可用的。如果想使用有优先级的端口,则需要以root身份来运行转发命令。
要找到DB2正在使用的端口号,可在“saam”系统上发出以下命令:
$ db2 get dbm config | grep SVC
TCP/IP Service name (SVCENAME) = db2c_DB2

然后在 services 文件中查找端口号:
$ grep db2c_DB2 /etc/services
db2c_DB2 50001/tcp

如果 DB2 服务器是在 Win32 架构上,则在这里查找:
C:\\WINNT\\system32\\drivers\\etc>grep db2c_DB2 services
db2c_DB2 50001/tcp
5.2 系统“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.
这个方法也适用于其他数据库,此方法也不局限于数据库流量。在 2003 年 8 月,有见到过一个使用此方法进行邮件访问的例子。
第6章 确保流量安全的其他选择
openSSH 通道并不是保证数据库流量安全的惟一选择。在某些选择中,ssh 转发是安全隐患,取决于客户机软件,可能还有安全套接字层 SSL 支持,但是这样配置起来可能会比较有挑战性。
保证流量安全的另一种方法是 SOCKS (不要与 Sox 混淆)。最后 ssh 内建了 SOCKS 支持,请使用-D 标志。


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





阅读(1539) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~