[ossec-list] Re: syslog logging

[Marty E. Hillman]

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.     From: ossec-list@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Forrest Aldrich Sent: Monday, September 18, 2006 9:38 AM To: ossec-list@googlegroups.com Subject: [ossec-list] Re: syslog logging   I'm trying to figure out how to specify the <port> properly in the <remote> section - I use 2 /24's to specify my private networks there. Yes, we need to get the online docs evolving with the development. I'd like to see more verbose examples... along with some common pitfalls for newbies ;-) For example, on some sections it would be useful to have example usage... I got lost on the <location>defined-agent</location> and <agent_id>xxx</agent_id> areas - but digging through the message archives helped me figure it out. In the config section about "port" there is: port 1514 for secure or 514 for syslog Any port number (from 1 to 65535) Specifies the port to listen for events. But the precursor to that, "remove_example.xml" only has: −     <remote> <connection>secure</connection> </remote> Which isn't terribly useful ;-) I think we can collaborate to get some docs going on in the Wiki and free Dan up for coding, as he's doing a great job... and we all certainly appreciate it.   ;-) _F Marty E. Hillman wrote: I am working on typing up some notes for the Wiki on configuring this for PIX, but I finally got mine working late last week. The trick is that you do NOT need to install syslog on your OSSEC server. If you do install a syslog service, you need to configure the device to monitor with OSSEC to use a port other than 514/UDP. You also need to specify the port configuration for this alternate port in your ossec.conf file using the <port> directive under the <remote> heading for syslog. If you do not do this and you install syslog-ng, you will note in your ossec.log file that the ossec-remoted service is unable to bind to port 514/UDP because another service is already listening on that port.   Hope this helps. Detailed isntructions are coming soon.     -----Original Message----- From: ossec-list@googlegroups.com on behalf of Forrest Aldrich Sent: Sat 9/16/2006 9:06 AM To: ossec-list@googlegroups.com Subject: [ossec-list] syslog logging   I have syslog configured on my OSSEC server and agent. But I don't see any syslog messages from ossec in any of the logs. My syslog.conf has these:   *.err;kern.warning;auth.notice;mail.crit /dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages daemon.alert /var/log/alert.log security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs ftp.info /var/log/xferlog cron.* /var/log/cron   This is pretty much the stock values from FreeBSD 6.1.   Things are getting logged into the various ossec logs themselves (under /var/ossec).   Once I determine my config is correct, I want to start shipping those syslog messages over the net to another server...   I may end up using syslog-ng at some point.     Thanks.           This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.     This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.