企业安全实战】开源HIDS OSSEC部署与扩展使用

0x01 概述

---

关于HIDS，并不是一个新鲜的话题，规模较大的企业都会选择自研，而如果你刚刚接手一个公司的网络安全，人手相对不足，那么OSSEC能帮助你安全建设初期快速搭建一套安全系统，后期如果遇到瓶颈也可以考虑自研去解决一些问题。

0x02 主要功能介绍

---

OSSEC的主要功能包括日志分析、文件完整性检测、Rootkit检测以及联动配置，另外你也可以将自己的其他监控项集成到OSSEC中。

1）日志监控

日志是平常安全运维中很重要的一项，OSSEC日志检测为实时检测，OSSEC的客户端本身没有解码文件和规则，所监控的日志会通过1514端口发送到服务端。

配置项可以在配置在每个agent的ossec.conf中或者在agent.conf中，需要写在 中，可配置项如下：

location

指定日志的位置，strftime格式可以用于日志文件名，例如，一个名为file.log-2011-01-22的日志文件可以写为file.log-%Y-%m-%d。通配符可以用于非windows系统。当使用通配符时，日志文件必须在ossec-logcollector启动时存在。它不会自动开始监视新的日志文件。strftime和通配符不能在同一条目上使用。

log_format

例如syslog、command、full_command等等

需要注意的是command和full_command不能配置在agent.conf中，需要配置在ossec.conf中

command

执行的命令。如果log_format指定的是command，那么将逐行读取。如果log_format指定的是full_command，将全部匹配。

alias

该命令的别名。这将替换日志消息中的命令。

例如配置usb-check

ossec: output: ‘reg QUERY HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR’:

将被替换为

ossec: output: ‘usb-check’:

frequency

命令运行之间的最小时间间隔。时间间隔可能会比该值大，适用于log_format为command、full_command。

check_diff

事件的输出将存储在一个内部数据库中。每次接收到相同的事件时，输出都会与之前的输出相比较。如果输出发生了变化，将生成一个警告。

 

命令监控的具体事例：

默认的ossec.conf中自带的配置检查硬盘空间：

2.  

3. command

4.  

5. df -P

6.  

所对应的rule在ossec_rules.xml

2.  

3. 530

4.  

5. ossec: output: 'df -P': /dev/

6.  

7. 100%

8.  

9. Partition usage reached 100% (disk space monitor).

10.  

11. low_diskspace,

12.  

默认的ossec.conf中自带的配置新增端口监听：

2.  

3. full_command

4.  

5. netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| ::1)' | sort

6.  

所对应的rule在ossec_rules.xml

2.  

3. 530

4.  

5. ossec: output: 'netstat -tan

6.  
8.  

9. Listened ports status (netstat) changed (new port opened or closed).

10.  

执行的结果保存在queue/diff/下，每次执行会进行比对

1. [root@localhost ossec]# cat queue/diff/192.168.192.196/533/last-entry

2.  

3. ossec: output: 'netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| \\1)' | sort':

4.  

5. tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

6.  

7. tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

8.  

9. tcp 0 0 0.0.0.0:37498 0.0.0.0:* LISTEN

10.  

11. tcp 0 0 :::111 :::* LISTEN

12.  

13. tcp 0 0 :::22 :::* LISTEN

14.  

15. tcp 0 0 :::62229 :::* LISTEN

这里测试一下用nc监听2345端口，告警如下：

1. ** Alert 1499397975.7591: mail - ossec,

2.  

3. 2017 Jul 07 11:26:15 (192.168.192.196) any->netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| \\1)' | sort

4.  

5. Rule: 533 (level 7) -> 'Listened ports status (netstat) changed (new port opened or closed).'

6.  

7. ossec: output: 'netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| \\1)' | sort':

8.  

9. tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

10.  

11. tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

12.  

13. tcp 0 0 0.0.0.0:2345 0.0.0.0:* LISTEN

14.  

15. tcp 0 0 0.0.0.0:37498 0.0.0.0:* LISTEN

16.  

17. tcp 0 0 :::111 :::* LISTEN

18.  

19. tcp 0 0 :::22 :::* LISTEN

20.  

21. tcp 0 0 :::62229 :::* LISTEN

22.  

23. Previous output:

24.  

25. ossec: output: 'netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| \\1)' | sort':

26.  

27. tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

28.  

29. tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

30.  

31. tcp 0 0 0.0.0.0:37498 0.0.0.0:* LISTEN

32.  

33. tcp 0 0 :::111 :::* LISTEN

34.  

35. tcp 0 0 :::22 :::* LISTEN

36.  

37. tcp 0 0 :::62229 :::* LISTEN

之前在《Linux应急响应姿势浅谈》中提到的，Linux下开机启动项是应急响应中很重要的检测项，Redhat中的运行模式2、3、5都把/etc/rc.d/rc.local做为初始化脚本中的最后一个。这里我在agent的ossec.conf中新加一个监控，检测当rc.local发生改变的时候告警。

2.  

3. full_command

4.  

5. /bin/cat /etc/rc.local

6.  

7. 10

8.  

在Server端的/var/ossec/rules/ossec_rules.xml下新增一条规则

2.  

3. 530

4.  

5. ossec: output: '/bin/cat

6.  
8.  

9. rclocal changed

10.  

然后重启Server和Agent

Agent执行echo “echo test” >> /etc/rc.local

报警如下：

1. ** Alert 1499399596.13605: mail - ossec,

2.  

3. 2017 Jul 07 11:53:16 (192.168.192.196) any->/bin/cat /etc/rc.local

4.  

5. Rule: 536 (level 7) -> 'rclocal changed'

6.  

7. ossec: output: '/bin/cat /etc/rc.local':

8.  

9. #!/bin/sh

10.  

11. #

12.  

13. # This script will be executed *after* all the other init scripts.

14.  

15. # You can put your own initialization stuff in here if you don't

16.  

17. # want to do the full Sys V style init stuff.

18.  

19. touch /var/lock/subsys/local

20.  

21. echo test

22.  

23. Previous output:

24.  

25. ossec: output: '/bin/cat /etc/rc.local':

26.  

27. #!/bin/sh

28.  

29. #

30.  

31. # This script will be executed *after* all the other init scripts.

32.  

33. # You can put your own initialization stuff in here if you don't

34.  

35. # want to do the full Sys V style init stuff.

36.  

37. touch /var/lock/subsys/local

2） 完整性检测

命令替换在应急响应中很常见，经常被替换掉的命令例如ps、netstat、ss、lsof等等。另外还有SSH后门。完整性检测的工作方式是Agent周期性的扫描系统文件，并将检验和发送给Server端。Server端存储并进行比对，发现修改是发出告警。

数据存放到服务端的/var/ossec/queue/syscheck目录下

1. [root@localhost syscheck]# ll /var/ossec/queue/syscheck

2.  

3. total 1388

4.  

5. -rw-r----- 1 ossec ossec 469554 Jun 29 03:16 (192.168.192.195) 192.168.192.195->syscheck

6.  

7. -rw-r----- 1 ossec ossec 469554 Jun 29 03:49 (192.168.192.196) 192.168.192.196->syscheck

8.  

9. -rw-r----- 1 ossec ossec 470797 Jun 29 18:13 syscheck

常用的配置如下：

默认值是/etc,/usr/bin,/usr/sbin,/bin,/sbin,/boot

属性配置如下

realtime：实时监控

report_changes：报告文件变化，文件类型只能是文本

check_all：check_*全部为yes

check_sum：监测MD5和SHA1 HASH的变化，相当于设置check_sha1sum=”yes”和check_md5sum=”yes”

check_sha1sum：监测SHA1 HASH的变化

check_md5sum：监测MD5 HASH的变化

check_size：监测文件大小

check_owner：监测属主

check_group：监测属组

check_perm：监测文件权限

restrict：限制对包含该字符串的文件监测

 

配置忽略的文件和目录。所配置的文件和目录依然会检测，不过结果会忽略。

支持正则匹配.log$|.tmp

检测周期

开始扫描的时间，格式可以是21pm, 8:30, 12am

配置一周中的哪天可以扫描，格式sunday, saturday, monday

忽略变化超过3次的文件

新文件创建时告警

启动时扫描

Windows注册表项监控

忽略的注册表项

Prelink会修改二进制文件，以方便其快速启动，所以会导致二进制文件的MD5修改，导致误报。这个配置目的是忽略掉prelink产生的误报，配置/usr/sbin/prelink -y需要注意的是改配置会影响性能。

跳过CIFS和NFS挂载目录

 

配置示例：

2.  

3. /etc,/usr/bin,/usr/sbin

4.  

5. /root/users.txt,/bsd,/root/db.html

6.  

修改告警级别，例如当/var/www/htdocs修改时，告警级别修改为12

2.  

3. syscheck

4.  

5. /var/www/htdocs

6.  

7. Changes to /var/www/htdocs - Critical file!

8.  

这里有一个需要注意的地方，我一开始使用OSSEC的时候，用的默认配置，然后凌晨3点的时候收到了大量的告警，如下：

1. ** Alert 1500341372.94081: mail - ossec,syscheck,

2.  

3. 2017 Jul 18 09:29:32 localhost->syscheck

4.  

5. Rule: 550 (level 7) -> 'Integrity checksum changed.'

6.  

7. Integrity checksum changed for: '/sbin/partprobe'

8.  

9. Old md5sum was: 'cabd9d003c9f3b194b32eff8d27e9dfc'

10.  

11. New md5sum is : '34a3700736e54368e296c24acef6f5b9'

12.  

13. Old sha1sum was: '0eb531a5bce4fdf30da3d69aed181b54b4870f0b'

14.  

15. New sha1sum is : '19640bd6d1ebc4298423498a9363dfe2074023ad'

16.  
17.  
18.  

19. ** Alert 1500341380.94500: mail - ossec,syscheck,

20.  

21. 2017 Jul 18 09:29:40 localhost->syscheck

22.  

23. Rule: 550 (level 7) -> 'Integrity checksum changed.'

24.  

25. Integrity checksum changed for: '/sbin/wipefs'

26.  

27. Old md5sum was: '61ddf66c79323caff5d8254a29b526dc'

28.  

29. New md5sum is : '45af33cff81598dd0a33f0439c6aa68f'

30.  

31. Old sha1sum was: '161d409336291c8ed03a89bd8378739934dca387'

32.  

33. New sha1sum is : 'a735876ea2090323bd766cfb6bad0f57c6a900f2'

告警显示/sbin下的执行文件MD5都修改了。其实这里是因为定时任务Prelink导致。Prelink利用事先链接代替运行时链接的方法来加速共享库的加载，它不仅可以加快起动速度，还可以减少部分内存开销， 是各种Linux架构上用于减少程序加载时间、缩短系统启动时间和加快应用程序启动的很受欢迎的一个工具。

 

以CentOS6.5系统为例，

1. [root@sec248 cron.daily]# ls

2. logrotate makewhatis.cron mlocate.cron prelink readahead.cron tmpwatch

prelink脚本内容如下：

1. #!/bin/sh

2. . /etc/sysconfig/prelink

3. renice +19 -p $$ >/dev/null 2>&1

4. if [ "$PRELINKING" != yes ]; then

5. if [ -f /etc/prelink.cache ]; then

6. echo /usr/sbin/prelink -uav > /var/log/prelink/prelink.log

7. /usr/sbin/prelink -uav >> /var/log/prelink/prelink.log 2>&1 \

8. || echo Prelink failed with return value $? >> /var/log/prelink/prelink.log

9. rm -f /etc/prelink.cache

10. # Restart init if needed

11. [ -n "$(find `ldd /sbin/init | awk 'NF == 4 { print $3 }'` /sbin/init -ctime -1 2>/dev/null )" ] && /sbin/telinit u

12. fi

13. exit 0

14. fi

15. if [ ! -f /etc/prelink.cache -o -f /var/lib/prelink/force ] \

16. || grep -q '^prelink-ELF0.[0-2]' /etc/prelink.cache; then

17. # If cache does not exist or is from older prelink versions or

18. # if we were asked to explicitely, force full prelinking

19. rm -f /etc/prelink.cache /var/lib/prelink/force

20. PRELINK_OPTS="$PRELINK_OPTS -f"

21. date > /var/lib/prelink/full

22. cp -a /var/lib/prelink/{full,quick}

23. elif [ -n "$PRELINK_FULL_TIME_INTERVAL" \

24. -a "`find /var/lib/prelink/full -mtime -${PRELINK_FULL_TIME_INTERVAL} 2>/dev/null`" \

25. = /var/lib/prelink/full ]; then

26. # If no more than PRELINK_NONRPM_CHECK_INTERVAL days elapsed from last prelink

27. # (be it full or quick) and no packages have been upgraded via rpm since then,

28. # don't do anything.

29. [ "`find /var/lib/prelink/quick -mtime -${PRELINK_NONRPM_CHECK_INTERVAL:-7} 2>/dev/null`" \

30. -a -f /var/lib/rpm/Packages \

31. -a /var/lib/rpm/Packages -ot /var/lib/prelink/quick ] && exit 0

32. date > /var/lib/prelink/quick

33. # If prelink without -q has been run in the last

34. # PRELINK_FULL_TIME_INTERVAL days, just use quick mode

35. PRELINK_OPTS="$PRELINK_OPTS -q"

36. else

37. date > /var/lib/prelink/full

38. cp -a /var/lib/prelink/{full,quick}

39. fi

40. echo /usr/sbin/prelink -av $PRELINK_OPTS > /var/log/prelink/prelink.log

41. /usr/sbin/prelink -av $PRELINK_OPTS >> /var/log/prelink/prelink.log 2>&1 \

42. || echo Prelink failed with return value $? >> /var/log/prelink/prelink.log

43. # Restart init if needed

44. [ -n "$(find `ldd /sbin/init | awk 'NF == 4 { print $3 }'` /sbin/init -ctime -1 2>/dev/null )" ] && /sbin/telinit u

45. exit 0

/etc/sysconfig/prelink文件内容如下：

1. [root@localhost cron.daily]# cat /etc/sysconfig/prelink | grep -v '^$' | grep -v '^#'

2. PRELINKING=yes

3. PRELINK_OPTS=-mR

4. PRELINK_FULL_TIME_INTERVAL=14

5. PRELINK_NONRPM_CHECK_INTERVAL=7

通过看上面的脚本，我们明白每14天会进行一次正常Prelink操作，也就是执行

/usr/sbin/prelink -av -mR

平时每天执行的Prelink操作其实是quick模式，也就是执行

/usr/sbin/prelink -av -mR -q

解决方案是添加配置

/usr/sbin/prelink -y

在比对MD5或者SHA1之前，会先执行prelink -y ，从而避免误报。prelink -y 会输出prelink之前的原始文件内容。

过了一段时间，突然一台机器上收到大量告警，所监控二进制文件的SHA都变成了da39a3ee5e6b4b0d3255bfef95601890afd80709。

然后我查看了OSSEC服务端的记录信息/var/ossec/queue/syscheck，syscheck记录内容如下：

1. ./(10.59.0.238) any->syscheck:+++0:0:0:0:xxx:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1531341371 /usr/bin/jdb

2. ./(10.59.0.238) any->syscheck:+++0:0:0:0:xxx:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1531341375 /usr/bin/policytool

3. ./(10.59.0.238) any->syscheck:+++0:0:0:0:xxx:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1531341397 /usr/bin/jmap

4. ./(10.59.0.238) any->syscheck:+++0:0:0:0:xxx:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1531341405 /usr/bin/javah

5. ./(10.59.0.238) any->syscheck:+++0:0:0:0:xxx:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1531341436 /usr/bin/appletviewer

6. ./(10.59.0.238) any->syscheck:+++0:0:0:0:xxx:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1531341448 /usr/bin/javac

的确好多二进制文件的SHA值都变成了da39a3ee5e6b4b0d3255bfef95601890afd80709，其实这是空字符的SHA1值。我手工执行Prelink测试一下

1. [root@localhost cron.daily]# prelink -y /bin/sh

2. at least one of file's dependencies has changed since prelinking

看起来原因是自动最后一次Prelink操作后，有些依赖库修改了。既然是依赖库修改了，那么肯定是运维升级了什么东西导致的。

搜索了一下Bash记录，发现的确是运维升级了Java相关包。

解决方法就是执行一次normal Prelink操作，quick模式无法修复该问题。

/usr/sbin/prelink -av -mR

3）Rootkit检测

Rootkit也是平时应急响应比较头疼的，OSSEC的检测原理如下：

对比rootkit_files.txt，该文件中包含了rootkit常用的文件。就像病毒库一样。

1. [root@localhost shared]# egrep -v "^#" rootkit_files.txt | grep -v '^$' | head -n 3

2.  

3. tmp/mcliZokhb ! Bash door ::/rootkits/bashdoor.php

4.  

5. tmp/mclzaKmfa ! Bash door ::/rootkits/bashdoor.php

6.  

7. dev/.shit/red.tgz ! Adore Worm ::/rootkits/adorew.php

如果是以”*”开头的话，会扫描整个系统。

对比rootkit_trojans.txt文件中二进制文件特征。

1. [root@localhost shared]# egrep -v "^#" rootkit_trojans.txt | grep -v '^$' | head -n 3

2.  

3. ls !bash|^/bin/sh|dev/[^clu]|\.tmp/lsfile|duarawkz|/prof|/security|file\.h!

4.  

5. env !bash|^/bin/sh|file\.h|proc\.h|/dev/|^/bin/.*sh!

6.  

7. echo !bash|^/bin/sh|file\.h|proc\.h|/dev/[^cl]|^/bin/.*sh!

扫描整个文件系统，检测异常文件和异常的权限设置，文件属主是root，但是其他用户可写是非常危险的，rootkit将会扫描这些文件。同时还会检测具有suid权限的文件、隐藏的文件和目录。

另外还会检测隐藏端口、隐藏进程、/dev目录、网卡混杂模式等。

这里看一下ossec.conf中默认的rootcheck的配置

2.  

3. /var/ossec/etc/shared/rootkit_files.txt

4.  

5. /var/ossec/etc/shared/rootkit_trojans.txt

6.  

7. /var/ossec/etc/shared/system_audit_rcl.txt

8.  

9. /var/ossec/etc/shared/cis_debian_linux_rcl.txt

10.  

11. /var/ossec/etc/shared/cis_rhel_linux_rcl.txt

12.  

13. /var/ossec/etc/shared/cis_rhel5_linux_rcl.txt

14.  

/var/ossec/etc/shared/rootkit_files.txt文件中包含了rootkit常用的文件。

/var/ossec/etc/shared/rootkit_trojans.txt文件中检测一些二进制文件的特征。

后面主要是检测系统配置。

测试：

server：192.168.192.193

agent：192.168.192.196

根据上述检测原理第一条，我们在192.168.192.196下创建文件/tmp/mcliZokhb

然后在Server端执行

[root@localhost ossec]# ./bin/agent_control -r -u 1028

 

OSSEC HIDS agent_control: Restarting Syscheck/Rootcheck on agent: 1028

当扫描完成后，Syscheck last started和Rootcheck last started的时间会更新。

1. [root@localhost rootcheck]# /var/ossec/bin/agent_control -i 1028

2.  
3.  
4.  

5. OSSEC HIDS agent_control. Agent information:

6.  

7. Agent ID: 1028

8.  

9. Agent Name: 192.168.192.196

10.  

11. IP address: any/0

12.  

13. Status: Active

14.  
15.  
16.  

17. Operating system: Linux localhost 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64

18.  

19. Client version: OSSEC HIDS v2.9.0 / 2d13fc898c1b864609180ad7f4512b4c

20.  

21. Last keep alive: Thu Jul 13 14:11:25 2017

22.  
23.  
24.  

25. Syscheck last started at: Thu Jul 13 14:05:27 2017

26.  

27. Rootcheck last started at: Thu Jul 13 13:55:00 2017

来看一下/var/ossec/queue/rootcheck下的内容

1. [root@localhost rootcheck]# cat \(192.168.192.196\)\ any-\>rootcheck

2.  

3. !1499925300!1499150323 Starting rootcheck scan.

4.  

5. !1499925927!1499150951 Ending rootcheck scan.

6.  

7. !1499925300!1499925300 Rootkit 'Bash' detected by the presence of file '/tmp/mcliZokhb'.

其中扫描开始时间为1499925300（2017/7/13 13:55:0），扫描结束时间为1499925927（2017/7/13 14:5:27）

然后在1499925300（2017/7/13 13:55:0），检测到了Rootkit。

然后查看ALert日志中的告警信息

1. [root@localhost rootcheck]# cat /var/ossec/logs/alerts/alerts.log

2.  

3. ** Alert 1499925300.0: mail - ossec,rootcheck,

4.  

5. 2017 Jul 13 13:55:00 (192.168.192.196) any->rootcheck

6.  

7. Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).'

8.  

9. Rootkit 'Bash' detected by the presence of file '/tmp/mcliZokhb'.

PS：

1）部署后，发现经常会收到进程隐藏的告警，经排查服务器也不存在异常。

Process ‘25905’ hidden from /proc. Possible kernel level rootkit.

添加规则rules/ossec_rules.xml

2.  

3. 510

4.  

5. hidden from /proc

6.  

7. Ignored process hidden entries.

8.  

9. rootcheck,

10.  

屏蔽掉该告警。

2）因为OSSEC会检测属主是Root但是Other用户有w权限的文件，有些正常业务的文件会导致误报。

添加规则rules/ossec_rules.xml

2.  

3. 510

4.  

5. /usr/local/fms

6.  

7. Ignored some files which owned by root and has write permissions.

8.  

9. rootcheck,

10.  

屏蔽掉这些目录。

3）用户添加白名单

vim syslog_rules.xml

2. 5901

3. name=flume

4. New group Ignore

6.  

8. 5902

9. name=flume

10. New user Ignore

添加flume的白名单用户

4）联动配置

主动响应分为两部分，第一步需要配置需要执行的脚本，第二步需要绑定该脚本到具体的触发规则。/var/ossec/etc/ossec.conf中相应配置如下：

2.  
4.  
6.  
8.  
10.  
12.  
14.  

Command配置参数如下：

name

对应active-response所使用的名称

executable

/var/ossec/active-response/bin中的可执行文件，不需要写全路径。

expect

命令执行的参数，选项可以是srcip和user（其他的名不接受）. 如果expect标签内的值为空，那么传递-代替真实的值。如果一个响应脚本需要srcip，那么它必须在expect选项中。

如果不需要传递参数值，写即可。

timeout_allowed

指定该命令是否支持超时。

 

active-response配置参数如下：

disabled

如果设置为yes，则禁用主动响应，默认为启用。

command

需要执行的脚本的名称，对应command标签中的name。

location

在哪里执行命令，具体参数如下：

local: 产生该事件的agent

server: 在server端

defined-agent: 指定一个agent，需要配置agent id

all: 所有agent

agent_id

需要执行脚本的agent的ID

level

大于等于该level的event将执行该响应

rules_group

响应将在已定义的组中的任何事件上执行。可以用逗号分隔多个组。

rules_id

响应将在任何带有已定义ID的事件上执行。可以用逗号分隔多个ID。

timeout

以封禁IP为例，指定IP封禁的时间（单位为秒）。

 

这里我们来测试一下：

Server：192.168.192.193

Client（ID:1029）192.168.192.195

Client（ID:1028） 192.168.192.196

首先看一下SSH登录失败的日志为：

Jul  6 15:15:57 localhost sshd[28590]: Failed password for root from 192.168.192.196 port 34108 ssh2

所对应的decode.xml中的解码规则为：

2.  

3. sshd

4.  

5. ^Failed \S+

6.  

7. ^for (\S+) from (\S+) port \d+ \w+$

8.  

9. user, srcip

10.  

这里通过正则表达式获取到了user和srcip

所对应的Rule在sshd_rules.xml中，可以看到告警等级为5：

2.  

3. 5700

4.  

5. ^Failed|^error: PAM: Authentication

6.  

7. SSHD authentication failed.

8.  

9. authentication_failed,

10.  

查看ossec.conf，这里我们添加如下：

2.  

3. test

4.  

5. local

6.  

7. 5

8.  

9. 60

10.  

所对应的执行脚本名称为test，脚本为本地执行，当rule级别大于等于5时触发，封禁时间为60S。

所对应的command配置为

2.  

3. test

4.  

5. test.sh

6.  

7. srcip,user

8.  

9. yes

10.  

这里传递了两个参数srcip,user（前后顺序不影响）。所对应的是ssh-failed解码规则中取到的user和srcip。

/var/ossec/active-response/bin/test.sh文件内容为

1. #!/bin/sh

2.  

3. LOCAL=`dirname $0`;

4.  

5. cd $LOCAL

6.  

7. cd ../

8.  

9. PWD=`pwd`

10.  

11. echo "`date` $0 $1 $2 $3 $4 $5" >> ${PWD}/../logs/active-responses.log

脚本所传递的参数如下：

$1 动作 (delete or add)

$2 user (or – if not set)

$3 srcip (or – if not set)

$4 时间戳

$5 规则号

 

修改权限和属组

[root@localhost bin]# chown root:ossec test.sh

[root@localhost bin]# chmod 550 test.sh

然后在192.168.192.196使用错误密码登录192.168.192.193，触发规则，查看日志

1. [root@localhost ossec]# tail -f logs/active-responses.log

2.  

3. Thu Jul 6 17:07:02 CST 2017 /var/ossec/active-response/bin/test.sh add root 192.168.192.196 1499332022.14278 5503

4.  

5. Thu Jul 6 17:08:32 CST 2017 /var/ossec/active-response/bin/test.sh delete root 192.168.192.196 1499332022.14278 5503

然后我们再用OSSEC自带的host-deny脚本测试一下。

2.  

3. host-deny

4.  

5. host-deny.sh

6.  

7. srcip

8.  

9. yes

10.  
12.  
14.  

15. host-deny

16.  

17. local

18.  

19. 5

20.  

21. 30

22.  

这里local，即仅在触发该规则的Agent有效。

然后我使用另外一台机器192.168.192.120使用错误密码登录192.168.192.196

触发规则后查看hosts.deny发现已经添加了IP192.168.192.120

1. [root@localhost ossec]# cat /etc/hosts.deny | grep 120

2.  

3. ALL:192.168.192.120

4. https://blog.csdn.net/Fly_hps/article/details/82943436