NTP configurations for IDS

[CSCO10235163]

Hi all,

I'm trying to configure all IDS systems to use NTP service, but the software (IDM as well as VMS) asks for NTP server IP, Key and Key ID. All these fields seem to be mandatory. My NTP server is not configured for authentication. What can I do? Is there a way to configure IDS in order to interface with a such NTP server?

Thanks,

Chiara

[altaf007]

Actully, i have the same problem with my IDS systems using NTP. Let me know if you find any solution . Thanks

altaf

[darin.marais]

funny that! i have the same problem, pls let me know too..

[Jeffrey Bollinger]

Authenticated NTP is mandatory with the IPS sensors. Authenticating your time service is critical to ensure that the time on your events is accurate and can be trusted.

Authentication is required because a DOS attack could be launched against the sensor by spoofing the NTP server and reporting the incorrect time to the sensor. Because event queries can be based on a time-range, this could cause the management system to believe that no alarms have been generated recently.

This would theoretically allow an attacker to hide their attack from the management system by periodically shifting the clock.

An easy way to implement authenticated NTP which definitely should be used on your sensors is to install authenticated NTP on a router in your network.

Configure the router with the following commands to set it up as the NTP server:

ntp authenticate

ntp authentication-key [keyId] md5 [keyValue]

ntp source [interfaceName]

ntp master

The keyId can be any value from 1-65535. The same keyId must be entered on the sensor. The keyValue is an ascii string of 1-8 characters. The same keyValue must be entered on the sensor. The interfaceName is the name of a defined interface that the sensors can route to (e.g. "FastEthernet1/0"). The IP address of the interface must be entered on the sensor as the address of the NTP server.

More info http://www.oreilly.com/catalog/hardcisco/chapter/ch10.html

[mkirbyii]

Im running into the same issue as the others. The documentation out there to get authenticated NTP working on a *nix box is limited. I can get it to work using a router, however, I have 27 sensors and do not want to use a router.

Is there anyone who has gotten this to work on a *nix ntp server? Does cisco know that this works using *nix?

Thank you

M

[psangree]

How to use Linux/Unix as an authenticated server.

Currently Cisco IDS/IPS sensors do not support unauthenticated NTP. That feature has been requested under CSCeg35205, but is not scheduled for any software release at this time.

One way to get around this problem is to configure a router or a Linux host to act as an NTP server with authentication. That host can either act as a stand-alone server, or it can be configured to synchronize its clock to another NTP server without authentication. This allows it to act as a sort of shim between a router that does not allow authentication and a sensor that requires authentication.

Officially, Cisco IDS sensors support compatibility with only Cisco routers as the ntp server. However I have successfully used a Red Hat Linux box as the server with no problems. I've attached sample configuration files for Linux, but they should work with other flavors of *nix operating systems.

Just copy the attached file "ntp.conf" to the /etc/ directory and copy the file "keys" to the /etc/ntp/ directory (be sure to back up any existing files). Then edit those config files for your specific network as described in the comments. Then start (or restart) ntp. This is usually done by executing (as root) the startup script, such as "/etc/init.d/ntpd start" or "/etc/init.d/ntpd restart". Wait about 20 minutes before trying to set up a sensor to use the new server, because it takes a while for it to stabilize before it will accept any connections.

I'll watch this thread for a while and will try to help with any troubles you may have.

[mkirbyii]

Thank you very much for the files and information. I will test as soon as I can. Thank you again.

M

[npham]

Not sure about 5.x branch, but in 4.x, set the Key and Key ID values to 1. It'll still work with your NTP server.

[marcabal]

This will only Appear to work in 4.x, it actually does not work.

When NTP is used there are 2 types of queries done by the sensor.

The first query is special because the sensor will query the NTP server time and immediately set the sensor's time to the NTP server time.

The second and follow queries are used to constantly try to keep the sensor in sync with minor differences between the sensor and NTP server.

In version 4.x that first query to the NTP server had a bug. The bug is that the first query was not enforcing the key authentication. So a 4.x sensor could (but should not) do an intial sync to a NTP server without a key.

In version 4.x the 2nd and follow queries do work properly and the 4.x sensor will Not accept time responses from a NTP server without a key.

(If you had relied on the 4.x bug for the initial sync your sensor can become out of sync later on because the 4.x sensor does not have the bug for follow on queries)

In version 5.x we fixed this 4.x bug.

In version 5.x the initial query (as well as the follow on) will require key authentication.

So in 4.x you should Not use a NTP server without a key. The sensor may appear to be in sync, but in fact it does not stay in sync. The fact that it even did the intial sync is a bug.

So in 5.x (as it should have been in 4.x) you must use a key authenticated NTP server.

[npham]

Thanks for the clarification. Yes, the initial synch does work, and the sensors slowly drift out.

I got the info from a Cisco document actually, that said to set the values to 1 if not using authenticated NTP.

Its too bad the direction was chosen to not support non-authenticated NTP. Although it would be a good idea to use it, not everyone run it - and the risks get accepted, and mitigated with appropriate network ACLs.

Think about the Mananged Security Services out there that would love to drop-ship an IDS offering into a client premise, only to find out they will also need the client to setup or reconfigure their NTP services. Or bring along their own NTP solution. Bah.