Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

syslog sending alerts to UDP 515?

Hey all, before I start writing a script to roll alerts into syslog I figured I'd make sure the box (4230) could syslog to my server. I changed /etc/syslog.conf to include the line:

local0,local1,local2,local3.debug @loghost

This started as local2.alert but grew through frustration. Also, I did use tabs, not spaces.

My /etc/hosts file has the following line:

1.1.1.1 loghost

Of course I changed the IP here for obscurity's sake.

After doing a "logger -p local2.alert hello" I get the following acl hit on my syslog machine:

denied udp 1.1.1.2(32784) -> 1.1.1.1(515), 1 packet

In fact every time I send something to syslog it tries to use UDP 515. A netstat -an shows me that the box is listening on UDP 514 and 515 as well. This makes no sense to me. Does anyone know what in tarnation is going on here and perhaps how to force the box to use 514?

Thanks for any help, Keith

1 REPLY
Cisco Employee

Re: syslog sending alerts to UDP 515?

This is because the syslog service on the sensor has been switched to work on port 515 because the nr.packetd service has to monitor port 514 for syslog messages coming from Cisco routers.

A few versions back, a feature was added to nr.packetd which allowed it to receive syslog messages from Cisco Routers and generate alarms when certain ACLs denied ip traffic.

To do this nr.packetd had to open up the UDP port 514. The router could not be configured to send to a different so port 514 was manditory.

The syslog service on the sensor itself, however, was using UDP port 514.

So the syslog service was modified (in the /etc/services file) to use UDP port 515 instead so that nr.packetd could open up UDP port 514.

Cisco does not support users making changes to the sensor's operating system or adding of their own files to the sensor. Users who choose to do this, do so at their own risk without the support of the TAC or Cisco's development teams. There multiple different modifications that were made to the underlying operating system that could cause user's problems when they try implementing their own scripts. You've run into one of these minor modifications while trying to get syslog to work to an exernal box.

So what to do?

You can't force syslog on the sensor to use port 514. If you edit the /etc/services file and change syslog back to 514, then it will compete with nr.packetd for control of the port. This will result in nr.packetd errors, and could prevent your sensor from monitoring.

Since Cisco doesn't support making modifications to the sensor OS files, or adding of use custom scripts, then I would consider deploying a solution that Cisco would support.

Cisco supports the execution of user scripts by it's enterprise IDS Management products. The new Security Monitoring Center (part of VMS2.1), and the older CSPM and Unix Director, all support the automatic execution of user created scripts when alarms of certain severities have been seen.

So instead of generating syslogs directly from the sensor, the sensor would send the alarm to your enterprise management station, which would then be configured to executed your custom script when it sees the alarm. You custom script would then generate the syslog message from the enterprise management station.

Review the documentation for your specific management product to determine and how to configure this functionality.

NOTE: IEV which comes at no extra cost with the 3.1 sensor does not support the execution of user custom scripts, if you are using IEV then you need to consider purchasing one of the supported enterprise management systems. I would recommend purchasing VMS 2.1 and using the included Security Monitor.

884
Views
0
Helpful
1
Replies