TheTAZZone - Internet Chaos

Cisco PIX – Slightly Advanced Configuration

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM 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

[size=150][u][b]3. Slightly Advanced PIX Configuration[/b][/u]
[/size]
If you have read part two you will know we have configured the PIX for basic operation; we have gave it a name, assigned IP addresses, speed/duplex setting and gave security levels to the interfaces. We configured NAT from the INSIDE to the OUTSIDE interfaces.
So now anything attached to the INSIDE interface will be allowed to send traffic to the internet and will pick up and external IP address when doing so.

Due to the security levels in place any traffic that comes to the OUTSIDE interface will be denied unless it is a return packet from an already existing connection that was initiated from a host on the INSDIE network. So although we are only using about 10% of the functionality of the PIX, it is still doing its job and protecting our INSIDE network with a very minimal configuration.

Before we moved on to a few advanced configuration commands, I will first cover a few things that can make our job easier when we come to configure the PIX and how to view information about our configuration. It is easy to get confused when using the command line when it comes to things like setting up VPN’s, upgrading firmware etc, so the following our commands we can use to simplify these tasks.

[u][b]Names[/b][/u]

When you have a lot of hosts on your LAN all obviously with different IP addresses it becomes hard to remember all the different IP addresses and can sometimes lead to very serious configuration errors. To ease these problems Cisco have introduced the ‘name’ command.
The name command allows us to assign a name to an IP address and once we have told it of this translation we are allowed to use the name of the host in place of the IP address in all subsequent configuration tasks.

[code]London (config)# names
London (config)# name 10.10.10.20 seans_pc
London (config)# name 80.80.80.85 Web-Server1
London (config)# name 192.168.1.20 DMZ_WEBSERVER-10
[/code]

We can use the following characters (up to a maximum of 16) when naming a host; a-z, A-Z, 0-9, – and a _.
It works in the same way DNS does except it is just a local naming table for the PIX to use, nothing else.

*I make a habit to always use UPPERCASE when naming a host, as it stands out easier when looking at your configuration, especially when it comes to reviewing ACL’s*

The above example is easy enough to understand, we can now use [b]seans_pc[/b] in all subsequent configuration commands instead of using 10.10.10.20.

If we want to delete of change a name, we can delete it all together by putting the ‘no’ command in front of it.

[code] London (config)#no name 10.10.10.20 seans_pc[/code]

If we want to clear all of the name we can use the ‘clear configure names’ command:

[code] London (config)# clear configure names[/code]

Finally if we want to view all of the names we have translated we use the ‘show names’ command.

[code] London (config)#sh names[/code]

So to put al this in to context here is a sample configuration using most of the commands covered in this and previous papers:

[code]London>en
Password
London# conf t
London (config)#interface e0
London (config-if)# nameif outside
London (config-if)# security-level 0
London (config-if)# speed 100
London (config-if)# duplex full
London (config-if)# ip address 80.80.80.80 255.255.0.0
London (config-if)#end
London# conf t
London (config)#int e1
London (config-if)#name-if inside
London (config-if)#security-level 100
London (config-if)#speed 100
London (config-if)#duplex full
London (config-if)#ip address 10.10.10.1 255.255.255.0
London (config-if)#end
London (config)# conf t
London (config)#int e2
London (config-if)#name-if DMZ
London (config-if)#security-level 50
London (config-if)#speed 100
London (config-if)#duplex full
London (config-if)#ip address 192.168.1.5 255.255.255.0
London (config-if)#end
London# conf t
London (config)#names
London (config)# name 80.80.80.81 WEB-SERVER-1
London (config)# name 10.10.10.20 SEANS_PC
London (config)# name 192.168.1.20 DMZ-WEBSERVER-10
London (config)# nat-control
London (config)# nat (inside) 1 0.0.0.0 0.0.0.0
London (config)#global (outside) 1 80.80.80.82–80.80.80.250
London (config)#nat (dmz) 2 192.168.1.0 255.255.255.0
London (config)#gloabal (outside) 2 80.80.80.10-80.80.80.79
London (config)# route outside 0.0.0.0 0.0.0.0 192.168.100.1 1
London (config)#route inside 10.10.10.0 255.255.255.0 10.10.10.2 1
London (config)#end
London# wr mem
[/code]

In the above configuration example we have configured the interfaces with IP addresses, names and speed/duplex settings – then we names some hosts on the various networks and also named an IP address on the outside network that we may use for a static NAT later on – then we used the nat-control command which says that everything must have a valid NAT translation – we told the PIX that everything on the INSIDE interface needs to be translated to an address that is in global pool 1 – and then we told it that everything on the 192.168.1.0 network on the DMZ interface needs to be translated to an address in global pool 2 when it leaves the OUTSIDE interface – we told it where to send traffic destined for an unknown IP address by putting in a static route on the outside interface and finally we entered a default route in the inside interface to tell it where to send traffic destined for the 10.10.10.0 network. W also wrote the configuration to the start-up configuration by issuing the ‘write memory’ command, so now are configuration is safe should the PIX suffer a power cut or should we mess up the running configuration we can reload the PIX and revert back to the configuration we know works.

Now we have a configuration we want to keep, we may need to review it when entering other commands to ensure we are doing it correctly. There are a multitude of show (sh for short) command we can use to see various settings.
Most show commands are entered from the privileged mode (the hostname# prompt) and not the configuration mode:

[code] London# sh run[/code]

Will show the entire running-configuration.

[code] London#sh run interface (sh run int – for short)[/code]

Will show the running-configuration of the interfaces only

[code] London#sh interface[/code]

Will show the statistics of all interfaces – i.e. how many packets have been sent and received, collisions, errors etc. This can be further narrowed down to specifying an interface, like so:

[code]London#sh int e1[/code]

We can view the memory usage and statistics of the PIX with the ‘show memory’ command:

[code] London#sh memory
Free memory: 493849384 bytes
Used memory: 109384928 bytes
————————————————
Total memory 603234312
[/code]

In conjunction with the Memory Usage we can also see the CPU Usage – these two commands come in very useful when troubleshooting performance problems with the PIX and to determine when you may need to upgrade it.

[code] London#sh cpu usage
cpu utilization for 5 seconds = 0%; 1 minute: 12%; 5 minutes: 78%
[/code]
This shows the average CPU utilization over 5 seconds, 1 minute and 5 minutes – if you start seeing consistently high CPU usage you are trying to do to much with your PIX and need to look into load balancing or using a higher model PIX.

*Occasionally you may get a N/A for the percentage of CPU usage, this happens if you have requested it during an interval update, issuing the command again will rectify this*

When contacting Cisco for support, upgrading your licence, firmware etc they will need certain information about your PIX such as BIOS number, serial number etc.
All this can be found with the ‘show version’ command;

[code] London#sh ver

Cisco PIX Security Appliance Software Version 7.0(1)

Compiled on Wed 10-May-06 13:22 by morlee
System image file is “flash:/PIX-701.bin”
Configuration file at boot was “startup-configuration”

Pixfirewall up 109 mins 29 secs

Hardware PIX-515, 128 MB RAM, CPU Pentium 200 MHz
Flash i28F427H5 @ 0x300, 16MB………..
BIOS Flash AT15236748 @ oxfffd8000, 32KB

This platform has an Unrestricted (UR) License

Serial Number: 289476272

Running Activation Key: 0x43345565 0x43454234 0x98642635 0x 174935139

Configuration has not been modified since last start

{OUTPUT TRUNCATED}
[/code]

If we need to see only the IP addressing in use on the PIX we can use the ‘show ip address’ command;

[code] London#sh ip address
System IP address
Interface name ip address subnet mask
Ethernet 0 outside 80.80.80.80 255.255.255.0
CONFIG
Ethernet 1 inside 10.10.10.1 255.255.255.0
CONFIG
{OUTPUT TRUNCATED}
[/code]

If we need to check what we named our interfaces we can use the ‘shoe nameif’ command;

[code] London#sh nameif
Interface Name Security
Ethernet 0 outside 0
Ethernet 1 inside 100
Ethernet 2 dmz 50
[/code]

We can review the NAT settings we have configured with the ‘show run nat’ command;

[code] London#sh run nat
nat (inside) 1 10.10.10.0 255.255.255.0
[/code]

The above output shows us we have configured the PIX to translate any host on the INSIDE interface on the 10.10.10.0 network when traversing the firewall, and the NAT ID is 1.

As we know the global command goes hand in hand with the nat command, hence the ‘show run global’ command will tell us what addresses we are using to replace the source address on outgoing packets.

[code] London#sh run global
global (outside) 1 80.80.80.81-80.80.80.250 netmask 255.255.0.0
[/code]
So we know the pool of addresses we have assigned to NAT ID 1 for the inside hosts to pick-up on the way out of the firewall.

If we want to see any translations that are currently in use with use the ‘show xlate’ command. Xlate is the translations table the PIX updates when a NAT has been setup between hosts on two interfaces.

[code] London#sh xlate
1 in use, 1 most used
Global 80.80.80.82 Local 10.10.10.20
[/code]

The above output tells us there is currently one NAT currently on going and there most ever used at one time was 1 (this is handy to check if you need to increase the pool of global addresses or not) It is also telling us the IP of 10.10.10.20 is using 80.80.80.82 to send traffic out of the OUTSIDE interface.

****************************************************************

[b][u]Internet Control Messaging Protocol a.k.a PING[/b][/u]

The ping command determines if the PIX has connectivity to networks / routers / hosts etc. As most people will know, we send out a packet and if we get a reply back then the host must have been active if it was able to reply to the ping.

If the ping was not received the command output will display ‘NO response received’. If this was to happen the first troubleshooting step is to issue the ‘show interface’ command to make sure that the interface is up and connected to the network and is passing traffic – if it is not issue the ‘show run interface’ command to review your configuration.

By default the PIX will make 3 attempts to reach an IP address.

ICMP can be configured in everyway possible on a PIX with ACL’s, you can allow all ICMP packets through both ways, allow them out but not in, in but not out, in to certain hosts but no to others, allow the interfaces to reply to ICMP requests etc. – this will be covered in much more detail later on.

If you wish to allow internal hosts to be able to ping external hosts an ACL needs to be created to allow echo replies.

If you are pinging through the PIX between routers, hosts etc and you think you have configured the interfaces and ACL’s correctly and you are sure the host is up but can not reach it for some reason, you can debug ICMP from the PIX with the command;

[code] London# debug icmp trace[/code]

Once you have configured the PIX in the same way as described so far, by default all external hosts will not be able to ping the INSIDE interface of the PIX. A rule of thumb is, if you can ping the INSIDE interface from internal hosts and if you can ping the OUTSIDE interface from an external hosts then all your routes and configurations are correct so far.

[b][u]Setting the Clock and NTP[/b][/u]

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[/code]

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[/code]

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[/code]

If you want to remove the clock set command you entered you can use the following command;

[code] London# clear configure clock[/code]

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[/code]

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.

[b][u]Network Time Protocol (NTP) [/b][/u]

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) [b]ntp server[/b] – 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) [b]ntp authenticate[/b] – Enables the NTP authentication
3) [b]ntp[/b] 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) [b]ntp trusted-key[/b] – 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
[/code]

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.

[b][u]Logging[/u][/b]

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) [b]Console[/b] – Each log message will appear on the console as the occur (only good when logged on to the console via the console port.
2) [b]Buffered[/b] – Sends all the logs to the PIX’s internal buffer and can be viewed with the ‘sh logging’ command.
3) [b]Monitor[/b] Will show the log messages on the screen when telneted in to the PIX.
4) [b]Host[/b] – Specified which syslog server will receive the log messages
5) [b]SNMP[/b] Enables the sending of log message as SNMP trap notifications.

Further to the logging methods there are 8 levels of logging we can use:

[b]0: Emergencies[/b] – System unusable messages
[b]1: Alerts[/b] – A condition has occurred that requires you to take immediate action
[b]2: Critical[/b] – A critical condition has occurred
[b]3: Errors[/b] – System error messages
[b]4: Warnings[/b] – Will display all system warning messages
[b]5: Notifications[/b] – Normal activity but of a significant nature [b]6: Informational[/b] Display any information messages
[b]7: Debugging[/b] – 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
[/code]

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[/code]

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
[/code]

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[/code]

Which will show you all your logging levels and what is being logged

[code] London (config)# clear logging buffer[/code]

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[/code]

Speaks for itself and turn all logging off.

Part 4 – In-depth NAT/PAT and how TCP/UDP connections are handled.

Leave a Reply

Your email address will not be published. Required fields are marked *

Advertise

If you'd like to advertise on The Mutt ( aka TheTAZZone.com ) feel free to contact us at: administration[at]thetazzone.com

TheTAZZone is a non-commercial entity. We do not sell any products or services ourselves. Our revenue comes from advertising and donations only.

We appreciate your support! Your advertising revenue ( or donations ) helps us to continue to upgrade, improve, and offset the costs of maintaining this site.

Donations can be made through the page ' Donate '.