Tag Archives: security

Tuning OSSEC Email Notifications

One of the common complaints you will encounter while working with Intrusion Detection Systems (IDSs) are about false positives and continuos notifications. OSSEC is no different, despite a global upper rule for email notifications, it continues to bombard emails for events with lower severity ratings.

Although the documentation of OSSEC states this explicitly , it does not mention which exact rules can trigger these email notifications:

“Some rules have an option set to force OSSEC into sending an alert email. This option is <options>alert_by_email</options>. One of these rules is 1002. To ignore these rules you will have to create a rule to specifically ignore it, or overwrite the rule without the alert_by_emailoption.

I sifted through the OSSEC configurations to list out the rules generating email notifications lower than the threshold limit(which is level 7 by default):

If you want to disable the email alerts, you would need to edit one or more of the above rules. I have provided the line numbers so that you can quickly refer them. I had difficulty in embedding the table above so its a screenshot (I did try airtable, but didn’t quite like it to be using here). You can download the .csv files for reference from here —

https://github.com/gravityfuel/ossec-tuning

Let’s take syslog_rules.xml as an example. As per the configuration, this is a level 2 rule and implying that it should not trigger any email notifications for the events if the global configuration for email notifications is set to Level 7 and above. But in reality, this particular rule triggers a lot of notifications if the server is public facing and the corresponding syslog entry contains any of the preconfigured key words:

Rule:

<rule id=”1002″ level=”2″>

<match>$BAD_WORDS</match>

<options>alert_by_email</options>

<description>Unknown problem somewhere in the system.</description>

</rule>

Trigger Condition:

<var name=”BAD_WORDS”>core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted</var>

Based on your environment, you can tune this further by either deleting some of the bad words or prevent this rule from triggering email alert by adding no_email_alert options

<options>no_email_alert</options>

or by commenting the default rule

<! — <options>alert_by_email</options> →

Once modified, the rule would look something like this:

<rule id=”1002″ level=”2″>

<match>$BAD_WORDS</match>

<options>no_email_alert</options>

<description>Unknown problem somewhere in the system.</description>

Ofcourse, above is only one of the many ways of minimizing notifications. Do comment on how you deal with incessant and false positive notifications.

Open Port 445, WannaCry,India, — A report

When WannaCry wrecked havoc last week there were widespread concerns that a lot of systems in India had fallen to this malware. However there were conflicting reports about the infection rate in India. Some reports cited that it was not as bad as expected while others differed.

With this in mind, I just wanted to know how vulnerable we were for this malware.

As per documents WannaCry malware tries to spread by infecting hosts that has port 445 open with Server Message Block (SMB) version 1 and running an unpatched version of Windows. Firstly, there is absolutely no need for systems to expose port 445 to internet, but why they are open could be topic for another blog post.

I looked up Shodan to identify the number of systems in India running with port 445 open to Internet. The result was a whopping 25000+ systems.

There is an interesting aspect to this. The numbers varied to a large degree over a period of week. Peeking on Weekdays and tapering on weekends. The following chart gives an overview:

On the weekdays the number of machines online with port 445 open were around 25342 at the highest while on weekends it lowered to 17000! Thats a different of nearly 8000, so looks like lot of systems are shutdown at the weekends. Do note that the Shodan crawlers work 24/7 and update the results realtime.

Though Shodan resulted around 25,000+ systems with port 445 open, not all of these machines were running vulnerable versions of Windows Operating Systems. Taking one of the days when the number was at its peak, following is the breakup:

There is however a large chunk of machines running older versions of Windows. Windows 2003/XP/2008/7/Vista accounted for nearly 65% of the servers scanned. Following chart gives the breakup of Windows Machines (Servers and Desktops editions included):

As you can see, lot of machines in India are running out of date operating systems. Note that machines like Windows Server 2003, Windows XP, Windows 7 have met their End Of Life. Microsoft went beyond its policy of not releasing security updates to their EOL products by actually releasing security updates for discontinued Operating Systems like XP, 2003 and others. If you are still running those Operating Systems please patch, better, Upgrade. Check this Microsoft page for more information — Customer Guidance for Wannacrypt Attacks

SMB Version Spread:

smb version spread in India

Note that SMB v.1 is vulnerable to WannaCry Attack

SMB Authentication Status.

For the exploit to work, SMB Authentication should be in a disabled state. Fortunately a good percentage of scanned machines seemed to have authentication enabled. Also note that exposing network shares to public is a security nightmare as it can leak data meant for internal users. At the least, enable password protection.

Top Cities in India with Port 445 Open:

Metros seemed to top the list of cities where machines were running with port 445 open. There is no reason for anyone to expose port 445 on internet. At the most they are needed for file / printer sharing and it should be limited to Local network. One should configure their firewalls to block port 445

ISPs with subscribers having Port 445 publicly exposed.

BSNL seems to operate a network with maximum number of machines having port 445 open. I am not surprised to see port 445 open is such large numbers on BSNL network. I suspect UPnP (Universal Plug n Play) feature is enabled by default in the Routers provided by BSNL and this in turn is causing the port 445 on internal hosts to be exposed! (people using BSNL/ISP Provided routers please comment)

There is an nmap script to check if the machine is vulnerable or not. To correlate the above findings, I randomly checked few machines in the list and couple of them turned out to be vulnerable, while others did not. Based on this, following seems to fit the bill for WannaCry infection:

  • Running SMB version 1.0
  • Running an unpatched version of Windows 7 / xp/ 2012/ 8 / 2003
  • Port 445 exposed to internet
  • Authentication disabled

If you are running a version of Windows and would like to check if the required patch is installed or not, please refer the article below:

https://support.microsoft.com/en-us/help/4023262/how-to-verify-that-ms17-010-is-installed

Further reading: