Some guidelines to remember for OSSEC HIDS server operating system hardening:
The system must be dedicated to the OSSEC HIDS server and provide no other services to the network. Unnecessary software must never be installed on the server. All non-OSSEC HIDS ports must be blocked. If SSH access is required to the system, it must be restricted to other secure hosts. If used, the WUI must only be accessible from other secured hosts. The OSSEC HIDS server system must not be part of the main network authentication domain. All documented techniques for hardening the chosen operating system must be followed before installing the OSSEC HIDS.These suggestions are all intended as preventative measures to reduce the risk of unauthorized access. They also make rootkit and Trojan installation extremely difficult even during a major incursion into your network.There are many resources available for system hardening. Thankfully, the OSSEC HIDS server does not run on Windows platforms so system hardening is not complicated. Here are some starting points for Linux system hardening:
Monday, 16 December 2013
OSSEC Server System Hardening
Your Intrusion Detection System is only as secure as the system it is build upon. From the official OSSEC Host-Based Intrusion Detection Guide
, the following are tips for hardening your server's OS:
OSSEC Rules
There are a series of rules.xml files in /var/ossec/rules
To customize rules, change only the local_rules.xml file.
Rules are applied as follows:
-an Event is logged
-Pre-Decoding is done on event
-Decoding is done on event
-Rule Matching is applied
-Alerting is triggered, either to DB storage, to Email Alert, or to Active Response
Example rule to extract user and srcip from sshd:
Extracts dcid as user, and 192.168.2.180 as srcip from sample event:
See /var/ossec/etc/decoder.xml for existing decoder examples.
Important note from manual:
OSSEC Rules syntax.
Rule Alert levels
Active Responses
To customize rules, change only the local_rules.xml file.
During the upgrade process, the scripts overwrite all rules files, except the local_rules.xml file.
Any user rule created to replace a preexisting OSSEC HIDS rule must contain the overwrite="yes" option within the rule.
Rules are applied as follows:
-an Event is logged
-Pre-Decoding is done on event
-Decoding is done on event
-Rule Matching is applied
-Alerting is triggered, either to DB storage, to Email Alert, or to Active Response
Event
Sample logged event:Apr 14 17:32:06 linux_server sshd[1025]: Accepted password for dcid from 192.168.2.180 port 1618 ssh2
Pre-Decoding
Extracts hostname, program_name, datestamp, and log message of event.Decoding
Decoder options available:Example rule to extract user and srcip from sshd:
<decoder name="sshd-test"> <program_name>sshd</program_name> <regex>^Accepted \S+ for (\S+) from (\S+) port </regex> <order>user, srcip</order> </decoder>
Extracts dcid as user, and 192.168.2.180 as srcip from sample event:
Apr 14 17:32:06 linux_server sshd[1025]: Accepted password for dcid from 192.168.2.180 port 1618 ssh2
See /var/ossec/etc/decoder.xml for existing decoder examples.
Rule Matching
There are two kinds of OSSEC Rules: atomic and composite.There are two types of OSSEC HIDS rules: Atomic, which are based on single events without any correlation; and Composite, which are based on multiple events.
User-defined rules should range from 100,000 to 119,999. If you choose any other ID, it might collide with the official ones from the OSSEC HIDS projectCustom Decoders and Rules
OSSEC Rules syntax.
Rule Alert levels
Alerting
OSSEC Output and Alert OptionsActive Responses
OSSEC Agent Configuration
There are two files which manage configuration options, ossec.conf and agent.conf.
ossec.conf is present on both server and agents, and agent.conf is a file you can create on the server to have configurations pushed out to clients, possibly based on agent host name or OS type.
Default locations are /var/ossec/etc/ossec.conf, and /var/ossec/etc/shared/agent.conf
Official Documentation is here.
The OSSEC server manager only re-reads configuration files every few hours, so restarting the manager will push the configuration files more quickly. Once the configuration is pushed, run agent_control to ensure the configuration was pushed:
agent_control -i 002 #assuming 002 is the id of the agent
And then restart the agent remotely:
agent_control -R 002#assuming 002 is the id of the agent
Sample configuration sections:
To run syscheck manually on all agents:
To run syscheck manually on agent 002:
ossec.conf is present on both server and agents, and agent.conf is a file you can create on the server to have configurations pushed out to clients, possibly based on agent host name or OS type.
Default locations are /var/ossec/etc/ossec.conf, and /var/ossec/etc/shared/agent.conf
Official Documentation is here.
The OSSEC server manager only re-reads configuration files every few hours, so restarting the manager will push the configuration files more quickly. Once the configuration is pushed, run agent_control to ensure the configuration was pushed:
agent_control -i 002 #assuming 002 is the id of the agent
And then restart the agent remotely:
agent_control -R 002#assuming 002 is the id of the agent
Sample configuration sections:
File Integrity Monitoring
<agent_config os="Windows"> <syscheck> <directories check_all="yes">C:\ossec_test</directories> <scan_time>10am</scan_time> <scan_day>friday</scan_day> <frequency>360</frequency>
</syscheck> </agent_config>
Note: All queries are recursive, so only the directory must be specified. You do not need to specify all the files within the directory to monitor the directory contents.
To run syscheck manually on all agents:
/var/ossec/bin/agent_control -r -a
To run syscheck manually on agent 002:
/var/ossec/bin/agent_control -r -u 002
Rootkit Detection
<agent_config name="agent1"> <rootcheck> <location>/var/log/my.log</location> <log_format>syslog</log_format> </rootcheck> </agent_config>
Log Analysis
<agent_config os="Linux"> <localfile> <location>/var/log/my.log</location> <log_format>syslog</log_format> </localfile> </agent_config>
Thursday, 12 December 2013
OSSEC Installation Tutorial for File Integrity Montoring
Intro
We have used Osiris File Integrity Monitor for several years at work, to satisfy PCI DSS Section 11.5. (PCI Compliance, or Payment Card Industry Compliance, is something your business has to achieve to process credit card payments, and includes rules your business must follow. See here.) It has worked well, but lately we have noticed Osiris processes running out-of-control and pinning the CPU on our production servers. We have used compensating controls to produce an Intrusion Detection System, as commercial packages such as Tripwire, though very good, are very costly (like $30K/year). Osiris has not been under active development since 2007. I updated the fine open-source code and compiled new agents to install on Windows 7 computers, and have happily shared this with many people over the years who discover and decide to use this software. However old, it worked. But it's time to move on...
Still budget-constrained, our organization has decided to go with OSSEC. the Open Source SECurity Host-based Intrusion Detection System. We're just getting started with the File Integrity Monitoring part, but OSSEC also performs log analysis, policy monitoring, real-time alerting and active response. All big-ticket items in PCI Compliance. It will also do rootkit detection, which is a bonus.
Following are some notes on how to get your File Integrity Monitoring (FIM) set up. OSSEC server requires a *nix system, while client agents are available for PC/Linux/Mac/BSD/Solaris.
I will set up the OSSEC server on an Ubuntu Server 12.04 (LTS) VM running in VMPlayer, connected to my Windows 7 box. Our production environment is 100% Windows, so we will need a separate *nix server to use this software. Going forward, using OSSEC will be worth it as we use more features of OSSEC to satisfy our PCI Compliance needs.
Instructions
This tutorial assumes you are doing this on a Windows machine, and running the test VM on this machine.Prepare the VM
Download the following files:
- VMWare Player 6.0
- Ubuntu Server 12.04 (LTS)
- OSSEC v2.7.1 agent executable for Windows
Download VMWare Player and Ubuntu Server iso.
Install VMWare Player.
Open VMWare Player, create a new VM. Select Ubuntu, select the iso file you downloaded.
Boot into the Ubuntu VM.
Install gcc:
sudo apt-get install gcc make
Install OSSEC
Get OSSEC:
wget http://www.ossec.net/files/ossec-hids-2.7.1.tar.gz
wget http://www.ossec.net/files/ossec-hids-2.7.1-checksum.txt
wget http://www.ossec.net/files/ossec-agent-win32-2.7.1.exe
wget http://www.ossec.net/files/ossec-agent-win32-2.7.1-checksum.txt
Unpack and verify file intergrity:
cat ossec-hids-2.7.1-checksum.txt
[this will show the MD5 and SHA1 hash values]
sha1sum ossec-hids-2.7.1.tar.gz
[this will show the SHA1 hash value of the file, can do same with md5sum]
tar xzvf ossec-hids-2.7.1.tar.gz
Compile source:
cd ossec-hids-2.7.1/
sudo ./install.sh
Once installed, run:
/var/ossec/bin/./ossec-control start
Accept the defaults, but enter your own email address and a valid smtp server. See bottom half of this page if you are uncertain.
You can verify what's running with:
/var/ossec/bin/ossec-control status
Install OSSEC Agent
On the Windows host, run the downloaded ossec-agent-win32-2.7.1.exeOnce installed, run the app. It will ask for the server IP and key values.
Back on the Ubuntu server VM, you can get the IP with:
ifconfig
There will be an IP listed under the "eth0" section, second line, 'inet addr:' Enter this in the "OSSEC Server IP" input field in the OSSEC Agent Manager GUI on the Windows Host.
On the Ubuntu server VM:
/var/ossec/bin/./manage-agents
Here you can List your Agents, Add/Delete Agents, and get existing Keys.
Select (A) Add an agent.
Give a descriptive name for the host Agent.
Give the IP of the host (in Windows, open Powershell and type: ipconfig. Use the IPv4 Address that is listed under the section "Ethernet adapter VMWare Network Adapter VMnet1:").
Accept the default Agent ID.
Confirm.
Select (E) Extract key for an agent.
Enter this key into the "Authentication Key" input field in the OSSEC Agent Manager GUI on the Windows Host.
(Reference: OSSEC Manual, Working With Agents)
Edit ossec.conf
On the Ubuntu server VM, copy then open the configuration file:sudo mv /var/ossec/etc/ossec.conf /var/ossec/etc/ossec-BACKUP.conf
sudo vi /var/ossec/etc/ossec.conf
Below the <global> section, add:
<email_alerts>
<email_to>YourEmailAddressHere</email_to>
<rule_id>550, 553, 554</rule_id>
<!-- monitor rules: 550 changes, 553 deleted, 554 added -->
</email_alerts>
In the <syscheck> section, you can enter types of files to ignore, for example:
<ignore type="sregex">.jpg$|.jpeg$</ignore>
Read through the rest of the config file, it will be self-explanatory where to add directories to monitor or skip.
The rules to monitor changes (550) and deletions (553) are pre-defined. To add the rule to create an alert for new files (554):
sudo vi /var/ossec/rules/local-rules.xml
Under <rule id="100001" ...>, enter:
<rule id="554" level="7" overwrite="yes">
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>Added file to system.</description>
<group>syscheck,</group>
</rule>
Restart OSSEC for rules to apply:
/var/ossec/bin/ossec-control restart
Add firewall rules on Windows for UDP Port 1514.
IP Tables will be wide open on the Ubuntu server. To lock it down, this is a nice summary of what you can do. Before the final rule to block all remaning traffic, I added:
#allow pings:
sudo iptables -A INPUT -p icmp -j ACCEPT
#ossec port
sudo iptables -A INPUT -p udp -–dport 1514 -j ACCEPT
Hook this up to scheduling and reporting, depending on your needs.
More Info
Agent to Server Connection IssuesAlert Options
OSSEC Google Group
Syscheck File Integrity Monitoring
OSSEC Host-Based Intrusion Detection Guide
Agent Control
Happy Intrusion Detection and File Monitoring!
Tuesday, 3 December 2013
Skype Ubuntu Default Browser
I've got Linux Mint Nadia, which is basically Ubuntu, which is built on Debian. Using the Desktop GUI I set my default browser, but Skype didn't seem to want to honour that request. So a quick check with update-alternatives showed me the way.
Just open a terminal and type in:
$ sudo update-alternatives --config x-www-browser
There are 3 choices for the alternative x-www-browser (providing /usr/bin/x-www-browser).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/epiphany-browser 85 auto mode
* 1 /usr/bin/chromium-browser 40 manual mode
2 /usr/bin/epiphany-browser 85 manual mode
3 /usr/bin/firefox 40 manual mode
Press enter to keep the current choice[*], or type selection number: 2
$
It was set on Epiphany, I selected Chromium. You can select whatever you want. Skype will fall in line. Hope this helps.
Just open a terminal and type in:
$ sudo update-alternatives --config x-www-browser
There are 3 choices for the alternative x-www-browser (providing /usr/bin/x-www-browser).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/epiphany-browser 85 auto mode
* 1 /usr/bin/chromium-browser 40 manual mode
2 /usr/bin/epiphany-browser 85 manual mode
3 /usr/bin/firefox 40 manual mode
Press enter to keep the current choice[*], or type selection number: 2
$
It was set on Epiphany, I selected Chromium. You can select whatever you want. Skype will fall in line. Hope this helps.
Subscribe to:
Posts (Atom)