Web服务器的安全和攻击防范 - 安全配制安全防线 - 安全技术

　　与这种错误经常相伴的是，为了进行维护而运行某些不安全的、可用于窃取信息的协议。例如，有些Web服务器常常为了收集订单而提供POP3服务，或者为了上载新的页面内容而提供FTP服务甚至数据库服务。在某些地方这些协议可能提供安全认证（比如APOP）甚至安全传输（比如POP或者FTP的SSL版本），但更多的时候，人们使用的是这些协议的非安全版本。有些协议，比如msql数据库服务，则几乎没有提供任何验证机制。

　　从公司外面访问自己的网络，完整地检测、模拟攻击自己的网站看看会发生些什么，这对于Web管理者来说是一个很好的建议。有些服务在机器安装之后的默认配置中已经启动，或者由于安装以及初始设置的需要而启动了某些服务，这些服务可能还没有正确地关闭。例如，有些系统提供的Web服务器会在非标准的端口上提供编程示范以及系统手册，它们往往包含错误的程序代码并成为安全隐患所在。正式运行的、可从Internet访问的Web服务器不应该运行这些服务，请务必关闭这些服务。

　　另外一种攻击者经常利用的资源是SNMP协议（简单网络管理协议，Simple Network Management Protocol)。它可能为攻击者提供有关系统和网络布局的极其详细和宝贵的信息。由于SNMP是一种UDP服务，比较简单的安全检查不会发现它。

　　当然，需要保护的不仅仅是Web服务器，在防火墙外面的所有其他机器更必须遵从同样的安全标准。

nmap可以从http://www.insecure.org/nmap/获得。

# nmap -sS -T Agressive -p 1-10000 www.example.server | grep open

Port State Protocol Service

21 open tcp ftp

22 open tcp ssh

25 open tcp smtp

80 open tcp http

111 open tcp sunrpc

119 open tcp nntp

3306 open tcp mysql

4333 open tcp msql

　　 www.example.server作为WWW和FTP服务器使用。此外，该服务器还提供了ssh、smtp、sunrpc、nntp、mysql和msql服务。

　　在这些服务中，ssh是一种带有完善加密和认证机制的协议，如果服务器上运行的ssh是最新版本，那么使用它应该是安全的。

　　 http、ftp、smtp和nntp是www.example.server服务器实际提供的服务，这些服务是必须运行的。只要FTP只用于匿名服务，网络上也不会因此出现以明文形式传送的密码。所有其他文件传输都应该用scp工具和ssh协议完成。

　　 sunrpc、mysql和msql服务没有必要从防火墙外面的机器访问，而且也没有必要被所有的IP地址访问。这些端口应该用防火墙或者包过滤器阻隔。

　　对于所有向公众开放的服务，你应该密切关注其程序的最新版本和安全信息，应该做好一旦发现与这些程序有关的安全问题就立即升级软件的准备。例如，某些版本的ssh会出现问题，在一些特殊的情形下服务器可能被骗并以非加密方式运行。对于有些FTP服务器、早期的sendmail以及某些版本的INN，已知的安全问题包括缓存溢出等。

　　有些时候端口扫描程序找到了一个打开的端口，但我们却不知道哪一个程序在操作这个端口，此时就要使用lsof之类的工具了。执行命令“lsof -P -n -i”即可显示出所有本地打开的端口以及操作这些端口的程序。

# lsof -P -n -i

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

xfstt 46 root 4u IPv4 30 TCP *:7100 (LISTEN)

httpd 199 root 19u IPv4 99 TCP 192.168.1.12:80 (LISTEN)

...

smbd 11741 root 5u IPv4 28694 UDP 127.0.0.1:1180

smbd 11741 root 6u IPv4 28689

TCP 192.168.1.3:139-< 192.168.1.2:1044 (ESTABLISHED)

　　增加额外的参数就可以扫描指定的协议和端口：

# lsof -P -n -i tcp:139

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

smbd 276 root 5u IPv4 175 TCP *:139 (LISTEN)

smbd 11741 root 6u IPv4 28689

TCP 192.168.1.3:139-< 192.168.1.2:1044 (ESTABLISHED)

运行nmap搜索整个网络可以列出域之内所有已知服务器。另外，你还可以查看DNS，看看服务器管理员为这个域所设置的内容。

　　再使用前面的example.server域：

# nslookup

< set type=ns

< www.example.server.

Server: ns.provider.net

Address: 10.4.3.1

example.server

origin = ns.example.server

mail addr = postmaster.ns.example.server

serial = 2000032201

refresh = 10800 (3H)

retry = 3600 (1H)

expire = 604800 (1W)

minimum ttl = 86400 (1D)

< server ns.example.server

Default Server: ns.example.server

Address: 192.168.129.37

< ls example.server.

[ns.example.server]

$ORIGIN example.server.

@ 1D IN A 192.168.240.131

wwwtest 1D IN A 192.168.240.135

news 1D IN A 192.168.240.136

localhost 1D IN A 127.0.0.1

listserv 1D IN A 192.168.240.136

...

igate 1D IN A 192.168.129.34

　　命令“set type=ns”（名称服务器）告诉nslookup只查找域的名称服务器信息，因此本例查询“www.example.server”将返回该主机的所有名称服务器。这里的查找结果只有一个服务器“ns.example.server”。

　　接下来我们用命令“server ns.example.server”把所有以后的查询直接定向到该服务器。然后，我们用“ls example.server”命令查询该服务器要求列出“example.server”区域的完整清单，结果就看到了example.server管理员所设定的所有主机名字和IP地址列表。

　　如果一个域有多个名称服务器，尝试查询所有的名称服务器往往是值得的，这是因为虽然主名称服务器往往有安全保护，其他名称服务器却往往没有，很容易从这些服务器得到域主机和IP地址信息。

　　注重安全的网络管理员总是在另外的机器上运行内部DNS服务，而不是在直接接入Internet的机器上运行。没有必要告诉整个世界自己的办公室内运行着哪些机器、这些机器怎样命名。把直接服务于Web网站的机器名字和地址发布出去已经完全足够了。

　　使用gnome程序Cheops（http://www.marko.net/cheops）可以生成一个网络示意图，清楚地显示出机器类型和连接。另外这个程序也可以进行端口扫描，但功能不如nmap灵活和强大。

　　使用网络监测器Ethereal（http://ethereal.zing.org/）可以分析网络传输。Ethereal能够跟踪TCP流，对于获知由telnet、ftp、pop3等协议传输的明文密码很有用。

　　使用rpcinfo和showmount（对于Linux的某些版本，还可以使用kshowmount），你可以查询自己机器的sunrpc提供了哪些服务。如果NFS正在运行，就有可能从服务器获得已导出文件系统的清单。

# rpcinfo -p www.example.server

program vers proto port

100000 4 tcp 111 portmapper

100000 3 tcp 111 portmapper

100000 2 tcp 111 portmapper

100000 4 udp 111 portmapper

100000 3 udp 111 portmapper

100000 2 udp 111 portmapper

可以看到，www.example.server的sunrpc服务开放了对外部机器的连接。这是没有必要的，我们可以安装带有访问控制的rpcbind程序或者配置防火墙阻断它。

　　由于NFS默认值极不合理，把文件系统完全不受保护地以可读写方式显露给外界就成了一种极为常见的错误。下面是一个实例：

# /usr/sbin/kshowmount -e center2.sample-university.net

Export list for center2.sample-university.net:

/usr/lib/cobol (everyone)

/usr/sys/inst.images (everyone)

/stadtinf (everyone)

/var/spool/mail (everyone)

/usr/lpp/info (everyone)

/usr/local (everyone)

/pd-software (everyone)

/u1 (everyone)

/user (everyone)

/fix (everyone)

/u (everyone)

/ora rzws01

/install (everyone)

/ora-client 192.168.15.20

　　所有注明了“everyone”的目录都是向公众开放的，其中包括：保存了数百个用户邮件的“/var/spool/mail”目录，以及用户的主目录“/u”和“/u1”。另外“/usr/local”和“/usr/lib/cobol”也是允许写入的，这使得它很容易被安装上特洛伊木马。任何人都可以进入这个系统，且不会遇到什么值得一提的阻力。我们要讨论的第二类安全问题涉及到服务器公用目录下的私有数据。许多Web空间提供商提供的只有“Web空间”，它们会把用户FTP目录的根映射到Web服务器的根。也就是说，用户可以通过FTP以“/”访问服务器目录“/home/www/servers/www.customer.com/”，同时任何人可以通过URL“http://www.customer.com/”访问它，用FTP方式保存的“/password”文件可以通过URL“http://www.customer.com/password”访问。如果用户Web应用需要保存一些私有的、不能从Web访问的数据，则根本无法找到满足要求的位置。

　　许多Web商店把订单日志和调试输出写入一个或多个日志文件，或者用配置文件来保存密码和商品数据。如果这些数据保存到页面文档根目录之下，那么它们就有相应的URL而且可以通过Web访问。此时攻击者所要做的只是猜出这些文件的名字。只要了解了20种主流在线商店系统的默认设置并正确地识别出目标网站所用的系统，要猜出这些文件名字是相当简单的。

　　如果Web服务器既提供私有数据存储又提供公用页面目录，上述问题就不会再出现。例如在这些方案中，FTP根目录“/”映射到“/home/www/servers/www.customer.com/”，但页面文档的根目录却在它的下一级目录“/home/www/servers/www.customer.com/pages”，可以通过FTP以“/pages”形式访问。在这种目录配置下，用户可以另外创建和页面文档根目录平行的目录，然后把敏感数据放到这些目录中。由于这些目录可以通过FTP访问，但不能通过HTTP访问，所以它们是无法通过Web访问的。

　　如果系统没有采用上述根目录分离的目录结构，我们还有一种解决问题的办法，即在页面文档根目录下创建专用的私有数据存储目录，如“/shop”，然后在这个目录中创建.htaccess文件，通过.htaccess文件拒绝所有HTTP访问（适用于Apache服务器）：

$ cat /shop/.htaccess

order deny, allow

deny from all

　　该目录中的文件只能通过FTP传输，因为FTP传输忽略.htaccess文件。但与前面采用页面文档根目录之外独立目录的方法相比，这种方法的风险更多一点，因为如果服务器管理员在服务器主配置文件中意外地关闭了该目录必不可少的“AllowOverride Limit”优先权，这种保护将不再有效。

　　上述问题还有各种变化形式。如果一台机器上运行着多个客户网站，那么客户就能够欺骗机器，访问在其自己目录层次之外的路径，例如“/home/www/servers/www.customer.com”目录之外的文件。通常，只需创建各种符号链接（指向保存在用户虚拟服务器之外的文件）就有可能实现这一点。最有可能成为链接目标的是包含文件和私有密匙，这是为了获取数据库密码和其他必须保密的信息（为了让应用能够正常运行这些信息往往以明文形式保存在这类文件中）。其他可能的攻击目标还包括保存在非公用目录中的订单记录和其他有用数据。

　　把尽可能多的服务隔离运行可以部分地解决这个问题，例如用Apache suexec程序的sbox让所有的CGI在隔离的环境以客户的用户ID而不是Web服务器的用户ID运行。另外，许多服务器上运行着FTP服务，例如wu-ftpd，该服务的所有文件传输都是隔离进行的，同样也保护了善意客户的资料避免被其他人偷看。

　　然而，恶意的客户仍旧能够用CGI程序创建符号链接指向其他用户的存储区域，然后通过它自己的Web服务器查看其他人的文件，这是因为在一个运行多个网站的环境中，Web服务器无法简单地以隔离方式以及用它为之应答请求的客户的用户ID运行。管理员应该配置Web服务器以及其他文件传输程序使其不再使用符号链接。在Apache上，这可以通过关闭最顶层的“FollowSymLinks”选项实现（不要在较低的层次上把它重新打开），配置代码示例如下：

< directory / >

Options -FollowSymLinks

< /directory >

第三类常见的安全问题是CGI程序或PHP脚本的质量低下，它们信任了来源不可靠的参数，未经严格的检查就立即使用CGI参数。

　　 Web应用一般包含位于防火墙之内的和防火墙之外的两部分，防火墙之内的如本地的脚本程序、数据库、Web服务器以及本地数据文件等。由于这些部件都由管理员直接管理和控制，因此可以认为它们都是可以信任的。Web应用的其他组成部分位于防火墙之外，是不可信任的。这主要是指用户的浏览器——如果用户使用浏览器，而且没有为了更方便地控制输入Web应用的数据和发现Web应用中可能存在的问题而直接在telnet会话中输入Web请求。

　　防火墙是可信任的Intranet和不可信任的Internet之间的分界线。

　　所有来自信任分界线之外的数据未经检查就不应该进入Web应用，这包括所有传递给CGI脚本的参数，比如：GET、POST和COOKIE变量，HTTP_REFERER、HTTP_USER_AGENT和所有HTTP_*变量，以及所有其他远程生成的变量值。在CGI脚本使用所有这些变量之前，都必须对它们进行合法性检查，这种检查可以确保变量的值确实在预期的范围内。

　　例如，有些脚本在请求的HTTP_REFERER正确时就接受表单输入，这是一种常见但错误的编程习惯。脚本用这种机制来防范伪造的请求是徒劳的。毫无疑问，对于攻击者来说，掌握必需的HTTP_REFERER并将它并入请求的其余部分一起发送是轻而易举的，因此这种保护是没有用的。这种脚本的错误在于：在这类调用中必须检查的不仅仅是HTTP_REFERER值，所有其他值都必须进行检查。

　　下面这个简单的PHP程序将输出CGI参数b的值以及HTTP_REFERER的值：

kris@valiant:~/www < cat test.php

< ?php

print "The value of b is $bn";

print "The value of HTTP_REFERER is $HTTP_REFERERn";

? >

　　用telnet连接到80端口，我们能够向上述脚本提供任意的参数值b，同时还可以任意提供HTTP_REFERER值。我们把下面的几行发送到服务器：

GET /~kris/test.php?b=this+is+a+test HTTP/1.0

Host: valiant.koehntopp.de

Referer: http://www.attacker.com/die_sucker_die.html

　　下面是完整的会话过程：

kris@valiant:~/www < telnet valiant 80

Trying 193.102.57.3...

Connected to valiant.koehntopp.de.

Escape character is '^]'.

GET /~kris/test.php?b=this+is+a+test HTTP/1.0

Host: valiant.koehntopp.de

Referer: http://www.attacker.com/die_sucker_die.html

HTTP/1.1 200 OK

Date: Sat, 08 Apr 2000 06:44:02 GMT

Server: Apache/1.3.9 (Unix) (SuSE/Linux) PHP/4.0RC2-dev mod_ssl/2.4.7 OpenSSL/0.9.4

X-Powered-By: PHP/4.0RC2-dev

Connection: close

Content-Type: text/html

The value of b is this is a test

The value of HTTP_REFERER is http://www.attacker.com/die_sucker_die.html

Connection closed by foreign host.

　　注意b的值必须以URL编码格式输入。要将字符串进行URL编码，可以使用一个简单的PHP程序，例如：

kris@valiant:~/www < cat urlencode.php

#! /home/kris/bin/php -q

< ?php

print urlencode($argv[1])."n";

? >

kris@valiant:~/www < ./urlencode.php "this is a test"

this+is+a+test

　　发送HTTP POST请求只是稍微复杂一点：现在应该在这个请求中包含一个合法的Content-Type头以及正确的内容长度字节数。下面是具体过程：

kris@valiant:~/www < telnet valiant 80

Trying 193.102.57.3...

Connected to valiant.koehntopp.de.

Escape character is '^]'.

POST /~kris/test.php HTTP/1.0

Host: valiant.koehntopp.de

Referer: http://www.attacker.com/die_sucker_die.html

Content-Type: application/x-www-form-urlencoded

Content-Length: 16

b=this+is+a+test

HTTP/1.1 200 OK

Date: Sat, 08 Apr 2000 06:55:11 GMT

Server: Apache/1.3.9 (Unix) (SuSE/Linux) PHP/4.0RC2-dev

mod_ssl/2.4.7 OpenSSL/0.9.4

X-Powered-By: PHP/4.0RC2-dev

Connection: close

Content-Type: text/html

The value of b is this is a test

The value of HTTP_REFERER is

http://www.attacker.com/die_sucker_die.html

Connection closed by foreign host.

　　另外一种常见的错误是把内部应用的状态数据通过< INPUT TYPE="HIDDEN" >标记从一个页面传递到另一个页面。把内部应用的状态放到信任界限之外就如把应用的心脏挖出来放到了攻击者的面前。对于如此缺乏安全保障的应用，任何想要摧毁它的攻击者都可以轻易地引导该应用并得到任何想要的效果。应用的状态应该通过会话变量保存在服务器上，永远不应该跨越信任界限。所有的Web应用开发平台都有这种机制。例如在PHP3中，PHPLIB可用于保存会话数据，PHP4使用的是session_*()调用，ASP提供Session对象，Cold Fusion提供几种不同的会话变量。

　　 Web应用不应该把任何来自信任界线之外的数据直接保存为会话变量：会话变量是可信任的变量，不应该用来保存不可信任的数据。通常，来自外面的数据（比如表单变量的数据）应该先传入检验其合法性的函数。只有当检验函数表示表单提供的数据是安全的，才可以把表单数据复制到会话变量。Web应用应该把这种检查集中到一起进行，应用的所有其余部分永远不应该直接接触表单变量，而是应该使用经过检查且确认安全的会话数据。

　　参考：

http://www.koehntopp.de/kris/artikel/webtune/

"Webserver verstehen und tunen" (德语)

http://www.koehntopp.de/php/

"de.comp.lang.php - H‰ufig gestellte Fragen" (德语)

http://www.insecure.org/nmap/

"NMAP Port Scanner" (英语)

http://ethereal.zing.org/

"Ethereal Network Monitor" (英语)

http://www.marko.net/cheops

"Ceops Network Mapper" (英语)

http://freshmeat.net/appindex/1998/04/06/891857252.html

"lsof - list open files" (英语)

"TCP/IP Illustrated, Volume 1: The Protocols" (英语)

W. Richard Stevens

Addison-Wesley

"Hacking Exposed - Network Security Secrets & Solutions" (英语)

McClure, Scambray and Kurtz

http://phplib.netuse.de/

"A library for PHP application development" (英语)

原文出处：http://www.devshed.com/Server_Side/Administration/WebSecurityII/

【返回顶部】【打印本页】【关闭窗口】