本文继上篇《日志管理与分析（二）--日志系统分析与报告》，健壮的日志分析系统，依赖于所分析日志数据的完整性。该系统必须对修改和删除数据的企图有适应能力，在此基础上，它还必须对日志数据的访问进行细粒度的控制。若日志数据作为法律上的证据，说明日志数据完整性的能力，对于该数据是否被视为可接受的证据，有着很大的影响。
攻击以日志为目标的原因有很多，这里不做赘述。首先，攻击者通常不希望被抓住，因为日志数据提供了活动的证据，所以要避免这些信息被发现。而更聪明的攻击者更可能通过误导来隐藏他的痕迹，使观察者认为发生的是其他事件。除隐藏痕迹外，攻击者也可能在日志中发现对自己有用的信息，例如事务数据，或者有助于攻击其他系统的信息，如密码或者账户编号等。因此，攻击者有不被日志记录、销毁日志、修改日志的动机，也希望窥探来自各种系统的日志，以收集情报。
2.1攻击什么？
对日志记录基础设施的攻击可以在基础设施的任何一点进行：
-
源：日志消息生成的主机，攻击系统或者日志记录应用程序本身都是可行的选择。
-
传输：源和日志主机之间的网络，或者处理和存储之间的网络。
-
收集器或者收集日志的代理：收集来自各种源的日志的场所。
-
日志数据存储：存储日志信息的数据库系统，也适用于存档日志数据的任何机制，包括利用训练有素的、以备份磁带为生的人。
-
分析：完成分析的系统和分析过程本身。
-
最后，攻击者可以攻击任何日志管理都无法避免的部分，查看数据和作出决策的分析人员。
攻击本身可以用计算机威胁分析的“CIA”模型分类：CIA即：
例如，远程入侵者使用rootkit中常常发现一种简单的攻击，即删除/var/log中的任何文件。这种攻击可以通过使用加固的集中日志主机来缓解，在原始主机上的数据仍然会被删除，但是日志主机上还有可用的拷贝。
另一种简单的攻击是对源和日志主机之间的网络进行洪水攻击，造成丢包，阻止日志数据到达日志主机。
2.2对机密性的攻击
对日志数据的机密性攻击，通常与隐藏痕迹的入侵者无关，而与收集情报相关。这里所说的情报可能是关于系统和网络的信息，这种信息可以用于其他攻击，信息的收集可能本身就是攻击。即使数据本身不是敏感的，法律或者公司政策可能将该数据的曝光视为违规。
-
你正在运行的应用程序，以及运行他们的主机。日志往往显示应用程序版本，也可能包括有关应用程序配置的信息。所有这些数据可以用来寻找漏洞。
-
你在日志中可能注意到什么，这是为了确定如何避免被注意，或者为了不被记入日志。
-
有用的信息片段，如谁有访问特权，员工合适登录登。
-
偶然曝光的证书。例如：用户在提示输入用户名时不小心输入了他们的密码，直到身份认证失败之后才发觉。错误输入的密码可能会被当作用户名记入日志中的“登录失败”消息。
-
可以窃取的数据或者事务记录的位置，这可能是攻击的真正目标。
2.2.1源机密性
得到日志数据的最简单方法是访问生成这些数据的地方--消息源。过高的权限或者间接访问可能使攻击者能够阅读日志数据。下面的简单例子，日志文件可以被任何人阅读：
如果非特权用户能够读取日志文件，他们就更加容易诊断自己的问题，但是他们也可能去阅读一些不应该阅读的内容--例如系统管理员在用户名（root）的位置输入了自己的密码。
为了避免这类攻击，验证日志文件及目录的权限，必须严格限制在特权用户上。还要确保日志所有上级目录只能由特权用户写入。否则，攻击者可以重命名目录和文件，并创建他可以读取的文件。
如果有需要访问日志的用户，可创建一个单独的组并为该组提供读取权限。还应该在磁盘和分区设备上检查权限。确保任何日志轮转程序在文件上设置了合适的权限。
除了对文件的直接访问之外，如果攻击者能够修改syslog配置文件，他就可以在另一个位置建立日志的第二拷贝，或者将日志转发到另一台主机。配置文件默认情况下一般不是所有人可读的，你应该保持这种配置。实际上，很少有理由将任何常规的文件设置为所有人可读。当然，具有根权限的攻击者仍然能够修改该文件，但是这样的攻击者可以做任何事情，所以这时你所要考虑的问题比日志文件要严重很多。
有些人建议将配置文件保存在另一个位置，这样日志所在位置就不会那么明显。而且试图修改这些文件的自动化rootkit使用默认的位置，无法完成这种攻击。rootkit是一组入侵工具包，它们往往设计为自动删除痕迹并安装后门。是否耗费精力去混淆日志文件的位置，完全取决于实施人员。
2.2.2传输中的机密性
如果你打算将日志数据转发到一台集中日志主机，具有源和日志主机之间网络访问权限的攻击者，可能会拦截传输中的数据。这类攻击可以在任一端点、利用对任一主机上网络设备的访问权限，或通过两台主机之间任意网络上的嗅探来完成。拦截网络流量使用tcpdump、wireshark就可以实现。该操作不像查看日志文件那么容易，对于攻击者来说却已足够。
缓解日志数据的网络拦截问题，有各种不同的方法，它们都基于传输中日志数据的加密。syslog可靠RFC提供日志数据流的加密，如果你使用支持RFC的syslog客户端和服务器，就可运用这一功能。如果你使用了基于TCP的日志传输，流量还可以用sslwra、stunnel通过SSL隧道传输，或者使用一个SSH隧道。
注意，控制其中一个端口的攻击者可以在日志数据加密前拦截，或者拦截加密秘钥。使用公钥加密方式，可以不将私钥保存在源或者日志主机，从而缓解后一种攻击。
如果你相信自己很好的控制了客户端和日志主机间的网络，可以选择不担心日志流量的拦截问题，这取决于你自己的判断和风险分析。
2.2.3日志主机的机密性
保护源上的数据机密性所涉及的所有问题，都适用于日志主机。此外，由于日志主机一般只用于收集和检查日志数据，你可以将日志主机上的账户限制在需要访问日志数据或者管理日志主机的账户。
对于一些环境，隐藏的日志主机可能更为必要。隐藏的日志主机在网络上不可见，但是网络上的主机仍然可以向其发送日志。
2.2.4日志存储的机密性
存储日志的数据库是机密性攻击的另一个向量。保护日志主机同样也适用。此外，具有数据库用户名和密码的攻击者，可能连接到数据库并查询数据，或者拦截日志主机和数据库服务器之间传输的事务。
数据库服务器应该同日志主机一样重视，并以相同的方式保护。数据库连接应限制在日志主机和用于日志分析的系统上。这些连接需加密以避免拦截。数据库用户的访问规则应该加以限制，使得只有授权用户能够查询数据。
将日志放入数据库中有许多方法，所有数据库都支持直接网络连接，使用不同的身份认证级别。在数据库中存放日志的另一种方法是使用文件传输机制，从日志主机将数据“拉”数据库服务器，然后从本地文件中将数据加载到数据库。
大部分数据库都提供数据库访问的某些控制方法，可以通过主机和用户限制。mysql使用GRANT语句，为两种限制提供相同的机制。Postgresql有类似的访问控制，但是实现的方式不同。主机和用户的访问控制被放入文件pg_hba.conf。Oracle用另一种机制提供类似的访问权限。
“拉”方法的好处是数据库不一定要允许任何网络连接，消除了数据库的一个攻击向量。因为攻击者无法直接通过网络攻击数据库服务器。
2.2.5分析的机密性
分析系统需要日志数据的访问权限，因此也是获取日志数据访问权限以及日志分析方法相关信息的攻击点。和数据库及日志主机一样，分析工作站应该通过将访问权限限制在使用工具的人、验证文件权限和加密流量，加以保护。
2.3对完整性的攻击
对日志完整性的攻击是通过重写或者插入虚假数据、删除日志，破坏真实数据的能力。攻击者破坏数据通常是为了掩盖活动的证据。最常见的方法是删除相关的数据。更聪明的攻击者可能只删除表示其在系统上的活动的日志消息，或者简单地修改消息，使得它们看上去像是合法的，因而不会引起注意。内部攻击者甚至可能想要修改日志，以“陷害”其他人，或者让人觉得其他人犯了错误。
上述的几类攻击者都想通过插入表示其他活动发生的虚假消息，分散人们的注意力，使他们忽视攻击者的活动。例如，攻击者可能插入虚假的错误消息，使系统管理员忙于跟踪根本不存在的问题。另一种技术是显示同一网络上的另一个主机发起的虚假攻击。
如果日志数据用于提供证据，能够断定日志数据的完整性，对于日志是否被接受为证据可能有影响。攻击者如果可以说明日志不能免遭破坏，就可以声称日志是伪造的，不能作为其不法行为的证据。
2.3.1源完整性
和上面提到的机密性的问题类似，不合适的权限可能使攻击者在日志数据存储时直接修改。
例如，假定系统上的用户“aotuho”正在做坏事，不希望这些活动和他联系起来，如果aotuho能够修改存储的日志文件，他就可以用“aotoiu”替代日志中所有的“aotuho”，将对该活动的职责转嫁给他人。
可以采用和机密性中我们所讨论的相同方法验证日志数据、设备、配置文件等。
此外，将日志转发到一台集中日志主机虽然不能避免这种攻击，但是创建了另一组日志，攻击者必须修改它才能有效地隐藏自己的痕迹。多组日志和多个日志信息来源更容易检测到攻击者的活动，即使某些日志文件遭到修改也仍然如此。“黑客”被发现时往往试图提出其他人进行攻击的证据。来自多个源的日志有时候能够对此提出证明。不仅在linux上，windows系统上也可能进行类似的攻击，其他平台也会受到影响。
对于事件日志，攻击稍难一些，因为文件是二进制格式，需要一个工具来读取和写入文件，这只需要少量编程。
对日志定时的攻击可以看作对完整性的一种特殊而具破坏性的攻击。
2.3.2传输中的完整性
标准的syslog消息通过UDP传输，UDP数据包报头中的IP地址没有认证，所以没有办法知道它是否来自所声称的主机。而且syslog传输是单向的；服务器不向客户端发送任何确认。由于服务器接收的数据包被当成来自显而易见的发送者接收，具备网络访问权的攻击者可以注入看上去是从网络上合法主机发送而来的伪造syslog消息。
具有源和目标之间网段访问权限的攻击者可以使用ARP欺骗中间人攻击拦截和修改IP流量（劫持会话）。对这类基于网络的攻击，最好的防御措施是使用验证消息完整性的机制。Syslog-sign协议提供了这种机制。另一个选项是使用安全套接字层（SSL）甚至Internet协议安全（IPSEC）。
如果这些消息完整性机制在你的网络上不可行，你可以在网络边界实施合适的防欺骗过滤器，并限制日志主机接受的消息来源主机，以缓解这类攻击。
ARP欺骗可以通过强制日志主机在每个日志源上有一个条目来避免。
2.3.3日志主机的完整性
对日志主机的完整性攻击基本和源上的攻击一样，适用相同的保护技术。但是，这种攻击的影响比对单一源的攻击更大，因为日志主机收集的所有数据的完整性都收到威胁。
2.3.4数据库完整性
和数据库上的机密性攻击一样，适用类型的规则。限制数据库用户写入或者附加到日志数据空间的能力。验证网络访问保护认证证书，并且能够避免会话劫持。最佳的方法是除访问规则之外，还使用一个验证数据完整性的机制。
数据库给关健数据保护带来了两个挑战，“变动数据”和“静止数据”的处理。前者指的是到达数据库的数据，后者指的是数据库存储的数据。数据库安全是一个巨大的知识领域。
变动数据通常通过加密从应用程序到数据库的连接，或者使用“推”日志集的方法来保护。
加密连接的主要挑战在于，没有HTTPS这样的标准化机制。现在有通过SSL传输SQL命令和数据的“SQLS”，但是没有广泛应用。
保护存储在数据库中的数据的唯一可靠方法是数据库加密。
2.3.5分析的完整性
对分析完整性的攻击试图动摇对分析系统准确度的信心。对分析系统完整性攻击的三个位置：
-
处理的数据（输入）
-
用于分析的工具（系统）
-
结果的显示（输出）
通过修改输入数据，攻击者可以导致系统报告虚假的攻击，或者不报告实际的攻击。分析系统用于访问数据的方法应该有完整性保护机制。如果这种方法通过数据库，则适用于存储访问的相同规则。如果通过文件服务器，应该加固传输安全，避免会话劫持和数据流破坏。
以分析系统为目标，攻击者可以更改分析工具，使系统不能像预期那样表现。分析系统的权限应该限制为仅供授权用户使用，用于分析的软件也应该有合适的修改保护。考虑对使用软件和修改软件的用户进行权限分离。应该采用修订控制或者用其他软件跟踪对软件的变更（包括配置文件），并定期验证软件的完整性。
最后，用户显示数据的系统可能遭到篡改，以更改或者抑制显示给分析人员的数据。这可以通过篡改系统创建的报告、创建虚假报告或者在数据审核中劫持会话来实现。
输出数据的安全应该和输入数据的安全同样看待，限制有写权限和系统访问权限的人。
显示系统也应该对会话劫持免疫。例如，如果使用一个web服务器审核报告，传输应该使用SSL和合适的签名证书，以及密码控制访问。
2.4对可用性的攻击
对可用性的攻击旨在阻止合法用户访问数据和系统。如前所述，攻击者的常用技术之一是获得系统访问权限，删除日志文件。有些可用性攻击和完整性攻击非常类似，使用相同的攻击向量。其他攻击则采不同的方法，例如，导致系统崩溃，以组织访问。
2.4.1源的可用性
除了删除本地日志文件之外，可以杀死日志守护进程，有效阻止所有日志记录，包括转发日志到日志主机。Syslog当前版本对拒绝服务攻击不敏感，但是较旧的版本会受到影响。
基于TCP的syslog守护进程可能遭到SYN洪水攻击，虽然有一些试验性的技术有助于避免这种攻击，但是最简单的方法是除了所处网络之外，阻止对日志守护进行的网络访问。
此外，虽然我们都理解UDP数据包在繁忙的网络中可能丢失，但是我们注意到一个有趣的现象：这些数据包甚至在本地网络连接上也可能丢失。攻击者可以简单地用虚假流量对日志守护进程发动洪水攻击，抑制守护进程记录的消息。这样的攻击甚至可以在主机上用非特权用户进行。
对于本地洪水攻击的补救方法不多。但是，通过对系统的活动建立基线，并搜索日志消息的不寻常数量，你就能够检测到洪水攻击的发生，类似的方法还可以用来检测崩溃的日志服务器，这通过搜索来自某台主机的消息缺乏的情况来完成。
抑制本地日志记录的另一种方法是填充存储日志的磁盘分区。这可以通过填充日志来完成，攻击者也可能有其他的方法写入分区，一定要验证用户无法写入日志所在分区。
销毁日志数据的一种有趣的间接方法是利用日志轮转系统。日志轮转用户保护日志记录服务器免遭溢出，也用于组织日志文件的存档。日志轮转意味着存储旧日志文件，并将日志记录切换到一个新文件，这在Linux和windows系统上都能完成。
如果攻击者知道日志在达到特定尺寸时将被轮转，他可能会生成足以导致轮转的日志消息，删除他的活动证据。
Windows根据大小轮转日志，默认设置只保留很小的量，在日志文件满时覆盖旧条目。很容易产生更多的日志记录，以取代相关的日志消息。
违规使用轮转的缓解方法是使用足够的磁盘空间和足够大的轮转容量，这就可以在攻击者填满日志文件之前发现违规行为。
2.4.2传输中的可用性
如前所述，标准的syslog传输机制使用UDP，通常称为“不可靠”传输。网络上的高流量可能造成UDP数据包在源和日志主机之间被丢弃。攻击者可以用流量对网络进行洪水攻击，使他不希望你看到的流量被丢弃，从而隐藏痕迹。
洪水攻击并不一定要使用日志流量，甚至不需要使用针对网络真实主机的流量。攻击者躲避跟踪的好方法之一是用完全虚假的流量进行网络洪水攻击，其目标是现有主机上未用的端口，或者网络上不存在的主机，甚至另一个网络上的主机。这些流量在主机上不会显示为连接，也不会以任何其他明显的方式出现，只会在网络设备上留下利用率的统计数字。
“ping洪水”是网络洪水攻击的最简单方式之一，它很容易被忽略，Ping程序的很多版本中有一个选项（通常是“-f”），告诉程序以至少每秒100个数据包（最高为主机能够响应的速度）的速度发送数据包。对与日志主机相同网段的一个主机发动Ping洪水攻击，可能会导致发送到日志主机的数据包被丢弃，在日志主机上不会有出现问题的指示。实际上，唯一不正常的指示是路由器或者交换机上的流量计数器会显示丢包和大量的互联网控制消息协议（ICMP）流量。
网络洪水难以缓解。如何区分合法的流量和虚假的流量？如果知道网络流量的激增不是因为业务真的转好？你只能监控流量统计，搜索不寻常的事件。
2.4.3日志主机可用性
和网络洪水一样，日志主机也可能遭到洪水攻击，用虚假日志流量对日志主机进行洪水攻击有两种效果。首先，它可能造成合法的流量被网络或者日志主机的内核丢失。此外，日志数据可能填充日志文件分区，迫使日志主机停止记录任何数据。（有时候这会造成主机系统故障）
基于TCP的syslog守护进程可以避免丢包，但是可能遭受SYN洪水攻击，这种攻击可能使服务器崩溃，至少造成其拒绝接受更多连接，就像人们可以阻塞所有其他基于TCP的服务一样。与保护日志主机免遭完整性攻击的相同措施也适用于这种情况。
除此之外，日志主机和日志源一样容易遭到拒绝服务器攻击，适用相同的保护性措施。
最后，数据库和日志主机一样容易遭到类似的攻击—网络洪水、SYN洪水、使数据库崩溃的攻击，以及存储文件的删除。这里适用对完整性攻击的相同建议。
2.4.4分析的可用性
除了禁用分析系统之外，用分析数据淹没系统，可能使其陷入困境。有效的数据精简技术有助于缓解这种攻击。
对可用性进行的一种攻击很有趣且常常被忽视，这就是对分析人员可用性的攻击。攻击者可能简单地依靠执行足够的不同攻击，或者注入数据使其看起来像攻击，从而避开他们的视线。
而且，一个有太多“假报警”的分析系统很快会被认为是无用的并被放弃。这种攻击的最有名例子是警报洪水攻击工具，如stick、sneeze和snot，这些工具会造成早期入侵检测系统的问题。除了给运行入侵检测软件的系统造成压力之外，警报洪水攻击工具生成许多警报，使监控系统的人员茫然不知所措。
日志事件的收集和分析必须以某种方式组织，最大程度地降低外部人员注入伪造数据能力。通常，加密有助于解决这个问题。至少，它能够解决从源到收集点的传输中的数据伪造问题。例如，用通过SSL、SSH或者IPsec隧道的可靠syslog代替基于UDP的syslog，能够阻止攻击者在收集点注入数据。
此外，某些机制还支持源身份认证，能够阻止攻击者引入虚假的日志记录来源，用它对系统进行洪水攻击，压垮技术组件和分析人员。
若你的企业没有认真地对待日志，说明你的企业对IT可审核性不重视，这也就是日志记录成为一种完善的依从性技术，许多法规和法律以及最佳实践框架都对此作出强制性要求的原因。日志管理与分析（四）重点在于根据PCI DSS以及ISO27001标准的日志的管理规程
关注脉搏，有更多安全资讯及技术性文章在等你！
