Best practice security management calls for a layered approach to security. Security vulnerability scanning, firewall, strong passwords, patch management, and intrusion detection capabilities are all important layers.

OSSEC provides several functions

• Real time log monitoring.
• File integrity checking - detects changes to files and system paths.
• Rootkit detection.
• Changes to the system / running services (netstat) / disk space / password file changes.
• Real time blocking of detected attacks through firewall rule modification.
• Execute arbitrary commands based on specific events.

At the most basic level you can install OSSEC, set an email address and let it do its job alerting you to security related events on your server. It has minimal cpu impact and is great bang for buck. More advanced alerting options are available using Slack or sending logs to a SIEM or centralised security management platform.

Tuning is straight forward. You will likely only need to tune out a few things to minimise the amount of alerts you receive as generally the rate of false positives is very low.

Quick guide to installing on Ubuntu

Updated 22nd March 2020 to include new libraries (libevent, libpcre2, zlib, openssl) required for the latest versions of OSSEC. Installation was tested with OSSEC 3.6.0 on Ubuntu 18.04 (should also work on Ubuntu 20.04).

user@test:~/ossec-3.6.0/$ sudo apt install libevent-dev
user@test:~/ossec-3.6.0/$ sudo apt install libpcre2-dev
user@test:~/ossec-3.6.0/$ sudo apt install zlib1g-dev
user@test:~/ossec-3.6.0/$ sudo apt install libssl-dev

Now for the installation. For the fastest way to get started select local as the installation type, enter your SMTP server and email, then follow the defaults. This will provide a working installation that will email you when something out of the ordinary occurs. From here you can move onto tuning the local_rules for your environment.

wget https://github.com/ossec/ossec-hids/archive/3.6.0.tar.gz

user@test:~/ossec-3.6.0/$ tar zxvf 3.6.0.tar.gz
user@test:~/ossec-3.6.0/$ cd ossec-hids-3.6.0
user@test:~/ossec-3.6.0/$ sudo ./install.sh


1. What kind of installation do you want (server, agent, local or help)?  local

* If you are doing a basic install to a single server select 'local'.
This creates a single install to monitor only the server you are
installing on. See the documentation on the site for details on
setting up multiple agents on a number of servers that all report back
to a server.

2- Setting up the installation environment.

 - Choose where to install the OSSEC HIDS [/var/ossec]:

   - Installation will be made at  /var/ossec .

3- Configuring the OSSEC HIDS.

 3.1- Do you want e-mail notification? (y/n) [y]:
  - What's your e-mail address?   -- enter your email address here

 - We found your SMTP server as: example.test.com.
  - Do you want to use it? (y/n) [y]: n

  - What's your SMTP server ip/host? enter your preffered smtp server here

 3.2- Do you want to run the integrity check daemon? (y/n) [y]:
   (this is for file integrity checking, alerts you to changes to
files on your system)

  - Running syscheck (integrity check daemon).

 3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
  (this checks for rootkits on a regular basis)

  - Running rootcheck (rootkit detection).

 3.4- Active response allows you to execute a specific
      command based on the events received. For example,
      you can block an IP address or disable access for
      a specific user.
      More information at:
      https://ossec-docs.readthedocs.io/en/latest/manual/ar/

  - Do you want to enable active response? (y/n) [y]:
(this can block attacks that meet certain rules)

If you select [y] yes for Active response, you are adding Intrusion Prevention capability. This is good, but you need to white list your own IP's as you don't want Active response to trigger against your IP and auto block your access. This could happen if you failed multiple ssh logins, or if you were to run a vulnerability scan against your IP as OSSEC would detect this as an attack. Your IP would get blocked, and you would be unable to ssh to your server for example to manage it!

After compiling is complete you will be presented with final instructions:

- System is Debian (Ubuntu or derivative).
 - Init script modified to start OSSEC HIDS during boot.

 - Configuration finished properly.

 - To start OSSEC HIDS:
               /var/ossec/bin/ossec-control start

 - To stop OSSEC HIDS:
               /var/ossec/bin/ossec-control stop

 - The configuration can be viewed or modified at /var/ossec/etc/ossec.conf


   Thanks for using the OSSEC HIDS.
   If you have any question, suggestion or if you find any bug,
   contact us at contact@ossec.net or using our public maillist at
   ossec-list@googlegroups.com
   ( https://www.ossec.net/about.html#support-options ).

   More information can be found at https://www.ossec.net

   ---  Press ENTER to finish (maybe more information below). ---

That's it your done. Now start the server with:

    user@test:~/ossec-3.6.0/$ sudo /var/ossec/bin/ossec-control start

After your initial install, you will get several alerts - assuming your SMTP is configured correctly. Agent starting up, new user logged in, that sort of thing.

For 15 minutes work, you now have real-time security monitoring of your server. If you would like to test active response try our online vulnerability scans and test your hosts defence.

If you have Active response enabled, vulnerability scanners will likely get blocked, and the scan will not be completed. To run a full scan against your system with Active response enabled, try adding the scanning host to the OSSEC white-list (preferred) or disable OSSEC for the duration of the scan (not recommended). Make sure you re-enable your protection after the scan completes.

Full installation instructions are available here https://www.ossec.net/docs/manual/installation/install-source.html

The post OSSEC Introduction and Installation Guide appeared first on HackerTarget.com.

Blocking is the next step in defense

The advantages of running OSSEC on your servers are pretty obvious, especially when you start to get a few alerts, even if they are false positives. OSSEC is a quick and easy way to ensure any "interesting" changes or security events are noticed by sending an email to the configured email address. Blocking is the next step in defense. If services are being brute-forced, then you can block an IP address that is performing the brute force.

Setting up Active response

After configuring OSSEC in a default configuration with Active response disabled, you need to enable it by modifying two sets of configuration parameters in the /var/ossec/etc/ossec.conf file.

Add command block

Add a command block to /var/ossec/etc/ossec.conf. This gives a name to the executable that you are going to run (typically located in /var/osssec/active-response/).

  <command>
    <name>firewall-drop</name>
    <executable>firewall-drop.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
  </command>

Rules and alert levels

Enable Active response on specific rules or all rules above a certain alert level.

<active-response>
        <disabled>no</disabled>
        <command>firewall-drop</command>
        <agent_id>001</agent_id>
        <location>local</location>
        <rules_id>31510</rules_id>
        <level>8</level>
        <timeout>600</timeout>
</active-response>

Rather than have a specific rule in the Active response block, omit the rules_id and all rules triggered above level 8 with source IP will be blocked by the firewall drop script using iptables for 600 seconds (10 minutes). Note the command block needs to be higher in the ossec.conf file than the active response block.

Verify

To see how effective your Active response is, take a look at /var/ossec/logs/active-responses.log. Here is a snippet of one of my logs. All the noisy bots are being blocked. Alerts for this noise no longer appear in my inbox as they are quietly blocked.

Sun Aug 14 11:55:04 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 192.1xx.250.89 1471175704.407764 31510
Sun Aug 14 12:05:34 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 192.1xx.250.89 1471175704.407764 31510
Sun Aug 14 14:34:25 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 103.255.xx.69 1471185265.450999 31153
Sun Aug 14 14:44:55 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 103.2xx.15.69 1471185265.450999 31153
Mon Aug 15 23:16:49 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 82.166.1xx.x4 1471303009.783488 31510
Mon Aug 15 23:27:19 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 82.1xx.1x9.94 1471303009.783488 31510
Tue Aug 16 11:43:14 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 91.200.1x.x47 1471347794.946259 31510
Tue Aug 16 11:53:45 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 91.20x.xx2.47 1471347794.946259 31510
Tue Aug 16 11:53:47 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 91.20x.xx.47 1471348427.992693 31510

Custom Active Response Rules

Over on the SANS ISC Blog there is an excellent example of using Active Response to launch tcpdump upon the triggering of a rule.

In the example used, it specifies if an alert condition is met, then launch tcpdump and capture packets from the host that triggered the alert for 10 minutes. One use of this is to capture web attack payloads from bots / random hosts, but do not wish to capture all the web traffic. As the web attacks are detected, tcpdump automatically starts collecting packets. Of course, you will miss the initial attacks that triggered the alert, but any subsequent traffic would be collected.

It is possible to apply the same methodology to launch any command or script on your host. The possibilities are wide-ranging and only limited by your imagination.

Conclusion

That's it folks, I have written about OSSEC before and still find it to be very useful and an important part of any server build.

The post Enable OSSEC Active Response appeared first on HackerTarget.com.