From OSSEC Wiki

Why is OSSEC not seeing PIX syslog messages?

• by Marty Hillman <mehillman ( at ) tech-pro.com> with lots of help from Daniel Cid

My configuration involved a Cisco PIX and OSSEC on FreeBSD 6.1.  The PIX device was configured to broadcast on 514/UDP.  In an attempt to get it to work through OSSEC, I installed syslog-ng – a very bad idea as it will take exclusive use of that port and not allow OSSEC to see the messages.  Ideally, one should not install a syslog service on the OSSEC machine or any other service that will consume ports that you may wish to monitor.  But I did and had to find a way around the problem.

Daniel gave me some troubleshooting steps that led to the resolution of my issue.   He deserves full credit for the solution that follows.  The first thing to do was to ensure that the machine was indeed receiving messages on the proper port.  Tcpdump works great for this.                

 # tcpdump -i eth0 -A -s 0 udp port 514 and host <pix_ip>

This showed me that traffic was flowing into the box on the appropriate port at regular intervals.  If you do not see any traffic when running this command, then your device is not broadcasting the requisite information or there is a firewall that is dropping the information.

Assuming that tcpdump is showing you data, you need to ensure that ossec-remoted is functioning.

 # ee /var/ossec/logs/ossec.log

There is a way to do this with netstat, but I found the log file to be an easier place to look.  At the end of the log file, you will see the ossec-remoted service.  It will tell you if it was started or not.  In my case, the log file stated that it was unable to bind to port 514/UDP.  Presumably because I had made the mistake of installing syslog-ng.

To combat the issue I had to configure the PIX to broadcast syslog messages on a different port.  PIX devices only allow broadcast on the assigned port of 514/UDP or a user defined port in the 1025/UDP to 5000/UDP range.  Since it was the lowest option and nothing else was running on that port, I configured it to broadcast on 1025/UDP.

The ossec.conf file then needs to be modified to tell the ossec-remoted service to listen on the new port using the <port> directive.

 <remote>
   <connection>syslog</connection>
   <allowed-ips>192.168.2.1</allowed-ips>  <!—ip addr of the device
   <port>1025</port>
 </remote>

Finally, the service needs to be restarted so that it will begin listening on the new port.

 # ./var/ossec/bin/ossec-control restart

If you lower your <email_alert_level> value, you should begin to see messages in your mail client.  You can also check the current log file to see if any new entries are being added to the file.  Don’t forget to put your <email_alert_value> back or you will continue to be flooded with messages.

Daniel also reported that there is a flaw in the system that could cause you to be flooded with messages.  I am having trouble locating his email, so I am not sure if it was syslog or PIX specific.  But he does have the issue patched.  If you have problems with flooding, upgrading to the latest snapshot should alleviate the problem.