Shulou(Shulou.com)06/01 Report--

Approach the OSSIM Sensor (Sensor) plug-in

After introducing the composition of the OSSIM architecture in the previous blog post, I will introduce its "mysterious" plug-ins, reminding you to be proficient in regular expressions before reading the plug-ins.

Sensor enables the plug-in list, and managing them is simple:

Take a look at the plug-in global configuration file

[plugins]

Apache=/etc/ossim/agent/plugins/apache.cfg

Nmap-monitor=/etc/ossim/agent/plugins/nmap-monitor.cfg

Ossec-single-line=/etc/ossim/agent/plugins/ossec-single-line.cfg

Ossim-monitor=/etc/ossim/agent/plugins/ossim-monitor.cfg

Pam_unix=/etc/ossim/agent/plugins/pam_unix.cfg

Ping-monitor=/etc/ossim/agent/plugins/ping-monitor.cfg

Prads_eth0=/etc/ossim/agent/plugins/prads_eth0.cfg

Ssh=/etc/ossim/agent/plugins/ssh.cfg

Sudo=/etc/ossim/agent/plugins/sudo.cfg

Suricata=/etc/ossim/agent/plugins/suricata.cfg

Whois-monitor=/etc/ossim/agent/plugins/whois-monitor.cfg

Wmi-monitor=/etc/ossim/agent/plugins/wmi-monitor.cfg

The Sensor plug-in sends the preprocessed data to Server, defined as follows

[output-server]

Enable=True

Ip=192.168.91.228

Port=40001

Send_events=True

1. Apache log processing plug-in

Taking the Apache plug-in as an example, take a look at the regular expressions in the plug-in:

[0001-apache-access] access log

Event_type=event

Regexp= ((? P\ d {1Magne3}\.\ d {1rect 3}\.\ d {1Magne3}\.\ d {1Magol 3}) (: (? P\ S+) (? P\ S+)\ [(? P\ d {2}\ /\ w {3}\ /\ d {4}:\ d {2}:\ d {2}:\ d {2})\ s + [+ -]\ d {4}\]\ "(? P [^\"] *)\ "(? P\ d {3}) ((? P\ d +) | -) (\" (? P [^\ "] *)\" (? P [^\ "] *)\")? $

Src_ip= {resolv ($src)}

Dst_ip= {resolv ($dst)}

Dst_port= {$port}

Date= {normalize_date ($date)}

Plugin_sid= {$code}

Username= {$user}

Userdata1= {$request}

Userdata2= {$size}

Userdata3= {$referer_uri}

Userdata4= {$useragent}

Filename= {$id}

[0002-apache-error] error log

Event_type=event

Regexp=\ [(? P\ w {3}\ w {2}\ d {2}:\ d {2}:\ d {2}\ d {4})\]\ [(? P (emerg | alert | crit | warn | notice | info | debug))\] (\ [client (? P\ S+)\])?

Date= {normalize_date ($date)}

Plugin_sid= {translate ($type)}

Src_ip= {resolv ($src)}

Userdata1= {$data}

If you don't know much about the basic format of Apache logs, please refer to the book Unix/Linux Network Log Analysis and Traffic Monitoring.

If you are forwarding apache logs through syslog, the rule should be as follows:

[0001-apache-syslog-access]

Event_type=event

Regexp= ^\ w {3}\ s +\ d {1Magne2}\ d:\ d\ d:\ d\ d\ d (? P\ S+) (? P\ S+) (: (? P\ S+) (? P\ S+)\ [(? P\ d {2}\ /\ w {3}\ /\ d {4}:\ d {2}:\ d {2}: \ d {2})\ s + [+ -]\ d {4}\]\ "(? P.*)\" (? P\ d {3}) ((? P\ d+) | -) (\ "(? P.*)\" (? P.*)\ ")? $

Src_ip= {resolv ($src)}

Dst_ip= {resolv ($dst)}

Dst_port= {$port}

Device= {resolv ($device)}

Date= {normalize_date ($date)}

Plugin_sid= {$code}

Username= {$user}

Userdata1= {$request}

Userdata2= {$size}

Userdata3= {$referer_uri}

Userdata4= {$useragent}

Filename= {$id}

[0002-apache-syslog-error]

Event_type=event

Regexp= ^ (? P\ w {3}\ s +\ d {1Magne2}\ d:\ d\ d:\ d:\ d) (? P\ S+)\ error: (? P (emerg | alert | crit | warn | notice | info | debug))\] (\ [client (? P\ S+)\])? (? P.*)

Date= {normalize_date ($date)}

Dst_ip= {resolv ($device)}

Device= {resolv ($device)}

Date= {normalize_date ($date)}

Plugin_sid= {translate ($type)}

Src_ip= {resolv ($src)}

Userdata1= {$data}

Let's see what the Apache plug-in can do.

This is the effect of normalizing Apache logs. Each type of plug-in corresponds to a plug-in ID. You should keep this ID number in mind when using SIEM event analysis (you will understand it if you read more).

2. SSH log processing plug-in

The Apache log is relatively simple, but the SSH log described below is much more complex.

The normalized event handled by the first rule above is shown in the following figure.

Let's take a look at how the second rule deals with how "invalid users" generate normalized events.

Then take a look at a regular expression of the SSH log plug-in

After processing, the corresponding normalized event is generated, as shown in the following figure.

When connecting to a host using SSH or SFTP, there will be a series of checks to make sure you can connect to the machine you want to connect to. One of them is "reverse lookup on the IP address" to check that the machine name matches the name of the machine you want to connect to. Otherwise, you will get an error message: "reverse mapping checking getaddrinfo for … POSSIBLE BREAK-IN ATTEMPT!". This tells us that although we are connecting to the example.com, the IP address of the server actually corresponds to the a.b.c.d.adsl-pool.jx.chinaunicom.com. But when this happens, it is because the reverse DNS on server is not set up.

Talk about the Cisco-ASA plug-in again when you have time.

After reading these examples, some people feel that the normalized event content contains more information than the original log. Why? If you want to learn more about this plug-in-based log collection and processing, please refer to the book "Open Source Security Operation and maintenance platform-OSSIM Best practices".

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.