ossec / ossec-hids

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

OSSEC v3.8.0 Copyright (C) 2019 Trend Micro Inc.

Information about OSSEC

OSSEC is a full platform to monitor and control your systems. It mixes together all the aspects of HIDS (host-based intrusion detection), log monitoring and SIM/SIEM together in a simple, powerful and open source solution.

Visit our website for the latest information. www.ossec.net

Current Releases

The current stable releases are available on the ossec website.

• Releases can be downloaded from: Downloads
• Release documentation is available at: docs

Development

The development version is hosted on GitHub and just a simple git clone away.

Screenshots

File Integrity Monitoring

Attack Detection

Help / Support

Join us on slack, ossec.slack.com: Invites to [email protected]

Join us on Discord: https://discord.gg/BXzM75Xzq7

Credits and Thanks

• OSSEC comes with a modified version of zlib and a small part of openssl (sha1 and blowfish libraries)
• This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)
• This product includes cryptographic software written by Eric Young ([email protected])
• This product include software developed by the zlib project (Jean-loup Gailly and Mark Adler)
• This product include software developed by the cJSON project (Dave Gamble)
• Atomicorp hosting the annual OSSEC conference. Presentations for the 2019 conference can be found at https://www.atomicorp.com/ossec-con2019/

ossec-hids's Issues

Windows Service contain spaces and are not encapsulated within quotes:

The following services contain spaces and are not encapsulated within quotes:

OssecSvc (C:\Program Files (x86)\ossec-agent\ossec-agent.exe)

A local attacker with low privileged access may be able to escalate to a high privileged role if successfully exploited.

Enhancements to SSL for ossec-authd and agent-auth

Hi all,

I'd like to have the ability to verify server and client certificates when using ossec-authd and agent-auth so I've been working on some enhancements to those utilities here:

https://github.com/mweigel/ossec-hids/tree/authd_certificate_verify

This functionality is aimed at organisations that want to run ossec-authd on a more permanent basis and that also have a private CA in place where client certificates are issued as part of the process of provisioning a new machine. With these enhancements users can select between:

1. No certificate verification (the current behaviour).
2. Verification of the server's certificate only.
3. Verification of the client's certificate only.
4. Verification of both server and client certificates.

Three additional command line options have been added to ossec-authd and agent-auth. If none of these options are specified then ossec-authd and agent-auth will behave exactly as they do currently.

-v
-x
-k

Only basic certificate verification is done at this stage and further enhancements could be made. I'm looking for feedback as to whether this is something that would be useful to others and whether this is something that you would consider integrating into the main project before I proceed any further, thanks.

cdb logtest and analysisd not returning the same data.

Org Ref:

• https://groups.google.com/forum/#!msg/ossec-list/qwdbTHXAIwg/pDYWz9x7U8UJ
• https://groups.google.com/forum/#!topic/ossec-list/gK5KzTO82rg

Hi everyone,

I'm having a problem getting lists to work. They work fine with ossec-logtest, but they're not working when I run ossec itself.

Here's a sample rule, in local_rules.xml:

  <rule id="100126" level="10">
    <if_sid>5715</if_sid>
    <list field="hostname" lookup="match_key">lists/list_secure_hosts</list>
    <!--
    <list field="user" lookup="not_match_key">lists/list_expected_secure_logins</list>
     -->
    <description>Unexpected user logged into a Secure machine</description>
  </rule>

(I commented out the check against the list of expected logins for testing.)

If I run this rule under ossec-logtest, it works:

Mar  5 13:58:13 secure-test sshd[20230]: Accepted publickey for jtcours from 192.168.1.1 port 53726 ssh2


**Phase 1: Completed pre-decoding.
       full event: 'Mar  5 13:58:13 secure-test sshd[20230]: Accepted publickey for jtcours from 192.168.1.1 port 53726 ssh2'
       hostname: 'secure-test'
       program_name: 'sshd'
       log: 'Accepted publickey for jtcours from 192.168.1.1 port 53726 ssh2'

**Phase 2: Completed decoding.
       decoder: 'sshd'
       dstuser: 'jtcours'
       srcip: '192.168.1.1'

**Phase 3: Completed filtering (rules).
       Rule id: '100126'
       Level: '10'
       Description: 'Unexpected user logged into a Secure machine'
**Alert to be generated.

I get the same results whether I run ossec-logtest as root or as user ossec.

However, when I run ossec itself, the rule won't match. Instead, the match stops at rule 5715. But if I comment out the check against lists/list_secure_hosts, rule 100126 matches, suggesting the problem is in searching the list.

I have this in ossec.conf:

  <rules>
    ...
    <list>lists/list_secure_hosts</list>
    ...
  </rules>

The lists are in /var/ossec/lists/, which has these permissions:

dr-xr-x---  2 root  ossec 4096 Mar  5 13:41 lists

I've recently run ossec-makelists against the files:

-rw-r--r-- 1 root ossec   58 Mar  5 13:40 list_secure_hosts
-rw-r--r-- 1 root ossec 2172 Mar  5 13:41 list_secure_hosts.cdb

and ossec-makelists recompiled the list after the most recent change.

I've tried restarting ossec using "ossec-control restart" and also by using "ossec-control stop", making sure there aren't any ossec processes running, and "ossec-control start". I also checked /var/ossec/logs/ossec.log but didn't see anything odd in there.

Any thoughts or ideas on what's breaking?

Thanks very much,
Jeff

Same expression on both sides of '&&'.

cppcheck found this in ossec-src/src/rootcheck/check_rc_pids.c on line 295. I tried to make sense of the mechanism in place but couldn't figure it out. Maybe it's just a copy&paste error as almost the same statement is on line 278 above. Someone with a more profound knowledge on how this works should take a look here.

Standard testing suite

syscheck/rootcheck scanning

It's my understanding that on the agent does not send the hashes,
and on the manager ignores the hashes sent. In both cases the
files/directories are still scanned (which I consider a bug).

@ddpbsd @mstarks01 @reyjrar raised in #47

ossec-logtest Overflow Vulnerability

I was fuzzing the binaries of ossec and found that.

COMMAND :

python -c 'print "A"*6136' | /var/ossec/bin/ossec-logtest

OUTPUT:

*** buffer overflow detected ***: /var/ossec/bin/ossec-logtest terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x4d)[0x331f4d]
/lib/libc.so.6(+0xfaf8a)[0x32ff8a]
/lib/libc.so.6(__fgets_chk+0x12e)[0x3302ae]
/var/ossec/bin/ossec-logtest(+0x337a)[0xbf137a]
/var/ossec/bin/ossec-logtest(main+0x599)[0xbf2099]
/lib/libc.so.6(__libc_start_main+0xe6)[0x24bd26]
/var/ossec/bin/ossec-logtest(+0x2f61)[0xbf0f61]
======= Memory map: ========
001fc000-00234000 r-xp 00000000 fd:00 2625871 /usr/lib/libGeoIP.so.1.4.8
00234000-00235000 rw-p 00038000 fd:00 2625871 /usr/lib/libGeoIP.so.1.4.8
00235000-003c6000 r-xp 00000000 fd:00 525192 /lib/libc-2.12.so
003c6000-003c8000 r--p 00191000 fd:00 525192 /lib/libc-2.12.so
003c8000-003c9000 rw-p 00193000 fd:00 525192 /lib/libc-2.12.so
003c9000-003cc000 rw-p 00000000 00:00 0
003cc000-003e9000 r-xp 00000000 fd:00 525169 /lib/libgcc_s-4.4.7-20120601.so.1
003e9000-003ea000 rw-p 0001d000 fd:00 525169 /lib/libgcc_s-4.4.7-20120601.so.1
00bee000-00c35000 r-xp 00000000 fd:00 1835821 /var/ossec/bin/ossec-logtest
00c35000-00c36000 r--p 00046000 fd:00 1835821 /var/ossec/bin/ossec-logtest
00c36000-00c37000 rw-p 00047000 fd:00 1835821 /var/ossec/bin/ossec-logtest
00c37000-00c40000 rw-p 00000000 00:00 0
00ca7000-00cc5000 r-xp 00000000 fd:00 525185 /lib/ld-2.12.so
00cc5000-00cc6000 r--p 0001d000 fd:00 525185 /lib/ld-2.12.so
00cc6000-00cc7000 rw-p 0001e000 fd:00 525185 /lib/ld-2.12.so
00f6f000-00f70000 r-xp 00000000 00:00 0 [vdso]
02529000-02611000 rw-p 00000000 00:00 0 [heap]
b7794000-b7795000 rw-p 00000000 00:00 0
b7796000-b779a000 rw-p 00000000 00:00 0
bfd7a000-bfd8f000 rw-p 00000000 00:00 0 [stack]
Aborted

Agent key generated differently between manage_agents and ossec-authd

It would appear that the code used to generate agent keys in manage_agents is entirely different from the analogous code in ossec-authd - mainly:

• In ossec-authd, str1 has uname information added at the end, presumably as extra entropy - comparison.
• In manage_agents, str2 contains an additional time delta at the beginning, presumably as extra entropy - comparison.
• In manage_agents, str1 is reset to a new string, based on its original MD5, the PID, the time, and yet another random number, and them re-MD5'd - again, presumably for extra entropy. There is no point of comparison here as this function is simply not performed at all in ossec-authd.

The third seems a bit hand-wavey to me, but perhaps I'm simply being a bit dense there.

The end result seems to be a key that is the concatenation of 2 MD5 sums - perhaps a single SHA256 would be simpler?

Tunable Agent Disconnect Timeout

Quick feature request. It looks like OSSEC won't recognize an Agent disconnect until 1830 seconds after the last keep alive. Would it be possible to make the disconnect time a tunable number in the OSSEC configuration?

I believe I saw mention of this in the past on the mailing list, but I've lost the thread and it doesn't look like it ever made it in to OSSEC.

Cheers!

Windows agent does not build completely on a Windows system

After the addition of the event channel, the Windows agent does not build completely on a Windows system. The event channel code is based on some mingw-64 headers that do not seem to be available in the Windows mingw environment. Is it possible to get the same headers for mingw on Windows? If not, we can only build the Windows OSSEC agent on *nix platforms.

/var/ossec path is hardcoded in several places

Sometimes it is required for ossec to be installed in a non-standard location, such as /opt/ossec. This can be done by setting USER_DIR in preloaded-vars.conf prior to configuring/compiling.

The problem is that there are a couple locations in which the /var/ossec path is hardcoded, and does not obey the USER_DIR configuration variable. I'm including a summary of the instances I was able to find below.

bin/util.sh
bin/ossec-batch-manager.pl

Vulnerability in agent-auth could lead to remote system compromise

This is to document and raise awareness for an issue in agent-auth that has existed and been known about by some developers for quite some time now. This is also related to #166, where a solution is proposed.

When using the automated key exchange functionality, the default behavior of agent-auth is that it will trust any system posing as the manager. On a local network, if ARP cache poisoning is performed, the attacker can present the agent with a key and begin receiving logs/checksums/etc of the target system.

If the agent has configured logcollector.remote_commands=1 (non-default), the attacker can now run commands as root on the target system. In an enterprise setting, since agents are typically widely deployed, this could mean a complete compromise of most of the 'nix-based infrastructure.

OSSEC should move towards using a trusted key exchange mechanism by default (secure-by-default, such as the case with the chroot, privilege separated users, etc) and not enable or permit this vulnerable behavior.

Add option to use unaltered hashes with Windows syscheck

I use OSSEC in a mostly Windows environment and find it difficult to trace back files using MD5 hashes. I know that OSSEC concatenates the MD5 and SHA1 hashes, but it seems to do that only with Windows agents. The Linux agents in use produce the correct MD5 hashes which can be verified using third-party tools.

Having the OSSEC Windows agent produce the same verifiable MD5/SHA1 hashes would enhance the forensic capabilities by allowing for a quick lookup of a file hash in a database or via the internet. Plus, it would eliminate the need to pull the same data twice from a computer.

Regards,
Mike

local_internal_options.conf lost on Windows upgrades

When the Windows agent is upgraded, it wipes out local_internal_options.conf, so any changes made that the user intended to keep will revert back to the default when they restart the agent.

Add small syscheck delay for more accurate alerts

When editing files using vim (and in other circumstances) and with realtime enabled, often there are two alerts: one that the file size changed to 0, then another that it is back at a non-zero size. I imagine inserting a small delay between the time inotify sees the change and the time OSSEC checks it would help.

Win32UI.exe Application Manifest Not Applied

Starting with Vista, applications need to have either an internal or external XML application manifest for applications that require administrator access. This elevates the application using UAC. os_win32ui.c has some code which seems to attempt to identify if the user is an administrator, and there is a .manifest file in that same directory, but it doesn't work.

Template formatting of alert emails

Some way to format or template to redefine how emails looks and and what contents they have.

ar.conf is root:root on creation

ar.conf is owned by root:root, it should be root:ossec.

Reported by Jeremiah Brock (jeremiah.j.brock gmail com) at
https://groups.google.com/forum/#!topic/ossec-list/ikXiERPtBBw

OSSEC OpenSUSE Installation Error

Sorry it took me a while to create this problem report.

Installation of OSSEC on OpenSUSE 13.1 x64 from source has some major issues. First, 3 additional (dummy) accounts are created, all with names like ossec, ossec-hids, etc. When I sign on under my usual username, I must manually go to the terminal, enter root mode, and issue the ossec start command (/var/ossec/bin/ossec-control start) to start the program. Any suggestions?

Profiles do not work on Windows

From ossec.log:
2014/04/01 17:47:58 ossec-agent(1243): ERROR: Invalid attribute 'profile' in the configuration: 'shared/agent.conf'.

Feature parity should exist among platforms except in cases where something cannot be implemented, so accordingly I'll label this as a bug.

testing again

testiong

Centralized Agent Config not being shared

http://ossec-docs.readthedocs.org/en/latest/manual/agent/agent-configuration.html
I got really excited when I read this page. I made some changes to files being watched and was glad I didn't have to hop around to all the agents and add to the conf files one by one. I edited /var/ossec/etc/shared/agent.conf with my changes, restarted /bin/ossec-control to propagate the changes faster, and let it go for a day. Two days later, checking the md5sum of my local /etc/shared/agent.conf doesn't match any agent client version.

Should I be checking that still? Or is there a different way to check for consistency without logging into an agent box?

And where do I start debugging this?

warnings/errors found by cppcheck

I wanted to get to know C/C++ a little better and ran cppcheck on ossec-hids. I found a memory/ressource leak in config/active-response.c that seemed to be easy and tried to fix it (see: ChristianBeer/ossec-hids@ec36add). However, cppcheck is silent now but I don't think this solution covers all cases. Coming from Java I usually don't care about memory leaks.

It would be great if you could point me in the right direction here. Should I try to fix those kind of warnings/errors or is it not worth the time?

Freebsd 10 use clang by default

With this ossec-hids does not build cleanly without some extra steps. We should have the install.sh check for this or make clang usable for all code (inline asm is the currect issue).

http://poop.jeremyrossi.com:8010/builders/build-fbsd/builds/0/steps/shell/logs/stdio

New Windows agent adds extra timestamp in log

I'm using a test Ossec Windows agent built from the git repository. When the Security event log gets sent to the Ossec server, it adds a second timestamp after the IP->WinEvtLog portion:

2014 Mar 21 12:53:54 (computername) x.x.x.x->WinEvtLog 2014 Mar 21 12:53:51 WinEvtLog: Security: AUDIT_SUCCESS(4689): Microsoft-Windows-Security-Auditing: (no user): no domain: computername.mycompany.com: A process has exited. Subject: Security ID: S-1-5-18 Account Name: computername$ Account Domain: mydomain Logon ID: 0x3e7 Process Information: Process ID: 0x17c Process Name: C:\Program Files\name\directory\programname.exe Exit Status: 0x0

If I switch the log_format to eventchannel, the format changes back to the old way, but I lose all the data:

2014 Mar 21 12:53:27 (computername) x.x.x.x->WinEvtLog WinEvtLog: Security: Information(4689): no source: no user: no domain: computername.mycompany.com: A process has exited.

This is on a Windows 7 x64 SP1 VM sending the logs to an OSSIM log collector. The 2.7 Ossec Windows agent works fine:

2014 Mar 21 01:28:07 (computername) x.x.x.x->WinEvtLog WinEvtLog: Security: AUDIT_SUCCESS(4689): Microsoft-Windows-Security-Auditing: (no user): no domain: computername.mycompany.com: A process has exited. Subject: Security ID: S-1-5-18 Account Name: computename$ Account Domain: mydomain Logon ID: 0x3e7 Process Information: Process ID: 0x1cb0 Process Name: C:\Windows\System32\SearchFilterHost.exe Exit Status: 0x0

Agent disconnected line doesn't show agent name

Ossec agent started has a subject line like this:

3 - Ossec agent started. - (agent_name) 1.2.3.4

Ossec agent disconnected has a subject line like this:

3 - Ossec agent disconnected. - manager_name

Agent disconnected alerts should match the agent started alerts, providing the useful agent name in the subject line.

SMS messages not going out

I've got some alerts set to send me texts, but the texts aren't coming out. Emails are working as expected. I've tested with verizon and AT&T, and no one is getting any texts when the alert level is above what should trigger texts.

Prevention tools and System Clean-Up Tools links on OSSEC.net return 404

The first two links under the Trend Micro Free Tools heading in the OSSEC.net footer don't seem to work.

• Prevention tools: Points to http://free.antivirus.com/prevention-tools/ and returns 404
• System Clean-up Tools: Points to http://free.antivirus.com/clean-up-tools/ and returns 404

hostname does not match logfile names

Sometime in the last 6 years <hostname> stopped matching the logfile path/name in a rule.

Based on a discussion on linkedin (http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=5849093138076966912&gid=25424&commentID=5851700194080485376&trk=view_disc&fromEmail=&ut=3EjAmuD3e4PC81).

<use_own_name> doesn't work in ossec-logtest

The <use_own_name> decoder option does not work in ossec-logtest. More info here: https://groups.google.com/forum/#!msg/ossec-list/TtFKNnaA6SA/yWaKXCuV5z4J

os_xml parse attribute error

os_xml.c --- > int _getattributes(FILE *fp,int parent,OS_XML *_lxml) method ,
When between attribute to '\ t', '\ n' segmentation, parse error.
and when attribute value contains '/' char , parse error too.

false-positive for checking open ports using netstat

int ret = system("netstat -an | grep \"^tcp\" | grep \"[^0-9]212 \" > /dev/null 2>&1");// port 212 is not open
printf("ret = %d \n", ret);// in my system(ubuntu12.04) it prints ret = 256

./src/rootcheck/check_rc_ports.c
int run_netstat(int proto, int port)
{
    ...(omit)...

    ret = system(nt);

    if(ret == 0)
        return(1);

    else if(ret == 1)
    {
        return(0);
    }

    return(1);// the ret is 256 so this function would return 1 for closed ports
}

http://man7.org/linux/man-pages/man3/system.3.html

The value returned is -1 on error (e.g., fork(2) failed), and the
return status of the command otherwise. This latter return status is
in the format specified in wait(2). Thus, the exit code of the
command will be WEXITSTATUS(status). In case /bin/sh could not be
executed, the exit status will be that of a command that does
exit(127).

so I suggest add ret = WEXITSTATUS(ret) to extract the real exit code of the netstat command chain.

Issues with admin detection when running win32ui.exe

The admin detection when running the win32ui.exe (the OSSEC manage agent GUI) on Windows has quite a few problems.

Starting at https://github.com/ossec/ossec-hids/blob/master/src/win32/ui/common.c#L187 the win32ui.exe starts off by using the ossec.conf file to try to determine if it was started with Administrative privileges which works fine unless a user changes the server's IP address using the UI which I'll explain a bit more later. This code seems OK to me except for the lack of error checking on the chdir call.

The first problem is when the UI uses this .test file at https://github.com/ossec/ossec-hids/blob/master/src/win32/ui/common.c#L201 to try and figure out if being run with Administrative privileges. This seems to get subjected to UAC redirection as you can pretty clearly see in this screen shot form procmon

Instead of getting ACCESS DENIED it receives a REPARSE to the appdata directory for the user where all tests will pass.

The next big problem comes when a user changes the server's IP address using the UI. The problem code is here https://github.com/ossec/ossec-hids/blob/master/src/win32/ui/common.c#L499.

After doing the renaming of files to keep a backup of the ossec.conf the file permissions are not retained/changed for the new ossec.conf file which is now readable by everyone. This means two things. The first is that this is fairly significant security issue IMO. The second is that the first test to see if admin access is working using the ossec.conf file will work even if the user does not have or run the program with Administrative privileges.

That combined with the fact that the second round of testing using the .test files are subjected to UAC redirection means that the UI can be started without Administrative prvileges.

Provide Debian packaging

It would be great if ossec sources were ready for Debian packaging "out of the box". I'd be happy to help in this regard. Basically install.sh and src/Install*.sh need to be modified to work with fakeroot and debhelper, and a new directory ./debian added with build instructions.

I've started some work on this in a fork:

https://github.com/genome-vendor/ossec-hids

But any work I do will be shortly undone if the scripts ever change. It would be nice to not have to worry about that going forward.

Is there any interest in this feature? I think the only thing I really need is a way to determine which files go in which package (common, client, server) after compilation. Right now these file locations are in ./src/Install*.sh, but you can't run those scripts without attempts to chown/chmod/useradd as well.

child rule only matches every other time

Bad issue, ignore

JSON syslog output is not correctly cleaned

Csyslogd currently only strips quotes from json_safe_message, and ignores many other characters that are invalid in a JSON string. This often causes a failure to parse at the receiving end, most often encountered with Windows events (the use of a backslash in file paths creates invalid escape sequences and some event logs entries contain newlines and tabs).

Instead of stripping the characters, it should look for and escape (via backslash) any quotation marks, backslashes, tabs, or newlines (including the carriage return for messages from Windows agents).

Agentless Diff Output Shows Changes Not Made

Well, not really, but let me explain...

We recently received an alert from our Cisco ASA agentless check that the configuration had changed. The alert contained all lines which had not changed and none which had.

As it turned out, the change had been done via the ASDM (GUI). The ASA decided to move a block of lines that had not changed somewhere else and append the line that had changed to the block. The OSSEC alert truncated the diff and so the real addition was not seen, while other lines that had not really changed were in the alert.

Pedantically speaking, this is correct. Those lines were moved, so the whole config changed. This works well for patches, but not for IDS alerts.

I propose an enhancement that does some post-processing before sending the alert. It should do something like sort the output and then compare them, or loop through the left side and compare the right, or compare the diff of the left with the right... or something. The traditional diff could still be available, but the alert should draw attention to true changes.

While this is technically not a bug, it leads to a false sense of what may or may not have changed and obscure what really did. An IDS should present a view useful to an IDS analyst, not necessarily the traditional programmatic diff viewpoint.

format source code

Can you format the source code with a tool like astyle (http://astyle.sourceforge.net/) to have a uniform look and to avoid whitespace, indentation or line ending changes?

Maybe you can create a script like https://github.com/danmar/cppcheck/blob/master/runastyle and ask everyone to run it before committing.

Rule 1003 cannot be overwritten

Specifically, using the overwrite=yes and increasing the maxsize attribute to something larger than the problem log line has no effect. It might also be that changing this attribute and not overwriting this rule is also broken. I have not tried that.

Syscheck / Rootcheck on directories with millions of files

Sometimes developers do clever things and wind up creating directories with millions of small files. This can cause a performance impact when syscheck or rootcheck cross paths with directories with this many entries. Need to investigate ways to prevent this from causing degradation.

Update rootcheck system audit files

rhel5 is pretty old at this point. What needs to be updated for rhel6?

Add local *_rcl.txt options

internal_options.conf and decoder.xml have local_* file options for individual customizations that don't get overwritten on upgrades. The policy monitoring files (i.e. rootkit, malware and audit files) would also benefit from this feature.

Windows agent compile error on linux

After running ossec-hids/src/win32/gen_win.sh, I get the following error after running the make.sh:
~/Dev/ossec-hids/src/win-pkg$ ./make.sh
Making windows agent
/usr/bin/i686-w64-mingw32-gcc
os_net/os_net.c:41:5: error: expected identifier or ‘(’ before numeric constant

The offending line in os_net.c is:
int ENOBUFS = 0;

If I modify that line to the following, the compile works:

define ENOBUFS 0

Not sure if that causes any other issues, but without that change it will never compile.

Add nolog option to client syslog

I think it would be useful to have an option where csyslogd alerts do not include the log(s) that triggered the alert. The reason is that often their is another mechanism by which all logs are saved and indexed and this results in duplicate logs. If OSSEC could be configured to just send high-level alert information, that information could be indexed as a true IDS alert as a queue to go look at the full log history around that time on the host.

Perhaps the exceptions to this are syscheck and rootcheck information, since those are generated from OSSEC, itself.

Active Response Stops Working after Manager Restart

Active Responses are not triggered on Agents after a restart of the OSSEC Manager - the Agents configured to use Active Response must first be restarted.

Workarounds:

1. Restart all agents manually using /var/ossec/bin/agent_control -R [id]
2. Use the Atomic Manager RPM, which according to the developer uses a workaround (SQL Lite DB?) so that restarts to the Manager do not impact the Agents.

This issue was originally described on the OSSEC-List:
https://groups.google.com/d/msg/ossec-list/TJfn1kTRu5I/gL0tW-IQMSsJ

Add ming window builds to travis ci

Just so a don't forget.

testing

testing....

web-log category doesn't work

In writing an IIS7 decoder, I discovered that the entire web_rules.xml ruleset doesn't work for IIS logs. The following decoder is correct:

<!-- IIS 7 child -->
<decoder name="web-accesslog-iis7">
  <parent>windows-date-format</parent>
  <type>web-log</type>
  <use_own_name>true</use_own_name>
  <regex offset="after_parent">^(\d+.\d+.\d+.\d+) (\w+) (\S+ \S+) (\d+) (\S+) (\d+.\d+.\d+.\d+) \.+ (\d+) \d+ \d+ \d+$</regex>
  <order>dstip, action, url, dstport, dstuser, srcip, status</order>
</decoder>

The type element corresponds with the category element for rule 31100 in web_rules.xml.

The following log line decodes properly and should match rule 31103, but it does not:

2014-03-26 15:37:56 192.168.2.1 GET /xp_cmdshell - 80 Anonymous 192.168.1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/33.0.1750.154+Safari/537.36 404 0 2 15

Even if I changed rule 31100 to level 1, such that no actual log content need be matched, it does not match.

This likely means that no IIS events will ever trigger any rule in web_rules.xml and they may never have. If this is true, then it is a serious bug.

Decoder identifying apache logs as pure-transfer

Title says it all. Here are some log entries to test with :

23.244.230.217 - - [23/Mar/2014:03:19:53 -0400] "GET /blog/archives/309-towards-building-more-secure-networks.html HTTP/1.1" 200 10881 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
107.22.134.166 - - [23/Mar/2014:03:20:40 -0400] "GET /robots.txt HTTP/1.1" 404 228 "-" "Mozilla/5.0 (compatible; linkdexbot/2.0; +http://www.linkdex.com/about/bots/)"
107.22.134.166 - - [23/Mar/2014:03:20:40 -0400] "GET /blog/index.php?/plugin/tag/computer HTTP/1.1" 200 10671 "-" "Mozilla/5.0 (compatible; linkdexbot/2.0; +http://www.linkdex.com/about/bots/)"
188.143.232.31 - - [23/Mar/2014:03:20:59 -0400] "GET /blog/index.php?/archives/26-Windows-XP-ISO-Mount-Utility.html HTTP/1.1" 200 47268 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Include LOCAL SYSTEM in win32 permissions

Include the LOCAL SYSTEM account in the permissions set by the win32 installation and clients mentioned by @mstarks01 in #169.