本文将提供日志收集和分析的简要概述。具体而言，将着重于三个基本问题：日志传输、日志收集和日志分析。同样会涉及到简单的日志存储和归档。编写此文的目的在于，紧接着《法庭现场分析存留的Linux系统》的日志处理再次进一步地论述。
日志传输
~~~~~~~~~
首先，让我们看看日志传输。对于传统的UNIX日志传输机制是UDP，514端口。日志消息发送和接收有系统日志守护进程来完成。网络安全设备（不仅是基于UNIX）还经常使用UDP记录。此方法最突出的问题是什么呢？信息可以被注入，悄悄地放弃（或更换）和传送延迟。此外，也没有确认发送或加密机制。考虑到这些问题，这样就很清楚了，UDP记录对于高度安全的环境是不适合的，除非收集的资料是一个单独的网络日志。

首先，有一个可靠的系统日志传输标准。最简单的方法是登录本地并定期复制到一个SSH服务器。有一些可用的自动方式来操作，如下所示：

1. 转储日志 – logrotate
2. 压缩 – gzip
3. 应用校验和算法 – md5sum
4. 从主机复制日志到服务器 – scp
5. 再次运行md5sum并进行比较
6. 在安全的地方存储日志文件并校验（很可能已加密）

不过，这种方法最明显的缺陷就是时间延迟。不同的是基于UDP的系统日志，该日志复制方法允许日志之间的生成和安全储存以及分析。有时需要立即看到至关重要的日志文件。

有一种方法能够即时访问日志，那就是隧道。使用Netcat可以通过安全隧道UDP通过重定向syslog到TCP隧道。基本步骤如下所示：

生成日志的主机：

1. 编辑/etc/syslog.conf：

*.*  @localhost

2. 运行命令：

# nc  -l -u -p 514 | cryptcat 10.2.1.1 9999

收集日志的主机：

1. 远程接收syslog
2. 运行命令：

# cryptcat -l -p 9999 | nc -u localhost 514

另外，Stunnel的SSL封包，可应用于Cryptcat。

如果不满意临时隧道解决方案，或者需要更高的安全性（如更高的发送确认或加密日志的完整性验证），这可能是考虑syslog替代品的时候了。我们将看看两个众所周知的替代品：由BalabIT开发的syslog-ng和CORE SDI开发的msyslog。（还有第三个选择，由Darren Reed编写的nsyslog，但似乎没有积极地更新了。）它们的共同特征包括TCP通道、更多过滤功能（除了标准的严重程度和系统日志设施）和日志文件的完整支持。
msyslog

在TCP模式安装工作需要涉及到主机上的情况，如下所示：

客户端：

1. 修改/etc/syslog.conf

*.*  %tcp -a -h loghost -p 514  -m 30 -s 8192

代替

*.*  @loghost

2. 运行msyslogd -i linux -i unix，仅仅运行/etc/init.d/msyslog start即可完成。

服务器：

1. 运行msyslogd -i linux -i unix -i ‘tcp -a -p 514’，这个可以修改/etc/syslonfig/msyslog完成：
IM_LINUX=”-i linux”             # 范例：”-i linux”
IM_TCP=”-t tcp -a -p 514″       # 范例：”-i tcp accepted.host.com 514″
IM_UNIX=”-i unix”               # 范例：”-i unix”

其结果是未加密的TCP连接（可以通过tcpdump proto TCP和514端口验证，即可看到日志信息）。在syslog的收集服务器中，分布着各种日志文件，需要进行以下任务：

1. 对syslog.conf添加一行：

*.info;mail.none;authpriv.none;cron.none %peo -l -k
/etc/.var.log.authlog.key %classic  /var/log/messages

2. 停止syslog守护进程并删除日志文件

3. 运行改程序创建初始校验（使用内置的“peochk”程序）：

# peochk -g -k /etc/.var.log.authlog.key

4. 开启syslog：/etc/init.d/msyslog start
测试一下：

peochk -f /var/log/messages -k /etc/.var.log.authlog.key

看：

(0) /var/log/messages文件是完好的

如果编辑“messages”文件（例如，删除一行），然后重新测试，结果将是：

(1) /var/log/messages已损坏

msyslog的优点包括：它使用相同的/etc/syslog.conf文件作为常规系统日志，全部在UDP模式以及广泛的正则表达式支持，这在安装过程中非常有用。

最安全的设置会涉及到一个具有约束的msyslog本地主机地址（127.0.0.1）和使用了SSH RSA/DSA认证的访问控制，以及相关日志服务器的哈希完整性检查。另一个重要问题是缓冲。由于TCP提供可靠的传输（不像UDP），确保日志服务器不会出现停机状况。Msyslog提供了可配置缓冲的选项。如上述配置：“-m 30 -s 8192”重试限制和缓冲区大小。
Syslog-ng

Syslog-ng支持TCP连接、过滤信息、完整转发主机日志等等，大量文档都可用到。

为了使Syslog-ng能够工作，就必须使用一个转换工具，转换/etc/syslog.conf到syslog-ng的格式文件。命令如下所示：

# /usr/share/doc/syslog-ng-1.5.17/syslog2ng < /etc/syslog.conf > syslog-ng.conf

卓有成效，摘录如下：

# 全局选项

options { use_dns(yes);
         use_fqdn(no);
         use_time_recvd(no);
         chain_hostnames(no);
         mark(0);
         sync(0);
};

source s_local { internal();
                unix-stream(“/dev/log” keep-alive(yes) max-connections(10));
                file(“/proc/kmsg”);
};

# *.*  @czyinvicta
destination d_2 {
       tcp(“czyinvicta” port(514));
};

filter f_5 {
       level(debug…emerg);
};

log { source(s_local); filter(f_5); destination(d_2); };

这很容易遵循逻辑，即使该文件与正常的syslog不同。无论如何，亲自手工写入文件并使用高级选项需要学习一些知识。

Syslog-ng还具有更细微的访问控制能力，可以使用TCP封包来限制网络访问。该程序还可以重定向消息的实时处理自定义程序。例如，每一个日志信息发送到标准输入的“correlate.sh”脚本，添加到配置文件：

log { source(s_local); destination(d_prg); };
destination d_prg { program(“/home/bin/correlate.sh -a”); };

第一次测试是进行交互操作性测试：syslog-ng客户端成功发送UDP和TCP消息到msyslog服务器。

Syslog-ng伴随着负荷测试工具（在一个大循环中调用“/usr/bin/logger”）。但是，显然TCP传输速度比UDP慢，甚至没有加密。应当指出，这对传统的syslog的UDP传输故障模式会造成信息丢失。

总之，使用msyslog和syslog-ng执行安全性任务是一个不错的选择。然而，在详细测试前，必须部署。

 

日志收集
~~~~~~~~~~
日志收集典型的方法是有一个专门记录日志的主机对许多机器的庞大日志文件进行定期压缩并收集。

数据库日志记录将把我们带到一个新的层次。Msyslog有本地数据库（MySQL和Postgress）记录支持。要使用服务器收集日志，需要配置以下内容：

0. 安装和启用MySQL：

# /etc/init.d/mysql start

1. 创建一个数据库实例：

# echo “CREATE DATABASE msyslog;” | mysql -u root -p

2. 定义日志存储表：

# cat syslog-sql.sql | mysql msyslog

该文件如下所示：

       CREATE TABLE syslogTB (
        facility char(10),   
        priority char(10),   
        date date,           
        time time,           
        host varchar(128),   
        message  text,       
        seq  int unsigned auto_increment primary key
      );

3. 编辑数据库日志模块syslog.conf：

*.*     %mysql -s localhost -u snort -d msyslog -t syslogTB

4. 插入信息访问权限：

# echo “grant INSERT,SELECT on msyslog.* to snort@localhost;” |  mysql -u root -p

5. 重新启动msyslog：

# /etc/init.d/msyslogd start

在PHPAdmin中显示的结果如下所示：

报文队列已经在客户端中启用（上图显示的配置）。在某些情况下，如果使用TCP模式，有必要在重新启动服务器之后，再重启客户端。

其他syslog收集工具包括SQLSyslogd，可定期使用syslog守护进程。

在这里介绍了收集数据库日志以纯文本存储的几个重要优势。数据库可以被设置为接受更高价值的信息。
日志分析
~~~~~~~~~
现在让我们转向日志分析这一部分。日志分析常常被定义为在数据和日志文件中获取入侵踪迹。事实上，有很多好的软件被写入到日志分析纯文本文件。

日志分析可分为实时分析和定期分析。如“swatch”或“logsurfer”工具能够进行实时处理，“logcheck”、“logwatch”工具可进行定期分析，当然，还有许多其他的工具。

如果日志存储到数据库，使用什么技术可以分析这些呢？通过活动并建立关系，而不是运行脚本或写一个简单的（或不那么简单，如果需要的话）SQL文件来分析。

分析日志，人们可能会想运行各种SELECT查询，如下所示：

高级概述查询：

—————————————————————————————-
|  number of events                      |  select count(*) from syslogTB;              |
—————————————————————————————-
|  number of hosts that sent messages in |  select count( distinct host) from syslogTB; |
—————————————————————————————-
|  number of messages per host           |  select host, count(host) from syslogTB      |
|                                        |  group by host order by host desc;           |
—————————————————————————————-

来自于MySQL的输出：

Host	Count(host)
box1	20
box2.example.com	3147

详细报告：

—————————————————————————————
|  Search Type             |    SQL String                                             |
—————————————————————————————
|  search by hostname      |    select * from syslogTB where host like “%box1%”        |
—————————————————————————————
|  search by message text  |    select * from syslogTB where message like “%restart%”; |
—————————————————————————————
|  search by combination   |    select * from syslogTB where message like “%restart%”  |
|                               and host like “box1″;                                  |
|                          |    select * from syslogTB where message like “%restart%”  |
|                               and time like “10:51%”;                                |
—————————————————————————————

来自于MySQL的输出：

facility	priority	date	time	host	message	seq
NULL	NULL	2010-02-05	10:51:19	box2.example.com	syslogd: restart	1
NULL	NULL	2010-02-05	10:51:41	box2.example.com	syslogd: restart	3

一个人的想象力是唯一的限制，因为SQL语法非常灵活，允许执行及其复杂的查询。只要记住，查询一个装载数据库的大量信息需要一段时间（无论如何，比“grep”的纯文本文件要快）。
尾声
~~~~~~
作为尾声，我在此总结一些最好的系统记录应遵循的做法：
·使用专用记录主机
·确保严格的访问控制，在各个服务器上启用日志记录
·加密日志
·尝试登录多个模块以提高可靠性
·留意日志分区/存储的溢出
·了解存储媒介或非联网的计算机是否存在病毒

link：http://blog.sina.com.cn/s/blog_51af865b0100hekd.html

 

原创文章转载请注明：转载自 七行者博客

本文固定链接: https://www.qxzxp.com/5557.html