本文档与站点安全有关，由本人根据实际工作经验编写而成;这里只是一个初稿，以后有时间我会更新它。站点服务器通常指托管在IDC的服务器，如果你有服务器托管在IDC那里，就不得不对它们的安全予以关注。如果你是网络程序员或系统管理员，本文或许会对你有所帮助，如果你是专业安全管理员，那么看一下本文也无妨。
站点安全应该包括几部分：物理安全、网络安全、系统安全以及安全管理，下面从这几方面予以阐述。
一. 物理安全
服务器运行的物理安全环境是很重要的，很多人忽略了这点。物理环境主要是指服务器托管机房的设施状况，包括通风系统、电源系统、防雷防火系统以及机房的温度、湿度条件等。这些因素会影响到服务器的寿命和所有数据的安全。我不想在这里讨论这些因素，因为在选择IDC时你自己会作出决策。
在这里着重强调的是，有些机房提供专门的机柜存放服务器，而有些机房只提供机架。所谓机柜，就是类似于家里的橱柜那样的铁柜子，前后有门，里面有放服务器的拖架和电源、风扇等，服务器放进去后即把门锁上，只有机房的管理人员才有钥匙打开。而机架就是一个个铁架子，开放式的，服务器上架时只要把它插到拖架里去即可。这两种环境对服务器的物理安全来说有着很大差别，显而易见，放在机柜里的服务器要安全得多。
如果你的服务器放在开放式机架上，那就意味着，任何人都可以接触到这些服务器。别人如果能轻松接触到你的硬件，还有什么安全性可言？以下是几个不安全的事例：
很多Windows服务器采用终端服务进行管理，在一个机架式的机房里，你可以随便把显示器接在哪台服务器上。如果你碰巧遇到某台机器的管理员或使用者正通过终端使用这台机器，那么他的操作你可以一览无余。甚至，你可以把键盘接上去，把他kill off，然后完全控制这台机器。当然，这种事情比较少见，但不意味着不可发生。
另外，很多Unix系统的管理员在离开机房时，没有把root或其他帐号的shell从键盘退出，这样你只要把键盘和显示器接上去，就完全可以获取这个shell的权限。这可比远程攻击获取系统权限容易得太多。我有次在机房时想要一个unix shell临时使用一下，于是我把显示器在旁边机架的几台服务器上接了一下，很快就发现一个没有退出的root shell，我把键盘接上去，做完我自己的事后，帮他退出了这个shell。如果我是一个不安好心的人，我完全可以在他的服务器里不带任何痕迹的安装一个(RootKit)。
某天我看到一个公司的维护人员在机房调试专线时，怀疑是协议转换仪有问题，于是他毫不犹豫的把旁边一个机架上的协议转换仪拔下来，接到他自己的专线上用于调试。被破坏的服务器数据传输会中断几分钟，这对某些公司可能是致命的，而他们的服务器管理人员可能到死也查不出原因!
还有，用一张光盘引导Linux系统，你可以毫无障碍的重新获取主机的root权限;你可以无意中碰动别人的电源，等等，不在这里赘述。所有这些是要说明一点，放在开放机架上的服务器是不安全的。如果你的服务器硬件可以让其他人轻易接触，那么不出事是你的幸运，出事了你也找不到原因或找不到责任人。
而放在密封式机柜里的服务器会安全很多，一般情况下，你的所有服务器放在一起(同一个机柜或者几个机柜)是明智之举，机柜里不要有其他公司的服务器。如果你的服务器只有有限的几台，那么放在机柜里也会安全很多。因为不是任何人都可以打开机柜接触到你的硬件，就算同一个机柜的其他公司的服务器的维护人员有这个机会，但风险也要小得多。而且，就算出事了，你也可以追查到责任人。
有一次我们的服务器因为电源断掉，而中断几个小时，我们根据系统日志很快判断出服务器的down机情况，在追查责任时，我首先想到是IDC机房的维护人员的责任，因为在我们那个机柜里没有其他公司的服务器，别人不会接触到那里面的电源。后来经查实，果然是该IDC的电工在弄电时不小心把我们的服务器电源断掉，他们向我们出具了道歉声明。而如果在一个开放式机架的机房里，碰到这样的情况你无从查起。
如果你的服务器只能放在开放式机架的机房，那么你可以这样做：
1)将电源用胶带绑定在插槽上，这样避免别人无意中碰动你的电源;
2)安装完系统后，重启服务器，在重启的过程中把键盘和鼠标拔掉，这样在系统启动后，普通的键盘和鼠标接上去以后不会起作用(USB鼠标键盘除外)
3)跟机房值班人员搞好关系，不要得罪机房里其他公司的维护人员。这样做后，你的服务器至少会安全一些。
二. 网络安全
网络安全是指你机房的服务器要有合理的安全拓扑结构。安全的网络环境会让你的系统管理任务轻松很多，否则你会时刻提心吊胆。例如，如果你的服务器直接面对，那么你的麻烦就来了。因此，在服务器的前面，至少要有网络屏蔽设施，或称为。
从头部署新的防火墙策略是一件复杂的事情，你要综合考虑许多方面。一般来说，防火墙有两种工作模式，称为路由模式和透明模式，在路由模式下，防火墙就象一 个，能进行数据包的路由。不同的是，它能识别网络第四层协议(即传输层)的信息，因此它能基于TCP/UDP端口来进行过滤。在该模式下，防火墙本 身要配备两个或多个网络地址，你的网络结构会被改变。在透明模式下，防火墙更象一个网桥，它不干涉网络结构，从拓扑中看来，它似乎是不存在的(因此称为透 明)。但是，透明模式的防火墙同样具备数据包过滤的功能。透明模式的防火墙不具备IP地址。这两种模式的防火墙都提供网络访问控制功能，例如你可以在防火 墙上设置，过滤掉来自因特网的对服务器的NFS端口的访问请求。
在网络中使用哪种工作模式的防火墙取决于你的网络环境。一般来说，如果你的服务器使用真实IP地址(该地址一般是IDC分配给你的)，会选择防火墙的透明 模式。因为在该模式下，你的服务器看起来象直接面对互联网一样，所有对服务器的访问请求都直接到达服务器。当然，在数据包到达服务器之前会经过防火墙的检 测，不符合规则的数据包会被丢弃掉(从服务器编程的角度看，它不会觉察到数据包实际已被处理过)。
实际上为了安全起见，很多服务器都采用私有IP地址(例如172.16.0.0/16和192.168.0.0/24都属于私有IP地址)，如 果这些服务器不必对外提供服务，那么就最安全不过了，如果要对外提供服务，就有必要通过防火墙的NAT(网络地址转换)来满足来自因特网的访问要求。 NAT是防火墙的一项功能，它实际上工作在路由模式下。大多数防火墙都会区分所谓的正向NAT和反向NAT，所谓正向NAT就是指从内网出去的数据包，在 经过防火墙后，包头会被改写，源IP被改写成防火墙上绑定的IP地址(或地址池，肯定是公网真实IP)，源端口也会有所改变，回来的数据包经过同样处理， 这样就保证内网具有私有IP的主机能够与因特网进行通信。在反向NAT的实现中，会将服务器的公网IP绑定在出口处的防火墙上，服务器只会使用一个私有 IP，防火墙会在它的公网IP和这个私有IP之间建立一个映射，当外网对这台服务器的请求到达防火墙时，防火墙会把它转发给该服务器。当然，在转发之前， 会先匹配防火墙规则集，不符合规则的数据包将被丢弃。
使用反向NAT，会大大提高服务器的安全性。因为任何用户的访问都不是直接面对服务器，而是先要经过防火墙才被转交。而且，服务器使用私有IP地址，这总 比使用真实地址要安全。在抗拒绝服务攻击上，这种方式的成效更显然。但是，相对于透明模式的防火墙，采用反向NAT方式的防火墙会影响网络速度。如果你的 站点访问流量超大，那么就不要使用该种方式。值得一提的是，的PIX在NAT的处理上性能异常卓越。
另外一种情况是，服务器使用真实IP地址，防火墙配置成路由模式，不使用它的NAT功能。这种情况虽然可以实现，但会使你的网络结构变得很复杂，似乎也不会带来效益的提高。
大多数IDC的机房不提供防火墙服务，你需要自己购买和配置使用防火墙。你完全可以按透明模式或NAT模式来配置，具体怎么配取决于你的实际情况。有些IDC公司会提供防火墙服务，作为他们吸引客户的一个手段。一般来说，他们的防火墙服务会收费。
如果你的在IDC提供的公共后面，那么就有必要仔细考虑你的内网结构了。如果IDC提供给你的防火墙使用透明模式，也即是你的服务器全部使用 真实IP地址，在这种情况下，除非你的服务器数量足够多(象我们在北京有500多台)，那么在你的逻辑网段里肯定还有其他公司的主机存在。这样，虽然有防 火墙，你的系统管理任务也不会轻松多少，因为你要受到同一网段里其他公司主机的威胁。例如，你的服务器的IP地址段是211.139.130.0/24， 你使用了其中的几个地址，那么在这个网段里还会有200多台其他公司的主机，它们与你的主机同处于一个防火墙之后，虽然防火墙可以屏蔽来自因特网的某些访 问，然而，内部这些主机之间的相互访问却没有任何屏蔽措施。于是，其他公司不怀好意的人可以通过他们的主机来攻击你。或者，网络中一台主机被，则 所有服务器都会面临严重威胁。在这样的网络中，你不要运行、Sendmail、BIND这样的危险服务。
这种问题的解决方法是自己购买防火墙，并配置使用透明模式，不要使用公用防火墙的透明模式。
有的IDC公司会给你提供NAT方式的防火墙，你需要在服务器上设置私有IP地址，然后由防火墙来给服务器做地址转换。这种情况与上述情况存在同样的问 题，那就是，在你的服务器所在的逻辑网段里还有其他公司的主机。例如在172.16.16.0/24这个网段可容纳254台主机，你的服务器使用了其中的 几个 IP，那么可能还有200多台其他公司的主机与你的服务器在同一个网段里。这样，虽然对外有防火墙保护，但无法防范来自内网的攻击。
要解决这个问题，你不必自己购买防火墙。既然私有IP是可以任意分配的，那么你可以向IDC单独要一个网段，例如172.16.19.0/24网段，把你的服务器都放在这个网段里，其中不要有其他公司的主机。这样一来，你的内网也无懈可击了。
实际上，如果你有一个大的UNIX主机的网络，那么没必要让每台主机都在防火墙上打开登陆端口。你可以特别设置一台或两台主机做为登陆入口，对其他主机的 访问都必须使用入口主机作为跳板。这样做牺牲了使用的方便性，但带来更强的安全性。当然，前提是你必须管理好入口主机。有一种电子令牌卡适合这种应用，它 是一张随身携带的卡，每隔一段时间(这个时间通常很小，几分钟或者几十秒)动态产生一个口令，你只有使用这个口令才能登陆主机，并且该口令很快就会失效。
不仅是UNIX主机，对Windows主机的终端管理也可以采用这种跳板的方式。但Windows的终端比UNIX的shell要麻烦得多，如果你不愿牺牲太多的方便性，那么就不要这样做。
三. 系统安全
系统安全是站点安全的主要部分。如果你的系统存在明显漏洞，那么再好的物理环境和网络环境也保不了你。一个很明显的问题是，如果你的存在安全漏洞，你在没有将其修补的情况下对外提供服务，那么不管你的防火墙有多坚固，也会很快被入侵。因此，系统管理员在保证系统功能稳定的同时，不得不花时间来研究系统的安全问题。
我所接触的服务器主要有Windows2000 Server、Freebsd、和Solaris。第一种是的产品，方便好用，但是，你必须要不断的patch它。Freebsd是一种优雅的，它简洁的内核和优异的性能让人感动。Linux和Freebsd一样，是免费的操作系统，它们都广泛使用GNU(一个伟大的组织)的实用工具集，Linux容易上手，但不如Freebsd简洁。Solaris是的商用操作系统，关于SUN的文章在网上被贴得到处都是，但遗憾的是，它看起来并不快，而且，你也要经常对它打补丁。
关于这几种操作系统的安全，每种都可以写一本书。我不会在这里对它们进行详细描述，只讲一些系统初始化安全配置。
1. Windows2000 Server的初始安全配置
Windows 的服务器在运行时，都会打开一些端口，如135、139、445等。这些端口用于Windows本身的功能需要，冒失的关闭它们会影响到Windows的功能。然而，正是因为这些端口的存在，给Windows服务器带来诸多的安全风险。远程攻击者可以利用这些开放端口来广泛的收集目标主机信息，包括操作系统版本、域SID、域用户名、主机SID、主机用户名、帐号信息、网络共享信息、网络时间信息、Netbios名字、信息等，并可用来枚举帐号和口令。今年8月份和9月份，微软先后发布了两个基于135端口的RPC DCOM漏洞的安全公告，分别是MS03-026和MS03-039，该漏洞风险级别高，攻击者可以利用它来获取系统权限。而类似于这样的漏洞在微软的操作系统中经常存在。
解决这类问题的通用方法是打补丁，微软有保持用户补丁更新的良好习惯，并且它的Windows2000 SP4安装后可通过Windows Update来自动升级系统补丁。另外，在防火墙上明确屏蔽来自因特网的对135-139和445、593端口的访问也是明智之举。
的服务也容易被攻击，今年3月份盛行的SQL即使得多家公司损失惨重，因此，如果安装了微软的SQL Server，有必要做这些事：1)更新数据库补丁;2)更改数据库的默认服务端口(1433);3)在防火墙上屏蔽数据库服务端口;4)保证sa口令非空。
另外，在Windows服务器上安装是绝对必须的，并且要经常更新库，定期运行杀毒软件查杀病毒。
不要运行不必要的服务，尤其是，如果不需要它，就根本不要安装。IIS历来存在众多问题，有几点在配置时值得注意：1)操作系统补丁版本不得低于SP3;2)不要在默认路径运行WEB(默认是c:\inetpub\wwwroot);3)以下ISAPI应用程序扩展可被删掉：.ida .idq .idc .shtm .shtml .printer。
2. Freebsd的初始安全配置
Freebsd在设计之初就考虑了安全问题，在初次安装完成后，它基本只打开了22()和25(Sendmail)端口，然而，即使是Sendmail也应该把它关闭(因为历史上Sendmail 存在诸多安全问题)。方式是编辑/etc/rc.conf文件，改动和增加如下四句：
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
这样就禁止了Sendmail的功能，除非你的服务器处于一个安全的内网(例如在防火墙之后并且网段中无其他公司主机)，否则不要打开Sendmail。
禁止网络日志：在/etc/rc.conf中保证有如下行：
syslogd_flags="-ss"
这样做禁止了来自远程主机的日志记录并关闭514端口，但仍允许记录本机日志。
禁止NFS服务：在/etc/rc.conf中有如下几行：
nfs_server_enable="NO"
nfs_client_enable="NO"
portmap_enable="NO"
该脚本只是判断MS、MS终端服务和Pcanywhere服务是否正常，如果不正常，就向管理员发送邮件报警。如果你需要检查其他的服务端口，修改该脚本即可。
你也可以配置任务来定期执行该脚本，不过请注意，Nmap扫描会影响网络，因此检测的时间间距不要太小。当然，在Unix系统下，有好些方法可以判断目标系统的开放端口状况，但使用Nmap扫描看起来也不错。
4.3 日志管理
不管是Windows系统还是Unix系统，都有自己的事件日志。在Windows下使用事件查看器可以清楚的了解系统运行的各项状态，它包括应用程序日志、安全日志和系统日志。你应经常阅读这些日志，尤其是一些红色标记的错误信息。根据这些错误提示发现问题和解决问题是Windows系统管理员应做的事。
如果不加入域，那么一般来说系统错误信息很少;如果在的服务器组成一个域，那么从日志里可能会经常看到各种错误提示，尤其是在域控制器有问题的时候。管理好一个域不是一件太容易的事，它凭空给系统管理员增加很多困难。如果你真碰到这样的问题，建议你到上面去查找答案，一般来说，你碰到的问题别人肯定也遇见过了，因特网上有很多热心的人愿意解答困难者的问题(尤其是国外的技术站点)。
读Windows的日志不浪费你太多精神，因为它都分门别类整理得很清楚，有什么错误能一目了然的看出来。每天快速翻一下它的日志是可行的，如果你的服务器有坏道，也能从日志里体现出来，为你及早更换磁盘、避免数据灾难赢得了时间。
在 Unix系统下，读日志要费劲一些，因为Unix系统通常把一些通用的日志信息写到messages文件里，导致这个文件里杂七杂八什么都有，包括应用程序信息、用户验证信息、网络连接信息、内核信息等等，在浏览它们时比较费劲。然而，这不意味着你可以不管它们。实际上，日志文件是系统侦错时的唯一依据。某天你的Unix系统崩溃了，在居丧之余，不要忘了去分析它的日志，或许可以为你找到原因。
在Unix系统下，有一个日志分析软件叫 Swatch，它能很好的帮你裁减和分析日志，减轻系统管理员的负担。关于它的安装和使用我不在这里详叙，因为我自己并没有使用它。我自己编写脚本用于查看日志，使用awk语句照样能将日志文件裁减到合理的程度。这个脚本的样式我不在这里描述，因为不同的系统和网络环境所产生的条件并不一样。
在UNIX系统下，另外一个日志文件也很值得关注，它记载了用户的登陆和验证信息，该文件一般位于/var/log下，名为authlog或者auth.log，只有root才可以对它进行读写。
如果系统中安装了Apache，那么经常查看Apache的错误日志和访问日志也值得推荐。从这两个日志里，你可以发现很多有趣信息，因特网上对WEB站点的攻击从来没有终止过(从这里也可以找到大量试图攻击的信息)。
4.4 用户管理
用户管理通常是指系统的用户帐户管理，不管是UNIX系统还是Windows系统，帐户安全是系统安全的关键。系统中应保持固定数量的用户帐户，作为系统管理员，应清楚每一个帐户的使用者和用途。用户新申请帐户应该有个流程，规范的管理总比不规范好。
在 Unix系统上，大多数系统帐户平时是没什么用的，包括：bin daemon adm lp mail news uucp operator games gopher rpc等，如果你不把它们删除，那么也不要让它们拥有真正的shell，检查/etc/passwd文件，看看这些帐户的最后一个域(shell)是否被置/sbin/nologin或/bin/false。经常检查帐户的权限，普通帐户不应该在root组(gid=0)，更不应拥有root权限(uid=0)。可以写一个脚本来替你检查，如下所示：
#!/bin/sh
# script name:checkuser
# check if there is any user who have real shell or have root id/gid
FILE=/etc/passwd
NUM=0
while read LINE
do
NUM=`expr $NUM + 1`
if [ $NUM -lt 3 ];then
continue
fi
USER=`echo $LINE |cut -d: -f1`
USER_SHELL=`echo $LINE |cut -d: -f7`
USER_UID=`echo $LINE |cut -d: -f3`
USER_GID=`echo $LINE |cut -d: -f4`
if [ "$USER_SHELL" != "/sbin/nologin" ];then
echo -e "\n$USER has one real shell:$USER_SHELL"
fi
if [ $USER_UID -eq 0 ];then
echo "$USER has the root uid(uid 0)"
fi
if [ $USER_GID -eq 0 ];then
echo "$USER has the root gid(gid 0)"
fi
done <$FILE
这个脚本运行在Freebsd下，Freebsd的/etc/passwd文件前两行是版本说明，所以在程序里把它跳过，从第三行起挨个检查用户帐号，它将每一个拥有真正shell或者拥有root用户ID或组ID的帐号在屏幕上打印出来。
同样，在Windows服务器上，如果不运行IIS服务，那么把IIS相关的帐号禁止掉，把终端服务帐号禁止掉，把guest帐号禁止掉。Windows系统的管理员组除了Administrator外不要有其他帐号，甚至应该把Administrator帐号改名。每一个帐号在帐号描述里说明它的用途。如果Windows服务器采用域的方式，那么应确保域中有尽可能少的用户。一般域中两个用户就够了，一个Administrators组的用户，一个普通用户。请记住，域的Administrators组的用户(通常是administrator)对你的每一台加入域的服务器都有生死控制权，所以你应绝对保证这个帐户的安全。
不管是系统的root密码还是普通用户密码，都应定期更改。我一般每两个月更改一次系统root密码。当然，如发现系统有被迹象，应马上更改密码。对于用户密码，不管在什么系统中，都可以设置密码过期期限，用户使用一段时间后必须更改密码。有的用户安全意识并不强烈，他们使用自己容易记住的词汇作为口令，例如自己的英文名或者生日。这些都容易被猜测，你可以使用工具破解这些简单口令。Unix下的John和Windows 下的LC3都是非常好的密码破解工具，在系统上运行它们几分钟就可以破解出一堆弱口令。口令过于简单的用户，一定要强制他们更改口令，否则后患无穷。如果用户拒绝更改口令，那就删除他们，我就做过这样的事。
4.5 安全巡检
最后要讲的是安全巡检，有时间就跑到机房看看去吧，看看服务器运行的环境，检查一下电源和网线，摸摸机表的温度，跟机房的值班人员聊聊天，都对你有好处。一般来说，就算服务器正常运行，每月也应去机房两次。当然，来去打车的费用，希望你的公司给你报销。