TAZ: TheTAZZone Network » cisco tutorials

Cisco PIX – Basic PIX configuration

admin — Wed, 17 Jun 2009 23:46:01 +0000

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]2: Basic PIX configuration[/b][/u][/size]

There are only 6 steps that need to be taken to enable the PIX to be able to send packets to the outside world, known by some as the PIX SIX, they are:

[b][i]Hostname
Interface
Nat-Control
Nat
Global
Route[/b][/i]

[b][u]Hostname:[/b][/u]

This assigns a host name to the PIX and should be called something that is meaningful for that particular PIX. The prompt will change to what you call the PIX when you set this and is set in the configuration mode with the command ‘hostname ’, like so:

[code]pixfirewall>en
password:
pixfirewall#conf t
pixfirewall(config)# hostname London
London(config)#
[/code]

Notice ‘pixfirewall’ now becomes ‘London’. Usually the firewall may be named after its geographic location, the service/project it is protecting etc. I look at it in such a way that if you have 3 different telnet sessions open to three different PIX’s you will always know exactly what you are configuring.

The hostname can be up to 63 alphanumeric characters in either uppercase of lowercase and defaults to ‘pixfirewall’ out of the box or when the ‘wr erase’ command is used followed by a reload.

[b][u]Interface:[/u][/b]

The interface command differs per PIX operating system, in version 7 it acts much like a Cisco router and drops you in to the ‘config-if’ sub context. On version 6.3 and earlier the prompt will not change and the command should be issued all on the one line. For this paper we are using version 7

The Interface or ‘int’ for short is the configuration command we use to allow us to alter the configuration of the PIX interfaces. We can assign it an IP address, subnet mask etc from this sub context.

[code]London (config)# interface ethernet0 (or ‘int e0’ for short)
London (config-if)#
[/code]

Notice with version 7 the prompt now changes to ‘config-if’ to let us know we are [b]config[/b]uring an [b]I[/b]nter[b]F[/b]ace.

We can now configure the interface with a name, IP address, speed settings and duplex settings amongst others.

[code]London (config-if)# nameif outside[/code]

Although it is already named outside by default the above example is to show the relevant command. ‘nameif’ as is fairly obvious, is used to assign a name to the interface.

Next we need to assign an IP address and subnet mask:

[code]London (config)# interface ethernet0 (or ‘int e0’ for short)
London (config-if)# nameif outside
London (config-if)# ip address 80.80.80.80 255.255.0.0
[/code]

If you make a mistake whilst entering this command, simply re-enter the correct information. The ‘clear configure ip’ command will clear ALL interfaces IP addresses to no IP address.

Interfaces can also be configured to pick up a DCHP assigned IP address, by using the ‘dhcp’ command.

[code]London (config)# interface ethernet0 (or ‘int e0’ for short)
London (config-if)# nameif outside
London (config-if)# ip address dhcp
[/code]

The PIX will now pick up a DCHP IP address on the OUTSIDE interface.

There are various DHCP commands we can use to view information about the DHCP IP address, such as the lease time etc

[code]London# sh ip address outside dhcp lease[/code]

And

[code]London# sh ip address outside dhcp server[/code]

The above will both provide you with information about the DHCP server and details about the IP address that the interface has been assigned.

To stop the interface from getting a DHCP IP address we use the ‘no’ command before the dhcp command. So:

[code] London (config-if)# no ip address dhcp[/code]

*Most of the commands you issue via the CLI can be disabled by re-entering them with the word ‘no’ in front of them.*

Next we need to assign a security level to the interfaces (the INSIDE and OUTSIDE interfaces have a precompiled security level, but for this example we will set them anyway).
A security level can be between 0 and 100, with 100 being the highest and most trusted. See part one if you want to read more about security levels.

To set it we use the ‘security-level’ command:

By default interfaces with the same security level can not communicate, to enable it use the ‘same-security-traffic’ command. This may be handy when you have a DMZ and you want it to be able to communicate with the INSIDE network without NAT being preformed.

[code]
London (config-if)# same-security-traffic
[/code]

Next we need to tell the interface what speed and duplex settings we want it to operate at. By default all interfaces are set to automatic detection and will try to detect the best speed and duplex settings to work at. However sometimes you may need to configure them manually.

The speeds for an Ethernet cable you can choose from are 10, 100, auto or nonegotiate.

10 = 10BASE-T
100 = 100BASE-T
Auto = automatically sets the speed
Nonegotiate = for small form factor pluggable media types (SFP) and sets the speed to 1000Mbps.

[b][u]Network Address Translation (NAT)[/b][/u]

As this paper is about configuring a PIX and not explaining how network protocols work I will very briefly explain about NAT.

Network Address Translation enables you to prevent external hosts from learning your internal IP addresses.
It accomplishes this by translating internal IP address, which is not routable over the internet, in to a globally unique IP address, which is routable over the internet. If you assigned your PC an IP address of 192.168.2.2 and tried to put it directly on the internet you would neither be able to receive or send traffic as the first router would drop your packets as soon as it saw your IP address.

This poses a problem for anyone with more than one computer behind a single connection, as if the above is true we would need an external IP address for every single computer on our network – which is obviously not possible as all the valid IP addresses would be used up very quickly.

Enter NAT.

Providing certain criteria are met the PIX will translate internal addresses to an external address as per your configuration. To anyone looking from the internet it will look like you have an external IP assigned to you and in most cases will never find out your internal address.

When an outbound IP packet that is sent from a device on the INSIDE network reaches your PIX which has NAT configured the source address is extracted and then compared with a table of existing translations. If the source address is not already in this table, it is now translated to an address taken from our external pool of addresses called a Global Pool. The table is now updated and the packet is forwarded on with our new external IP address in the source address part of the frames header.

This entry will stay in the translation table for three hours by default (this can be changed manually) if no activity is detected for this translation after the three hours it is removed and the external IP is free to be used for another host.

[b][u]Configuring NAT[/b][/u]

To configure NAT we first need to tell the PIX which hosts/networks on our INSIDE interface are allowed to be translated and them we tell it what we would like them to be translated to.

We can configure NAT on a global level with the command ‘nat-control’. If we enter the nat-control command we are telling the PIX that all addresses need to be translated before packets can be sent out of another interface.

The opposite is ‘no nat-control’ which means that all hosts can send packets and only where a specific NAT rule has been entered will a translation take place. No nat-control is the default.

There are two types of NAT policies on a PIX; Inside NAT Policy and Outside NAT Policy.

As their names suggest if Inside NAT Policy is enabled all INSIDE hosts need to have an inside NAT rule configured, likewise it Outside NAT is enabled all OUTSIDE addresses must have an outside rule configured

We configure NAT by telling the PIX, which interface the hosts/network is on that we want to translate:

[code]London (config)# nat (inside) 1 0.0.0.0 0.0.0.0[/code]

The above tells the PIX that we want to perform [b]nat[/b] on the [b](inside)[/b] interface, the [b]1[/b] is the ‘nat group’ we have assigned it, this will be come apparent later, the [b]0.0.0.0 0.0.0.0[/b] tells the PIX that we want to perform NAT on everything that is attached to the INSIDE interface. We could substitute this with 192.168.2.2 255.255.255.255 which would say that the host with that exact IP address needs to be NAT’ed or we could use 192.168.1.0 255.255.255.0 which would say that everything between192.168.0.1 and 192.168.0.255 needs to be translated.

*The 0.0.0.0 0.0.0.0 can be abbreviated to 0 0 however this can look a bit confusing to anyone not comfortable configuring a PIX so you may want to use 0.0.0.0 0.0.0.0.*

So now we have told it what IP addresses that require translating we need to tell the PIX what we want them translated to.
To do this we use the ‘global’ command.

[code]London (config)# global (outside) 1 80.80.80.81 – 80.80.80.200 netmask 255.255.255.0[/code]

The above command tells the PIX that we are assigning [b]global[/b] IP addresses on the [b](outside)[/b] from NAT group [b]1[/b] and the range of address available are [b] 80.80.80.81 – 80.80.80.200 [/b]

Our configuration so far:

[code] London (config)# interface ethernet0 (or ‘int e0’ for short)
London (config-if)# nameif outside
London (config-if)# ip address 80.80.80.80 255.255.0.0
London (config-if)# security-level 0
London (config-if)# speed 100
London (config-if)# duplex full
London (config-if)# end
London# conf t
London (config)# nat (inside) 1 0.0.0.0 0.0.0.0
London (config)# global (outside) 1 80.80.80.81 – 80.80.80.200 netmask 255.255.255.0[/code]

So now all hosts on the INSIDE interface will be translated to an address between 80.80.80.81 to 80.80.80.200 whenever the send traffic from the INSDIE interface to the OUTSIDE interface.

*If the NAT command is used there MUST be a GLOBAL command, otherwise NAT will not work*

We can use static NAT’s that NAT a specific IP address either on the INSIDE or OUTSIDE interface to another IP on a different interface but this will be covered later in the Advanced PIX Configuration papers.

[b][u]Route[/b][/u]

Just like a router we need to tell the PIX where to send traffic destined for unknown and known IP addresses. We do this by configuring Static and/or Default Routes.

A static route is basically saying ‘To send a packet to the specified network, send it to this router’

A default route tells the PIX where to send traffic destined for an IP address/network not in its routing table. We normally configure a default route to state where internet traffic should go. It is impossible to enter every IP address on the internet in to the PIX’s routing table but it is easy to enter out internal networks in to it. So we say that, if there is no entry in the routing table, then the traffic is destined for the internet so send it here. If when the packet gets to the gateway it is not destined for the internet and has an internal IP, it will be dropped for reasons mentioned earlier.

[code]London (config)# route outside 0.0.0.0. 0.0.0.0 192.168.2.1 1[/code]

The above is an example of a default route. It is saying to [b]route[/b] traffic out the [b]outside[/b] interface if the IP address is not in the routing table [b]0.0.0.0. 0.0.0.0[/b] to the router with the IP address of [b]192.168.2.1[/b] which is [b]1[/b] hop away.

[code]London (config)# route inside 10.10.10.0 255.255.255.0 10.10.10.1 1[/code]

The above is an example of a static route. This is telling the PIX that any traffic arriving on the [b]inside[/b] interface destined for the [b]10.10.10.0[/b] network should be sent to the router with the IP address of [b]10.10.10.1[/b] which is [b]1[/b] hop away.

There we have our finished initial BASIC configuration. We have named an interface, assigned it an IP address and subnet mask, told it what speed to operate at, told it that we want to NAT all hosts on the INSIDE interface to the external IP addresses of 80.80.80.81-200, we have gave it a default route to tell it where to send unknown traffic and we have told it where to send traffic destined for the internal network of 10.10.10.0.

Obviously the IP addresses are just for demonstration purposes and all interfaces will need to be configured as above for the PIX to work.

Part three will be ‘slightly advanced PIX configuration’. :

Cisco PIX – TCP, UDP, NAT, PAT and Port Redirection

admin — Tue, 09 Jun 2009 23:07:40 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

4: TCP, UDP, NAT and PAT as the PIX see’s it.

In part four I will cover how the PIX handles TCP and UDP protocols, how static and dynamic translations work, how TCP interception features work and how to configure Dynamic NAT’s, Static NAT’s across one interface and multiple interfaces.

Almost the entire world uses Internet Protocol (IP) to communicate between computers, networks etc. An IP connection between two devices is known as a session. A session predominately uses one of two protocols, TCP or UDP.

From a PIX point of view TCP is very easy to inspect as a TCP ‘packet’ follows a very strict and well defined set of rules and has a very obvious start point and end point, and also makes it very clear what protocol the payload consists of.

UDP on the other hand is a very difficult protocol to inspect for the PIX as it has no clear beginning, flow state, payload information or end.

*The definition of Outbound and Inbound traffic differs from the normal definition as far as the PIX is concerned. When dealing with a PIX Inbound traffic is deemed to be traffic coming from a less secure interface to a more secure one (one with a lower security level to one with a higher level) and Outbound traffic is deemed to be traffic flowing from a more trusted interface to a less trusted one. Usually this will be INSDIE to OUTSIDE but this may not always be the case*

Transmission Control Protocol

TCP is a connection-orientated, reliable and high performance protocol that works at the transport layer (see herefor a definition of the various layers). It is reliable due to the fact each packet has a sequence number that is incremented each time a packet is sent or received and the packets are acknowledged once they are received to indicate to the sending device the packet has reached its destination satisfactorily. Due to the nature of TCP the PIX (or anything else) can see what state a current TCP connection is in at any given time as each header has various ‘flags’ is can set to indicate what type of packet it is and what is going on in the connection.

When a TCP Session from a host on a more secure interface (for the duration of this paper we will use the INSIDE interface) is started, the PIX creates an entry in the session state filter table. As its name suggests the session state table is used for the PIX to keep tabs on the state of any given session.

The PIX can monitor a TCP session in real time and is constantly aware of what packets are going where and (if configured to do so) what is in the payload of each packet.

When the session is initiated the PIX allows the packet out, but adds the Source Address, Source Port, Destination Address, Destination Port, and a random TCP sequence number, Flag (SYN, SYN-ACK etc) in to the session table. When a packet is returned to the sending IP address, the PIX is aware of what stage the connection is at and what is expected to be returned, so a valid packet would now be addressed to the sending hosts, IP address and correct source port, is from the correct IP address and Source Port, has the correct sequence number and the correct flag (in this case a SYN-ACK).

If any one of the above details are incorrect the packet is dropped.

SO to put it in easy terms with a very simplified header:

Code: Select all: Source IP Source Port Dest IP Dest Port Flag Seq Number Ack Seq 10.10.10.20 32452 67.1.1.1 139 SYN 12345

This is the essential information that would be in the header. The PIX would then enter this information in its State Table.

Code: Select all: Inside Network 10.10.10.20 32452 67.1.1.1 139 SYN
12345

When the return packet came back it would expect to see this:

Code: Select all: Sce IP Sce Port Dest IP Dest Port Flag Seq Number Ack Seq No 67.1.1.1 139 10.10.10.20 32452 SYN_ACK 54321 12346

So the PIX checks the source IP and Port of this return packet to see if it has previously been sent any data, it looks to the session table and sees that something has indeed been sent to 67.1.1.1 to port 139 – it sees that this was sent by 10.10.10.20 from Port 34252 and then checks the destination IP of the return packet, 10.10.10.20 going to Port 32452 – so far so good – now it looks at the Flag, sees it is a SYN-ACK, due to the rules of TCP a SYN-ACK follows a SYN so when it looks at the session table for the connection it will expect to see a SYN flag – yep, all is good so far – now it looks at the Sequence number, the return packets Acknowledgment Sequence number should be the sending hosts sequence number incremented by one, 12346 – the PIX checks the state table entry and expects to see 12345 – yes all is good.

This packet meets all the requirements to be allowed through and will be sent on its journey.

*There is more to take into consideration, such as Access Rules, Fix-up protocols, Deep packet inspection etc but that is for later on, for now we will ignore them and just look at it from a Stateful Inspection point of view.*

As this session has not completed the ‘Three-way handshake’ that governs how TCP will connect two hosts together, the connection is known as an embryonic connection or a ‘half open’ connection.
No data will be sent between the two hosts until the connection is properly established. The PIX can be configured to terminate embryonic connections after a set period of time and to limit the amount any one host can have open. Once the entire three-way handshake has been completed the embryonic counter is reset for that particular connection.

There is a lot more to TCP but this paper is about how the PIX looks at and handles TCP sessions, not how TCP works. You can read this for more information on how TCP works.

User Datagram Protocol (UDP)

UDP is considered to be an efficient but connectionless protocol as unlike TCP there is no three-way handshake, session monitoring, error checking etc. Some people call it a ‘fire and forget’ protocol as once the data has been sent the sending station has no way to check if it ever reached it destination or not. There are no sequence numbers either.

For these reasons the PIX has a difficult job to try and secure a network against UDP packets….it has no sequence number to verify, no SYN, SYN-ACK etc Flags to check…the PIX has no way of knowing what state a UDP session is in, if it has ended etc so must take other measures to secure UDP traffic.

The PIX creates a ‘UDP Slot’ whenever a UDP session is initiated from a more secure interface to a less secure interface, any subsequent UDP packets that match the details in the UDP Slot are allowed through, ACL permitting.

As the PIX can’t tell when a UDP exchange has ended it starts a counter when a packet leaves, the default is 2 minutes. If a return UDP packet has not been received that fits the parameters in the UDP Slot then the slot is closed.

All UDP packets have to meet the same Stateful Source IP & Port, Destination IP & Port prerequisites that the TCP packet do, but as there is no sequencing it is relatively easy to spoof a UDP packet and maybe even get it through the firewall.

The main defence against UDP is the session timeout.

TCP Intercept and Connection Limits

Denial of Service (DoS) attacks are relatively easy to conduct due the amount of scripted software available for download today. For this reason it is in our interest to set connection limits for all incoming connections and all embryonic connections.
There are four common limits we can set:

1. TCP Maximum Connection limit – this limits the amount of connections a real IP host can have open concurrently
2. Embryonic limit – an embryonic connection is a TCP connection that has not completed a three-way handshake between the source and destination hosts.
3. UDP Maximum Connections – limits the maximum amount of concurrent UDP connections a real IP host can have open
4. Connection Timeout – The amount of time before an idle/embryonic connection is closed

SYN Flooding

As mentioned earlier, when a host uses TCP to communicate with another host it initiates a three-way handshake. Amongst other things, included in the three-way handshake are various flags that indicate the state of a connection.

When a host first makes contact with another host it sets the SYN flag in the TCP header, the receiving host the sets the SYN and ACK flags in the return packet, the first host sets the ACK packet in the subsequent packet.

A SYN flood is where we send a packet from a spoofed IP address to a host with the SYN flag set. The receiving host will send a SYN ACK packet back as expected but as the initiating IP is spoofed, there is nothing to receive the packet, hence the ACK flag that our server is waiting for to complete the third part of the handshake never comes back to it, if we flood the server with these SYN packets we will soon fill its buffer up as it will be keeping all connections open awaiting the ACK packets that will never arrive. This is what we call an embryonic connection and why we should limit the amount of them!

There is a very clever defence mechanism in the PIX to stop SYN Flooding should we reach our embryonic connection limit. If we set an embryonic limit that gets reached during a DoS attack, it would be pointless if the PIX drops all incoming SYN packets as then the DoS attack would still be successful, likewise the PIX is not about to let all SYN packets through!

To prevent the DoS attack from working the PIX uses what is know as TCP Intercept.

TCP intercept is a feature whereby if the embryonic connection limit is reached the PIX will assume responsibility for all incoming SYN packets on behalf of the server whose limit has been reached.

When a SYN packet comes in the PIX will log all pertinent state information as normal (Sequence number etc), respond with an empty SYN ACK packet and then drop the original SYN packet.
If the relevant ACK packet comes back from the server and all the state table information checks out the clients SYN segment is sent to the server and the three-way handshake takes place with the PIX and internal server instead.
Once this three-way handshake has been completed the connection will be allowed as normal.

TCP Intercept proved to be a very CPU intensive procedure and could still potentially result in a DoS state. To avoid this issue Cisco came up with a feature called SYN Cookies.

SYN Cookies

‘SYN cookies’ is a procedure PIX version 6.2 and later will use in place of TCP intercept.

When a SYN packet comes in and after the embryonic connection has been reached the PIX will still take over the three-way handshake on behalf of the server only instead of keeping stateful information like it does with TCP intercept, it will make a mathematical HASH or the destination IP, destination port, source IP, source port, sequence number and a secret key. This is then placed in the packets header in the form of a cookie and sent back to the initiation host with the relevant SYN ACK packet.

As the PIX is the only thing that knows the secret key, only the PIX will be able to decipher the return cookie

No state information is kept by the PIX thereby keeping its state table free and taking up no memory space.

When the initiating host responds with the expected ACK packet the cookie will still be in the packet header. The PIX extracts this cookie, deciphers it and calculates if it is a response to a previous SYN ACK sent out by the PIX, if so the PIX will attempt to open a connection to the server.

SYN cookies is by far a more manageable method of handling embryonic connection overflows.

The commands for all of the above are very very simple and are used with our NAT and Static commands.

Code: Select all: London(config)# static (inside, outside) 80.80.80.100 10.10.10.10 netmask 255.255.255.255 0 25

Notice the 0 and 25 at the end of the above command. The 0 sets the maximum TCP connection limit to Unlimited (this can be substituted for a number of your choice) and 25 sets the maximum embryonic connections for to 25.

*If you do not specify any limits when you use the NAT and Static commands the PIX default both to unlimited*

UDP

As we know UDP is not a stateful protocol and does not use flags to keep track of the connection state.

However, we can still be flooded by UDP connections/packets from spoofed IP addresses when we have Static NAT’s and/or PAT’s so it is a good practise to limit the number of UDP connections we will allow to a single server.

The syntax is similar to the TCP method:

Code: Select all: London(config)# static (inside, outside) 80.80.80.100 10.10.10.10 netmask 255.255.255.255 udp 100

As you can see we simply specify the protocol and the maximum amount of UDP connections that the server can have, in this case we are saying that 10.10.10.10 can have a maximum of 100 udp connections at anyone time.

A more realistic command may be:

Code: Select all: London(config)# static (inside, outside) 80.80.80.100 10.10.10.10 netmask 255.255.255.255 0 25 udp 100

Which says that 10.10.10.10 can have unlimited TCP connections, a maximum of 25 embryonic connections and a maximum of 100 UDP connections

Network Address Translation

As mentioned in Part two, NAT is a method to reduce the amount of external routable IP addresses an organization needs and also to hide the internal IP addresses from outside viewing.

When configuring NAT remember that an interface with a higher security level can access an interface with a lower security level unless they are explicitly denied.
The Nat and Global commands go hand in hand with each other.
If you want to enable a lower security level interface to access a higher security interface then you must have the relevant access rule permitting it and a static NAT / PAT translation.

The PIX supports both Static and Dynamic translations.

Static Translation
Is a permanent one-to-one translation, or mapping, between an IP address on a more secure interface to an IP address on a less secure interface. You can only statically NAT one external IP address to one inside IP address, i.e. if you NAT 80.80.80.81 to 10.10.10.20 – when traffic arrives on the OUTSIDE interface, ACL permitting, it will be directed to 10.10.10.20. 80.80.80.81 can only now be statically NAT’d to this IP address and no other, otherwise the PIX would not know where to send the incoming traffic. This is different from Port Address Translation (PAT) which can be translated to more than one IP address and will be covered later on.

You would typically use a Static NAT when you host a web server that sits on an internal IP. Obviously you want your external IP of the Web Server to always be the same, if you Static NAT it to the internal IP of the server you will ensure that when someone browses to the outside IP they will always be translated across to the correct web server.

The syntax for a Static NAT is:

Code: Select all: London (config)# static (inside, outside) 80.80.80.81 10.10.10.20 netmask 255.255.255.255

At first glance the above command could seem confusing but look at it this way:

(inside, outside) 80.80.80.81 10.10.10.20

Firstly you specify the real interface that the server is attached to, in this case our web server is on the INSIDE interface.
Secondly specify the interface that the mapped IP address is on, in this case the OUTSIDE interface – then specify the mapped IP address.
Next we specify the real IP address of the server and its netmask.

Just remember the mapped interface and IP are in the centre of the command, and the real interface and IP go at either end of the command.

A Static NAT can also be used to translate entire networks and is known as Net Static.

Code: Select all: London (config)# static (dmz, outside) 80.80.80.0 10.20.20.0 netmask 255.255.255.0

The above command will Nat the entire DMZ subnet to an IP address in the 80.80.80.0/24 subnet when passing traffic to the outside interface. This comes in handy when you have multiple subnets on a single interface.

Dynamic NAT

Dynamic NAT’s are used when no outside host will have to initiate a connection to come into your network(s). Typically a dynamic NAT is used for a normal office LAN that has not external facing servers/services and just need normal outside connectivity i.e. to the internet.

Firstly we must identify which internal hosts we want to NAT to an external IP address. This can be an entire subnet, specific hosts or everything attached to a certain interface. We then give these hosts a group number, usually starting from 1.

After we have decided what hosts will be eligible for translation, we must then decide what external IP’s we want them to use when they talk to the outside world. And assign these external IP addresses to the same group as the internal hosts we have just defined.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.25.255.0

nat = Tells the PIX we are defining hosts to be NAT’d.
(inside) = Tells the PIX where the hosts are located, in this case they are on the INSDIE interface
1 = Group number for these hosts
10.10.10.0 = the subnet we want to configure NAT’ing for. In this case every host between 10.10.10.1 and 10.10.10.254 will be translated to an external address when sending packets out of the OUTSIDE interface.
255.255.255.0 = the subnet mask that defines our subnet.

Now we have told the PIX which internal hosts we want to NAT, we must now tell it what addresses it can use to translate them.

Code: Select all: London(config)# global (outside) 1 80.80.80.81-80.80.80.100 netmask 255.255.255.0

The syntax is very similar to the NAT command we gave earlier.

global = Tells the PIX that we are defining what global (external) IP addresses it can use.
outside = Tells the PIX that these global IP’s are to be used by the OUTSIDE interface
1 = The NAT-ID group. This must be the same as what we defined in the NAT command for the inside interface. We can have multiple groups. For example if we hade two different internal subnets we want to NAT to two different sets of external IP’s, we would make two groups, one for each subnet. This would then tell the PIX, if the inside host is in group 1 then he gets an external IP from global group 1 and if the internal host is in group 2, he gets an external IP from group two.

Finally we tell it the range of IP’s available on the OUTSIDE interface. These are issued out on a ‘first come – first served’ basis until they are all used up. If the PIX administrator has not configured the PIX correctly and all the available IP addresses are in use, then some hosts will not have external connectivity, until IP addresses become available.

Multiple Interfaces and NAT

Multiple interfaces are configured the exact same way as a single interface to enable NAT on them. There are a few options when it comes to the Global Addresses though.

You can either use a new group by using a different NAT-ID number and then assign the group a new range of external IP’s or you can share one Group of external IP addresses between multiple interfaces.

Remember we assign the Global addresses to the OUTSIDE interface, so any traffic passing through the OUTSIDE interface will pick-up a Global IP address. We could have five other interfaces all sharing the same NAT-ID and as long as there are IP addresses available from the pool, they will all pick-up an IP before traversing to the outside world.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# nat (dmz) 1 172.18.10.10 255.255.255.0 London(config)# nat (eth3) 1 192.168.50.0 255.255.255.0 London(config)# global (outside) 1 80.80.80.81-80.80.80.240 netmask 255.255.255.0

In the above example we have configured three different subnets on three different interfaces to all share the same pool of addresses when traversing the OUTSIDE interface. As long as there are IP address available all hosts will have external connectivity.

We don’t have to share the same pool, as mentioned a few paragraphs above we can use more than one NAT-ID.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# nat (dmz) 2 172.18.10.10. 255.255.255.0 London(config)# nat (eth3) 3 192.168.50.0 255.255.255.0 London(config)# global (outside) 1 80.80.80.80-81.80.80.100 netmask 255.255.255.0 London(config)# global (outside) 2 90.90.90.91-90.90.90.100 netmask 255.255.255.0 London(config)# global (outside) 3 100.100.100.100-100.100.100.150 netmask 255.255.255.0

As you can see each interface is in a different NAT group and has a different pool of IP addresses to chose from when traversing the OUTSIDE interface.

Port Address Translation (PAT)

PAT is more commonly used on small to medium sized office LAN’s as most small business don’t have a pool of external IP addresses to use.

As mentioned earlier a Static NAT is only god for one IP address and one host, you can’t Static NAT a single IP address to two different hosts.

If we only have one IP address (or very few) we need to use PAT

One single external IP can theoretically be used for up to 64,000 inside hosts and can be a virtual IP address which is different from the IP address assigned to the interface.

PAT can be used in conjunction with NAT if you so desire.

There are a few applications that have problems with PAT such as some VoIP protocols and various other multimedia applications so you may want to research PAT if you have multimedia applications on your network(s).

If we want to use an IP address that is different than the IP address we assigned to the interface we set it up in the same way we have been setting NAT up, except we only use one IP address in the Global pool with a 32 bit subnet mask.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# global (outside) 1 80.80.80.82 netmask 255.255.255.255

Each time a host on the 10.10.10.0 network sends data out of the OUTSIDE interface the source port in the frame header is dynamically changed by the PIX to a port greater the 1024.

For this example we will say a host with an IP of 10.10.10.10 has sent data to the internet and used port 3000 to send it. When this packet arrives at the PIX it will change the source port in the packet header to one greater then 1024, for now we will say it is changed to 2000.

Then when data arrives on the outside interface destined to 80.80.80.92 and with a destination port 2000 the PIX knows that is substituted the source port of 2000 for the host with the IP address of 10.10.10.10, it will now change the destination port back to 3000 as otherwise the host would not accept the packet and sends the data on its way. (TCP and UDP inspection is still carried out as normal as per the Stateful Algorithm Rules)

We can also use the IP address of the interface if we have no spare IP addresses left.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# global (outside) 1 interface

The above command speaks for itself, instead of specifying an IP address or a pool of IP addresses, we tell it to use the IP address assigned to the interface

PAT will take place in exactly the same way as mentioned above, except it will use the interfaces IP address.

Just as we can with NAT we can assign multiple subnets to a single IP address in the same group or we can have a single IP address per group.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# nat (inside) 2 10.10.20.0 255.255.255.0 London(config)# global (outside) 1 80.80.80.83 netmask 255.255.255.255 London(config)# global (outside) 2 80.80.80.84 netmask 255.255.255.255

Here we have two different subnet attached to the INSIDE interface but we want to separate the external IP’s they use. So now the 10.10.10.0 network will PAT to 80.80.80.83 in the normal way and the 10.10.20.0 network will PAT to 80.80.80.84 in the normal way.

We can back up an IP address we are using for PAT with another one to keep in reserve should too many hosts want external connectivity at the same time.

Code: Select all: London(config)# nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# global (outside) 1 80.80.80.83 netmask 255.255.255.255 London(config)# global (outside) 1 80.80.80.84 netmask 255.255.255.255

The hosts on the 10.10.10.0 network will use 80.80.80.83 for external connectivity until the port pool is at maximum usage, then the PIX will start using ports from the 80.80.80.84 address.

We can even use a PAT IP address to argument a NAT global pool in case we run out of ‘NAT’able’ IP addresses.

Code: Select all: London(config)#nat (inside) 1 10.10.10.0 255.255.255.0 London(config)# global (outside) 1 80.80.80.81-80.80.80.90 netmask 255.255.255.0 London(config)# global (outside) 1 80.80.80.91 netmask 255.255.255.255

So now all hosts on the 10.10.10.0 network will use the global pool of 80.80.80.81-90 and be NAT’d across to these until there are no more available, then the 80.80.80.91 address will be used to PAT any more hosts the require external connectivity.

This is a sneaky method if you only have a few external IP addresses but don’t want to PAT all hosts or if you have ran out of external IP’s and don’t want to buy another subnet’s worth of them.

Identity NAT

As stated earlier NAT can be set to one of two settings, either all traffic will be NAT’d unless an explicit rule exists to say a certain IP address does not need to be NAT’d or no traffic will be NAT’d unless an explicit rule exists to say a host will be NAT’d.

Identity NAT, also know as NAT 0, allows us to map our IP addresses transparently so that our internal host’s IP addresses are visible to the internet without any address translation occurring. All hosts that are behind a higher security level with translate themselves to all lower interfaces.

Typically this is used when we have Internet Network Information Centre (InterNIC) registered IP addresses (external IP’s) on our internal network that we want people to be able to connect to directly from the internet without any NAT taking place.

Keep in mind that an ACL will still need to be applied to say traffic can pass from a lower level security interface to a higher one.

Code: Select all: London(config)# nat (dmz) 0 80.80.80.234 255.255.255.255

This command tells the PIX to not translate 80.80.80.234 to anything when passing traffic to and from it.

Remember to put a ’0’ after the interface instead of NAT-ID group and to add the necessary ACL to allow the PIX to pass traffic to the host.

Port Redirection (Static PAT)

If we have a secure web server, a non-secure web server and an FTP server on our internal network that require connections to be initiated from the outside how would we set this up?

We could static NAT 3 different IP Addresses to the servers and apply the relevant ACL’s which would allow outside users to connect to all of out services.
Whilst this solution would work and is a viable one in some cases, it is a waste of IP addresses.

Would it be better if we could share one IP address between all the hosts? But didn’t we say that we could only static NAT one IP address to one host?

Since all three of our servers use different ports, we can static NAT & PAT one IP address between any amount of hosts that require the use of different ports.

We basically tell the PIX, if traffic comes in to x.x.x.x on port xx then send it to x.x.x.x on port xx

So say we have an external IP of 80.80.80.132 and an FTP server with the internal IP of 10.10.10.50

We tell the PIX:

Code: Select all: London(config)# static (inside, outside) tcp 80.80.80.132 ftp 10.10.10.50 ftp netmask 255.255.255.255

The above command tells the PIX that any tcp traffic that comes in to the outside interface destined for 80.80.80.132 that is ftp (on port 21) should be sent to the inside interface to the host that has the IP address of 10.10.10.50 on the ftp port (port 21)

If you spend a few seconds looking at the above command it will become obvious what it is doing.

For an added layer of security we can use a non-default port on the outside interface and redirect it to the default port, like so:

Code: Select all: London(config)# static (inside, outside) tcp 80.80.80.132 12345 10.10.10.50 ftp netmask 255.255.255.255

The above command tells the PIX that any tcp traffic that comes in to the outside interface destined for 80.80.80.132 on port 12345 should be sent to the inside interface to the host that has the IP address of 10.10.10.50 on the ftp port (port 21)

Usually due to the time issue when scanning all 65.535 ports most casual vertical scans do not exceed the well known ports ( 0-1024), so by opening up port 12345 to an incoming FTP request we could fool a casual attacker into thinking we do not have an FTP server on the network.

*A vertical scan is a scan that checks the ports of a certain hosts, a horizontal scan refers to a ‘ping sweep’ or a scan that tries to determine active IP addresses*

An ACL would still need to be configured to allow the external connections to pass through the PIX.

So for our three servers a sample configuration could look like:

Code: Select all: London(config)# static (inside, outside) tcp 80.80.80.132 12345 10.10.10.50 ftp netmask 255.255.255.255 London(config)# static (inside, outside) tcp 80.80.80.132 80 10.10.10.60 http netmask 255.255.255.255 London(config)# static (inside, outside) tcp 80.80.80.132 https 10.10.10.70 https netmask 255.255.255.255

We can change the first set of ports to anything we want, but unless the default ports on the server have been altered we need to use the defaults for the second port number we enter.

We can use the service name for common services such as FTP, HTTP and HTTPS or we can use the port number should we so wish, the PIX sees it all in the same way.

Summary

Well if you have read all of this, Congratulations as it took me 5 days to write!

Due to the extraordinary length and detail in this paper I will summarize the process a packet will follow when it arrives at the OUTSIDE interface of the PIX.

1) Packet arrives at the PIX
2) The PIX first consults the Access Rules of the interface the packet arrives on.
3) The PIX makes a routing decision to determine which interface to send the packet out of
4) The source address of the packet is checked against LOCAL ADDRESSES in the translation table
5) If an entry is found in the translation table, it is translated as per the configuration
6) If an entry is not found the PIX will look for a translation match in the following order:
1) nat0 access-list (NAT Exemption) to see if the host is exempt translation or not
2) Static (Static NAT) will look through the static NAT table starting at the top until it finds a match
3) Static TCP / UDP (PAT) – will examine the static PAT table starting at the top until it finds a match
4) nat (NAT-ID access-list) this is policy NAT which will be covered later
5) nat – regular NAT, best match
6) If no match is found at all then the packet is dropped

The PIX keeps a State Table for all TCP and UDP connections and a Translation Table for all NAT translations.

Current TCP/UDP and NAT connections can be seen with the sh conn and sh xlate command respectively.

The PIX uses SYN cookies to prevent SYN Flooding, a form of DoS or if you have a version prior to 6.2 it will use TCP Inspection

You can Port Redirect traffic from a non protocol default port to a protocol default port.

The NAT and GLOBAL commands argument each other and will not work on individually.

You can only Static NAT one IP address to one host but you can Port redirect fro one IP address to many hosts.

Next paper will be Access Control and Content Filtering.

Cisco PIX – Configuring Site-to-site VPN’s

admin — Sat, 16 May 2009 22:42:17 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

[size=150][b][u]Configuring Virtual Private Networks with the Cisco PIX Security Appliance[/b][/u][/size]

Historically the only feasibly secure method to connect two remote sites together was via a costly leased line or ISDN line. Although leased lines are still perfectly acceptable in some situations, the variety of VPN solutions available on the market today make a VPN topology and more flexible and economical solution to adopt.

A Virtual Private Network or VPN is a service that provides a means for secure and reliable connectivity over a public infrastructure, such as the Internet.

VPN’s can be divided into three common types depending on what components are accessing the VPN.

[b]Access VPN:[/b]
An Access VPN is a secure means for remote workers to access the corporate network from home or any other remote location. Typically an access VPN comprises of software installed on the clients computer that ‘dials in’ to a VPN end point such as a PIX, authenticates the user and allows them to access parts of the network that have been defined in the VPN configuration. This type of VPN is commonly called a Remote Access VPN.

[b]Extranet VPN:[/b]
An Extranet VPN is in essence an Intranet VPN in so much as no software is required to be installed on any remote hosts and the configuration is all done between the two end points. Typically an Extranet VPN is used for connectivity to customer networks and the network access is granted at both ends of the tunnel; usually restricted to certain hosts only.

[b]Intranet VPN:[/b]
An Intranet VPN is used between two sites that belong to the same company and is commonly referred to as a site-to-site VPN. Usually it provides full and unrestricted access to the enterprise LAN and acts as seamless extension to the LAN – the end uses may very well never know the VPN exists.

This paper will cover Extranet and Intranet VPN’s. Access VPN’s will be covered in a later paper due to the size of the subject.

Extranet and Intranet VPN’s are configured almost identically, with the only difference being is that an extranet VPN may restrict what hosts can be reached via the VPN. The actual secure channel is setup and configured the same way and uses IKE and IPSec.

[b][u]Internet Protocol Security (IPSec)[/b][/u]
IPSec is not in itself a protocol, it is more a combination of other protocols and algorithms bundled together to provide data security at the network layer to address the inherent weaknesses in Internet Protocol.

IPSec uses Internet Key Exchange (IKE) to create a secure channel between two end points, known as a Security Association, before establishing the IPSec part of the VPN tunnel.

The method of establishing the VPN is broke into two phases; IKE Phase one and IKE phase two.

[b][u]Internet Key Exchange (IKE)[/b][/u]
IKE is the abbreviated abbreviation (eh?) for Internet Security Association and Key Management Protocol with Oakley distribution commonly known as ISAKMP (pronounced ice-a-camp). ISAKMP and the Oakley and Skeme key exchange are two different protocols, but are collectively known as IKE.

ISAKMP is defined in RFC 2408 and dictates the format used for the management of IPSec connections, however it does not include any [cryptographic] key management functions , in-other-words it doesn’t say how the keys should be shared with the two peers or how often they should be changed. To address these two limitations we use IKE in conjunction with ISAKMP. For the sake of VPN management the terms IKE and ISAKMP generally refer to the same thing and either can be used, for the rest of this paper I will use the term IKE.

IKE operates over User Datagram Protocol (UDP) on port 500 and is used to negotiate a mutual key exchange to create a secure path between two peers (end points). This secure connection is established in two phases, the first phase is used to establish the IKE Security Association (SA) and the second phase establishes the IPSec SA.

IKE provides the following functions:

Provides antireplay protection for IPSec communications
Provides a means to define an SA’s life-span
Supports Certification Authorities (CA’s)
Automatically negotiates the parameters for SA’s which reduces the manual configuration involved in setting it all up
Permits the encryption key to be changed dynamically with out the need to tear down the IPSec session.
Provides a very flexible approach to setting up IPSec connections

It may seem a bit confusing at first but think of it like this:

Before you set up an IPSec connection with a remote node, we need to know that the remote node we are talking to is in fact the node we want to set up the VPN tunnel with. After we have verified the identity of the remote node we also need to share the cryptographic keys between the two nodes in a secure manner – this is the job of IKE phase one. After this has been established we need to set up the IPSec part of the connection and the two nodes will use the secure IKE channel setup in phase one to establish the IPSec tunnel.

[b]IKE Phase One[/b]
As mentioned IKE comes into play in phase one by setting up an SA between the two IKE peers. If IKE does not first establish an SA in phase one, then the IPSec SA in phase two will never take place.

**A Security Association (SA) is in plain terms a set of rules two end points agree to use and accept for the duration of that particular SA, such as encryption algorithms and hashing algorithms etc. **

During the IKE SA establishment he following must be mutually negotiated between the two end points:

1. Encryption Algorithm
2. Hash Algorithm
3. Authentication Method
4. Diffe-hellmen group

Once the two end points agree on what they are going to use for all of the above, a bidirectional SA is established which then allows the IPSec SA to take place.

Phase one can be established in one of two modes; Aggressive mode or Main Mode.

[u]Main Mode[/u]
Main mode negotiation consist of six message exchanges that mirror each other between the two peers and is used if you are using certificates to authentic remote peers. The message exchange is as follows:

1 – Initiator; negotiates an exchange policy
2 – Responder; negotiates the exchange policy
3 – Initiator; exchanges Diffe-Hellmen public keys and a random value between 8 – 256 bits, called a nonce.
4 – Responder; exchanges Diffe-Hellmen public keys and a random value between 8 – 256 bits, called a nonce
5 – Initiator; authenticates the Diffe-Hellmen key exchange
6 – Responder; authenticates the Diffe-Hellmen key exchange

Initiator Responder
IKE Header with SA payload ——– > ——– > ——— > ———>
<--------- < -------- < -------- < --------- < ----------- IKE Header with SA payload

IKE Header Key Exchange Nonce (initiator) -------- > ——– > ——– >
<-------- < -------- < -------- IKE Header Key Exchange Nonce (Responder)

IKE Header (payload is now encrypted)
Identification Hash Payload (initiator) -------- > ——– > —— >
<-------- < -------- < -------- < -------- < -------- IKE Header (payload is now encrypted)
Identification Hash Payload (initiator)

[u]Aggressive Mode[/u]
Aggressive mode only has three exchanges and is used if you are using Pre-Shared Keys (PSK’s) for authentication. The first two exchanges negotiate the policy to use, exchanges public keys and authenticates the responder. The third message authenticates the initiating peer and is sent in encrypted text after the negotiation has finished.

**Diffe-Hellmen (DH) is a public cryptography protocol that two IPSec peers use to come up with a shared secret over an unsecured means such as the Internet, without actually having to send the key to each other. The mathematics behind it are ingenious; each peer will create a public and private key using a DH group, these peers then send their public keys to each other, next the peers run the public key they have just received and their own private key (which has never been shared with the other peer) through the DH algorithm and come up with a fixed length value that will be identical on both hosts... this is the shared key they will use to encrypt the subsequent key exchange for the SA to be established.**

During this phase one exchange, rather than negotiate each parameter individually, i.e. negotiate 3DES for the encryption standard and then negotiate SHA-1 for the Hash standard etc, the algorithms are grouped in to sets, called transform sets or IKE transform sets to be exact. These transform sets will delineate what standards can be used for encryption, authentication, key length and the mode to be used. Once a common transform set has been mutually agreed upon during the first message exchange the main Mode/Aggressive Modes exchange can continue. If a common transform set can not be found the tunnel is closed down and the IKE SA will not occur.

For any peer to participate in an IPSec session it is essential for them to first authenticate each other via either main mode or aggressive mode as otherwise IKE phase two can not start. Hence the need for IKE Phase One.

Which brings us on to the IPSec part of the setup process:

[b]IKE Phase Two[/b]
Having successfully authenticated each peer and establishing a secure channel for further communications, IKE Phase One evolves in to Phase Two.

As mentioned phase two can only occur after the IKE SA negotiation has completed. Phase Two’s main purpose is to negotiate mutual policies for non ISAKMP SA’s such as the IPSec SA and to derive the keying material to be used.

Phase Two only has the one mode, called Quick Mode.

Once the secure tunnel has been setup by Phase One, Phase Two negotiates the IPSec parameters to be used such as the various algorithms, Shared Secret keying material etc. It is also used to re-negotiate the a new SA once the predetermined life-span of the current IPSec SA has expired.

IPSec has two main protocols, ESP and AH.

**I will cover the encryption and hashing standards first – if they seem confusing at first it will all become apparent later on when the VPN gets configured**

[i]Encapsulating Security Payload – ESP[/i]
ESP is an extensive protocol that provides antireplay services, data authentication and data encryption and is primarily responsible for [i]securely[/i]getting the data from the source to the destination in such a way that the destination host will know if the data has been tampered with hence ensuring that your session can not be effectively hijacked.
ESP is versatile enough to be able to encrypt either just the payload of the packet or the entire data packet and can also authenticate the sender of the data either in conjunction with Authentication Header or on its own.

[u]IPv4 Packet Encrypted with ESP:[/u]
_________________________________________________________________________
|IP HEADER | ESP HEADER | TCP INFO | DATA | ESP TRAILER | ESP AUTHENTICATION |
``````````````````` --------- ENCRYPTED BY ESP ---------- ``````````````````````````
the ESP Header and all up to and including the ESP Trailer is Authenticated by ESP

[i]Authentication Header[/i]
Authentication Header pretty much does as it names suggests, it authenticates the information that is in the IP Header, or in other words it ensures that the data did originate from where it says it does in the header by means or origin authentication. By doing this is provides antireplay services and prevents your session being hijacked. It may seem similar to ESP but the one glaring difference is that AH does not provide any data encryption, its only purpose is to authenticate the sender.

One major downfall with AH is that it is not compatible with Network Address Translation (NAT). Due to the address translation occurring before the IPSec SA being established, by altering the sending IP address you would cause the AH hash that confirms the sending source to fail.

[u]IPv4 Packet with AH[/u]
__________________________________________________________
| IP HEADER | AUTHENTICATION HEADER (AH) | TCP | DATA |
``````````````````````````````````````````````````````````
As you can see no encryption takes place, unlike ESP which encrypts the payload of the packet.

**ESP and NAT is supported by the PIX by way of a fix-up protocol that inspects ESP on a more granular level**

ESP and AH can be configured to use different algorithms to encrypt and hash the data.

**An Encryption Algorithm is used to encrypt the data where as a Hash Algorithm is used to provide data integrity**

The PIX will support the following encryption algorithms:

[u]Data Encryption Standard (DES):[/u]
DES is a 56 bit symmetric encryption algorithm. Although it is somewhat outdated now it is included with the PIX for legacy reasons and should not be used if there is another option available. Due to US technology export restrictions it is more commonly used outside the USA.

[u]Triple Data Encryption Standard (3DES):[/u]
3DES as it name suggests it three time as strong as DES by way of a 168 bit symmetric cipher which is obtained by encrypting the data three consecutive times using DES. More specifically the data is first encrypted using a 56 bit DES key, then decrypted using another 56 bit DES key and then re-encrypted using yet another 56 bit DES key.

[u]Advanced Encryption Standard (AES)[/u]
AES is a symmetric block cipher that encrypts and decrypts the data using cryptographic keys of 128, 192 or 256 bit lengths. The resulting encrypted data is then placed into 128 bit blocks which are combined into cipher block chains.

**Symmetric encryption uses only a single secret key by itself to encrypt and decrypt the data. Asymmetric encryption uses a key pair -- both a public and a private one -- for encryption and is commonly used for Certificates. The sending host uses the receiver's public key to encrypt the data and the receiver uses their private key to decrypt it.**

[b][u]Message Hashing[/b][/u]
A hash algorithm simply talks the message, puts is through an algorithm and creates a fixed length Message Digest (MD) from it. This message digest is then put into another algorithm called a digital signature algorithm which in turn generates a signature (or hash) for the message from the message digest, rather than from the actual message, which reduces the processing time of the message. Should the data be altered even slightly it will massively throw out the message digest (which remember is derived from the original data) and as a knock on affect the signature (or hash) will be invalid.

For the hash to be created at the sending station and then understood at the receiving station both stations must be using the same algorithms.

The PIX will support the following hash algorithms:

[u]Secure Hash Algorithm 1 (SHA -1)[/u]
SHA -1 produces 160 bit output and is considered more secure than MD5 for this reason

[u]Message Digest 5 (MD5)[/u]
MD5 output is 128 bit. It is considered faster that SHA -1 but less secure.

[b][u]IPSec Session[/b][/u]
Once Phase One and Phase two are established, traffic deemed interesting for the IPSec session will flow through the tunnel in encrypted form. The tunnel is not an ‘always on’ means and will time out after either a predefined time limit is reached or a predefined amount of data has been sent through it.

One of the main weak points with any encrypted service is the amount of data sent in the encrypted form that had been encrypted using the same keysets. The more data that can be collected the easier it may be for the encryption algorithm to become compromised ( you only have to look at WEP for a perfect example of this). For this reason the SA’s established will time out either after a predefined amount of time or a predefined amount of data has been sent through the IPSEC tunnel. When the SA times out IKE performs a whole new Phase Two negotiations and if needs be a new Phase One negotiation. This is done before the current SA times out to prevent any interruption in the data flow.

Just as a quick summary for those who may not have followed it so far:

IKE Phase One provides a low level set of security services via policies/standards that are first negotiated and then mutually agreed upon once common ground has been found. Once this secure channel has been established IPSec can use this secure channel to set up the IPSec Security Association (SA) in Phase Two.

**As mentioned earlier without Phase One there would be no way to verify that the end point in use when you set up the IPSec SA is actually the correct end point and that in fact you are not setting up your IPSec tunnel with an attacker of some kind**

IKE Phase Two is where IKE negotiates the IPSec SA’s parameters via the secure link setup in Phase One and sets up the IPSec ‘tunnel’ between the two peers. This established IPSec SA is what then protects all the resulting traffic that flows between the tunnel end points. IPSec uses IPSec transform sets in the same way IKE uses IKE transform sets. Again just like IKE, if no common transform set can be agreed upon the connection is torn down and the IPSec VPN fails.

Most Cisco products support three methods of IPSec peer authentication:

[b]RSA Signatures (Certificates)[/b] - This is considered the preferred method of authentication as it uses digital certificates that are authenticated by an RAS Signature.
[b]Pre-shared Keys[/b] – As the name suggests these are manually configured case sensitive keys that must exactly match on both peers.
[b]RSA Encrypted Nonce’s[/b] - Cisco appliances can use RSA (Rivest Shamir Adleman) encryption to encrypt a random number (a nonce) that is generated by the peer along with other pre configured values. The PIX does not support this type of authentication at this moment in time.

[b]Certificates and Certification Authorities (CA)[/b]
Certificate authorities manage certificate requests, issue the requested certificates once approved and publish Certificate Revocation Lists (CRL’s, pronounced “Crills”). IKE understands X.509v3 certificates that require public keys.

A digital certificate has a public key, which is available publically strangely enough, and is used for the automatic authentication of servers and/or users. The connecting node needs to trust the root CA that issued the certificate for it to accept it. By default the connecting node also needs access to the CRL to check if the certificate has been revoked by the root CA. Some third party CA’s are already trusted for web browsers etc but the PIX will only trust the following third party CA’s:

VeriSign
Microsoft Corporation
Baltimore Technologies
Entrust Corporation

Certificates replace the need for pre-shared keys as they already have a public and private keys as part of the frame work of the certificate.
For certificates to work on the PIX there are four steps to take:
Generate an RSA Key pair

Obtain the CA’s certificate which will have the public key
Using the generated key and the public key obtained by the CA the firewall will then request a signed certificate from the CA
The CA then verifies the request and offers the signed certificate to be published (depending on how the CA is configured this sometimes requires an administrator to manually approve the request)

[b]Pre-Shared Keys[/b]
Pre-Shared Keys (PSK) are usually used if you only have a few firewalls to configure and you control all of the firewalls in the VPN configuration, as when you change a PSK on one firewall obviously you will need to change it on the other. PSK’s offer the quickest and easiest way to configure a VPN. A PSK can be up to 128 bytes long and uses alphanumeric characters ( A-Z and 0-9)

[b][u]Configuring the PIX for VPN Usage[/b][/u]
When configuring site-to-site VPN’s sometimes you can be dealing with an administrator from another organisation, or you could be lucky enough to be the administrator of both the VPN peers. Either way it is always a good idea to write down the exact configuration that will be entered on both firewalls, such as the transform set, pre-shared key (if using one), peers IP address etc. Most VPN configurations run into problems because the configurations do not mirror each other.
If you are dealing with an administrator from another company I have always found it better in the long run to email each other with the configuration you are going to use but then to phone each other up and configure the firewalls at the same time, this way you will ensure you are entering the same information on the firewalls and can exchange a PSK verbally which is obviously more secure than doing it by email.
The whole process could be broken down into 8 steps (you could also use these steps to troubleshoot problems)

1.Can you ping the remote peer IP address – If you cant establish non-VPN connectivity to the remote peer then you are never going to establish a VPN connection. (if you are dealing with a remote administrator ensure his firewall will respond to ICMP requests)
2.Design the topology/layout of the VON and ensure it meets all company security requirements
3.Allow IPSec traffic into your network with an ACL
4.Configure an ACL to determine with traffic to protect (encrypt)
5.Decide on a mutual configuration policy for IKE phase 1
6.Decide on a mutual configuration policy for IKE phase 2
7.Verify the configuration once finished
8.Check the status of the connection

There are many ways to configure a VPN and many different commands can be used depending on your configuration but ultimately they all fall somewhere within the above steps. As mentioned you can use the above steps to troubleshoot any VPN problems:

Can you ping the peer
Have you permitted IPSec traffic into the PIX
Is your ACL protecting the right traffic
Do the IKE phase one parameters match
Do the IKE phase two parameters match
What state is the VPN connection in according to the PIX

[b][u]Configuring IKE[/b][/u]
When you design the VPN topology you will work out where the VPN end point is going to be. As we know by default the PIX will drop all traffic coming to a lower security level interface, which is where the VPN traffic will more than likely enter your network from; so we need to permit it. If you are using a VPN concentrator of some kind that is behind the PIX then you still need to permit the PIX to allow the VPN traffic to pass through it with an ACL.

IPSec/IKE/ISAKMP used the following ports & protocols:
IKE/ISAKMP = UDP port 500
Authentication Header (AH) = IP protocol number 51
Encapsulation Security Payload (ESP) = IP protocol number 50

So your ACL will take on the following syntax:

**For the remainder of this paper when entering a configuration anything in the ‘<>’ should be substituted with the relevant information specific to your configuration, i.e. an IP address, anything in the ‘[]’ is optional and will depend on your needs and configuration, the ‘|’ symbol means you have a choice of entering one of the commands that are either side of it ( this command|or this command) and anything with no symbols around it should be entered as shown**

[code]
London(config)# access-list permit udp host eq isakmp
London(config)# access-list permit ah host
London(config)# access-list permit esp host
[/code]

If you do not know the remote peers IP address then use 0.0.0.0 for the IP address, this will usually be the case for remote access VPN’s.

A sample configuration would be:

[code]
London(config)# access-list permit udp host 80.81.81.81 host 80.80.80.80 eq isakmp
London(config)# access-list permit host 80.81.81.81 host 80.80.80.80
London(config)# access-list permit esp host 80.81.81.81 host 80.80.80.80
[/code]

Alternatively you can use the following command:

[code]
London(config)# sysopt connection permit-ipsec
[/code]

This command can be used in place of the above ACE’s however it allows all IPSec traffic to enter the PIX regardless of where it originates from, so use it with caution.

[b]Authentication[/b]
Now we have allowed the IPSec traffic in to the network we need to configure how we will authenticate a remote peer, there are two options for site-to-site VPN’s; Pre-Shared Keys and Digital Certificates.
If you are a mid to large sized organization you may very well have a security policy which states exactly what authentication, encryption and hashing policies you should use, if you are a smaller company you will probably have to make this decision for yourself.
I won’t make any recommendations here as it will depend on your organizations needs.

First off we need to enable IKE on the PIX, we do this in the same way any service is activated on most Cisco equipment, with the keyword ‘enable’.

[code]
London(config)# isakmp enable outside
[/code]

The above command speaks for itself; we have enabled IKE on the outside interface.

Obviously for the PIX to authenticate a remote peer we need to define it first, for this we can use an IP address or a host name providing the name has been configured first on the PIX. If you want to use a host name you will need to tell the PIX this with the following command (I find it good practise to always use this command before configuring any VPN’s to ensure the PIX is using the correct lookup method)

[code]
London(config)# isakmp identity < IP adderss|host name>
[/code]

**Personally I always use the IP address method, as the host name either requires DNS (which is prone to spoofing) or a local hosts table…..either way it is still more configuration. If you do decide to use host names then substitute anything saying with the relevant host name in the forthcoming configurations.**

Once we have told the PIX if we are using IP addresses or hostname for the remote peer we need to tell it the PSK we want to use to authenticate the remote peer with:

[code]
London(config)# isakmp key address []
[/code]

The subnet mask is optional and should be used if you are configuring a range of peers on the same subnet that will all use the same PSK. If you omit the subnet mask it will default to 255.255.255.255.

So an example configuration so far would be along the lines of:
[code]

London(config)# isakmp identity address
London(config)# isakmp key qwertyuiop address 80.80.80.80
[/code]

That’s it for the PSK, all configured. The final think to say about PSK’s is that is you want all your VPN peers to use the same PSK then you can use 0.0.0.0 as the IP address to prevent having to enter a PSK and IP address for each peer; obviously this means if your PSK ever gets compromised then all of your VPN’s will also be compromised.

Once we have done this we need to create the policies for IKE to use. There are five things we must decide on and they must match on both peers:

Authentication Method (PSK, Certificates)
Encryption Algorithm (3DES, AES etc)
Message Hash (SHA-1 or MD5)
Key exchange settings – Diffie-Hellman group 1, 2 or 5.
The SA lifetime in seconds (default of 86,400 seconds)

We know what the PIX can support, so after deciding on what is secure enough for you needs you can supplement the standard from one from the below configuration and number the policy accordingly:

[code]
London(config)# isakmp enable outside
London(config)# isakmp identity address
London(config)# isakmp key qwertyuiop address 80.80.80.80 netmask 255.255.255.255
London(config)# isakmp policy 10 authentication pre-share
London(config)# isakmp policy 10 encryption 3des
London(config)# isakmp policy 10 group 2
London(config)# isakmp policy 10 hash md5
London(config)# isakmp policy 10 lifetime 86400
[/code]

As you can see from the above configuration we have created a policy and gave it the priority number of 10, within this policy we have included 3DES as the encryption standard to use, MD5 as the hashing standard, group 2 for the Diffie-Hellman group and the SA has a lifetime of 84,600 seconds (one day), we are using a PSK for peer authentication for the peer with the IP address of 80.80.80.80 and the PSK is ‘qwertyuiop’.

This policy must exactly match the remote peers policy but it does not have to have the same priority number. As multiple policies can be configured on the peers due to the fact there may be more than one VPN on this host, the PIX will start with the first policy in the list (lowest priority number) and trawl through them all until a match is found; so this could easily be policy 60 and it will still work providing the algorithms in use are identical. For this reason it is considered best practise to put you r stronger policies at the top of the list.

That is IKE phase one configured on the firewall to use Pre-Shared keys. If you want to use certificates there is a lot more configuration involved but the added security should be considered a more than good enough trade-off.

[b]Certificates[/b]
Personally I would say that if your knowledge of VPN’s, Certificates and configuring the PIX is relatively small AND if your security needs allow it, stay away from certificates and use PSK’s (not everyone will agree with this though ) as if you do not have a solid understanding of it then it can become a very daunting task very quickly.

Currently the PIX will support the following Certificate Authorities (CA’s):

Microsoft Windows Certificate Services (internal PKI)
VeriSign
Baltimore Technologies
Entrust Technologies

There are a few things that need to be configured on the PIX before it can use Certificates. Set the date and time, create your own RSA keys and make sure you have enough memory to store the certificates.

[b]Set the date and time[/b]
Use the following command to set the correct date and time on the PIX:

[code]
London(config)# clock set
[/code]

So it would be something like:

[code]
London(config)# clock set 22:26:00 october 12 2006
[/code]

If you do not have the correct date and time set you will run in to problems with any certificates you have on the PIX as all digital certificates have a valid from and a valid to date and time on them.

You should use the same settings that are on your CA to avoid any issues with the certificates you receive from it.

[b]Set the host name and domain[/b]
Every IPSec device in the chain needs a unique identity, as we know the PIX can be configured with a Fully Qualified Domain Name (FQDN):

[code]
London(config)# hostname
London(config)# domain-name
[/code]

[b]Check memory space[/b]
When using certificates the PIX will need to store the following in Flash:

RSA Public and Private Keys
PIX’s certificate issued to it by a CA
CA’s certificate ( and an RA’s certificate if one is used)
CRL (will have two CRL’s if an RA is being used)

Use the “show flashfs” command to view the amount of space available in Flash.

[b]Create the RSA keys for the PIX to use[/b]
Here is where it all starts to get somewhat complicated…
After you have configured the time, date and FQDN of the PIX you need to generate your own RSA keys. RSA keys are used to create a digital signature for the certificate belonging to the PIX and to also verify the signature that is on the certificate.

When you create the keys you will have a public key and a private key, you may view the public key but there is no way for anyone, including the PIX administrator, to ever view the private key of the PIX.

To create the keys use the following syntax:

[code]
London(config)# ca generate rsa
[/code]

The ‘key’ switch will generate a single public and private key combination which are known as General Purpose keys, the ‘specialkey’ switch creates two sets of keys that are used for General Purpose and Encryption reasons.
The option is a value between 512 and 2048 and defines the bit size of the key, the higher this number the more secure the keys will be but the longer it will take to process.

To view the newly created keys use the following command:

[code]
show ca mypubkey rsa
[/code]

**Remember you can not view your private key**

So, now we are ready to connect to a CA and retrieve its certificate.

[b]Obtain CA’s Certificate[/b]
Before you go any further you should check with your certificate administrator (if you have one) and obtain some details from him:

Fully Qualified Domain Name (FQDN) of the CA (if external)
IP Address of the CA
The CGI-BIN script location (optional)
If the CA supports an LDAP server
If a registration Authority (RA) is in use

You won’t need all of the above information as there is more than one way to configure it depending on your setup.

[code]
London(config)# ca identity [:ca script location] [LDAP IP Address]
London(config)# ca configure [crloptional]
London(config)# ca authenticate [fingerprint of the CA]
[/code]

If you have a CA administrator I would personally email him this configuration and ask him to fill in the blanks, however if you don’t have one here is the breakdown of it:

The first command ‘identity [:ca script location] [LDAP IP Address]’ is pretty straight forward, it tells the PIX the FQDN and the IP address of the CA (you need to specify both for an external CA, however you can make do with just the actual CA’s name if it is internal)
The ‘:ca script location’ is optional and specifies the issuing script location is stored on the CA. The ‘LDAP IP Address’ is again optional and only needs to be entered if the CA uses an LDAP server for authentication.

A complete configuration for the first part could resemble this for Windows 2000 that does not need an LDAP server:

[code]
London(config)# ca identity Certserver 192.168.10.10:/certserv/mscep/mscep.dll
[/code]

The second command ‘ca configure ’ speaks for itself, the ‘ca|ra’ allows you to tell the pix if it is a Certificate Authority or a Registration Authority, the tells the PIX how often in minutes it should try to connect to the CA/RA and can be any value from between 0 – 60 minutes (1 is the default if nothing is entered) , the states how many times the PIX can try to contact the CA during the establishment of the session and is a value between 0 – 100 with 0 being the default if nothing is entered (unlimited).

Finally the ‘crloptional’ tells the PIX whether it should continue to trust a previously issued certificate from the CA when the connection gets rebuilt, in other words in stead of going through the process of checking the remote peers certificate it will simply check the CRL to see if the previous one has been revoked, which is much quicker. If the CRL is not available and you have not used the ‘crloptional’ command then the PIX will not continue with the IPSec session as authentication will fail.

The first two commands deal with accessing the CA; the last command ‘ca authenticate ’ downloads the CA’s certificate. You must use the same CA name that you used in the ‘CA identity’. Optionally you can include the fingerprint of the CA and the PIX will automatically verify the certificate once it is downloaded, otherwise you will have to do it yourself.

So, we have told the PIX where to find the CA, how to access it and we have downloaded the CA’s certificate so we now trust the CA and can talk to it via encrypted means. The next step is to have the CA issue the PIX with a certificate so we can use it for authentication means when setting up an IPSec session.

To do this we use the following command:

[code]
London (config)# ca enroll [serial] [ipaddress]
[/code]

The first part of this is self explanatory and tells the PIX to go to the CA and enroll (ask for) a certificate.
The is a password that can be up to 80 characters long and is alphanumeric. This is used if you ever want to revoke the certificate you just received and maybe asked for by your CA administrator. The CA can also use this to verify the identity of the requester of the certificate. If you don’t want to use a password you can use either the serial number of the PIX by using the ‘[serial]’ command, or you can use the IP Address of the PIX with the ‘[ipaddress]’ command instead, you can specify both if you so wish. Cisco recommend you use a password.

To verify you have received a certificate use the following command:

[code]
London# show ca certificate
[/code]

**CA’s are usually configured to require the manual approval of the CA Administrator before a certificate is issued. If this is the case you will have to wait for the CA admin to view your request and then approve it before your certificate is issued.**

Certificate information is not saved with the ‘wr mem’ command and you will need to use the ‘ca save all’ command to save your certificate information, key pairs etc:

[code]
London(config)# ca save all
London (config)# wr mem
[/code]

**In the unlucky occurrence of your private key becoming compromised you can remove the existing public and private keys with the ‘ca zeroize rsa’ command. You will also need to revioke the relevant certificate and request a new one. Likewise if you install a new CA or change the existing one for any reason you can remove the configuration stored in flash with the ‘no ca identity’ command – if you do this you will have to configure a whole new CA and obtain a new certificate from it.**

So an example configuration so far (without the IPSec and ACL configuration) that uses a certificate and not a PSK would be:

[code]
London(config)# ca identity Certserver 192.168.10.10:/certserv/mscep/mscep.dll
London(config)# ca configure Certserver ra 1 5 crloptional
London(config)# ca enroll Certserver abcdefg12345
London(config)# ca save all

London(config)# isakmp policy 10 authentication rsa-sig
London(config)#isakmp policy 10 encryption 3des
London(config)# isakmp policy 10 group 2
London(config)# isakmp policy 10 hash md5
[/code]

Obviously you will need to NAT your CA and allow the remote peer access to it on port 80 for it to be able to authenticate to it

[b][u]Configuring IKE phase two[/b][/u]
Now we have configured all the parameters for IKE phase one whether using a PSK or Certificate for authentication, we need to configure the IPSec part of it.

We start off by telling the PIX what traffic we want it to encrypt using the policies we have defined. As always when we want to identity a certain type of traffic coming through the PIX we use an ACL, commonly know as a crypto ACL or cACL for short.

In the Crypto ACL we use the PERMIT statement to say that we DO want the traffic encrypted and the DENY statement to say what traffic we DON’T want the PIX to encrypt. Don’t confuse this ACL with a filtering ACL which will block or allow traffic, the cACL only informs the PIX if the traffic needs to be encrypted or not, it does not block or allow any traffic.
However just to confuse the issue a tad because of the nature of a VPN this cACL has a knock on effect to certain traffic depending on what interface it comes in on.

1.Outbound traffic that does not match a permit statement in the cACL will not be protected (encrypted)
2.Outbound traffic permitted in the cACL will be protected
3.Inbound traffic that is permitted in the cACL but is not protected will be dropped (remember incoming traffic from a VPN peer is expected to be encrypted, if it is not then there is something not right with it so the PIX will drop the traffic)
4.Inbound traffic that is protected but does not match the cACL will be processed normally in case the VPN end point in internal to the network.
5.Inbound traffic that is permitted and arrives protected will be processed in accordance with the policies configured for it, if the HASH check fails or the PIX is unable to decrypt it the traffic will be dropped.
6.Inbound unprotected traffic that does not match any cACL will be processed normally

You can have more than one cACL if your security needs require it.

[code]
London(config)# access-list VPN_PROTECTED permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
[/code]

The above cACL will protect (encrypt) any traffic from 192.168.10.0\24 that is destined to 192.168.20.0\24. Remember a permit statement in an ACL by default denies anything else that is not explicitly permitted.

The last thing we need to do with this cACL is tell the PIX to not perform Nat on any of the traffic we want to protect, else the VPN peer will drop the packets. We do this with the nat 0 command:

[code]
London(config)# nat (inside) 0 access-list VPN_PROTECTED
[/code]

Now we have told the PIX what traffic we want it to protect, we need to tell it what policies to use to actually encrypt it with, just like we done with the IKE phase one configuration. We do this with what is known as a Transforms, which are collectively know as Transform Sets.

[b][u]Transform Sets[/b][/u]

An IPSec SA, just like the IKE SA need to agree on a set of rules (which are called transforms when we are talking about IKE phase two) to follow to encrypt and verify the traffic it is sending and receiving.

The PIX can support the following transforms:

[b]Ah-md5-hmac[/b] – Used for Authentication
[b]ah-sha-hmac [/b]– User for Authentication
[b]esp-null[/b] – ESP transform that does not provide encryption
[b]esp-des[/b] – ESP transform that used DES for encryption (56 bit)
[b]esp-3des[/b] – ESP transform that uses 3DES for encryption (168 bit)
[b]esp-aes[/b] – ESP transform using AES encryption (128 bit)
[b]esp-aes-192[/b] – ESP transform using AES-192 encryption (192 bit)
[b]esp-aes-256[/b] – ESP transform using AES-256 encryption (256 bit)
[b]esp-md5-hmac[/b] – ESP transform with HMAC – MD5 authentication and is used with ESP-DES or ESP-3DES to provide extra integrity for ESP packets
[b]esp-sha-md5[/b] – ESP transform with HMAC-SHA authentication, used with ESP-DES or ESP-3DES for additional integrity for ESP packets.

**HMAC is outline in RFC 2104 and represents Keyed-Hashing for message authentication.**

Obviously the larger key sets you opt for the more processing power you will use and the longer the data-flow will take.

Once you have decided on a transform set, the syntax for configuring it is as follows:

[code]
London(config)# crypto ipsec transform-set
[[transform 2] [transform 3]]
[/code]

The transforms 2 & 3 are optional. The PIX will search through all configured transform sets until it finds a suitable match.

So it could be something like so:

[code]
London(config)# crypto ipsec transform-set STRONGEST esp-3des esp-md5-hmac
[/code]

So I am using [b]esp-3des[/b] for encryption and [b]esp-md5-hmac[/b] for authentication

Next we need to specify the connection type; either tunnel or transport. Usually tunnel is used for site-to-site VPN’s (and is the default):

[code]
London(config)# crypto ipsec transform-set STRONGEST mode tunnel
[/code]

So now the transform set called STRONGEST is using es-3des for encryption, esp-md5-hmac for authentication and tunnel mode for the connection.

Now we have told it what standards to use to create a tunnel, we need to tell it how long the tunnel can be active for. This can be defined in either seconds or kilobytes:

[code]
London(config)# crypto ipsec security-association lifetime seconds 86400
[/code]

[code]
London(config)# crypto ipsec security-association lifetime kilobytes 4608000
[/code]

The default for kilobytes is 4,608,000 and the default for seconds is 28,800 (8 hours). The idea is to force a key exchange before the minimum amount of encrypted data needed to crack your encryption key can be gathered.
It is hard to say what this minimum is due to the ever changing state of technology as bigger and better CPU’s come out the lower the theoretical minimum amount of data needed becomes. I usually leave them to their defaults, unless extra security is needed then I lower them, in no case do I increase them.
Once the PIX has reached to within either 30 seconds of the maximum lifetime or to within 256KB of it the negotiation begins to setup a new connection. The ‘change over’ of connections should be seamless and no adverse effects should be experienced by any users.

Now we have all this information we need to link it all together and assign it to a specific VPN connection. We do this with Crypto Maps.

[u][b]Crypto Maps[/b][/u]
A crypto map simply ties in together all the necessary information to allow the PIX to setup the IPSec SA. You could think of it as the equivalent to the ‘isakmp policy’ command when configuring IKE phase one.

There are normally five crypto map commands we need to configure for the IPSec part to work. When you string these five entries together you will have a complete basic IPSec configuration.

First as always you need to give the crypto map a name and tell the PIX what to use it for:

[code]
London(config)# crypto map
ipsec-isakmp
[/code]

The
speaks for itself, the sequence number is the equivalent to the priority number when configuring the isakmp part earlier and ipsec-isakmp tell the PIX to use IKE to setup the IPSec connection.

[code]
London(config)# crypto map VPN 10 ipsec-isakmp
[/code]

We then need to tie in the ACL we configured earlier to inform the PIX which traffic to protect:

[code]
London(config)# crypto map
match address
[/code]

We obviously use the same name and sequence number and tell it to [b]match address[/b] (the IP address) to what is defined in the ACL.

[code]
London(config)# crypto map VPN 10 match address VPN_PROTECTED
[/code]

So now the PIX will follow the rules about protecting traffic I mentioned earlier in the Crypto ACL section.

Now we need to tell it which transform set to use:

[code]
London(config)# crypto map
set transform-set
[/code]

Again use the same map name and sequence number, then just change
for the name of the transform set you have created.

[code]
London(config)# crypto map VPN 10 set transform-set STRONGEST
[/code]

We need to tell the PIX which VPN peer we want to apply this crypto map to when it tries to establish an SA.

[code]
London(config)# crypto map
set peer [/code]

Enter the IP address of the remote peer that we are going to set the VPN tunnel up with.

[code]
London(config)# crypto map VPN 10 set peer 80.81.81.81
[/code]

Lastly we need to bind the crypto map to an interface, which is very straight forward:

[code]
London(config)# crypto map VPN 10 interface outside
[/code]

Replace ‘outside’ with the relevant interface if needed.

And that is it for configuring Site-to-Site VPN’s.
I will sum it all up with two sample configurations, one with CA and one with a PSK:

[b][u]PSK[/b][/u]

[code]
London(config)# access-list IKE permit udp host 80.81.81.81 host 80.80.80.80 eq isakmp
London(config)# access-list IKE permit host 80.81.81.81 host 80.80.80.80
London(config)# access-list IKE permit esp host 80.81.81.81 host 80.80.80.80

London(config)# nat (inside) 0 access-list VPN_PROTECTED

London(config)# isakmp enable outside
London(config)# isakmp identity address

London(config)# isakmp policy 10 authentication pre-share
London(config)# isakmp policy 10 encryption 3des
London(config)# isakmp policy 10 group 2
London(config)# isakmp policy 10 hash md5
London(config)# isakmp policy 10 lifetime 86400
London(config)# isakmp key qwertyuiop address 80.81.81.81 netmask 255.255.255.255

London(config)# access-list VPN_PROTECTED permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
London(config)# crypto ipsec transform-set STRONGEST esp-3des esp-md5-hmac
London(config)# crypto ipsec transform-set STRONGEST mode tunnel
London(config)# crypto ipsec security-association lifetime seconds 86400
London(config)# crypto map VPN 10 match address VPN_PROTECTED
London(config)# crypto map VPN 10 set transform-set STRONGEST
London(config)# crypto map VPN 10 set peer 80.81.81.81
London(config)# crypto map VPN interface outside
[/code]

[b][u]Certificates[/u][/b]

London(config)# access-list IKE permit tcp any host 80.80.80.90 eq 80
London(config)# static (inside, outside) 80.80.80.90 192.168.10.10 netmask 255.255.255.255
London(config)# nat (inside) 0 access-list VPN_PROTECTED

London(config)# ca identity Certserver 192.168.10.10:/certserv/mscep/mscep.dll
London(config)# ca configure Certserver ra 1 5 crloptional
London(config)# ca enroll Certserver abcdefg12345

London(config)# isakmp enable outside
London(config)# isakmp identity address

London(config)# isakmp policy 10 authentication rsa-sig
London(config)#isakmp policy 10 encryption 3des
London(config)# isakmp policy 10 group 2
London(config)# isakmp policy 10 hash md5

In this configuration I have NAT’ed the CA server (192.168.10.10 to the external IP of 80.80.80.90 and allowed connections on port 80 for certificate authentication reasons. The internal IP is included in the ‘protect’ ACL so IPSec traffic can reach it internally but the Peer can also reach it via it’s global address when needed before the IPSec connection is established.

[b][u]Troubleshooting[/b][/u]
Troubleshooting VPN’s can be an absolute nightmare at time, but nearly always come down to the configurations not matching on both peers.
First check if you can ping the remote peer – the other firewall admin may have disabled ICMP and you may need to ask him to enable it temporarily.

Once your ping has been successful, the following ‘show’ commands will show you all of your VPN configuration:

Show isakmp
Show isakmp policy
Show access-list
show crypto map
Show cryptoipsectransform-set
Show crypto ipsec security-association lifetime
Show crypto isakmp sa
Show crypto ipsec sa

By comparing the results of the above command(s) on both VP end points you should be able to narrow down your miss configuration.

Check the PSK’s are identical and the remote peer’s IP address and subnet mask are correct.
Check you have enabled IKE
Check the relevant traffic is being protected
Check you are not NAT’ing the protected traffic
AND check your configurations are identical!

The final step in troubleshooting VPN’s is to debug the entire VPN and watch the tunnel forming in real time (this is process heavy so conduct it during periods of low activity)

Debug crypto isakmp
Debug crypto ipsec

The commands speak for themselves and will allow you to see either the isakmp negotiation taking place, or the IPSec association, depending on which command you use.

The next paper will be on the ADSM.

Cisco PIX – Access Control Lists and Content Filtering

admin — Tue, 12 May 2009 22:39:38 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

Cisco PIX 5: Access Control Lists and Content Filtering

Hopefully after reading this you will understand the basic and advanced features of ACL’s, how to block ActiveX and Java applets and how to configure URL filtering on a security appliance.

Just to recap, by default every PIX has an INSIDE interface with a security level of 100 and an OUTSIDE interface with a security level of 0. There is nothing more secure than the INSIDE interface and likewise there is nothing less secure than the OUTSIDE interface.

By default a more secure interface can send traffic to a less secure interface with a minimum of ACL’s configured but if we want to allow traffic from a less secure interface to pass to a more secure one we need to have a static translation and an ACL permitting that type of traffic.

An ACL can be configured on any interface to filter both inbound and/or outbound traffic but they are ‘evaluated’ only once per connection.

If there is no ACL applied to an interface then the above mentioned default rule set is followed – allowed outbound by default but denied inbound.

The guidelines for applying ACL’s are fairly simple.

From a higher to lower security level (Inside to Outside) an ACL is used to restrict outbound traffic, so for example it would be applied to the first interface traffic would encounter, in this case the INSIDE interface. The source IP address in the ACL is the real address of the host and/or network not the translated external address.

For lower to higher security level traffic the ACL is used to enable traffic from a less secure network to traverse he PIX so it is applied to the less secure interface, e.g. OUTSIDE interface, an ACL on the OUTSIDE interface can also be used to restrict protocols. The destination IP address in the ACL will be the external translated address.

The following diagram will explain it a bit better:

Code: Select all: London(config)# static (dmz, outside) 80.80.80.80 10.10.10.20 netmask 255.255.255.255 Translated IP 80.80.80.80 --DMZ-- 10.10.10.20 |Internet|--->--->--->--->--->--->--->| PIX | --->--->--->--->--->--->| Web Server |

So we have a web server in a DMZ with a real IP of 10.10.10.20. This is translated to 80.80.80.80 on the outside interface of the PIX, in other words an internet user puts 80.80.80.80 into his web browser which then arrives at the PIX interface, the PIX knows that anything coming to 80.80.80.80 needs to go to 10.10.10.20. But what if FTP, Telnet, SMTP etc traffic arrives? We have not told it what traffic is allowed on what port and from what host(s). Remember a static translation needs two things, a Address translation and an Access List that is applied to the correct interface.

To reiterate what I said before about applying the correct ACL to the correct interface; if the ACL saying that only HTTP traffic was allowed to go the web server was applied to the DMZ interface, the PIX would have dropped the traffic before it ever gets a chance to reach the DMZ….why? If you remember back to the last paper about the process the PIX goes through when traffic comes in:-

1) Packet arrives at the PIX
2) The PIX first consults the Access Rules of the interface the packet arrives on.
3) The PIX makes a routing decision to determine which interface to send the packet out of
4) The source address of the packet is checked against LOCAL ADDRESSES in the translation table
5) If an entry is found in the translation table, it is translated as per the configuration
6) If an entry is not found the PIX will look for a translation match in the following order:
1) nat0 access-list (NAT Exemption) to see if the host is exempt translation or not
2) Static (Static NAT) will look through the static NAT table starting at the top until it finds a match
3) Static TCP / UDP (PAT) – will examine the static PAT table starting at the top until it finds a match
4) nat (NAT-ID access-list) this is policy NAT which will be covered later
5) nat – regular NAT, best match
6) If no match is found at all then the packet is dropped

In step one the PIX checks the Access Rules of the interface the packet is received on…..if we applied the ACL for the web server on the DMZ interface the PIX will never look there for it, so will presume there is none…..even though there is a translation for it, there is no rule telling the PIX it is allowed to send it, so ultimately the packet will be dropped.

If we apply it on the OUTSIDE interface, and thus the first interface the traffic encounters on its way to the web server, when the PIX looks for an access rule, the ACL is there and the PIX will act accordingly

If you want to restrict traffic leaving your network, put your ACL on the inside interface, if you want to restrict it coming in put it on the outside interface.

So what access rule do we apply?

Code: Select all: London(config)# access-list ACLOUT permit tcp any host 80.80.80.80 eq www

Here is the break down:
access-list – tells the PIX we are configuring a ACL
ACLOUT – The name of the access list, this can be anything you want, I have called it ACLOUT to let me know it is the ACL I have applied to the OUTSIDE interface.
permit permit the following traffic
TCP – TCP traffic
[/b]any[/b] – that comes from any host on the OUTSIDE interface
host 80.80.80.80 – destined for the host with the IP address of 80.80.80.80.
eq – equal to [the type of traffic being permitted]
www – the type of traffic allowed, in this case HTTP, we can use [port] 80 instead if we want.

So in a nutshell, any TCP traffic coming from any host that is destined for 80.80.80.80 and is HTTP traffic will be allowed to pass through as per the translation rule we have set up. If UDP traffic, or say FTP traffic came in it would be dropped.

When configuring an ACL by default you deny everything else. So after entering the above ACL, we will have denied EVERYTHING that does not meet the criteria laid down in that ACL.

Once we have compiled the ACL we still need to apply it to the correct interface using the rules I mentioned above. The following command is used for this:

Code: Select all: London(config)# access-group ACLOUT in interface outside

The breakdown of the command is:
access-group- – tells the PIX we want to bind an access list to an interface
ACLOUT – the name of the ACL we want to bind to the interface. We can only apply one ACL to an interface using the access-group command
in – The direction of traffic that will be affected by this ACL, in this case inbound traffic.
interface outside – this speaks for itself, we have applied the ACL to the OUTSIDE interface.

So we have now told the PIX that any HTTP traffic incoming to the OUTSIDE interface, from ANY IP address destined for 80.80.80.80 on port 80 is allowed to pass through as per the translation rule. The PIX will now look at the translation table, see the 80.80.80.80 is translated to 10.10.10.20 and allow the HTTP traffic to pass through.

*It is a good habit to name the ACL’s using capital letters, such as ACLOUT, to make it more obvious when viewing the configuration afterwards.*

We can use the following commands to view our access lists/groups:

sh access-list
sh run access-group

With version 7 of the PIX operating system we have the ability to use time based ACL’s, so for example we could permit traffic to a web server from the hours of 09:00 – 13:00 only. Or if a temporary worker was hired for a month and needed access to something you could set an ACL to allow him access to the server between certain hours for a one month period.

Timed ACL’s (tACL) depend on the system clock, so ensure the clock and date are correct, it is best to configure the PIX to use NP times from an NTP server (explained in an earlier paper).

Like most of the PIX commands, the command relates to what we are doing:

Code: Select all: London(config)# time-range WEB-SERVER London(config-time-range)#

Obviously the command we use to tell the PIX we are configuring a tACL is time-range the WEB-SERVER is the name of the tACL, and again it is a good practise to use capital letters for brevity reasons when viewing configurations.

Code: Select all: London(config)# time-range WEB-SERVER London(config-time-range)# absolute start 00:00 1 october 2006 end 00:00 20 october 2006 London(config-time-range)# periodic weekdays 8:00 to 17:00

Now we have two different commands, the absolute command defines the absolute start and finish time of the tACL’s validity, this can be as long or as short as is needed. The Periodic command sets the recurring weekly time for the tACL.

So our tACL called WEB-SERVER would apply from 08:00 to 17:00 on every weekday between midnight on the 1st October to midnight on the 20th October.

Now we have defined when the tACL is valid to and from, we need to define what the actual tACL actually allows:

Code: Select all: London(config)# static (dmz,outside) 80.80.80.81 10.10.10.21 London(config)# access-list ACLOUT permit tcp host 123.123.123.123 host 80.80.80.81 eq www time-range TEMP-WORKER

So we have statically translated a web server to an external IP in the normal way, then created the necessary ACL permitting tcp traffic from host 123.123.123.123 going to host 80.80.80.81 with traffic that equals www, then we told the PIX to apply a time range to it and the time range that it needs to apply is what we specified in the TEMP-WORKER tACL.

Modifying ACL’s

Obviously we are not going to get the ACL’s correct first time and they are not going to remain unchanged for the lifetime of the firewall. ACL’s on the PIX or given consecutive line numbers, to allow us to change, add or remove Access Control Entries (ACE) without having to change the entire ACL.

An ACL is made up of one or more ACE’s.

If we issue the ‘sh access-list’ command the output will be along the lines of:

Code: Select all: London(config)# sh access-list access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0) access-list ACLOUT line 3 permit udp any any (hitcnt=0) access-list ACLOUT line 4 permit tcp any any eq ftp (hitcnt=0) access-list ACLOUT line 5 permit tcp any any eq https (hitcnt=0)

**The hitcnt (hit count) shows us how many times that specific ACE has been used by the PIX which gives us the best indication of if they are being used or not.**

The PIX automatically adds the line numbers for the ACE’s and requires no configuration from the administrator.

**The line numbers are only displayed when you issue the sh access-list command and will not appear when you view the running or startup configuration**

So say we add a new web server with the IP of 80.80.80.81, we need to be able to add the ACE without taking down the whole ACL.

Here is what we do:

Code: Select all: London(config)# access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www

This would add the ACE to the ACL at line 3 and push the other ACE’s down one (unlike a router where this command would overwrite the existing ACE)

Code: Select all: London(config)# sh access-list access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0) access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www (hitcnt=0) access-list ACLOUT line 4 permit udp any any (hitcnt=0) access-list ACLOUT line 5 permit tcp any any eq ftp (hitcnt=0) access-list ACLOUT line 6 permit tcp any any eq https (hitcnt=0)

Or if we decide we don’t need a particular ACE anymore we use the ‘no’ command to remove it from the ACL.

Code: Select all: London(config)# no access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www

Remarks
When a lot of ACE’s are configured in an ACL viewing and administering them can become very hard indeed, especially when you are looking for a certain ACE to alter. For this reason Cisco have given us the option to add a remark to an ACE to better explain to us or subsequent administrators what the ACE is for.

Code: Select all: London(config)# access-list ACLOUT line 1 remark BILLING WEB SERVER ACE London(config)# access-list ACLOUT line 3 remark ORDERING WEB SERVER ACE

Code: Select all: London(config)# sh access-list Access-list ACLOUT line 1 remark BILLING WEB SERVER ACE access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0) access-list ACLOUT line 3 remark ORDERING WEB SERVER ACE access-list ACLOUT line 4 permit tcp any host 80.80.80.81 eq www (hitcnt=0) access-list ACLOUT line 5 permit udp any any (hitcnt=0) access-list ACLOUT line 6 permit tcp any any eq ftp (hitcnt=0) access-list ACLOUT line 7 permit tcp any any eq https (hitcnt=0)

As you can see in the above output the remark is inserted above the ACE it is remarking about and all the subsequent line numbers are incremented by one. This is a good example as to why anything like this should be wrote in capitals, as it stands out straight away for us.

A remark can be up to 100 characters long.

ICMP

ICMP can be configured in pretty much everyway imaginable on the PIX.

By default pinging through the PIX to a PIX interface is not allowed but pinging an interface from a host attached to that interface is permitted. So for example a host on the internal network can ping the INSIDE interface but not the OUTSIDE interface.

It is recommended to permit ICMP type 3 messages (destination unreachable) as denying this type 3 ICMP disables the ICMP MTU discovery which can cause IPSec and PPTP traffic to fail.

To allow ICMP we use the following command:

Code: Select all: London(config)# icmp permit any echo-reply outside London(config)# icmp permit any unreachable outside

The syntax for the ICMP commands is:

icmp {permit | deny} Source Address Source mask {icmp type} {interface name}

icmp permit 80.80.80.81 255.255.255.255 echo outside
icmp deny any redirect outside

And so on.

You can find a list of all the different ICMP types here:

http://www.iana.org/assignments/icmp-parameters

To remove all ICMP configurations use the ‘clear icmp’ command:

Code: Select all: London(config)# clear icmp

Alternative methods for using an ACL

NAT exemption
Up until now we have only used ACL’s to permit or deny traffic. ACL’s can be used in conjunction with other commands to alter the normal flow of traffic.

Take a site to site VPN for example, even though we may have told the PIX that everything leaving the OUTSIDE interface needs to be NAT’d, we would not want our VPN traffic to be NAT’d but rather tunnelled. Hence we need to tell the PIX to exempt the VPN traffic from NAT.

As mentioned earlier we do this with the NAT 0 command – but we can take this one step further with a NAT 0 access-list command.

Code: Select all: London(config)# access-list VPN_NAT permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0 London(config)# nat (inside) 0 access-list VPN_NAT London(config)# nat (inside) 1

You should by now be familiar with the layout of ACL’s, so I will only briefly explain the above.

We have created an ACL called VPN_NAT, which permits IP traffic from 10.10.10.0/24 going to 10.10.20.0/24.
Then we told the PIX not to NAT traffic on the INSIDE interface if it meets the settings laid out in the VPN_NAT ACL.

Policy NAT
Policy NAT is very commonly confused with NAT Exemption as explained above.

Policy NAT allows us to identify traffic that will be translated when it meets a certain criteria that we configure such as destination port and source port.

So if we want to NAT a host when it is sending HTTP traffic to Company A (90.90.90.90) to an external IP address but when it sends HTTP traffic to Company Z (100.100.100.100) we want it to use a different external IP address, then we can use policy NAT.

The following configuration should make it more apparent:

Code: Select all: London(config)# access-list COMPANY_A permit tcp 10.10.10.0 255.255.255.0 host 90.90.90.90 eq www London(config)# nat (inside) 5 access-list COMPANY_A London(config)# global (outside) 5 80.80.80.81 netmask 255.255.255.255 London(config)# access-list COMPANY_Z permit tcp 10.10.10.0 255.255.255.0 host 100.100.100.100 eq www London(config)# nat (inside) 6 access-list COMPANY_Z London(config)# global (outside) 6 80.80.80.82 netmask 255.255.255.255

Here is what we just configured:

We defined an access-list and called it COMPANY_A which permits tcp traffic from 10.10.10.0 255.255.255.0 going to 90.90.90.90 that is equal to www (HTTP).

Then we told the PIX that any traffic that matches the criteria defined in access-list COMPANY_A should be NAT’d to the IP address defined in the global pool with the ID of 5

We then defined the global pool by giving it an ID of 5 and the IP address of 80.80.80.81 255.255.255.255

So when a host on the 10.10.10.0 network sends HTTP traffic to 90.90.90.90 the PIX will NAT it to an external IP of 80.80.80.81

We then configured traffic destined for COMPANY Z in the exact same way, just with the relevant IP addresses.
When the PIX sees HTTP traffic destined for 100.100.100.100 it will NAT it to an external IP of 80.80.80.82

The ACL defines the type of traffic to be NAT’d – and the NAT command defines what the translation will be.

So we have an ACL in conjunction with a NAT command.

Filtering Malicious Code

We can also configure the PIX to filter unwanted code such as ActiveX and Java. Although you may thing this will be a very complex thing to configure, it is in fact extremely easy.

Java
As we all know Java programs can provide an ideal ‘carrier’ through security systems to invade an inside host as they are executable programs that arrive on port 80 – which is nearly always open in most firewalls. Java can contain hidden code that could potentially destroy data on an internal network.

Most decent security policies prevent Java Applets from being downloaded/displayed.

The Applet filter on the PIX looks out for the ’café babe’ string and if found it will drop the packet(s).

**Read THIS if you are unsure what café babe refers to. Basically it is the unique ‘Magic Number’ that identifies the type of program **

A sample Java class snippet would be:

Code: Select all: 0000000: café babe 002 004a 0023 6243 8252

The café babe identifies it as a Java program, which obviously the PIX will see and block the packet.

**MAC OS X also used the café babe magic number, so you may want to test the configuration before hand if you have OS X hosts on your network**

To configure Java filtering we use the following commands:

Code: Select all: London(config)# filter java 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

The above command simily filters java on port 80 to any local IP address ( 0.0.0.0 0.0.0.0) going to any remote IP address (0.0.0.0 0.0.0.0)

Or we could have:

Code: Select all: London(config)# filter java 80 10.10.10.10 255.255.255.255 0.0.0.0 0.0.0.0

Which would stop the host with the IP address of 10.10.10.10 from downloading a Java Applet from any IP address.

We can configure it for individual hosts, subnets or entire networks in this way.

ActiveX
ActiveX controls or Object Linking and Embedding (OLE) as it’s known by some are applets that can be inserted in to web pages or other applications and provide a method of entry on to a network through a firewall as just like java they arrive on port 80 and can be embedded in a web page without the users knowledge and can bring a server to its knees fairly quickly.

It is blocked in exactly the same way as Java, we just replace the ‘java’ keyword with ‘activex’

Code: Select all: London(config)# filter activex 80 10.10.10.10 255.255.255.255 0.0.0.0 0.0.0.0

Again, it can be configured for certain hosts, subnets or the entire network.

URL Filtering

The PIX itself can not filter URL’s but instead it can forward requests to a web filter server such as Websense and N2H2

When the PIX receives a request from a user requesting access to a URL the PIX wil querery the URL filter server to enquire if it should block or return the requested web page. Web filter servers can be configured to display a blocking message or to send the users to a particular web site.

For large networks multiple web filter servers can be configured, up to a maximum of 16. But you may only use one application at a time, either Websense or N2H2.

To configure the PIX to use a Websense server the following command is used:

Code: Select all: London(config)# url-server (inside) vendor websense host 10.10.10.50 protocol tcp

The syntax for a Websense server is as follows: (anything in the [] will be specific to your setup and requirements, anything without the [] should be entered as shown)

Code: Select all: url-server [interface name] vendor websence host [ip address of server] [timeout in seconds] protocol [tcp | udp | version]

And for N2H2 the syntax is: (anything in the [] will be specific to your setup and requirements, anything without the [] should be entered as shown)

Code: Select all: url-server [interface name] vendor n2h2 host [ip address of server] [port number to talk to n2h2 server, default is 4005] [timeout in seconds] protocol [tcp | udp ]

So now we have told the PIX where the web filter server is and what make it is, we need to turn URL filtering on:

Code: Select all: London(config)# filter url http 0 0 0 0 allow

We have told the PIX to filter url’s from data crossing the PIX that or on port 80( http) from any local IP address 0 0 destined for any IP address 0 0. If for any reason the URL filter server was to go offline then the PIX will allow the traffic through.

Without the ‘allow’ command at the end the PIX would block all traffic on port 80 until the web filter server came on line again.

We can add a few more key words to the end of the command should we so wish:

proxy-block – Prevents users from connecting to a HTTP Proxy server
longurl-truncate – Enables outbound URL traffic regardless of if the URL buffer is available or not
longurl-deny – Denies the URL request if the URL is over the maximum size or the URL buffer is unavailable.
cgi-truncate – Sends a CGI script as a URL

And finally, with version 6.3 and later of the PIX operating system we can also filter HTTPS and FTP traffic.

The syntax is the same as the HTTP command; we just remove the URL keyword and replace HTTP with HTTPS or FTP.

Code: Select all: London(config)# filter https 0 0 0 0 allow

Code: Select all: London(config)# filter ftp 0 0 0 0 allow

If we wanted to could use 443 instead of the HTTPS keyword and 21 instead of the FTP keyword.

The only difference is we have one more keyword we can use with FTP filtering and that is interact-block, which would stop a user connecting to an FTP server through an interactive FTP application.

Next Chapter will be Object Grouping.

Cisco PIX – Object Grouping for quick and easy ACL’s.

admin — Fri, 08 May 2009 22:31:01 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

PIX 6: Object Grouping

It is recommended to read Access Control Lists and Content Filtering before reading this:

http://tazforum.thetazzone.com/viewtopic.php?t=3848

When configuring access and rules for the PIX, if you have a lot of servers, protocols, ICMP filtering and networks that you need to configure access lists for, pretty soon creating individual ACL’s will become a very complicated thing; for this reason Cisco have created the Object Group feature.

Object Grouping is supported by version 6.2 and later of the PIX Operating System.

Object grouping allows you to group together the following:

Network – to group hosts and subnets
Protocol – to group IP protocols such as TCP, UDP etc
Service – to group port numbers, hence services
ICMP-type – to group ICMP types

After creating a group, you can apply an access list to everything that is in the group.

Network Object-Group
Say for example if you have five web-servers all needing an external presence ( a NAT and an ACL) instead of having to create an ACL for each of them, you can group them altogether in a network object group and just have the one ACL that will apply for all of them.

So, say your web servers are addressed as 10.10.10.1 all the way to 10.10.10.5 and you have gave each of them a static NAT ranging from 80.80.80.81 to 80.80.80.85.

Now that you have NAT’d those to an external IP, you now need to configure an access rule to say that traffic is permitted to be sent to them. Without Object Grouping you would have to write five different ACL’s, which whilst it doesn’t sound very time consuming, imagine you have 10 web servers, 5 FTP servers and a mail server, there is 16 ACL’s at a minimum – also when you look at the running config you now have 16 ACL’s to trawl through. With Object grouping we can reduce this to just 3 ACL’s.

We create an Object Group like so:

Code: Select all: London(config)# object-group network WEB-SERVERS London(config-network)# description Billing Web Servers London(config-network)# network-object host 80.80.80.81 London(config-network)# network-object host 80.80.80.82 London(config-network)# network-object host 80.80.80.83 London(config-network)# network-object host 80.80.80.84 London(config-network)# network-object host 80.80.80.85 London(config-network)#exit London(config)#access-list OUTSIDE_ACL permit tcp any object-group WEB-SERVERS eq www London(config)#access-group OUTSIDE_ACL in interface outside

Ok, so let’s break this down. Our first command tells the PIX we are configuring an object-group and it is going to be a network object group and that we are going to call it WEB-SERVERS

Code: Select all: London(config)# object-group network WEB-SERVERS

Notice the prompt now changes to

Code: Select all: London(config-network)#

To let us know we are configusing a network object group.

Then we gave it a description, the description should be intuitive to the type of group you are configuring to aid yourself and future admins when configuring the firewall. The key-word to enter a description is description funnily enough:

Code: Select all: London(config-network)# description Billing Web Servers

Then we defined what is actually in the network object-group:

Code: Select all: London(config-network)# network-object host 80.80.80.81

The first part of the command tells the PIX that we want to add a network-object to the object-group and that this object is the host with the IP of 80.80.80.81 we then do this for every host we want to place in this object group.

**As the ACL is going on the outside interface, it will be dealing with the external IP addresses (the incoming packets will be destined for the 80.80.80.x address not the 10.10.10.x one) we need to use the external IP of the host. Names can also be used if you have previously configured them**

So after we have added all the necessary hosts to the object group we save it by exiting from the object-group sub menu:

Code: Select all: London(config-network)#exit

The first thing to note is that it brings us out of the object-group sub menu and places us back in to the global configuration menu. We can tell this as the prompt is now:

Code: Select all: London(config)#

So we have now told the PIX we want to define a network object group, we want to call it WEB-SERVERS and we have told it what hosts we want to place in this object group.
Now we need to take the object-group and apply it to an ACL, as this is the reason we have defined it in the first place.

To do this we configure an ACL in the normal way but where we would put the local host in, we put the name of the object group

Code: Select all: London(config)#access-list OUTSIDE_ACL permit tcp any object-group WEB-SERVERS eq www

We start the command off in the normal way by telling the PIX we are configuring an access-list and that we want to call this access list OUTSIDE_ACL then we tell it what we want the ACL to do by configuring it to permit tcp traffic from any host that is destined for anything defined in the object-group called WEB-SERVERS and if the packet equals www (HTTP) it is allowed to pass through in accordance with the NAT rule in place for it.

Without an object group we would need to configure five different ACL’s, one for each host.

Service Object-Group
We can also use object groups to group types of Service/Ports such as HTTP, HTTPS, FTP etc

Code: Select all: London(config)# object-group service WEBandFTP tcp London(config-service)# port-object eq ftp London(config-service)# port-object eq http London(config-service)# port-object range 2000 3000 London(config-service)# exit London(config)# access-list OUTSIDE_ACL permit tcp any any object-group WEBandFTP London(config)# access-group OUTSIDE_ACL in interface outside

We define the object group in the same way as the network object group with the exception that we use the key word “service” instead of “network” and then name it something intuitive as to what it will do. Directly after the name we inform the PIX what IP protocol we want to use, the options for this are:

TCP
UDP
TCP-UDP

As the services defined in the object group (FTP and HTTP) use TCP I only need to define TCP after the object group name. Next instead of adding hosts like we done in the network object group, we add the ports/services we want to group together. I added the following command:

Code: Select all: London(config-service)# port-object range 2000 3000

To illustrate how to group a range of ports together.

Then all that is left to do is apply the object group to an ACL and apply the ACL to an interface if needed.

Code: Select all: London(config)# access-list OUTSIDE_ACL permit tcp any any object-group WEBandFTP London(config)# access-group OUTSIDE_ACL in interface outside

We can also take the service object groups one step further by having multiple object groups within the same ACL:

Code: Select all: ( London(config)# object-group service PERMITED-PORTS tcp London(config-service)# port-object eq ftp London(config-service)# port-object range 2020 2021 London(config-service)# exit London(config)# object-group service HIGH-PORTS tcp London(config-service)# port-object range 1024 65535 London(config-service)# exit London(config)# access-list OUTSIDE_ACL permit tcp any object-group HIGH-PORTS any object-group PERMITED-PORTS

Here we have defined two port groups, one consisting of permitted ports, in our case FTP and a custom FTP port, and then we defined another service group and included all high-range ports.

In the ACL we are permitting traffic from any host with a source port of any between 1024 and 65535 to go to any host as long as the destination port is in the PERMITED-PORTS object group (21, 2020 or 2021)

ICMP Object-Groups
We can group ICMP types in an object group:

Code: Select all: London(config)# object-group icmp-type PERMITTED_ICMP London(config-icmp-type)# icmp-object time-exceeded London(config-icmp-type)# icmp-object echo London(config-icmp-type)# icmp-object 3 London(config-icmp-type)# exit London(config)# access-list OUTSIDE_ACL permit icmp any any object-group PERMITTED_ICMP

You can use either the RFC compliant numerical value for the ICMP type or use the ICMP type name.

I think the ICMP object group speaks for itself so will not elaborate on it other than to say use the ICMP types wisely and do not allow unrestricted ICMP in to your network.
You can find a list for all the ICMP types and their respective numbers here:

http://www.iana.org/assignments/icmp-parameters

Protocol Object-Groups
IP types can also be grouped together with protocol object groups providing that they are the standard PIX protocol names allowed in an access-list such as TCP, UDP, GRE), EIGRP etc. Basically if the protocol sits on top of TCP or UDP then it cannot be specified with a protocol object group.

Code: Select all: London(config)# object-group protocol WEBSERVERandROUTER London(config-protocol)# protocol-object tcp London(config-protocol)# protocol-object udp London(config-protocol)# protocol-object eigrp London(config-protocol)# exit London(config)# access-list OUTSIDE_ACL permit object-group WEBSERVERandROUTER any any

Nesting Object-Groups
Finally it is possible to nest and object group, within an object group of the same type.

So:

Code: Select all: London(config)# object-group network ABC-WEBSERVERS London(config-network)# network-object host 80.80.80.100 London(config-network)# network-object host 80.80.80.101 London(config-network)# exit London(config)# object-group network 123-WEBSERVERS London(config-network)# network-object host 100.100.100.100 London(config-network)# network-object host 100.100.100.101 London(config-network)# exit London(config)# object-group network ALL_WEBSERVERS London(config-network)# group-object ABC_WEBSERVERS London(config-network)# group-object 123-WEBSERVERS London(config-network)# exit

We have defined two object groups, containing web servers belonging to two different companies, ABC and 123 respectively this will allow us to configure separate access lists containing separate object groups but we have also made a third object group called ALL-WEBSERVERS which will allow us to apply an ACL to all web servers for both companies.

This can easily be done for any of the four different types of object groups, but remember they have to be of the same type, i.e. you can not nest a protocol object group in with a service object group.

**One point I forgot to mention, the “exit” command save the newly defined object group to the running config.**

Next PIX instalment will be Modular Policy Framework (MPF)

Cisco PIX – Slightly Advanced Configuration

admin — Sun, 15 Feb 2009 05:37:02 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

[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.

Cisco PIX – Introduction, how it operates and the CLI.

admin — Mon, 07 Jul 2008 02:28:38 +0000

TUTORIAL BY NOKIA FOR THETAZZONE/TAZFORUM

TAZ Forum :: A Computer, Gaming, and Social Network Community of Friends :: TAZForum :: View topic – Cisco PIX – Introduction, how it operates and the CLI.

The PIX Firewall.

The Cisco PIX firewall is one of the most popular brands of firewalls available today. Whilst they can be a very useful piece of equipment, it is not always straight forward to configure them.
Due to the nature of a Firewall and what it is used for it is essential to deploy and configure it correctly to prevent you inadvertently leaving your network wide open to attack when you thought it was secure.

The PIX comes in several form factors:

501 – This the cheapest and smallest firewall in the PIX range and is aimed almost exclusively at Small Office – Home Office (SOHO) setups. It can support up to 7500 concurrent connections and has 60 Mbps throughput.
Interface wise it has a 10/100BASE-T Ethernet interface for the outside connection (100BASE-T is only in version 6.3) and a four-port 10/100 switch for the inside interfaces. It can also support up to 10 simultaneous VPN connections. It does not support any failover at all.

As you can no doubt see it is only useful for the very small SOHO setup.

506E – Although more useful for the SOHO setup than the 501, the 506E is more geared up towards the ROBO setup (Remote Office – Branch Office) and is an ideal choice for a small – medium sized business if you don’t need any failover capabilities, a lot of VLAN’s or a very fast throughput of data.
It can provide 25,000 concurrent connections and 100 Mbps clear text throughput.
It has only two 10/100BASE-T interfaces and support for up to Two VLAN’s and can support up to 25 simultaneous VPN connections. It does not support version 7 of the PIX operating system or the ADSM utility, instead it has a less useful PDM for remote configuration.

515E – Is designed for small to medium sized businesses and enterprise networks. It can handle up to 130,000 concurrent connections and provides 190 Mbps of clear text throughput. It can have up to 6 10/100 Fast Ethernet interfaces, 25 VLAN’s and up to five contexts (contexts will be explained later).
It is the first PIX in the range that supports failover and version 7 of the PIX operating system. It can have up to 2,000 VPN tunnels and supports site to site and remote access VPN’s

525 – The 525 is probably the most common security appliance in the PIX range that you may come across due to its affodability Vs funcionality. It can support up to 280,000 concurrent connections, has 330 Mbps of clear text throughput, up to 10 10/100 Fast Ethernet interfaces, up to 100 VLAN’s and 50 contexts.
It supports failover and version 7 of the PIX operating System and up to 2,000 VPN tunnels.

535 -The Cisco PIX 535 is a high-performance, purpose-built security appliance designed for very large enterprise and service provider networks.

It supports up to ten 10/100 Fast Ethernet interfaces or nine Gigabit Ethernet interfaces and redundant power supplies, can handle up to 1.7 Gbps of firewall throughput with the capacity to handle more than 500,000 simultaneous sessions.

Certain PIX 535 models include an integrated hardware VPN acceleration card that delivers up to 440 Mbps of Triple Data Encryption Standard (3DES) VPN throughput and 440 Mbps of Advanced Encryption Standard-256 (AES) VPN throughput.

The PIX firewall range has a wide variety of add on cards and can work hand in hand with the Adaptive Security Appliance (ASA). There are too many add on cards and different ASA configurations to go in to here but the Cisco web site has all the information if you need to research it further.

Getting Started:

There are three ways to connect to the PIX:

1) Via the console cable
2) Via the PDM or for the 515 and later the ADSM
3) Via Telnet /SSH (needs to be configured first)

If you are comfortable with the Command Line Interface (CLI) on the PIX then the best way to connect is via the console port. To do this, simply attach the supplied console cable and open hyper terminal (or a terminal emulation program of your choice) set the baud rate to 9600 and press enter.

If you are not comfortable using the CLI then Cisco have provided a GUI for you to use. On the 501 and the 506E this is known as the PDM and on the 515 and above it is known as the ADSM.

Connect to the INSDIE interface of the PIX (Eth1) using a normal Cat5 Ethernet cable, open your web browser and type 192.168.1.1.If you get stuck trying to connect to the PIX to use the PDM/ADSM refer to the user manual and it will tell you the IP address range the DHCP server uses. This is usually 192.168.1.1/24 so either set your PC to receive an IP via DHCP or configure it in the correct subnet 192.168.1.2 is usually good with a 255.255.255.0 mask.

There is a known problem when using the PDM with Sun’s latest versions of Java. You need to have version 4 installed, which you can get from the archive pages on the Sun web site. If you can not connect you may need to remove the latest Java update from the Add/ Remove programs window in the control panel.( 5.0 update 5 and 5.0 update 6)

For now we will use the CLI.

Once connected there are four administrative modes you can be in:

1) Unprivileged
2) Privileged
3) Configuration
4) Monitor

When you first connect via the CLI you will be in unprivileged mode, which uses the > prompt:

Code:

Firewall>

Just like a router you would now type ‘enable’ or en for short

Code:

Firewall>en

If there is a password set you will now be prompted for a password, the PIX usually ships with the default password of either pix or cisco.

If you enter the password successfully you will now land in privileged mode, which uses the # symbol:

Code:

Firewall#

From the privileged mode you can issue most commands that will show you details about the configuration but will not allow you to alter the configuration except for setting passwords, writing configuration to memory and a few others:

Code:

Firewall#show running-config (or sh run for short)

The above command would show you the entire running configuration of the PIX.
To make and changes to the actual configuration of the PIX we need to be in configuration mode. We get this by using the command Configure Terminal (or conf t for short)

Code:

Firewall#conf t

The prompt will now change to:

Code:

Firewall#

This shows us we are in configuration mode. From here we can now change the configuration of the firewall.

Monitor mode is a special mode that enables us to update the OS image over a network to perform password recovery. Whilst in Monitor mode we can enter commands to specify the location of a TFTP server, the location of the updates software or a password recovery file to download.

As mentioned with most Cisco equipment that uses a CLI commands can be abbreviated to the fewest unique characters for that command.
So sh run is short for Show Running-Configuration, en is short for Enable, copy run start is short for copy running-configuration > startup-configuration.

The first thing we can do is set a password for the PIX to stop unauthorised access. It is easy to get so engrossed in the configuration of the PIX to forget to set a user password once finished, so I make it a habit to set the password on any device first.

There are 15 different access levels we can grant a user when he logs on to the PIX, with 15 being the highest. Depending on what password is used will depend on what access level the user is dropped in to.

To set the password we need to be in the privileged mode (the # prompt).

Code:

Firewall>en
Password:
Firewall#

We now issue the command enable password

Code:

Firewall#enable password tazzone123 15

Enable = we want to set the enable password (the password that is presented when the enable command is issued)
Password = we are setting the password and not giving the enable command.
Tazzone123 = the password we want to set
15 = the privilege level that anyone using that password will be granted. In this case the user will have total control of the PIX.

Before we go in to the configuration commands there are a few commands we need to know to save the configuration to memory and to erase it in case we mess it up!

Like a router the PIX has two different configurations; running configuration and start-up configuration.

The running configuration is what we are making all the changes to. If after making the changes we do not save it to the start-up configuration and the PIX was to be unplugged, suffer a power cut etc it would start up with the configuration that is in the start-up configuration and all our changes would be lost.

There is a twofold advantage to this – we can make changes ‘on the fly’ and if the firewall was to stop working as it should, we can just reload it and it will have its old configuration, the other benefit of it is if we are unsure of any changes that have been made we can use the sh start and the sh run commands to view both configuration’s and compare then to each other.

After we have made a change to the running configuration and are sure we want to keep it, the command ‘write memory’ is used to save the running configuration to the start-up configuration.

Code:

Firewall#write memory (or wr mem for short)

If we have made a complete hash of the running configuration and want to start over again but still retain the start-up configuration we can use the command ‘clear configure all’.

Code:

Firewall#clear configure all (or clear con all for short)

Finally if we want to clear everything and start from afresh we can use the command ‘write erase’

Code:

Firewall#write erase (or wr er for short)

You will be prompted to confirm that you do want to erase the start-up configuration, hitting Enter or typing Yes will clear the configuration.

We will still be active in the running configuration however so we need to either reload the PIX or copy the running configuration to the start-up configuration.

To reboot the PIX we use the command ‘reload’

Code:

Firewall#reload

We will be prompted to confirm we want to reload the device.

Or we can use the copy run start command to copy the running configuration to the start-up configuration:

Code:

Firewall#copy run start

If you are writing a script to send or paste straight in to the PIX we can issue the ‘reload noconfirm’ command – which will just reload the device without asking for confirmation.

*Before making any changes to the PIX once you have an up and running configuration you can copy the results of the ‘show run’ command in to a text editor such as notepad. Then if you ever need to revert back to the configuration you can just copy and paste it straight back in to the firewall.*

Security Levels

The whole concept of the PIX security appliance revolves around security levels. The more trusted the network the higher the security level.

Obviously the most un-trusted network is going to always be the internet – and the interface that is going to be attached to the internet is the OUTSIDE interface (Eth0) which has by default the security level of 0.

The most trusted network attached to the PIX is going to be your internal network, which funnily enough is attached to the INSIDE (Eth1) interface and has a security level of 100 by default.

*You can remember which interface is which by the Ethernet numbers, Eth0 = Outside interface, Eth1 = Inside network…. 0-Out 1-In)*

The interfaces came with the INSIDE and OUTSIDE names pre-complied and can not be changed, likewise the security levels can not be changed either.

Code:

Outside level 0 -<–<—<–|PIX|–<—<—<-Inside level 100

An interface that has a higher security level can by default send traffic to an interface with a lower security level – hence internal hosts attached to the inside network with a security level of 100 can by default pass traffic through the outside interface as it only has a security level of 0. Traffic can flow downhill but not uphill.

This allows for one way (outbound) connections with a minimum number of configuration changes. The PIX will monitor the outgoing packets and when the return packet comes in, it is checked to ensure it is a valid packet and if so, is sent on its way.

The outside interface as it has a 0 security level can not send traffic to the inside interface with out a preconfigured permission to do so in the form of an Access Control List (ACL)

If you were to add a third interface for a DMZ and give it a security level of 50, the INSDIE interface would be able to pass traffic to it by default, but with out an ACL the DMZ would not be able to initiate a connection to send data to the INSIDE interface and obviously the least trusted interface (OUTSIDE) would not be able to initiate any connection to any interface with out an ACL being in place.

It is possible to enable same security level traffic flow, so two interfaces with the same security level can pas traffic unhindered should you wish..

The PIX Adaptive Security Algorithm is a stateful approach to security, in so much as every inbound packet (the packet originating from a host on a less secure network destined for a host on a more secure network, i.e. DMZ (50) ->->-> INSIDE (100) ) is checked against a database called the State Table which is stored in the PIX’s memory which keeps the state of every connection that has passed through the PIX. This will tell the PIX if the packet is a return packet from a connection initiated from the INSIDE network, or if it has arrived out of the blue.

This table keeps a record of the original packets:-

1) Source IP Address
2) Source Port
3) Destination IP Address
4) Destination Port
5) Additional TCP / UDP Flags / Protocol etc
6) Original TCP Sequence number
7) Replacement TCP Sequence number
(The PIX randomizes the first TCP sequence number to reduce the risk of TCP Hijacking and does this by default.)

If a returning packet does not match ALL of the above criteria it is dropped there and then. Each of these entries is called a ‘Session Object’ and will stay in memory until the connection is terminated in the normal way or the session has timed out.

So in a nutshell if a packet arrives on the OUTSIDE interface, the PIX will check that either a Static NAT/PAT Translation exists for it and if so will then check if it is permitted by an ACL, if there is an ACL the PIX will act in accordance with it.
If no static translation exists the PIX will check the state table to see if it is a return packet from a connection that has been initiated by an inside and therefore trusted host – if it meets all the requirements in the state table the packet is allowed to continue its journey. If not the packet is dropped straight away.

The stateful design to the PIX maintains the secure perimeters of the different networks by creating session flows based upon the destination and source address and also the destination and source port numbers of the packets. Fundamentally, this is how the whole PIX is designed to work and will be discussed in more detail in further papers.

*Inbound and outbound traffic is not necessarily traffic coming from the internet to the inside network and vice versa. Traffic is considered to be inbound if it is coming from an interface with a lower security level and is considered to be outbound if it is coming from a higher security level. The most interfaces the PIX can support is 14 depending on Model and License*

Next ‘Chapter’ is Basic PIX configuration.