OSSEC HIDS初探

1. OSSEC简介

OSSEC是一款开源的基于主机的入侵检测系统，可以简称为HIDS。它具备日志分析，文件完整性检查，策略监控，rootkit检测，实时报警以及联动响应等功能。它支持多种操作系统：Linux、Windows、MacOS、Solaris、HP-UX、AIX。

0x1：安装

# Add Apt sources.lst
wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash

# Update apt data
sudo apt-get update

# Server
sudo apt-get install ossec-hids-server

# Agent
sudo apt-get install ossec-hids-agent

0x2：主要功能

1. File Integrity checking【文件完整性监控】

There is one thing in common to any attack to your networks and computers: they change your systems in some way.

The goal of file integrity checking (or FIM - file integrity monitoring) is to detect these changes and alert you when they happen. It can be an attack, or a misuse by an employee or even a typo by an admin, any file, directory or registry change will be alerted to you.

2. Log Monitoring【日志采集驱动的异常检测（规则+统计）】

Your operating system wants to speak to you, but do you know how to listen?

Every operating system, application, and device on your network generate logs (events) to let you know what is happening.

OSSEC collects, analyzes and correlates these logs to let you know if something suspicious is happening (attack, misuse, errors, etc). Do you want to know when an application is installed on your client box? Or when someone changes a rule in your firewall? By monitoring your logs, OSSEC will notify you.

3. Rootkit detection【特征检测】

Criminal hackers want to hide their actions, but using rootkit detection you can be notified when the system is modified in a way common to rootkits.

4. Active response【自动响应、响应联动】

Active response allows OSSEC to take immediate action when specified alerts are triggered. This may prevent an incident from spreading before an administrator can take action.

0x3：OSSEC Architecture

OSSEC is composed of multiple pieces. It has a central manager for monitoring and receiving information from agents, syslog, databases, and from agentless devices.

1. Manager (or Server)

The manager is the central piece of the OSSEC deployment. It stores the file integrity checking databases, the logs, events, and system auditing entries. All the rules, decoders, and major configuration options are stored centrally in the manager; making it easy to administer even a large number of agents.

2. Agents

The agent is a small program, or collection of programs, installed on the systems to be monitored. The agent will collect information and forward it to the manager for analysis and correlation. Some information is collected in real time, others periodically. It has a very small memory and CPU footprint by default, not affecting the system’s usage.

Agent security: It runs with a low privilege user (generally created during the installation) and inside a chroot jail isolated from the system. Most of the agent configuration can be pushed from the manager.

3. Agentless

For systems that an agent cannot be installed on, the agentless support may allow integrity checks to be performed. Agentless scans can be used to monitor firewalls, routers, and even Unix systems.

4. Virtualization/VMware

OSSEC allows you to install the agent on the guest operating systems. It may also be installed inside some versions of VMWare ESX, but this may cause support issues. With the agent installed inside VMware ESX you can get alerts about when a VM guest is being installed, removed, started, etc. It also monitors logins, logouts and errors inside the ESX server. In addition to that, OSSEC performs the Center for Internet Security (CIS) checks for VMware, alerting if there is any insecure configuration option enabled or any other issue.

5. Firewalls, switches and routers

OSSEC can receive and analyze syslog events from a large variety of firewalls, switches and routers. It supports all Cisco routers, Cisco PIX, Cisco FWSM, Cisco ASA, Juniper Routers, Netscreen firewall, Checkpoint and many others. 

0x3：配置监控项 && 启动监控

处于实验目的，我们的client和server端各自部署在一台服务器上。实际工业场景中，agnet是装机在海量的服务器上，而server一般是一个可以支持横向扩容的负载均衡转发器。

1. server端配置【120.55.103.79】

1）部署配置

server端的主要作用是：

• 收集agent传输过来的”alert消息“，并传递给之后的展示模块（如果有的话）
• 向client分发检测规则和监控项配置

# 启动 OSSEC HIDS
/var/ossec/bin/ossec-control start
# 停止 OSSEC HIDS
/var/ossec/bin/ossec-control stop

 

启动ossec服务端必须先添加一个客户端，否则直接启动服务端是会失败的，通过如下命令查看日志会发现如下错误：

在服务器上添加客户端，执行如下命令，

导出刚才添加的那个agent的key，用于后面的客户端连接到服务端： 

MDAxIG9zc2VjLWFnZW50IDEyMC41NS4xMDMuNzkgYjllY2Y3OTBjNmM1YTQzMDZhYzIyMjQ5NjRmNjY5Nzg5N2E5ZGU3ODFiNTdmOTIyZWM0N2Q5YTI5YzI2OGViOQ==

该key可以可以理解为一个安装序列号，每个client都有一个对应的序列号，才能被serve所识别，否则即使安装了ossec-client也无法和server通信。

配置白名单：

<global>
    <white_list>127.0.0.1</white_list>
    <white_list>::1</white_list>
    <white_list>192.168.2.1</white_list>
    <white_list>192.168.2.190</white_list>
    <white_list>192.168.2.32</white_list>
    <white_list>192.168.2.10</white_list>
    <white_list>47.110.42.37</white_list>
  </global>

支持接受远程机器的syslog，所以我们还需要对ossec.conf文件中的syslog部分进行配置，修改ossec.conf文件，按照下面的内容进行修改，把client的网段可以全添加进去：

<remote>
    <connection>syslog</connection>
    <allowed-ips>47.110.0.0/16</allowed-ips>
  </remote>

到现在就可以启动我们的ossec服务端了， 

/var/ossec/bin/ossec-control start

2）规则配置

/var/ossec/etc/ossec.conf

2.1）系统完整性检测模块

<syscheck>
    <!-- Frequency that syscheck is executed -- default every 20 hours -->
    <frequency>72000</frequency>

    <!-- Directories to check  (perform all possible verifications) -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/bin,/sbin,/boot</directories>

    <!-- Files/directories to ignore -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore>/etc/mail/statistics</ignore>
    <ignore>/etc/random-seed</ignore>
    <ignore>/etc/random.seed</ignore>
    <ignore>/etc/adjtime</ignore>
    <ignore>/etc/httpd/logs</ignore>

    <!-- Check the file, but never compute the diff -->
    <nodiff>/etc/ssl/private.key</nodiff>
</syscheck>

2.2）rootkit检测模块

<rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
</rootcheck>

检测原理主要依靠已知rootkit安装或运行时存在的路径和进程名特征作为检测依据。

2.3）系统日志监控，alert消息检测

以sshd登录行为审计为例，

2.4）应用日志监控

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/messages</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/authlog</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/secure</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/xferlog</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/maillog</location>
  </localfile>

  <localfile>
    <log_format>apache</log_format>
    <location>/var/www/logs/access_log</location>
  </localfile>

  <localfile>
    <log_format>apache</log_format>
    <location>/var/www/logs/error_log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/exim_mainlog</location>
  </localfile>

如果你希望监控其他文件, 只需要在配置文件ossec.conf中添加新的一项。

2. client端配置【47.110.42.37】

1）部署配置

OSSEC HIDS 服务器的IP地址或主机名：

<client>
    <server-ip>120.55.103.79</server-ip>
  </client>

运行”manage_agents“工具导入服务器端产生的认证密匙。

/var/ossec/bin/manage_agents

MDAxIG9zc2VjLWFnZW50IDEyMC41NS4xMDMuNzkgYjllY2Y3OTBjNmM1YTQzMDZhYzIyMjQ5NjRmNjY5Nzg5N2E5ZGU3ODFiNTdmOTIyZWM0N2Q5YTI5YzI2OGViOQ==

启动agent

/var/ossec/bin/ossec-control start

 

Relevant Link: 

https://www.ossec.net/docs/manual/non-technical-overview.html
https://www.ossec.net/
https://www.ossec.net/docs/manual/ossec-architecture.html
https://www.cnblogs.com/zlslch/p/8512757.html

 

2. 应用场景

0x1：监测CC攻击

• 监控web服务器web日志文件读取日志。
• 针对/phpinfo.php该页面建立一条rule，规则为每当检测到/phpinfo.php被访问到一次，则触发一次。
• 再新建一条rule，规则为一定时间内同一个ip触发我们刚才建立的rule达到一定次数，则触发本条规则（本文为方便验证，暂设为每分钟10次）。

 

https://www.freebuf.com/tag/ossec?type=1

https://www.freebuf.com/articles/network/36484.html

https://www.freebuf.com/articles/system/68869.html

 

关于HIDS日志采集架构形态的一些思考

ossec的安全思路是将部分安全规则下放到agent上，从多源日志中进行规则匹配，得到第一层”alert消息“，随后将alert消息统一上报给server master作汇总、关联分析、可视化呈现。

但是这种架构思路存在几个很严重的问题：

• 安全规则的编写复杂度：在安全攻防领域，安全规则是安全知识输出的一个非常重要的手段，同时这也导致安全规则的编写是一个灵活度和复杂性相对较高的事情，而对每个agent来说，不管再怎么框架化，其规则都是遵循一定的格式的，这就意味着安全工程师只能将自己的安全知识经过”裁剪和变化“，以适应各个agent支持的规则形式，很多时候这会限制安全知识的表达和呈现，最终影响安全检测和防御的效果。以一个”redis未授权漏洞导致病毒植入的攻防场景“举例，在这个例子中，
  • 安全工程师需要在网络侧加入特征包规则（snort）
  • 需要对redis的审计日志加入日志审计规则（ossec）
  • 需要对redis写文件的行为日志加入进程写文件规则（audit/sysdig）
  • 需要对/etc/crontab、/init.d下的自启动项的完整性监控加入完整性检测规则（ossec）
• 规则更新的频度：随着漏洞、攻击方式、攻击向量组合的不断演进和变化，原有的安全规则可能需要修改。agent-server的cs架构中，每次规则的修改，都要在短时间内将最新的规则推送给所有的client，并让client重新加载，这会带来很大的性能开销和不可避免的延迟滞后问题
• 异源日志融合困难：毫无疑问，因为操作系统是分层的，所以位于不同层技术栈的agent所能采集到的日志也代表了不同的上下文属性（例如ossec和snort）。这就导致了异源日志之间的关联分析和溯源推理变得困难
• 无法支持复杂的数据分析和数据挖掘：传统的SEIM和EDR的大部分安全规则都在agent端直接完成了（例如文件完整性对比、网络包特征匹配、异常流量统计），这导致上报到elasticsearch中的数据已经是一个个代表了元异常的alert数据，这种数据中存留的可用冗余信息已经不多了，有的甚至是直接可以用作告警的数据。带来的最大缺点就是，基于日志层面的机器学习和数据挖掘工作就很难展开了。

与这种cs架构相比，业界的另一种架构思路是”agentless-server-data analysis engine“，即

• agent不做任何分析逻辑，而是采用各种hook/callback技术对各层的原始日志进行采集和全量上报
• server对海量agent的消息进行汇总，并投递到中心数据仓库中
• data analysis engine提供了sql、流分析、规则匹配、算法组件化能力，对海量日志直接进行建模分析，建模的灵活性全部由安全工程师决定，可以随时修改和更新