qdata

2006-10-07T20:31:00.000-07:00

黑客的聪明并不只是在于他们知道如何去入侵服务器，还在于他们知道如何去伪装自己的攻击。恶意的攻击者会使用多种逃避的手段来让自己不会被检测到，所以作为系统管理员，也应当了解这些手段以应付可能发生的攻击。

这篇文章的主要目的不是揭示黑客新的攻击手法，而是对那些黑客所用到的逃避检测的手法以及他们可能留下的证据做描述。这些手段的欺骗性很大，所以想检测到它们也更加的困难。

网络服务器

我们的实验环境使用两种最常用的网络服务器，Apache和微软的InternetInformationServer(IIS)。我们在RedHatLinux上运行Apache1.3.9,在WindowsNT4.0上运行IIS4.0。并且两种都采用普通和允许SSL的版本，所以我们可以对加密和未加密的服务器的攻击做测试。

16进制编码

一种最简单的将攻击伪装的手段就是修改URL请求。作为管理员,我们一般会在日志文件中查找某些字符串，或是一些普通文本的字符集。例如我们在请求中查找匹配已知漏洞的字符串。例如，我们在我们的IIS服务器中发现了如下的字符串，我们就知道有人正在查找是否有IIS中可以远程利用的MDAC漏洞：

06:45:2510.0.2.79GET/msadc/302

要知道攻击者是如何躲过这种匹配检测的，请参考以下作为恶意攻击者策略一部分的请求。要确定msadc目录是否存在，攻击者可能键入以下内容：

[root@localhost/root]#nc-n10.0.2.5580 GET/msadcHTTP/1.0

这就会产生我们以上所见的日志文件。攻击者可以将请求进行十六进制的ASCII字符编码。在以上的例子中，字符串msadc在十六进制编码以后就会变为6D73616463。你可以使用WindowsCharmap程序来快速的进行字符的ASCII到十六进制的转换。以上的HTTP请求，将字符串msadc用十六进制编码以后，就变成了：

[root@localhost]#nc-n10.0.2.5580 GET/%6D%73%61%64%63HTTP/1.0

IIS的日志文件显示：

07:10:3910.0.2.31GET/msadc/302

应当注意的是，虽然采用了十六进制编码的手段，但是所产生的日志和没有使用十六进制编码的URL产生的是一样的。所以在这个例子里，编码并没有帮助攻击者逃避检测。但是，如果我们看看看Apache的日志情况，那么就是另外一个情形了。以下列出了攻击者使用来搜索某个CGI脚本的命令，后面跟着的是使用十六进制编码以后的同样命令:

[root@localhost]#nc-n10.0.0.280 HEAD/cgi-bin/test-cgiHTTP/1.0 [root@localhost]#nc-n10.0.0.280 HEAD/%63%67%69-bin/test-%63%67%69HTTP/1.0

现在我们来查看一下access_log文件：

10.10.10.10--[18/Oct/2000:08:22:47-0700]"HEAD/cgi-bin/test-cgiHTTP/1.0"2000 10.10.10.10--[18/Oct/2000:08:23:47-0700]"HEAD/%63%67%69-bin/test-%63%67%69HTTP/1.0"2000

首先应注意到的是在这两个例子中都是200代码说明命令完成成功。但是在第二中情况中，日志中出现的是十六进制的值而不是明文的。如果我们是依赖于形式来对这种攻击进行检测的话，那么我们是不可能检测到所发生的攻击的。许多的入侵检测系统使用的格式匹配技术智能化都不高，并且有些产品不会将十六进制的URL转换过后进行匹配。但是不论所使用的入侵检测软件是否能够对十六进制的代码进行转换，所有的网络管理员都应当对这种伎俩有所了解。

代理服务器

因为对攻击者而言完全隐藏攻击行为是很难做到的，所以掩盖攻击的真实来源也就成为相当重要的课题了。如果黑客可以隐藏他的源IP地址的话，那么他就可以在不用担心被抓住的情况下进行攻击。而黑客用来隐藏他们的源IP地址的一种手段就是使用代理服务器。

代理服务器是被合法的用来从一个单一的访问点转发多种协议的。一般来说，内部用户必须通过代理服务器才能访问Internet，因此管理员就可以在代理服务器指定外部访问以及内部访问的限制策略。用户首先是和代理服务器建立连接，然后代理服务器就将连接请求转发到真正的目的地址。目的地址会记录下代理服务器的IP地址以作为请求的源地址，而不是最初发出请求的系统的IP地址。

但是不幸的是代理服务器在Internet上的放置太随意了。(可以查看Proxys-4-All来获得这些错误配置机器的列表。)这些服务器经常会存在配置错误使得Internet用户可以连接到这些代理服务器上。一旦某个Internet用户通过代理服务器连接到某个服务器上，该服务器就会将代理服务器的IP地址作为发出请求的源地址记录在日志中。而在被攻击服务器的日志中对攻击者的记录其IP地址是属于一个没有任何攻击行为的“无辜”主机的，而不是攻击者的真正地址。我们来看以下的例子。

下面的例子显示了黑客的攻击和攻击在日志中产生的相关信息。

攻击者 [root@10.1.1.1/]#nc-v10.8.8.880 HEAD/HTTP/1.0 日志文件 10.1.1.1--[18/Oct/2000:03:31:58-0700]"HEAD/HTTP/1.0"2000 在下面这种情况中，我们看到攻击者达到了同样的目的，但是这次他使用了代理服务器。攻击者 [root@10.1.1.1/]#nc-v216.234.161.8380 HEAD

2006-09-29T20:40:00.000-07:00

随着存储区域网络(SAN)的日益普及，SAN的安全问题日益受到人们的关注。为了保证SAN的高度安全性，企业必需对SAN的常见风险和攻击有通盘的了解，然后才能对症下药，最大程度抵御这些威胁，尽可能避免系统停顿及经济损失。

　　下图显示了攻击威胁对存储网络的各个可能切入点，每一个攻击点都有可能成为后续攻击的垫脚石。为了保证高度的安全保护，SAN系统管理员必须在入侵者和数据之间设置多个监测点。认识各个攻击点有助制定相应的抗击对策。就象一座城堡拥有多种抵御入侵者的武器，企业同样必须安装多个屏障来阻挡安全威胁。

　　图注：本文介绍了7个攻击的入侵点。其中一个最重要的是带外以太网与交换机或其它设备的连接。限制这个连接的访问权限是保证安全的重要环节。

　　攻击点跨越基础设施的多个层次。第1、5和6点从物理层上开始，在光缆连接到装置时发作。1到4点可能在物理连接完成后启动。如果掌握每个攻击点的具体威胁，则可以定出最有效的对策，本文将分析下列各类威胁：

　　未经授权的访问
　　欺骗 (Spoofing)
　　数据盗窃(Sniffing)

未经授权的访问

　　未经授权的访问是最为常见的安全威胁，它的成因可以是简单地接上了错误的电线，复杂者可以是将一台已被入侵的服务器连接到光纤网络上，未被授权的访问将导致其它形式的攻击，因此必须先作介绍。

　　系统管理员可在下列攻击点控制未经授权访问的入侵：

　　1. 带外管理应用程序：交换机有非光纤通道端口，例如以太网端口和串行端口，以满足管理工作的需要。通过建立一个独立于公司内联网的专用网络来管理SAN，便可以限制对以太网端口的访问。如果交换机是与企业内联网络连接的，可以使用防火墙和VPN限制对以太网端口的访问。通过控制物理访问和对使用者授权以鉴别，可以限制对串行端口(RS 232)的访问。物理访问连接以太网端口后，交换机还可以根据访问控制名单，限制访问交换机的程序，交换机也可以限制通过3号攻击点进行访问的程序或个别用户。

　　2. 带内管理应用程序：未经授权访问也可通过带内管理应用程序入侵交换机。带内管理程序将访问诸如命名服务器和光纤网络配置服务器等光纤网络服务。管理访问控制名单(MACL)控制对光纤网络的访问。

　　3. 用户到应用程序：一旦用户获得一个管理程序的物理访问权，他们需要登录到这个应用程序上。管理应用程序是根据用户的工作性质来给予不同程度的访问授权。管理应用程序需要支持访问控制名单和每个用户的角色。

　　4. 设备到设备：当两个Nx_端口在光纤网络登录之后，一个Nx_端口可以端口登录(PLOGI)到另一个Nx_端口，分区及逻辑单元屏蔽可以在这环节限制设备的访问。每一个交换机上的活动区域设置会在光纤网络上执行分区限制。存储设备将维持有关逻辑单元屏蔽的信息。

　　5. 设备对光纤网络：当一个设备(Nx_端口)连接到光纤网络(Fx_端口)，设备将发送一个F端口登录(FLOGI)指令，这一指令包括了各种端口全球名字(WWN)的参数。交换机可以批准端口在光纤网络登录或拒绝FLOGI并中止连接。交换机需要维持一个准许连接WWN的访问控制列表。真正的数据威胁发生在设备登录至光纤网络和进入攻击点4或5之后。

　　6. 交换机对交换机：当两台交换机连接时，交换链接参数（ELP）和内部链接服务（ILS）将发送类似交换机全球名字(WWN)的相关信息。一台交换机可以批准其它交换机组成一个更大的光纤网络，如果另一台交换机不被允许加入的话，则可以隔离链接。每个交换机都需维持一个授权交换机的访问控制名单(ACL)。

　　7. 存储数据：存储的数据易于受到内部攻击、来自光纤网络的未经授权访问的攻击，和基于主机的攻击。例如存储协议全都是cleartext，因此存储、备份及主机管理员能在没有访问限制及登录的情况下访问未经处理的原始存储数据。存储加密码设备提供为存储数据提供一层保护，在有些情况下提供附加的应用层身份鉴别和访问控制。

　　通过访问控制名单(ACL)控制访问只可以防止意外事故，但它不能防御那些假伪身份的攻击者。不幸的是，大多数网络盗贼能很容易地取得假冒身份。为了阻止诈骗者（盗用他人身份者）渗透入网络，那些获得授权的个体也必须经过身份鉴定。

2006-09-24T20:02:00.000-07:00

在这个步步高教程之前的文章内，我们几乎讨论的都是关于存储在FAT或者FAT32文件系统上的数据恢复。现在我们把注意力放在存放在NTFS卷上的数据。
　　因为NTFS文件系统与FAT和FAT32文件系统完全不同，数据恢复必须采用不同的方法。然而，也有例外，这篇教程的最后一部分将讨论无论任何系统格式下都能运行的最终(last ditch)恢复技术，但是现在我们要讨论的是NTFS文件系统从一个数据恢复点是如何工作的。
　　如果你用Google搜索一下NTFS数据恢复技术，你可能得到最多的链接是关于卖数据恢复产品的网站。这是因为NTFS被设计可以自己执行数据恢复，而不需要使用第三方数据恢复软件或者操作。在这个工作中有两个主要技术来实现这个功能:簇重映射(cluster remapping)和事务日志(transaction logging)。
簇重映射
　　簇重映射是通过自动方式把数据从硬盘包含坏的分区的簇上自动移动到良好的簇的技术。簇重映射的结构不用，取决于包含这个坏的扇区的卷是否是容错的，而且坏的扇区在读写过程中是否被发现。
　　让我们讨论一下在没有容错的卷上写入的操作，当数据被写入NTFS卷，操作系统在写的操作时把检查扇区做为确认进程的一部分，如果操作系统检测到一个扇区是损坏的。Windows标记整个簇都是损坏的，这样它在将来就不往这个簇上存储数据。(这是因为簇不能被再细分)数据将被存储到良好的簇内，这样不会有数据损失。
　　但是如果这个坏的扇区在读取时候被检测到，情况就不一样了。操作系统将返回一个读取错误的消息来响应被数据请求。这里有几种不同的理论关于接下来如何解决这个问题。一些资料表示，一旦这个读取错误发生，Windows把这个扇区和其中的簇标记为损坏，所以簇其中的数据将完全丢失。另外一些资料说，如果这个数据的一部分能读出来，Windows在标记这个扇区为损坏之前，把这些数据移到另一个簇。如果有读者知道关于权威地描述这个问题的微软资料，麻烦告知我(http://www.sitit.com/)。

2006-09-19T20:31:00.000-07:00

认识硬盘
首先让我们来认识一下硬盘，现在的硬盘性质和原理和老式的留声机差不多，只不过设计更精密，磁头在高速的旋转脱离了盘片而在离盘片小距离的高度上旋转，磁头发射的激光从盘片上的凸凹反射激光而产生数据信号，当我们把硬盘通电以后，磁头就开始从盘片的外边沿滑入盘片，但是在进来以前是急快的旋转脱离盘片，以后都以相同的速度惯性的在高速的旋转，所以在通电以后如果突然受到外界的干扰以后，就会旋转不平衡，在移动的时候碰到了盘片而损坏盘片！
另一种破坏硬盘盘片的情况是：也许有人会发现，上面的情况，磁头是从盘片的外边沿开始旋转，以一个高速的旋转速度悬在盘片上方一定的高度上旋转，当关闭停止时，它又会以一定的速度回到盘片的边沿上！如果说，当我们操作电脑时，如果强制关机，突然断电，那么磁头因为电压不稳定而来不及回到边沿而落到盘片上破坏了盘片上的凸凹介质，而损坏了盘片，时间久了就会破坏了数据结构，到最后而不能检测到硬盘！
数据恢复成功的优势
数据丢失的朋友如果找过数据恢复的公司，并把数据从硬盘里恢复出来，不过有很多人会发现他需要的数据已经被破坏了，而不重要的数据却能找的出来，并且还是那些WORD，EXCEL等找到了却打不开，而且坏了，这是为什么呢？
当我们把硬盘分好区，建立文件夹，保存数据，那样我们的数据位置就确定了，虽然那些分区是逻辑的，并不一定在一个盘片一个地方，但是我们保存，写，读数据时，都会找到那个地方然后把数据找出来，所以当我们写数据的时候，他会经常的到那个地方重复的扫描，时间久了，那个地方读的次数多了，就会被磁头的强激光照射而发热变形，导致数据的破坏！所以如果你经常的整块数据备份的话，那样数据保存到别的地方而能不因为硬盘损坏了而恢复不出完好的数据出来了！
数据覆盖，删除恢复原理
数据恢复的原理，很多人对数据恢复感到陌生，有些人数据丢失却很害怕，不过有时候并没有想象那么可怕，如果你能从上面一直看下来，你如果了解了硬盘的结构以后你会发现，我们的数据保存到有存储介质的盘片上，当我们保存数据的时候，就会在盘片上做凸凹不平而保存数据。如果我们删除了文件的时候，我们并没有把所有的凸凹不平的介质抹掉，而是把它的地址给抹去，而让操作系统找不到这个文件，而认为它已经消失，可以在这个地方写数据，把原来的凸凹不平的数据信息给覆盖掉了，所以数据恢复的原理是，如果没被覆盖，我们就可以用软件，突破操作系统的寻址和编址方式，重新找到那些没被覆盖的地方的数据并组成一个文件，如果几个小地方被覆盖，可以用差错效验位来纠正，如果覆盖太多，那么就每办法恢复了！所以我们提倡如果发现文件丢失，立即找数据恢复公司恢复，不要做任何操作！

2006-09-17T23:52:00.000-07:00

IT灾难恢复基础之灾难恢复五步法
公司数据灾难恢复五步操作法
在当今商业环境下，网络宕机就意味着公司将遭受巨大经济损失，而客户也会难以接受。做好灾难恢复准备的公司能够更好地维持运营、保住客户并避免长期损害。要在紧要关头进行灾难恢复，必须具备三个条件：人员、数据（包括数据处理所需的硬件和软件）和转移位置。最近Dynamic Markets公司为VERITAS所做的、对全球850多个IT 专业人员的独立调查显示：47%的公司把与潜在灾难相关的金融风险作为计算灾难恢复成本的主要标准。被调查的IT专业人员估计，恐怖主义袭击（他们认为这是公司的最大成本支出）所造成的损失和恢复的平均成本为1.15亿美元。
日前，维尔软件公司（VERITAS）宣布推出IT公司灾难恢复五步操作法。
1.联系相关人员。每个公司都需要有一种方法来迅速召集相关人员到灾难恢复现场。无需电话线或移动服务设备的通信方法，如卫星电话就是一个很好的选择。这种方法可以为不直接参与数据恢复的员工提供一条热线，使之能够获得最新信息，而您则可以集中精力完成手头的任务。
2.快速找到您的灾难恢复计划。在远离办公地点的地方（如车上、家里甚至公文包）保存灾难恢复计划副本，并将副本提供一份给您的非现场存储供应商。此次调查显示，60%以上的公司仅在某个位置保存灾难恢复计划?D?D即主要数据中心，一旦主要数据中心不能用，就会遇到麻烦。
3.联系您的供应商，寻求他们的帮助。许多公司从来没有实际施行过灾难恢复计划。事实上，此次调查显示，只有三分之一的公司实际进行过此类实施。如果您面临实际灾难恢复计划施行，请致电专家寻求援助。如果您要从磁带上恢复数据，您的非现场灾难恢复存储供应商应当把磁带送到恢复现场，以便您的备份软件供应商能够帮助恢复存档数据。
4.调用您的次级站点。许多公司订购了一种次级灾难恢复“热站点”，可以在业务中断时与其他用户共同使用。重大事故发生时，如美国东北部最近发生的大停电，热站点可以迅速替补，确保尽快电话通告灾难的发生。为了确保备用站点的可用性，许多公司配备了他们自己的次级灾难恢复数据中心。采用VERITAS公司提供的高可用性灾难恢复软件，可以将业务从受灾站点切换到次级站点，而不会中断业务，这有助于将灾难对员工、客户和合作伙伴的影响降至最低。
5.确定紧急次级站点。如果次级站点无法使用或者出现故障，就立刻想别的办法，即使其他所有措施都不能用，宾馆舞厅或会议中心配备的高带宽连接和空调设备也能够为灾难恢复提供足够的资源。

2006-09-13T23:45:00.000-07:00

我常常在想，如果数据库不用考虑数据恢复，对我们这些做数据库的人来说，日子也许将变过美好很多。
　　没有一种软件会象数据库这样，需要面对如此恶劣的环境。你需要考虑各种可能的错误和故障，例如系统断电、磁盘损坏、甚至是地震火灾。而给你的目标非常明确：不论发生何种故障，数据都不能被丢失，你可能觉得这有些小题大做，可对于许多商业应用（如银行、火车订票系统等）来说，这只不过是最基本的要求。
　　要保证每一步操作都不会丢失，既无必要，也无可能（除非你能发明一种和硬盘一样大，和内存一样快，同时断电时数据不丢失的东东）。因此同并发控制中一样，数据库同样也利用了事务的概念。事务是这样一组操作，这组操作要么都做，要么都不做（我们通常把这叫做事务的原子性）。而当你决定结束一个事务时，你可能会选择：是提交（COMMIT）这个事务，还是应该滚回（ROLLBACK）它。如果你选择提交，那么你在这个事务中所做的全部修改都会被存入数据库中，如果这个数据库系统足够强壮，它将保证：只要事务提交完成，不管今后发生何种故障，事务所做的修改都不会丢失。如果你选择滚回，那么系统将回到事务开始的状态，你在该事务中所做的所有修改都将丢失。如果在事务运行当中，系统发生了任何故障，你会期望它的结果应该和你滚回这个事务一样。
　　恢复的本质是数据的冗余，在众多的冗余手段中，日志（log）也许是我们最常使用的技术（尽管我们还有许多其它的选择，如影子页面等）。在我们对数据库进行修改之前，系统会将数据修改前的影象（前项）和你要修改的数据影象（后项）保存在日志当中。在这个过程中，有两点需要保证。一是日志必须先于它对应的修改被写入数据库，我们把这叫做先写日志（WAL）协议，这很容易理解，想象一下，如果修改被先写入数据库，而系统在日志被写入之前崩溃了，那么它将无法把该事务恢复到开始的状态。二是在事务提交之前，必须将它的日志写入数据库。否则，系统无法保证后续的故障不会丢失该事务的修改。我们将不能实现我们在前面对用户所做出的承诺。
　　我们继续上文的讨论，看看我们到底有哪些故障需要应付。
　　首先是应用故障，例如用户不小心错删了一张表，或者应用破坏了完整性约束。这种故障的恢复非常简单，对于前者，你可以显式地滚回事务（利用日志的前项），如果你不小心提交了事务，那么问题就麻烦了，系统也许只能把它当作介质故障（利用备份）来恢复了；对于后者，系统会强迫把该事务滚回。只要数据库还在运行，在系统看来，事务的滚回与其它正常操作并没有什么区别。
　　然后是进程故障，假如在系统运行时，一个client崩溃了，或者网络断了（通常服务器无法区别这两种状态）；或者服务器端的某个进程死了。这时我们恐怕得为系统配置一个监视进程，由它来定期地检查系统状态，恢复或清除失败的进程（连接），同时把对应的事务滚回。我们会希望这个监视进程是所有进程的父进程，因此假设连它也死了，我们就能把这种情况归结到后面将要讨论的系统故障。
　　接着是系统故障，假如系统因为内部错误（例如数据库或操作系统含有bug），或者发生断电。这时缓冲区里的数据全部丢失，但幸运地是磁盘上的数据还在。因此系统在重新启动（RESTART）后，首先重做所有事务的修改（利用日志的后项），这就让数据库回到了发生故障时的状态，这时再将所有在这一点上未提交的事务滚回就完事了。注意这一过程是自动完成的，你完全不需要去关心它。
　　再接着是介质故障，假如磁盘出现了坏磁道，或者整个磁盘报销了。这时上面的数据肯定已经丢失了。由于介质故障只能在你试图再次存取磁盘时被发现，而这时故障可能早已发生。因此对介质故障的恢复需要你的参与才能完成。你必须定期地备份（BACKUP）数据库，这样，当介质故障发生时，你可以先用备份重新覆盖整个数据库（RESTORE过程），然后利用日志重做从备份那点到当前的数据库的更新（ROLL-FORWARD过程），接下来的事情就和系统故障完全一样了。你可能会问，那要是日志也坏了怎么办呢？没办法，鸡生蛋、蛋生鸡，总得有个头吧。所以你最好祈祷日志不要坏，为了保证这一点，你应该对日志文件进行镜象，或者干脆用RAID。
　　除了这种恢复方式，我们还有一种叫做逻辑恢复的方式，也就是利用我们常常在用的IMPROT/EXPORT工具对数据进行备份/恢复。当然我们只把它看作是介质故障恢复的一种辅助形式（也许它更适合于恢复我们前面说的那种应用故障），因为你只能把数据恢复到你备份的那一点。
　　最后是灾难，象发火灾、被人黑了什么的，这时整个系统可能被完全破坏。你当然仍然可以对数据库进行备份，然后把备份（磁盘）放到另一个安全的地方，但这样做，备份以后数据库所做的修改可能就永久丢失了。一个更为稳妥的办法是我们在远程建立一个备份系统，所有在本地产生的日志同时也送往这个远程系统，为了防止网络发生故障，本地与远程系统之间应该同时建立几条相互独立的网络连接。这听上去好象有点超前，可实际上许多关键应用早就用上了。
　　应该明白的是，恢复毕竟是一种非常耗时的工作，特别是进行后三种故障的恢复时，数据库对用户不可用。而这对象银行这样的部门来说，损失实在太大了。因此在很多情况下，我们只把恢复看作是最后的一道防线，我们希望最好永远也别需要用到它。因此现在就出来了各种各样的容错设备，象RAID、双机系统什么的，它们会把故障发生的概率降低到一个实际上可能永不发生的程度。