Linux 服务器日志文件查找技巧精粹
用来在日志文件里搜索特定活动事件的工具不下几十种，本文将介绍搜索日志文件时应该采取的策略。然后，通过几个具体示例介绍一些使用grep命令手动搜索日志文件的办法。接下来，我们将看到logwatch工具和logsurfer工具的用法。最后，将看到需要自行下载和安装的工具，如swatch等。 1、查找日志文件简单方法
一般来说，系统日志文件几乎都保存在/var/子目录（该路径由syslog.conf文件定义）。如果想让所有的应用程序都把日志文件集中存放到/var/子目录下，需要依次对每一个应用程序的配置文件进行编辑。把日志集中到/var/子目录下是个很好的主意。首先，当需要查看它们、修改它们的权限或者对它们进行备份的时候，只要到一个地方就可以找到所有的日志文件。
其次，/var/子目录通常是在一个独立于根目录（/）的文件系统里，这有助于防止日志文件迅速变大并占满可用空间，避免操作系统和应用程序受到影响。可以利用find命令把你不知道的日志文件查找出来具体做法是：先切换到根目录下，然后以根用户（root）身份执行下面这条命令把最近被修改过的文件全部找出来：
find . -type f -mtime -5 �Cprint | grep -v proc | grep -v lock
2、搜索日志文件时的策略
日志文件分析工作中的第一个挑战是把异常活动从正常活动中识别出来。完成这项挑战的前提是你必须知道系统和网络上的正常活动在日志文件里是什么样子。如果没有事先积累的经验，很难知道按规律发生的事件在日志文件里的表现。熟悉正常的日志文件活动要有一个时间过程，要求大家一上来就把日志文件看明白显然不现实，这是一个需要时间积累的过程。
要知道，随着网络上的应用程序和用户的数量不断增减和变化，日志文件的内容肯定会发生相应的改变。把异常情况孤立出来之后，接下来的步骤是正确地判断这种异常情况是否属于警报条件。要想正确地做出判断，只能通过加深对公司日常活动的了解才能做到。往往需要在系统的可用性与防范风险之间把握一种平衡。
3、以手动方式搜索日志文件
grep是Unix系统上功能最强大的shell命令之一。利用grep命令在日志文件里搜索各种可疑线索是这个文本文件搜索命令的绝佳用途。grep命令的用法很简单――在命令行上输入：
grep "failed" /var/log/messages
上面这条grep命令将把/var/log/messages文件里包含单词“failed”的文本行全部找出来。在默认情况下，grep命令是大小写敏感的，你可能需要根据具体情况使用grep命令和它的“-i”选项来进行对大小写不敏感的搜索。搜索日志文件的挑战之一是你必须先知道自己想找什么东西，然后才可以把可能存在的这个东西找出来。有几种办法可以帮助解决这一问题。
如果你知道自己想找的事件或活动――比如，用户试图使用su命令切换为根用户――可以先自己进行一次这样的活动，然后去日志文件里看看它是什么样子。比如，在SUSE Linux系统上，执行失败的su命令将在日志文件里留下这样一条记录：
Apr 1 11:15:54 chim su: FAILED SU (to root) rreck on /dev/pts/1
于是，如果想把所有这类活动都查出来，应该使用下面这样的命令：
grep "FAILED SU" /var/log/messages
上面示例里的活动是黑客攻击的一种标志。如果grep命令只在日志文件里零零散散地找到了几个这样的失败事件，那很可能是有人忘记了口令字或者是打字时出现了错误。反之，如果grep命令在日志文件里找到几十个这样的失败事件，很可能是有人在试图闯入你的系统，应该立刻采取措施在网络级拒绝他们的访问。
4、使用logsurfer工具搜索日志文件
logsurfer是一个日志文件搜索工具。与swatch等日志搜索工具相比，logsurfer允许人们做出更细致的决定。与其他日志搜索程序相似，logsurfer工具也是把日志文件里的每一行与一些规则表达式进行匹配，每找到一个匹配就相应地执行某个动作，而那些动作被表达为“规则”。logsurfer工具在某些方面比swatch工具做得还要好。
首先，logsurfer工具使用两组规则表达式匹配文本行；日志文件中的文本行必须匹配第一组表达式，但不需要匹配可选的第二组表达式。这种安排在某些场合非常有用，它可以让人们方便地排除异常情况。logsurfer工具的另外一个突出优点是它可以结合上下文进行检查而不是只检查单个的文本行。这很方便，因为日志文件里的单独一行文本往往不足以包含做出某个决定所需要的信息。
要说不足，不少人认为logsurfer工具比较难以配置，因为对它进行配置必须精通规则表达式，而且它本身提供的配置示例不够多。如果想了解更多关于logsurfer工具的信息，它的man文档是最好的地方。列在表1里的细节都可以在这个工具的man文档里查到。logsurfer配置文件里的每
一行可以是以下三种情况之一：如果第一个字符是“#”，它是一个注释行；如果第一个字符是空格，它是上一行的继续；如果第一个字符既不是“#”也不是空格，它是一条新规则的开始。每条新规则由六个必要字段（第1、2、3、4、5、7字段）和一个可选字段（第6字段）组成，对这七个字段的详细解释见表1。
表1 logsurfer配置行上的各个字段
字段编号
是否是可选
字段名
字段解释
1
必要
match_regex
“字段1”被解释为一个规则表达式。如果文本行匹配“字段1”（match_regex），按后续各项定义依次处理；如果不匹配，logsurfer将用下一条规则匹配这个文本行，本规则后续各项定义不起作用
2
必要或-
not_match_regex
这个字段将被解释为一个规则表达式。用“字段1”（match_regex）匹配到的文本行只有在不匹配“字段2”（not_match_regex）的情况下才继续按后续各项定义依次处理
3
必要或-
stop_regex
如果不是减号（-）字符，本字段将被解释为一个规则表达式。如果这个表达式得到匹配，本规则将从活跃规则表里被删除
4
必要或-
not_stop_regex
如果不是减号（-）字符，本字段将被解释为一个规则表达式。只有在“字段3”（stop_regex）存在且已得到匹配和“字段4”（not_stop_regex）不匹配的情况下才删除这个规则
5
必要或0
timeout
以秒计算logsurfer规则的寿命，把“字段5”设置为0表示规则永远有效
6
可选
Continue
如果这个字段被设置为“continue”，logsurfer将继续使用下一条规则来匹配文本行；如果没有“continue”，后续的规则将全部被跳过
7
必要
Action
以下几种动作之一：ignore、exec、pipe、open、delete、report、rule
表2 logsurfer动作解释
动作名称
解释
Ignore
什么都不做，忽略被匹配到的文本行。有时候，虽然用logsurfer工具找到了一些日志文本行，但如果知道它们并不重要，可以用这个动作不让logsurfer发出警报
exec
这个动作的参数被解释为一个程序，规则得到匹配时logsurfer将调用该程序
pipe
类似于exec动作，但被调用的程序将从stdin设备读入一个日志文本行
open
增加（打开）一个新的上下文，但在匹配match_regex（“字段1”）时已经存在的上下文就不必再次打开了
Delete
如果一个现已存在的match_regex被用做这个动作的参数，指定的上下文将被关闭并删除，而且不采取“default_action”选项定义的默认动作
report
这个动作的第1个参数是一个将被调用执行的程序（及其命令行选项）。随后的参数是一些将被用做该程序的标准输入的上下文定义
Rule
这个动作将创建一条新规则。关键字“rule”的后面必须有一个告诉logsurfer按什么顺序使用新规则的指示符：before（在本规则之前使用）、behind（在本规则之后使用）、top（在本配置文件所有规则之前使用）、bottom（在本配置文件所有规则之后使用）
5、使用swatch工具搜索日志文件
swatch工具不是Red Hat Enterprise Linux发行版本的标准组成部分，但因为swatch工具很容易安装、配置和使用，所以你应该考虑下载并安装它。在开始使用它之前，还需要一个配置文件。在默认情况下，swatch工具将在启动它的那个用户的登录子目录里寻找.swatchrc文件（例如/home/rreck/.swatchrc），但你可以用“-f”选项为它另外指定一个配置文件，如下所示：
swatch �Cf /etc/.swatchrc
接下来，看看如何使用swatch工具从日志文件里发现黑客活动的踪迹以及发现之后该做些什么。
◆修改swatch配置以监测针对Apache的攻击
下面这个例子里的攻击手段是一种真实存在的攻击手段，我们来看看它会在日志文件里留下怎样的踪迹以及在发现这些踪迹后如何修改系统配置加以防御。在过去，因为mod_userdir模块（一个默认的Apache模块）的缺陷和它的默认配置，Apache的HTTP服务器经常受到攻击，攻击者可以用一种能扫描远程主机的程序获得远程主机上的某些用户账户信息。
该工具先检查是不是Apache，再检查它是不是有安防漏洞的那个版本，如果是，它将自动地使用很多常见的用户账户去试探目标系统。这种扫描非常快，根据网络连接和服务器的速度，扫描一个账户有时候不用一秒钟。扫描出来的用户信息将被黑客用来攻击FTP等其他系统服务，因为黑客已经确切地知道那些用户账户是存在的。这种攻击将在Apache的access_log日志里留下大量的事件记录。如果黑客试测的用户账户不存在，会在日志里留下404出错信息。
如果黑客试测的用户账户存在但不允许访问，会在日志里留下403出错信息。除了进入日志文件，这些出错信息还将返回到攻击者那里，这正是攻击者希望的。攻击者只对403出错信息感兴趣――导致403出错信息的账户在目标系统上是存在的，黑客可以针对这些账户发动下一步攻击。把下面几行代码添加到用swatch工具检查Apache日志文件时使用的.swatchrc文件里，就可以通过电子邮件知道哪些账户最有可能成为上述攻击手段的受害者：
#Apache403errors
watchfor/403/
echo
bell
mail
偶尔出现一条403出错信息没有关系，但如果在几秒之内连续出现许多403出错信息，就应该知道必须采取行动了。因为403出错不是一种经常发生的事情，定期进行搜索就可以。比如，如果打算安排swatch工具在每晚0点5分对Apache日志文件进行一次检查，可以在根用户的crontab文件里增加一项如下所示的计划任务：
5 0 * * * --config-file=swatchrc.apache swatch --examine-file=/var/log/httpd/access_log
最保险的做法是把swatch运行为一个守护进程或让它运行在“tail”模式下，这可以让你在事情发生的时候立刻收到swatch发来的警报。可以用下面这条命令达到这个目的：
swatch --config-file=swatchrc.apache --tail-file=/var/log/httpd/access_log
一旦确认攻击正在发生，应该立刻采取补救措施：在Apache的配置文件/etc/httpd/httpd.conf文件里增加和修改几条配置指令，然后用命令重新启动Apache守护进程。修改Apache配置文件的具体办法有两种。第一种办法是先全局禁用UserDir指令，再把需要激活的用户账户激活，如下所示：
UserDir disabled
UserDirenabled user1 user2 user3
第二种是先全局激活UserDir指令，再把不想让外界知道的用户账户禁用掉，如下所示：
UserDir enabled
UserDir disabled user4 user5 user6
◆修改swatch配置以监测针对SSH守护进程的攻击
通过扫描日志文件及时掌握系统安全状况有重要意义。日志的作用只有通过人们对日志信息的运用才能真正体现出来。在设法弄到系统上的一个用户名后，黑客就可以发动“暴力”攻击了，这是一种通过SSH服务试测几千个口令字以期获得远程系统shell访问权限的攻击手段。这种暴力攻击会在系统（Red Hat）的日志里留下记录类似下面这样：
Jun 6 13:01:56 chim sshd(pam_unix)[17331]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.1.199 user=rreck
Jun 6 13:02:01 chim sshd[17331]: Failed password for rreck from 192.168.1.199 port 33181 ssh2
Jun 6 13:02:03 chim sshd[17331]: Failed password for rreck from 192.168.1.199 port 33181 ssh2
Jun 6 13:02:03 chim sshd(pam_unix)[17331]: 2 more authentication failures; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.1.199
user=rreck
让自己尽早获知这些事情正在发生是防范这类攻击最有效的策略。为了做到这一点，需要把一段下面这样的swatch配置代码添加到系统的swatchrc文件里：
# Failed password
watchfor / Failed password for /
echo
bell
mail
此后，当swatch以cron计划任务或以“tail”模式运行时，如果在日志文件里发现这种攻击的特征，就会立刻通过电子邮件向你发出警报。这种电子邮件警报是有行动信号。根据你的具体情况，你或许需要允许rreck用户从多个主机登录。编辑/etc/ssh/sshd_config文件，下面给出的配置代码将明确地拒绝rreck用户从已发生多次试测口令字失败活动的主机进行登录，但同时允许rreck从其他主机登录：
# Prevent access for hacker even if they guess the password !
DenyUsers [email protected]
AllowUsers rreck@*
接下来，向sshd发出一个SIGHUP信号或者用下面这条命令重新启动它：
/etc/rc.d/sshd restart
当你在/var/log/messages文件里看到sshd发来的如下消息时，就可以知道你做的修改已经生效，攻击者的登录企图已经被sshd拒绝了：
Apr 1 17:42:55 linux sshd[5864]: User rreck not allowed because listed in DenyUsers
这条日志消息表示，即使猜到了正确的口令字，rreck用户也不能登录。从黑客那边看，没有任何东西可以让他知道你已经改变了配置，他们怎么努力也不可能得逞。
总结：笔者想通过这个例子告诉大家，信息安全工作没有尽头；它需要长期持久的努力。降低或者消除风险的最佳办法是保持勤奋和警惕。一定要密切留意日志，一定要不断总结系统上各种正常活动的规律。必须时刻保持警惕并认真解读日志消息的含义，只有常备不懈，才能保证安全。对日志进行监控可以帮助你及时发现问题并指导你对有关配置做出针对性的修改。
说到最后，最好的安全防御措施就是采取行动。在事情发生之前把一切可以采取的措施都考虑周全会对今后产生极大的帮助，这将保证你在采取行动前不会浪费任何时间。提前做好安排还有助于避免在事情发生时的情绪化因素干扰你的判断和思考，保证你对事件做出的反应是在力所能及的范围内最合理有效的
一般来说，系统日志文件几乎都保存在/var/子目录（该路径由syslog.conf文件定义）。如果想让所有的应用程序都把日志文件集中存放到/var/子目录下，需要依次对每一个应用程序的配置文件进行编辑。把日志集中到/var/子目录下是个很好的主意。首先，当需要查看它们、修改它们的权限或者对它们进行备份的时候，只要到一个地方就可以找到所有的日志文件。
其次，/var/子目录通常是在一个独立于根目录（/）的文件系统里，这有助于防止日志文件迅速变大并占满可用空间，避免操作系统和应用程序受到影响。可以利用find命令把你不知道的日志文件查找出来具体做法是：先切换到根目录下，然后以根用户（root）身份执行下面这条命令把最近被修改过的文件全部找出来：
find . -type f -mtime -5 �Cprint | grep -v proc | grep -v lock
2、搜索日志文件时的策略
日志文件分析工作中的第一个挑战是把异常活动从正常活动中识别出来。完成这项挑战的前提是你必须知道系统和网络上的正常活动在日志文件里是什么样子。如果没有事先积累的经验，很难知道按规律发生的事件在日志文件里的表现。熟悉正常的日志文件活动要有一个时间过程，要求大家一上来就把日志文件看明白显然不现实，这是一个需要时间积累的过程。
要知道，随着网络上的应用程序和用户的数量不断增减和变化，日志文件的内容肯定会发生相应的改变。把异常情况孤立出来之后，接下来的步骤是正确地判断这种异常情况是否属于警报条件。要想正确地做出判断，只能通过加深对公司日常活动的了解才能做到。往往需要在系统的可用性与防范风险之间把握一种平衡。
3、以手动方式搜索日志文件
grep是Unix系统上功能最强大的shell命令之一。利用grep命令在日志文件里搜索各种可疑线索是这个文本文件搜索命令的绝佳用途。grep命令的用法很简单――在命令行上输入：
grep "failed" /var/log/messages
上面这条grep命令将把/var/log/messages文件里包含单词“failed”的文本行全部找出来。在默认情况下，grep命令是大小写敏感的，你可能需要根据具体情况使用grep命令和它的“-i”选项来进行对大小写不敏感的搜索。搜索日志文件的挑战之一是你必须先知道自己想找什么东西，然后才可以把可能存在的这个东西找出来。有几种办法可以帮助解决这一问题。
如果你知道自己想找的事件或活动――比如，用户试图使用su命令切换为根用户――可以先自己进行一次这样的活动，然后去日志文件里看看它是什么样子。比如，在SUSE Linux系统上，执行失败的su命令将在日志文件里留下这样一条记录：
Apr 1 11:15:54 chim su: FAILED SU (to root) rreck on /dev/pts/1
于是，如果想把所有这类活动都查出来，应该使用下面这样的命令：
grep "FAILED SU" /var/log/messages
上面示例里的活动是黑客攻击的一种标志。如果grep命令只在日志文件里零零散散地找到了几个这样的失败事件，那很可能是有人忘记了口令字或者是打字时出现了错误。反之，如果grep命令在日志文件里找到几十个这样的失败事件，很可能是有人在试图闯入你的系统，应该立刻采取措施在网络级拒绝他们的访问。
4、使用logsurfer工具搜索日志文件
logsurfer是一个日志文件搜索工具。与swatch等日志搜索工具相比，logsurfer允许人们做出更细致的决定。与其他日志搜索程序相似，logsurfer工具也是把日志文件里的每一行与一些规则表达式进行匹配，每找到一个匹配就相应地执行某个动作，而那些动作被表达为“规则”。logsurfer工具在某些方面比swatch工具做得还要好。
首先，logsurfer工具使用两组规则表达式匹配文本行；日志文件中的文本行必须匹配第一组表达式，但不需要匹配可选的第二组表达式。这种安排在某些场合非常有用，它可以让人们方便地排除异常情况。logsurfer工具的另外一个突出优点是它可以结合上下文进行检查而不是只检查单个的文本行。这很方便，因为日志文件里的单独一行文本往往不足以包含做出某个决定所需要的信息。
要说不足，不少人认为logsurfer工具比较难以配置，因为对它进行配置必须精通规则表达式，而且它本身提供的配置示例不够多。如果想了解更多关于logsurfer工具的信息，它的man文档是最好的地方。列在表1里的细节都可以在这个工具的man文档里查到。logsurfer配置文件里的每
一行可以是以下三种情况之一：如果第一个字符是“#”，它是一个注释行；如果第一个字符是空格，它是上一行的继续；如果第一个字符既不是“#”也不是空格，它是一条新规则的开始。每条新规则由六个必要字段（第1、2、3、4、5、7字段）和一个可选字段（第6字段）组成，对这七个字段的详细解释见表1。
表1 logsurfer配置行上的各个字段
字段编号
是否是可选
字段名
字段解释
1
必要
match_regex
“字段1”被解释为一个规则表达式。如果文本行匹配“字段1”（match_regex），按后续各项定义依次处理；如果不匹配，logsurfer将用下一条规则匹配这个文本行，本规则后续各项定义不起作用
2
必要或-
not_match_regex
这个字段将被解释为一个规则表达式。用“字段1”（match_regex）匹配到的文本行只有在不匹配“字段2”（not_match_regex）的情况下才继续按后续各项定义依次处理
3
必要或-
stop_regex
如果不是减号（-）字符，本字段将被解释为一个规则表达式。如果这个表达式得到匹配，本规则将从活跃规则表里被删除
4
必要或-
not_stop_regex
如果不是减号（-）字符，本字段将被解释为一个规则表达式。只有在“字段3”（stop_regex）存在且已得到匹配和“字段4”（not_stop_regex）不匹配的情况下才删除这个规则
5
必要或0
timeout
以秒计算logsurfer规则的寿命，把“字段5”设置为0表示规则永远有效
6
可选
Continue
如果这个字段被设置为“continue”，logsurfer将继续使用下一条规则来匹配文本行；如果没有“continue”，后续的规则将全部被跳过
7
必要
Action
以下几种动作之一：ignore、exec、pipe、open、delete、report、rule
表2 logsurfer动作解释
动作名称
解释
Ignore
什么都不做，忽略被匹配到的文本行。有时候，虽然用logsurfer工具找到了一些日志文本行，但如果知道它们并不重要，可以用这个动作不让logsurfer发出警报
exec
这个动作的参数被解释为一个程序，规则得到匹配时logsurfer将调用该程序
pipe
类似于exec动作，但被调用的程序将从stdin设备读入一个日志文本行
open
增加（打开）一个新的上下文，但在匹配match_regex（“字段1”）时已经存在的上下文就不必再次打开了
Delete
如果一个现已存在的match_regex被用做这个动作的参数，指定的上下文将被关闭并删除，而且不采取“default_action”选项定义的默认动作
report
这个动作的第1个参数是一个将被调用执行的程序（及其命令行选项）。随后的参数是一些将被用做该程序的标准输入的上下文定义
Rule
这个动作将创建一条新规则。关键字“rule”的后面必须有一个告诉logsurfer按什么顺序使用新规则的指示符：before（在本规则之前使用）、behind（在本规则之后使用）、top（在本配置文件所有规则之前使用）、bottom（在本配置文件所有规则之后使用）
5、使用swatch工具搜索日志文件
swatch工具不是Red Hat Enterprise Linux发行版本的标准组成部分，但因为swatch工具很容易安装、配置和使用，所以你应该考虑下载并安装它。在开始使用它之前，还需要一个配置文件。在默认情况下，swatch工具将在启动它的那个用户的登录子目录里寻找.swatchrc文件（例如/home/rreck/.swatchrc），但你可以用“-f”选项为它另外指定一个配置文件，如下所示：
swatch �Cf /etc/.swatchrc
接下来，看看如何使用swatch工具从日志文件里发现黑客活动的踪迹以及发现之后该做些什么。
◆修改swatch配置以监测针对Apache的攻击
下面这个例子里的攻击手段是一种真实存在的攻击手段，我们来看看它会在日志文件里留下怎样的踪迹以及在发现这些踪迹后如何修改系统配置加以防御。在过去，因为mod_userdir模块（一个默认的Apache模块）的缺陷和它的默认配置，Apache的HTTP服务器经常受到攻击，攻击者可以用一种能扫描远程主机的程序获得远程主机上的某些用户账户信息。
该工具先检查是不是Apache，再检查它是不是有安防漏洞的那个版本，如果是，它将自动地使用很多常见的用户账户去试探目标系统。这种扫描非常快，根据网络连接和服务器的速度，扫描一个账户有时候不用一秒钟。扫描出来的用户信息将被黑客用来攻击FTP等其他系统服务，因为黑客已经确切地知道那些用户账户是存在的。这种攻击将在Apache的access_log日志里留下大量的事件记录。如果黑客试测的用户账户不存在，会在日志里留下404出错信息。
如果黑客试测的用户账户存在但不允许访问，会在日志里留下403出错信息。除了进入日志文件，这些出错信息还将返回到攻击者那里，这正是攻击者希望的。攻击者只对403出错信息感兴趣――导致403出错信息的账户在目标系统上是存在的，黑客可以针对这些账户发动下一步攻击。把下面几行代码添加到用swatch工具检查Apache日志文件时使用的.swatchrc文件里，就可以通过电子邮件知道哪些账户最有可能成为上述攻击手段的受害者：
#Apache403errors
watchfor/403/
echo
bell
偶尔出现一条403出错信息没有关系，但如果在几秒之内连续出现许多403出错信息，就应该知道必须采取行动了。因为403出错不是一种经常发生的事情，定期进行搜索就可以。比如，如果打算安排swatch工具在每晚0点5分对Apache日志文件进行一次检查，可以在根用户的crontab文件里增加一项如下所示的计划任务：
5 0 * * * --config-file=swatchrc.apache swatch --examine-file=/var/log/httpd/access_log
最保险的做法是把swatch运行为一个守护进程或让它运行在“tail”模式下，这可以让你在事情发生的时候立刻收到swatch发来的警报。可以用下面这条命令达到这个目的：
swatch --config-file=swatchrc.apache --tail-file=/var/log/httpd/access_log
一旦确认攻击正在发生，应该立刻采取补救措施：在Apache的配置文件/etc/httpd/httpd.conf文件里增加和修改几条配置指令，然后用命令重新启动Apache守护进程。修改Apache配置文件的具体办法有两种。第一种办法是先全局禁用UserDir指令，再把需要激活的用户账户激活，如下所示：
UserDir disabled
UserDirenabled user1 user2 user3
第二种是先全局激活UserDir指令，再把不想让外界知道的用户账户禁用掉，如下所示：
UserDir enabled
UserDir disabled user4 user5 user6
◆修改swatch配置以监测针对SSH守护进程的攻击
通过扫描日志文件及时掌握系统安全状况有重要意义。日志的作用只有通过人们对日志信息的运用才能真正体现出来。在设法弄到系统上的一个用户名后，黑客就可以发动“暴力”攻击了，这是一种通过SSH服务试测几千个口令字以期获得远程系统shell访问权限的攻击手段。这种暴力攻击会在系统（Red Hat）的日志里留下记录类似下面这样：
Jun 6 13:01:56 chim sshd(pam_unix)[17331]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.1.199 user=rreck
Jun 6 13:02:01 chim sshd[17331]: Failed password for rreck from 192.168.1.199 port 33181 ssh2
Jun 6 13:02:03 chim sshd[17331]: Failed password for rreck from 192.168.1.199 port 33181 ssh2
Jun 6 13:02:03 chim sshd(pam_unix)[17331]: 2 more authentication failures; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.1.199
user=rreck
让自己尽早获知这些事情正在发生是防范这类攻击最有效的策略。为了做到这一点，需要把一段下面这样的swatch配置代码添加到系统的swatchrc文件里：
# Failed password
watchfor / Failed password for /
echo
bell
此后，当swatch以cron计划任务或以“tail”模式运行时，如果在日志文件里发现这种攻击的特征，就会立刻通过电子邮件向你发出警报。这种电子邮件警报是有行动信号。根据你的具体情况，你或许需要允许rreck用户从多个主机登录。编辑/etc/ssh/sshd_config文件，下面给出的配置代码将明确地拒绝rreck用户从已发生多次试测口令字失败活动的主机进行登录，但同时允许rreck从其他主机登录：
# Prevent access for hacker even if they guess the password !
DenyUsers [email protected]
AllowUsers rreck@*
接下来，向sshd发出一个SIGHUP信号或者用下面这条命令重新启动它：
/etc/rc.d/sshd restart
当你在/var/log/messages文件里看到sshd发来的如下消息时，就可以知道你做的修改已经生效，攻击者的登录企图已经被sshd拒绝了：
Apr 1 17:42:55 linux sshd[5864]: User rreck not allowed because listed in DenyUsers
这条日志消息表示，即使猜到了正确的口令字，rreck用户也不能登录。从黑客那边看，没有任何东西可以让他知道你已经改变了配置，他们怎么努力也不可能得逞。
总结：笔者想通过这个例子告诉大家，信息安全工作没有尽头；它需要长期持久的努力。降低或者消除风险的最佳办法是保持勤奋和警惕。一定要密切留意日志，一定要不断总结系统上各种正常活动的规律。必须时刻保持警惕并认真解读日志消息的含义，只有常备不懈，才能保证安全。对日志进行监控可以帮助你及时发现问题并指导你对有关配置做出针对性的修改。
说到最后，最好的安全防御措施就是采取行动。在事情发生之前把一切可以采取的措施都考虑周全会对今后产生极大的帮助，这将保证你在采取行动前不会浪费任何时间。提前做好安排还有助于避免在事情发生时的情绪化因素干扰你的判断和思考，保证你对事件做出的反应是在力所能及的范围内最合理有效的