CISCO
PIX: SLIGHTLY ADVANCED CONFIGURATION CONT...
Setting the Clock and NTP
Like all network hardware the PIX has an internal clock that needs to
be set correctly for logging reason, certificate reasons etc.
*If you are having a problem with IPSec over your VPN’s the system
clock is a good first place to check!*
The PIX clock is very simple to set. We use the ‘clock set’ command to
do so;
Code:
London# clock set 12:25:00 aug 30 2006
It is fairly simple to understand and does not need any elaboration
from me!
The clock setting is retained in system memory when the PIX is powered
down and does not need to be reset every time you start it up.
The PIX can be configured to send system messages to a syslog server
which be default does not put a time-stamp on the message. The
following command will ensure the time-stamp is included with all
messages;
Code:
London# logging timestamp
Logging to a syslog server will be covered later on.
You can view the current system time with a show command;
Code:
London#sh clock
If you want to remove the clock set command you entered you can use the
following command;
Code:
London# clear configure clock
To prevent IPSec issues when daylight saving time comes in to play you
can configure the PIX to adjust the clock accordingly with the ‘clock
summer-time’ command;
Code:
London (config)# clock summer-time GMT recurring 1 Sunday April
00:01 last Sunday October 00:01
This tells the PIX we want to put the clock in to summer time mode, it
is in the GMT time zone and summer time starts at 00:01 on the first
Sunday in April and ends on the last Sunday in October at 00:01.
Network Time Protocol (NTP)
The PIX can be configured to use your networks NTP server just like
anything else on the network, it can also be told to require
authorization before updating its system clock (a common ‘hack’ that
can bring down every VPN / IPSec connection you have is to put a bogus
time server on a network to push out incorrect time details)
There are four commands we can use with NTP:
1) ntp server – Specifies the NTP server to use. The PIX will listen on
the NTP port (123) on any interface that you have configured NTP on. If
an NTP packet arrives out of the blue, in other words not as a result
of an NTP request from the PIX, the packets are dropped.
2) ntp authenticate – Enables the NTP authentication
3) ntp authentication-key – Tells the PIX what authentication key must
be used when receiving NTP updates – obviously the NTP server must use
the same key.
4) ntp trusted-key – defined which key is to be used for the NTP
updates.
So:
Code:
London (config)# ntp authentication-key 123 md5 TAZZONE123
London (config)#ntp trusted-key 123
London (config)#ntp server 10.10.10.100 key 123 source inside prefer
London (config)#ntp authenticate
In the above configuration we have told the PIX that we want to call
the trusted key 123 – it is encrypted using the md5 algorithm – and the
key is TAZZONE123.
The trusted key we want to use is the 123 one (123 is the name we
assign to the key as we could have more than one of them in use on
different interfaces. So the next one could be called ABC and the
actual key could be CISCO12345)
The NTP server has the IP address of 10.10.10.100 and we want the NTP
updates to come in on the INSIDE interface – if they come in on any
other interface they will be ignored.
Finally we told the PIX that we want to authenticate all NTP packets
with the above criteria.
Logging
If there is one area of improvement for the PIX in my humble opinion it
is the logging.
Checking the logs of a firewall is fundamental to network security;
unfortunately it looks like logging was an afterthought for the PIX.
The PIX can either store the logs as log files or export them in real
time to a syslog server. If your syslog server happened to be offline,
the PIX can store 512 messages in its memory but after that it will
start overwriting them.
There are five logging options available to us:
1) Console – Each log message will appear on the console as the occur
(only good when logged on to the console via the console port.
2) Buffered – Sends all the logs to the PIX’s internal buffer and can
be viewed with the ‘sh logging’ command.
3) Monitor Will show the log messages on the screen when telneted in to
the PIX.
4) Host – Specified which syslog server will receive the log messages
5) SNMP Enables the sending of log message as SNMP trap notifications.
Further to the logging methods there are 8 levels of logging we can use:
0: Emergencies – System unusable messages
1: Alerts – A condition has occurred that requires you to take
immediate action
2: Critical – A critical condition has occurred
3: Errors – System error messages
4: Warnings – Will display all system warning messages
5: Notifications – Normal activity but of a significant nature 6:
Informational Display any information messages
7: Debugging – Debug messaged, FTP command, HTTP URL’s being used
Level 0 is the least informative and level 8 is the most. If you
specify you want say level 5, all level 5, 4, 3, 2, 1 and 0 messages
will be logged. If you specify level 8, then all messages will be
logged for you.
There are five steps to configure logging of system messages on the PIX:
Code:
London (config)# logging host inside 10.10.10.101
London (config)# logging trap warnings
London (config)# logging timestamp
London (config)# logging device-id London
London (config)# logging on
The above configuration has told the PIX – we want to send log messages
to the syslog server with the IP address of 10.10.10.101 which is
located on the INSIDE interface – we want the log level to be warnings
(level 4 – 0 ) – we want to include the system date and time in the
messages – we want the messages to say they have came from the PIX with
the hostname of London – and finally we want to turn logging on.
As you can see the logging levels are not that great but when can
sanitize them a bit further when logging to a syslog server. The log
messages have a log-id depending on what they are logging, so a NetBIOS
log message will have a log-id of 710005 if we are being flooded with
them and don’t want to log them we can issue the following command;
Code:
London (config)# no logging message 710005
Which will stop the PIX from logging any NetBIOS messages.
You can also have different levels of logging for different messages;
Code:
London (config)# logging message 320023 level 5
London (config)# logging message 710005 level 0
London (config)# no logging message 800021
Configuring the logging level is not a quick thing and is something you
prefect over time and with regular analysis of your logs, as you detect
that you are logging a certain type of message you don’t want to, you
can stop logging it by using the message ID, if you decide you need a
higher level of logging of a certain type of message you can increase
the level of logging for the type of message.
As you can see if takes quite a bit of time to get useful logs from the
PIX and a lot of tiral and error in most cases – but once it is set-up
how you want it the logs will start to make more sense.
There are three other logging commands you may need from time to time;
Code:
London (config)#sh logging
Which will show you all your logging levels and what is being logged
Code:
London (config)# clear logging buffer
Which will clear the PIX’s log buffer completely and comes in handy
when you want to view only the latest or real time logs.
Code:
London (config)# no logging on
Speaks for itself and turn all logging off.
Part 4 – In-depth NAT/PAT and how TCP/UDP connections are handled.
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on September 12th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.