Skip navigation.
Home

Configuring the Nokia time offset on Nokia Checkpoint Firewalls

It is common that the firewalls go out of synchronization of NTP servers and the clocks starts to drift apart. With the device times going out of synchronization on the infrastructure, it could lead to problems in security events management.

Troubleshooting the Nokia time offset on Nokia Checkpoint Firewalls

Introduction

Nokia offers a suite of security products designed to enable a fundamental layer of security infrastructure with firewalls, VPN capabilities and client - management capabilities that extend applications to devices securely.

As one of the most powerful solutions in the industry, Nokia delivers firewall application, with a proprietary and hardened OS on purpose-built, high performance platforms. Nokia Firewall allows the administrator to setup NTP clients, in order to keep system time accurate and in synchronization with other devices. NTP is a recommended security practice, as it allows correlating information from multiple machines (e.g. log files) during forensics or incident response.

NTP is a UDP-based service, where NTP server listens on port 123 and the client uses a random port above 1023.

In this article will discuss about how to correct the NTP offset problem on Nokia firewalls.

Nokia Time Offset Problem

It is very common that the firewalls go out of synchronization of NTP servers and the clocks starts to drift apart. With the device times going out of synchronization on the infrastructure, it could lead to problems in security events management.

Troubleshooting Nokia Time Offset

Step 1: Check if NTP is running on the firewall

FIREWALL A[ ]# ps -aux | grep ntp
root 14848 0.0 0.2 612 1108 ?? S 8:17PM 0:01.17 /bin/xntpd
root 16628 0.0 0.0 228 124 p0 R+ 2:07AM 0:00.01 grep ntp

FIREWALL A[ ]#

Good, this tells us that NTP deamon is running on this firewall.

Step 2: Check the Time

FIREWALL A[ ]# date
Wed Dec 28 02:07:35 GMT 2005

In this case, the time was correct and only a few seconds apart from the actual time at that moment.

Step 3: NTP status query.

Run the command xntpdc –pn, where option ‘p’ shows the ntp peers and option ‘n’ is for not resolving the ip addresses to save time. The xntpdc command interface displays extensive state and statistics information. The following website link would give all the options for this command: http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds6/xntpdc.htm

FIREWALL A[ ]# xntpdc -pn
remote local st poll reach delay offset disp
==================================================
=W.X.Y.Z 5.0.0.0 16 1024 0 0.00000 0.000000 16.0000
*A.B.C.D 0.0.0.0 3 512 377 0.10312 0.000319 0.00049
FIREWALL A[ ]#

-p = Show NTP peers
-n = Don’t resolve IPs
St column = Stratum

A stratum value of 16 means that, it can’t connect to that NTP server. In this example the firewall is not able to connect to the server W.X.Y.Z. This could be due to a missing route, a firewall rule on local firewall or any other firewall between this one and the NTP server or possibly that the specified NTP server is not running.

What does the Stratum Number Mean:

Stratum 0 means an atomic clock (the main reference clock). Every hop away from that increases the stratum by 1. So the server that is connected to the atomic clock is stratum #1.

In this example, the firewall is connected to a stratum #3 server (*A.B.C.D 0.0.0.0 3 512 377 0.10312 0.000319 0.00049).

This means that there are three machines between the firewall and the atomic clock. If a client were to query the firewall for NTP, the firewall would report as a stratum #4 server.

So in this example though everything is fine with this firewall, but I have a secondary firewall connected, so lets check that.

Step 4 : NTP settings on the secondary firewall:

FIREWALL B[ ]# ps -aux | grep ntp
root 8089 0.0 0.0 332 164 p0 S+ 2:44AM 0:00.02 grep ntp

Uh Oh! The NTP deamon xntpd is not running on this firewall.

FIREWALL B[ ]# date
Wed Dec 28 02:55:08 CET 2005

The date is 31 minutes away from the actual time and it is in CET. So the first step of resolution is fixing the time on this firewall. You can do this with the command:

ntpdate NTPSERVER1 {NTPSERVER2}……

FIREWALL B[ ]# ntpdate A.B.C.D < ---------This NTP server is reachable by the firewall.
28 Dec 03:27:58 ntpdate: step time server A.B.C.D offset 1880.775280

Run the date command

FIREWALL B[ ]# date
Wed Dec 28 03:28:04 CET 2005

The time is now synchronized. To change the time zone to GMT, go to Voyager > Config > Local Time Setup.

To enable the NTP client, go to Voyager > Config > NTP >

Click on “NTP Global Settings > Enable NTP”

Add New server: Address: A.B.C.D.
Add New server: Address: W.X.Y.Z.

Apply and save.

Confirm Everything

FIREWALL B[ ]# xntpdc -pn
remote local st poll reach delay offset disp
=================================================
=W.X.Y.Z 5.0.0.0 16 1024 0 0.00000 0.000000 16.0000
*A.B.C.D 0.0.0.0 3 64 377 0.11055 0.024615 0.00148
FIREWALL B[ ]#

FIREWALL A[ ]# date
Wed Dec 28 03:21:39 GMT 2005
FIREWALL A[ ]#

FIREWALL B[ ]# date
Wed Dec 28 03:21:35 GMT 2005
FIREWALL B[ ]#

NTP server related issues could create problems in setups where Certificates are being used for authentication and VPN setups. If the times are offset, then even valid certificates can be revoked by the CRLs. Time offsets can also cause issues with IPSEC/IKE.

Search



 

Web

www.secmanager.com