Showing posts with label ossim. Show all posts
Showing posts with label ossim. Show all posts

Saturday, July 19, 2014

Scripts to inject sample data to AlienVault / OSSIM SIEM

I just published a few scripts I wrote to inject sample data to AlienVault or OSSIM (Open Source Version) Unified SIEM. Those can be found in Github:

https://github.com/santiago-bassett/Alienvault-Demo_scripts

The scripts are ready to emulate Syslog data coming from these sources: Aruba Wireless, Cisco ASA, Cisco PIX, ClamAV, Oracle Database, OSSEC HIDS, Sonicwall and SSH.

As well, the scripts are ready to inject malicious network traffic in a dummy interface so it can be analyzed by Snort NIDS. Some of the traffic injected is related to: botnets, C&C communications, Zeus, spambot or spyware. The pcap files can be found in this directory:

https://github.com/santiago-bassett/Alienvault-Demo_scripts/tree/master/pcaps
Posted by at 3 comments:
Labels: , , , ,

Sunday, September 23, 2012

OSSIM hands-on 7: Detecting network attacks with Snort IDS

In this practical exercise we are going to analyze a botnet traffic with different tools, using Snort IDS to alert OSSIM. For distributed deployments, please follow these steps at your OSSIM sensor (in our case 10.0.0.31).

1.-  Setting up a dummy interface in promiscuous

# lsmod | grep dummy (checking that dummy module is loaded)
# ifconfig dummy0 up (waking up dummy0)
# ifconfig dummy0 promisc (setting the interface to promiscuous mode)

2.- Analyzing a traffic sample with tcpdump and tshark

a) Download the traffic sample: zeus-sample-3.pcap (more samples can be found in https://www.openpacket.org)
b) tcpdump -r /root/zeus-sample-3.pcap (reading the pcap file)
c) tcpdump -s 0 -AA -r /root/zeus-sample-3.pcap (showing the packet payloads)
d) tshark -R "tcp.port==80" -r /root/zeus-sample-3.pcap (filtering port 80 traffic)
e) Filtering HTTP POST and GET methods:
# tshark -R 'http.request.method == "GET" || http.request.method == "POST"' -r /root/zeus-sample-3.pcap
 4  0.110877 192.168.3.65 -> 188.72.243.72 HTTP 229 GET /kartos/kartos.bin HTTP/1.1   
 239 30.255596 192.168.3.65 -> 188.72.243.72 HTTP 527 POST /kartos/youyou.php HTTP/1.1   
 240 30.255632 192.168.3.65 -> 188.72.243.72 HTTP 611 POST /kartos/youyou.php HTTP/1.1   
 247 30.749280 192.168.3.65 -> 188.72.243.72 HTTP 226 GET /kartos/krt.exe HTTP/1.1   
 386 33.850475 192.168.3.65 -> 188.72.243.72 HTTP 425 POST /kartos/youyou.php HTTP/1.1   
 394 35.078393 192.168.3.65 -> 188.72.243.72 HTTP 221 GET /ser.exe HTTP/1.1   
 1099 51.216823 192.168.3.65 -> 188.72.243.72 HTTP 425 POST /kartos/youyou.php HTTP/1.1

3.- Enabling Snort plugin

a) Configure Snort to listen in dummy0 interface (using ossim-setup)
b) Enable snortunified plugin (using ossim-setup)
c) Check previous configurations in /etc/ossim/ossim_setup.conf
[sensor]
detectors=snortunified
interfaces=dummy0
d) Check that Snort process is running on dummy0 interface:
sensor1:~# ps aux | grep -i snort
 root   9247 0.0 9.9 506352 392020 ?    Ssl 20:59  0:00 /usr/sbin/snort_dummy0 -m 027 -D -d -l /var/log/snort -u root -g snort -c /etc/snort/snort.dummy0.conf -S HOME_NET=[192.168.0.0/16,172.16.0.0/12,10.0.0.0/8] -i dummy0

4.- Configuring Snort IDS

a) Enable fast syslog output (editing /etc/snort/snort.dummy0.conf)
output alert_fast: /var/log/snort/snort.alert 
b) Check that the following rules are loaded
include $RULE_PATH/emerging-trojan.rules (or emerging_pro-trojan.rules)
include $RULE_PATH/emerging-info.rules (or emerging_pro-info.rules)
include $RULE_PATH/file-identify.rules
include $RULE_PATH/shellcode.rules
c) Restart snort process
# /etc/init.d/snort_dummy0 restart
d) Check that ossim-agent process is reading snort unified output
#sensor1:~# lsof +d /var/log/snort
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
snort_dum  9247 root    4w   REG  202,1     3185 184565605 /var/log/snort/snort.alert
snort_dum  9247 root    8w   REG  202,1    48284 184565614 /var/log/snort/snort_dummy0.1348372798
ossim-age 18247 root   38r   REG  202,1    48284 184565614 /var/log/snort/snort_dummy0.1348372798

5.- Injecting the network traffic

a) Use tcpreplay to inject the network traffic (-t for top speed)
# tcpreplay -i dummy0 -t zeus-sample-3.pcap 
b) See alerts in /var/log/snort/snort.alert 
 09/22-21:03:36.305795 [**] [1:2013976:10] ET TROJAN Zeus POST Request to CnC - URL agnostic [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.3.65:1033 -> 188.72.243.72:80  
 09/22-21:03:36.305834 [**] [1:2013976:10] ET TROJAN Zeus POST Request to CnC - URL agnostic [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.3.65:1034 -> 188.72.243.72:80  
 09/22-21:03:36.306197 [**] [1:2014819:1] ET INFO Packed Executable Download [**] [Classification: Misc activity] [Priority: 3] {TCP} 188.72.243.72:80 -> 192.168.3.65:1033  
 09/22-21:03:36.306197 [**] [1:15306:12] FILE-IDENTIFY Portable Executable binary file magic detection [**] [Classification: Misc activity] [Priority: 3] {TCP} 188.72.243.72:80 -> 192.168.3.65:1033  
 09/22-21:03:36.314984 [**] [1:2013976:10] ET TROJAN Zeus POST Request to CnC - URL agnostic [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.3.65:1034 -> 188.72.243.72:80  
 09/22-21:03:36.316004 [**] [1:16435:6] FILE-IDENTIFY Ultimate Packer for Executables/UPX v0.62-v1.22 packed file magic detection [**] [Classification: Misc activity] [Priority: 3] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.317775 [**] [1:12798:4] SHELLCODE base64 x86 NOOP [**] [Classification: Executable code was detected] [Priority: 1] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.317808 [**] [1:12798:4] SHELLCODE base64 x86 NOOP [**] [Classification: Executable code was detected] [Priority: 1] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.341320 [**] [1:12798:4] SHELLCODE base64 x86 NOOP [**] [Classification: Executable code was detected] [Priority: 1] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.341381 [**] [1:12798:4] SHELLCODE base64 x86 NOOP [**] [Classification: Executable code was detected] [Priority: 1] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.341565 [**] [1:12798:4] SHELLCODE base64 x86 NOOP [**] [Classification: Executable code was detected] [Priority: 1] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.341625 [**] [1:12798:4] SHELLCODE base64 x86 NOOP [**] [Classification: Executable code was detected] [Priority: 1] {TCP} 188.72.243.72:80 -> 192.168.3.65:1035  
 09/22-21:03:36.341958 [**] [1:2013976:10] ET TROJAN Zeus POST Request to CnC - URL agnostic [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.3.65:1036 -> 188.72.243.72:80

6.- Using the SIEM interface to analyze the attack

a) Go to Analysis -> Security Events and search for IP address 192.168.3.65 (use IDM search filters)
b) Click on Unique Events to see the different types of alerts collected


c) Check payload of alerts with the signature snort: "ET TROJAN Zeus POST Request to CnC - URL agnostic"
POST /kartos/youyou.php
Host: ishi-bati.com

7.- Searching for the domain name in CLEAN MX database

a) Go to http://support.clean-mx.de/clean-mx/viruses.php
b) Search domain: ishi-bati.com

8.- Outcome analysis

In the results table we have a link to virustotal (click here for direct access), where we can download a malware sample for reverse engineering. As well we can see that 25 antivirus out of 41 detected it as malware, most of them naming it as a Zeus bot. Actually, in the latest scan, the number of antivirus detecting it goes up to 39. 

References

http://alienvault.com
http://communities.alienvault.com
http://virustotal.com
http://support.clean-mx.de
Posted by at 19 comments:
Labels: , , , , , , ,

Sunday, September 16, 2012

OSSIM hands-on 6: Reading a log file with OSSEC agent

In this guided exercise we are going to configure OSSEC agent, installed on a Windows system, to read logs from a file. This can be useful when we try to grab data from an application that logs directly into a file.

 For this purpose we have created a sample file in "C:\Users/Administrator/Desktop/test.txt" with the following first log line: "ourapplication: This is a test line".

1.- Configuring agent to read a file

a) Edit C:\Program Files (x86)\ossec-agent\ossec.conf
b) Add the following settings
<localfile>
<location>Path to the file</location> (be careful with slashes, format "C:\directory/file")
<log_format>syslog</syslog>
</localfile>
c) Restart ossec-agent service

2.- Test that the log line is sent to the server

a) Write the log line in the file and save
b) Check in OSSEC server the file archives.log (logall option need to be set to "yes" in ossec.conf first)

3.- Create a new decoder at OSSEC server to parse the incoming log lines

a) At the server edit /var/ossec/etc/local_decoder.xml (same as decoder.xml but this one is not overwritten when updating the system)
b) Create a new decoder to parse first part of the log message
<decoder name="ourapplication">
<prematch>^ourapplication: </prematch>
</decoder>
c) Restart ossec
d) Run /var/ossec/bin/ossec-logtest and paste the log line
e) Check if it recognizes the decoder

4.- Create a new rule at ossec server to parse lines pre-parsed by the decoder

a) At the server edit /var/ossec/rules/local_rules.xml
<group name="ourapplication">
<rule id="99990" level="0">
<decoded_as>ourapplication</decoded_as>
<description>ourapplication is enabled</description>
</rule>
<rule id="99991" level="1">
<if_sid>99990</if_sid>
<match>Brian</match>
<description>Brian string found</description>
</rule>
</group>
b) Restart ossec
c) Run /var/ossec/bin/ossec-logtest and paste the log line (in our case "ourapplication: Brian says hello")
d) Check if it recognizes the rule

5.- Check that ossim-agent reads the alert.log file and the event is processed by OSSIM

a) Check /var/ossec/logs/alerts/alert.log
b) Check /var/log/ossim/agent.log
c) Check /var/log/ossim/server.log
d) Add 99991=7999 to the translation table of ossec.cfg (this is because that value is used for the plugin_id)
d) Insert new plugin_sid with value 99991 for ossec plugin:
INSERT IGNORE INTO plugin_sid(plugin_id, sid, category_id, class_id, reliability, priority, name) VALUES(7999, 99991, NULL, NULL, 1, 2, "ossec: our application_brian_rulematch");
e) Restart ossim-server
f) Generate new logs and look in the GUI for the results

6.- Optionally we can also enable file integrity checking

a) At the windows system edit ossec.conf file (C:\Program Files (x86)\ossec-agent\ossec.conf)
b) Under syscheck options change frequency to 30 seconds (how often the integrity check is going to run)
c) Include the log file we are monitoring
<directories check_all="yes">C:\Users/Administrator/Desktop/test.txt</directories>
d) Save and restart ossec-agent service
e) Check ossec-agent logs C:\Program Files (x86)\ossec-agent\ossec.log
f) Modify the file, delete it, create a new one with the same name
g) Check if new ossec alerts have been generated at ossec server
h) Check if there are new events related with this in the SIEM interface
Posted by at 4 comments:
Labels: , ,

OSSIM hands-on 5: Installing OSSEC agent in a Windows server

Welcome to another OSSIM hands-on practical exercise. In this case we are going to collect Windows events using OSSEC HIDS agent.

1.- Download OSSEC agent into the windows system:

a) Open a browser and connect to the IP of OSSIM server (10.0.0.30)
b) Go to Configuration -> Collection -> Downloads
c) Download OSSEC agent for Windows

2.- Run the downloaded executable and install the agent following the wizard

a) For the server use the OSSIM server IP address

3.- Create a new OSSEC key for the agent

a) At GUI go to Analysis -> Detection -> HIDS
b) Go to agents (top right corner)
c) Add a new agent
d) Copy the key and use it at the agent

4.- Restart agent at the Windows server

 a) A new Windows service can be found named ossim-agent
 b) Restart the service

5.- Check that the agent is working

a) Logout and Login in the Windows system
b) See in the GUI that the events have been collected and processed


6.- Troubleshooting 

a) Check ossec agent logs at C:\Program Files (x86)\ossec-agent\ossec.log
b) Check ossec configuration file at C:\Program Files (x86)\ossec-agent\ossec.conf
Posted by at 32 comments:
Labels: , , ,

OSSIM hands-on 4: Collecting syslog data from a Linux system

This is the fourth of a series of hands-on exercises that are intent to help OSSIM users to configure their system In this post we will cover how to collect syslog data from a Linux system (10.0.0.80), using syslog filters, enabling files rotation and activating ssh plugin.

1.- Connect to the source Linux system and configure syslog forwarding to sensor (10.0.0.31)

a) edit /etc/rsyslog.conf and see $IncludeConfig variable
b) create a new file named /etc/rsyslog.d/alienvault.conf with the following rule:
*.* @10.0.0.31
c) restart rsyslogd

2.- Connect to sensor (10.0.0.31) and test that we are actually receiving syslog data

a) Run a tcpdump to monitor incoming traffic through syslog port (udp 514)
- generate authentication logs at the source system so new evens are forwarded through syslog
b) See /var/log/syslog file to check if the remote data is also written there.

3.- Configure rsyslog rules manage remote incoming data

a) create a new file named /etc/rsyslog.d/10.0.0.80.conf (that is the source system ip address)
b) add new rules to 10.0.0.80.conf file:
if ($fromhost == '10.0.0.80') and ($rawmsg contains 'ssh') then -/var/log/ossim/ssh.log
if ($fromhost == '10.0.0.80') then ~
c) add comments (using #) explaining what are those rules supposed to do
d) restart rsyslogd

4.- Configure ssh plugin to read /var/log/ossim/ssh.log and restart ossim-agent

5.- Check that ssh logs at source Linux box are being parsed and processed by the siem

6.- Configure log file rotation

a) edit /etc/logrotate.d/rsyslog and include new file (/var/log/ossim/ssh.log)
b) force logrotation (logrotate -f /etc/logrotate.d/rsyslog)
c) check that new syslog file has rotated and that ossim-agent process is reading the new file (generate new events if needed)

7.- Rsyslog debugging

a) create file /etc/rsyslog.d/debug.conf with the following content:
*.* /var/log/all.log;RSYSLOG_DebugFormat (this will apply the template RSYSLOG_DebugFormat to incoming messages)
b) restart rsyslog
c) check /var/log/all.log file and see existing properties to identify variables that can be used for filtering
d) disable debugging 
mv /etc/rsyslog.d/debug.conf /etc/rsyslog.d/debug.conf.disabled
restart rsyslog

8.- Add a new filtering rule to write sensor ssh logs into /var/log/ossim/ssh.log too

a) create a file named /etc/rsyslog.d/10.0.0.31.conf
b) use necessary properties to create a new rule
c) don't use a discard rule (~) in this case, so rest of local logs can be written to their files.

9.- Collected logs at the SIEM GUI



References

http://alienvault.com
http://communities.alienvault.com
Posted by at 37 comments:
Labels: , ,

OSSIM hands-on 3: Creating a custom OSSIM plugin

This one is the third post regarding the series of practical exercises for OSSIM users. Now we are going to create a custom plugin to process Exchange Web Server logs through the SIEM engine.

Exchange Web SMTP server logs

The log file used for this practical hands-on exercise can be downloaded here: exchangews.log

Once downloaded, open the file to see the logs we are going to parse. Here are some sample lines:
 2011-10-09 05:00:19 1.1.1.1 36A42160 SMTPSVC1 MEE-PDC 192.168.1.2 0 QUIT - 36A42160 240 6219 68 4 0 SMTP - - - -  
 1.1.1.10 - 1.1.1.9 [11/Oct/2011:13:16:40 -0600] "HELO -?+1.1.1.9 SMTP" 250 46

Creating the plugin configuration file - exchangews.cfg

1.- Global plugin configuration settings
  • Copy ssh.cfg into another one named exchangews.cfg
  • Change the plugin_id field (use 9001 as it is part of the user range that goes up to 10000)
  • Change location to point to the log file /var/log/exchangews.log
  • Delete startup and shutdown fields since those are not going to be used (there is no application associated to this plugin)
  • Create new translation table:
    • HELO=1
    • MAIL=2
    • RCPT=3
    • DATA=4
    • QUIT=5
    • xxxx=6
    • DEFAULT_=9999

 2.- Creating new rules, filling up the fields below

 We will create two regular expressions to parse the data, since we have two different formats in the log file.
 [exchangews - Generic rule]
 #2011-10-09 05:00:15 1.1.1.1 36A42160 SMTPSVC1 MEE-PDC 192.168.1.2 0 HELO - +36A42160 250 0 48 13 0 SMTP - - - -  
 #2011-10-09 05:00:16 1.1.1.1 36A42160 SMTPSVC1 MEE-PDC 192.168.1.2 0 MAIL - +FROM:+<test@sample1.com> 250 0 57 45 0 SMTP - - - -  
 event_type=event  
 regexp="(?P<date>\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2})\s(?P<src_ip>\IPV4)\s(?P<userdata2>\S+)\s(?P<hostname>\S+)\s(?P<userdata3>\S+)\s(?P<dst_IP>\IPV4)\s\d\s(?P<type>\w+)"  
 date={normalize_date($date)}  
 plugin_sid={translate($type)}  
 dst_ip={resolv($dst_ip)}  
 src_ip={resolv($src_ip)}  
 hostname={$hostname}  
 userdata2={$userdata2}  
 userdata3={$userdata3}  
 [exchangews = Generic rule 2 NCSA Format]  
 #1.1.1.10 - 1.1.1.9 [11/Oct/2011:13:16:40 -0600] "HELO -?+1.1.1.9 SMTP" 250 46  
 #1.1.1.10 - 1.1.1.9 [11/Oct/2011:13:16:41 -0600] "MAIL -?+FROM:+<Keith@testdomain.com> SMTP" 250 46  
 event_type=event  
 regexp="(?P<src_ip>\IPV4)\s-\s(?P<dst_ip>\S+)\s\[(?P<date>\d\d\/\w{3}\/\d{4}:\d\d:\d\d:\d\d)\s-\d{4}\]\s\"(?P<type>\w+)"  
 date={normalize_date($date)}  
 plugin_sid={translate($type)}  
 dst_ip={resolv($dst_ip)}  
 src_ip={resolv($src_ip)}

3.- test exchangews.cfg file against the log file (/var/log/exchangews.log)
/usr/share/ossim/scripts/regexp.py /var/log/exchangews.log /etc/ossim/agent/plugins/exchangews.cfg q

Creating database file - exchangews.sql

1.- Create the file using the following examples

 INSERT INTO plugin (id, type, name, description) VALUES (9001, 1, 'exchangews', 'Exchange E-mail Web server');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (9001, 1, NULL, NULL, 'exchangews: HELO' ,3, 2);
…
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (9001, 9999, NULL, NULL, 'exchangews: Generic exchange event' ,3, 2);

2.- Insert file values into the database at the server box (10.0.0.30 in case you are following the other hands-on exercises)

 cat exchangews.sql | ossim-db

3.- Apply changes in the SIEM

 /etc/init.d/ossim-server restart

Enable the plugin on the sensor

  • Edit /etc/ossim/agent/config.cfg.orig and add a new line with exchangews plugin.
  • Enable the plugin using ossim-setup command.
  • Check that ossim-agent is reading the log file with lsof +d command.
  • Insert new logs into the file (using cat >>).
  • Check in the web interface that those events have been processed.


Results and troubleshooting

For troubleshooting check the log files at:
  • /var/log/ossim/agent.log
  • /var/log/ossim/server.log

 This exercise resulting files can be downloaded here:

References

http://alienvault.com
http://communities.alienvault.com
Posted by at 4 comments:
Labels: ,

Saturday, September 15, 2012

OSSIM hands-on 2: Configuring distributed profiles

This is the second hands-on exercise designed to help OSSIM users be able to distribute Server and Sensor profiles.

 We will be using the current published release version (4.0.2) with IP 10.0.0.30 acting as the server, and IP 10.0.0.31 acting as a sensor.

Configuring server (10.0.0.30)

1.- Edit /etc/ossim/ossim_setup.conf and set these variables
server_ip= 10.0.0.30
framework_ip=10.0.0.30
hostname=server
vpn_infraestructure=yes
vpn_net=192.168.1 (defines vpn network range for server-sensor communications)

2.- Add new hostname to /etc/hosts and /etc/hostname

3.- Run ossim-reconfig and check server network socket
server:~# ossim-reconfig -c -v -d
server:~# netstat -nap | grep -i ossim-server
tcp        0      0 0.0.0.0:40001           0.0.0.0:*               LISTEN      16678/ossim-server

4.- Generate VPN configuration files for the new sensor
server:~# ossim-reconfig --add_vpnnode=10.0.0.31 (sensor IP)
server:~# scp /etc/openvpn/nodes/10.0.0.31.tar.gz root@10.0.0.31:/etc/openvpn/

Configuring sensor (10.0.0.31)

1.- Edit /etc/network/interfaces to use static IP 10.0.0.31
sensor:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.0.31
netmask 255.255.255.0
gateway 10.0.0.200
sensor:~#/etc/init.d/networking restart 

2.- Edit /etc/ossim/ossim_setup.conf (at the sensor)
admin_ip=10.0.0.31
admin_gateway=10.0.0.200
hostname=sensor
sensor:~# ossim-reconfig - c -v - d

3.- Add new hostname to /etc/hosts and /etc/hostname

4.- Uncompress VPN tar file and restart Openvpn
sensor:~# cd /etc/openvpn
sensor:~# tar -xvzf 10.0.0.31.tar.gz
sensor:~# /etc/init.d/openvpn restart

5.- Configure sensor settings at /etc/ossim/ossim_setup.conf
profile=Sensor
server_ip=192.168.1.1 (vpn server IP)
framework_ip=192.168.1.1 (framework server IP)
detectors=ossec, ssh (enabling ssh and ossec plugins)
sensor:~# ossim-reconfig -c -v -d

Check Sensor and Server communications

1.- Check log files
sensor:~# tail -f /var/log/ossim/agent.log
server:~# tail -f /var/log/ossim/server.log

2.- Insert sensor and check results
Go to Configuration -> Alienvault Components and insert sensor with ip 192.168.1.10 (sensor IP in the VPN). After that, try to log into the sensor through SSH to generate some new events. Then check the results in the GUI under Analysis -> SIEM.


Posted by at 4 comments:
Labels: , , , ,

OSSIM hands-on 1: Setting up OSSEC and SSH plugins

This is the first of a series of hands-on practical exercises on how to configure OSSIM components. In this case we will just enable both OSSEC and SSH plugins and test that those work as expected.

Enabling plugins

These steps work for an all-in-one profile system. For distributed deployments with several sensors, we would need to edit sensors configuration and set the profile variable to "sensor".

1.- Check configuration variables at /etc/ossim/ossim_setup.conf
  • Global variables
    • admin_gateway=10.0.0.200 (set it to your system gateway)
    • admin_ip=10.0.0.30 (set it to your system ip)
    • admin_netmask=255.255.255.0 (use your network mask)
    • profile=Database, Server, Framework, Sensor
    • framework_ip=127.0.0.1
    • server_ip=127.0.0.1
  • Under sensor settings
    • detectors=ossec, ssh
2.- After saving changes, apply those running ossim-reconfig
  # ossim-reconfig -c -v -d

3.- Check with lsof that ossim-agent process is reading the log files
  # lsof +d /var/log/ | grep auth.log
  # lsof +d /var/ossec/logs/alerts/ | grep alerts.log

 Both auth.log and alerts.log are the files where SSH and OSSEC write their logs. The plugins configuration files (located in /etc/ossim/agents/plugins) point to those locations.

Checking that plugins work

First of all try to log into the system with a non existent user.

#Eagle:~ santiago$ ssh test@10.0.0.30
test@10.0.0.30's password:
Permission denied, please try again.
test@10.0.0.30's password:
Permission denied, please try again.
test@10.0.0.30's password:
Permission denied (publickey,password).

#tail -f /var/log/auth.log
siem:/var/ossec/logs/alerts# tail -f /var/log/auth.log
 siem:/var/ossec/logs/alerts# tail -f /var/log/auth.log  
 Sep 14 23:53:25 siem sshd[8162]: pam_unix(sshd:auth): check pass; user unknown  
 Sep 14 23:53:25 siem sshd[8162]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.200  
 Sep 14 23:53:27 siem sshd[8162]: Failed password for invalid user test from 10.0.0.200 port 63952 ssh2  
 Sep 14 23:53:28 siem sshd[8162]: pam_unix(sshd:auth): check pass; user unknown  
 Sep 14 23:53:31 siem sshd[8162]: Failed password for invalid user test from 10.0.0.200 port 63952 ssh2  
 Sep 14 23:53:32 siem sshd[8162]: pam_unix(sshd:auth): check pass; user unknown  
 Sep 14 23:53:35 siem sshd[8162]: Failed password for invalid user test from 10.0.0.200 port 63952 ssh2  
 Sep 14 23:53:35 siem sshd[8162]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.200  
 Sep 14 23:54:01 siem CRON[8263]: pam_unix(cron:session): session opened for user root by (uid=0)  
 Sep 14 23:54:03 siem CRON[8263]: pam_unix(cron:session): session closed for user root
#tail -f /var/ossec/logs/alerts/alerts.log
 ** Alert 1347692016.425295: - syslog,sshd,invalid_login,authentication_failed,  
 2012 Sep 14 23:53:36 siem->/var/log/auth.log  
 Rule: 5710 (level 5) -> 'Attempt to login using a non-existent user'  
 Src IP: 10.0.0.200  
 User: (none)  
 Sep 14 23:53:35 siem sshd[8162]: Failed password for invalid user test from 10.0.0.200 port 63952  
 ssh2

Visualizing events in OSSIM GUI

1.- Log into https://your_system_ip (if it is your first login, create the Admin user)

2.- In case the sensor is not configured, add it at Configuration -> Alienvault Components

3.- Browse to Analysis -> SIEM and search for your username (in our case "test")



The new SSH and OSSEC events have been collected and processed by the SIEM as expected. 

Troubleshooting

If the events don't appear in the interface, try looking at OSSIM components logs:

# tail -f /var/log/ossim/agent.log
# tail -f /var/log/ossim/server.log

As well check your policies and default server behavior (at Confuration -> Alienvault Components -> Servers).

Finally mention that OSSIM software version used for this hands-on exercise is 4.0.2, both for ossim-agent and ossim-server packages.

References

http://alienvault.com
http://communities.alienvault.com
Posted by at 3 comments:
Labels: , , ,