PIX Lab: Tutorial in PIX

Following is PIX LAB tutorial:

1. Basci PIX Configuration
2. Installing WebSENSE
3. Config NAT Stats and Conduits
4. Config Multiple Interfaces
5. Config Authentication
6. Config the Primary PIX Firewall
7. Verify IPSec Configuration
8. Passwrod Recovery & Image Update
9. Configuring the CSIS Feature Set
10. Configure Cisco Secure ACS NT
11. Configure AAA and Authentication Proxy
12. Verify Authentication Proxy Configuration
13. Configure the PIX as a DHCP Server Configuring PIX as a DHCP Client
14. Configuring Logging
15. Configuring Logging -Verification
16. Denying Outbound Traffic
17. Allowing Outbound Traffic
18. Configure PIX to work with Websense
19. Configure WebSense to Block by URL
20. WebSense to Block by Workstation
21. Configure the Fixup Protocol on PIX
22. Configuring PIX for IDS Signatures
23. CSACS Install and Add User
24. Configure IKE and IPsec on the PIX

Link Download:

Let visit this thread in forum to download

How to build a secure Enterprise Firewall?

Firewalls and their architecture are a critical part of sound network security, but they are only the beginning to a secure enterprise network. In this paper, we will cover the fundamentals of good firewall design using a single multi-homed firewall design with stateful failover. The end result will be a network that is simple to manage, high performance, high availability, high security, and budget saving.

What is the most important aspect?

There has been some fierce debate in design philosophy on whether it is best to have one brand of firewall or more. I personally subscribe to the idea that two are usually not better than one because firewall vulnerabilities are rarely the problem in vast majority of break-ins. Hackers typically don’t need to hack the firewall because they come in through the ports that are already open and exploit the weaknesses on the servers behind the firewall. Additionally, there usually is nothing there for the hacker to hack on the firewall, because any smart administrator will lock that firewall down to drop all connections to the firewall it self except for the designated firewall management stations. Even if for example there is a known vulnerability in Apache or SSH on your firewall, the threat can only come from the designated management stations which are well protected or even turned off

1. Human factors comprises 99% of all firewall compromises
2. The cost of running multiple vendor firewalls may even force you to give up on the very things you need to be most concerned about.
3. Finite resources are usually much better spent hardening a single platform.
4. The biggest problem in firewall security is poor maintenance, bad policy and bad network design

Firewall design goals:

A good firewall policy and network design can mitigate (but not eliminate) the following security risks:

• The Internet attacking your DMZ servers
• Any part of your network attacking the Internet
• Your users or servers attacking your DMZ servers
• Your DMZ servers attacking your users, servers or even further harming them selves
• Threats from business partners and extranets
• Threats from remote offices via WAN connections

The first point is rather obvious; simply by limiting the service port access from the Internet to your DMZ servers, you can greatly reduce the chances that they will be hacked. On an SMTP mail server for example, only TCP port 25 is permitted from the Internet. Therefore, if that SMTP server happened to have a vulnerability in it’s web server service or daemon, it would not be exposed to the Internet where worms and hackers are always on the prowl for port 80 vulnerabilities.

The next point may seem a bit odd, why would one be concerned about protecting the public Internet with one’s own network? While this may seem to be just a good exercise in Netizenship (Internet citizenship), it is also for the selfish purpose of protecting one’s own Internet connection. Take the recent SQL slammer worm for instance; it managed to decimate large segments of the Internet for an entire day. Had there been better firewall policies in place, you could have prevented the DoS (Denial of Service) effect on your Internet connection and also saved the Internet.

One of the least recognized dangers in security is the internal threat. The most expensive firewall on the planet cannot protect your network from “Sneaker net” with conventional designs, a phenomenon where your user walks in to your network with a laptop or disk infected with a virus or worm from home or some other source. A good network design and firewall policy would protect your DMZ servers from your servers and users the same way it protects them from the Internet.

The reverse situation of the above is also a potential threat. Since DMZ servers are exposed to the public Internet, there is a chance that they can be compromised by a hacker or worm. It is essential that you limit the damage that your DMZ servers can do to your internal servers or user stations. Additionally, a tight firewall policy can also prevent DMZ servers from further damaging them selves. If a server is compromised by a hacker through some known or unknown vulnerability, the first thing they will try to do is down load a “root kit”. The firewall policy should prevent the downloading of this deadly payload and make life harder on the attacker.

Additional threats from Extranet partners and Remote office WANs can also be mitigated. Routers that connect these networks using WAN technologies such as frame relay, ISDN, private lease line, or VPN tunnels can be secured by the firewall. Trying to implement security with firewall enabled routers on each and every one of those routers is expensive not only in terms of hardware/software costs, but setup and administration as well. An enterprise firewall can provide simple and centralized management of WAN and Extranet security with additional zones beyond the conventional triple homed design.

The bottom line is that firewalls can limit the flow of traffic between network zones which are broken down by logical organization and functional purposes. A firewall cannot however limit and protect hosts from other hosts within the same subnet because data never passes the firewall for inspection. This is why the more zones a firewall supports, the more useful it is in a well designed enterprise network. This is now easier than ever to accomplish since all of the major players like Cisco and Nokia support trunking of interfaces. A single gigabit port can easily support as many zones as you like and still perform much better than several fast Ethernet ports.

Implementing a good firewall policy:
1. The first critical component of secure firewall architecture is policy design.

In firewall policies, this simply means that unless there is a specific reason that a service needs to be used, that service should be blocked by default.

To implement this default service blocking policy, only one simple firewall rule needs to be implemented globally at the end of all policy sets, the any-any-any-drop rule. This simply means that the default behavior of the firewall will drop all packets from any source to any destination on any service. It is important that this rule is the last rule in any policy set because firewalls act from top to bottom.
==> The narrower these rules are made, the more secure the network is.

For example, users should be permitted outbound ports for common services like HTTP, FTP, media services, but nothing else should be permitted unless there is a special case to allow such traffic. When there is a special case based on a business need, tightly targeted rules should be added when approved. A very common error that administrators make is that they extend user rights to server and DMZ networks. Outbound rules that are appropriate for users are generally not appropriate for servers. When you really think about it, there is no reason that your Web server needs to surf the Web. Servers should serve and are rarely a client. The bottom line is, the DMZ or Server farm should almost always never be permitted to initiate traffic. Servers typically take in requests, but almost never request services from the public Internet except for XML and EDI applications with business partners. Other exceptions can be things like legitimate vendor sites that provide drivers and software updates, but all exceptions should be narrowly defined. Following these strict guidelines can vastly reduce server compromises, to the point that even the intra-subnet spread of worms like Code Red and NIMDA could have been prevented had such policies been in place even if the servers were not patched.

Implementing a good firewall network design:

Figure 1 illustrates a Pix 525 with 2 Gigabit Ethernet ports and 6 100-Mbit Fast Ethernet ports. This is a great way to achieve physical separation of the different subnets needed for an Enterprise network, provided that each port is plugged in to a physically different Ethernet switch. How ever, I can tell you that this is rarely done and is often impractical to deploy more than half a dozen physical switches in the data center for each subnet. More often than not, enterprises employ virtual LANs by segmenting a single physical switch in to multiple bridge groups, which is extremely easy to provision addition ports for any existing subnet or future ones. Because of this and the fact that all the enterprise firewall vendors have added 802.1q trunking support (Cisco came late in February 2003), one can easily use a single Gigabit port to connect the Layer 3 core switch, DMZ, extranet, guest subnet, and any other VLAN subnets that an enterprise needs. Therefore, one can do with out the second Gigabit Ethernet card and 4 port Fast Ethernet card in the PIX 525 shown in figure 1. This has how ever raised need for Layer 2 switch security against things like “VLAN hopping” which is rarely discussed even among experts, but we shall leave that for another piece. But even with the trunked Gigabit port, you should continue using the two built in Fast Ethernet ports for public Internet and stateful failover synchronization. Bottom line, two firewalls in the same class as a PIX 525 can provide enough flexibility and throughput for most enterprise networks.

Figure 2 illustrates the use of the two firewalls in a stateful failover configuration. Network connections were only drawn to the logical firewall to avoid messy connectors in the drawing, but in reality there would be a physical connection to each firewall for each subnet. Those connections could be physically separate cables or a single trunked cable over a single Gigabit connection in to your 802.1q VLAN capable switch. The two built in fast Ethernet ports in a PIX 525 are used for the public Internet connection and the stateful failover synchronizing, and the remaining internal subnets can share the Gigabit port. This configuration is much faster than a configuration with separate fast Ethernet ports that often get congested when trying to do network intensive tasks like tape backup between zones.

The internal side of the firewall can connect the following subnets:

• Core layer 3 switch
• DMZ
• Extranet and WAN
• Guest zone
• Others

The core layer 3 connection typically goes to your core switch with routing capability between VLANs. Those VLANs from that core switch may contain hundreds of user VLANs with tens of thousands of users, and server farm VLANs with hundreds of servers that do not get direct Internet exposure. You must understand how ever that there is no firewall between the server farm VLANs and the user VLANs in this example, because user to server traffic is routed by the core L3 switch and never passes through the firewall. There are companies that go to the extreme of putting all of their servers directly behind the firewall and separated from the users, but the management of that many internal servers behind a firewall with a lot of port requirements can be very difficult, so this is not often done.

DMZ is used for servers that need to be accessed from the public Internet. This is directly behind the firewall and is always filtered for traffic.

The Extranet and WAN zone is for the internal interfaces of routers that connect the remote WAN sites and partner sites. Using this configuration allows you to secure against WAN and Extranet sites without having to buy or configure firewall feature sets on the routers them selves. One can even go to the extreme of putting the external interfaces of the routers in a non-NAT zone on the firewall, this helps prevent hackers from compromising the router from the outside. This approach allows the high availability enterprise firewall to secure countless routers.

The guest zone is something new, but this is actually a security feature. Instead of guests connecting to your internal LAN when they need access to VPN or the Internet, have them connect to a guest network with access to the Internet but not your internal LAN. This new zone is extremely useful in the wireless environment. With new Wi-Fi infrastructure technology supporting VLANs and 802.1q trunking, a single wireless Wi-Fi infrastructure can support multiple VLANs, one internal VLAN running it’s own SSID and 802.1x/EAP security, and a guest VLAN that runs a simple WEP password for Internet only access.

VLAN SECURITY

by Rik Farrow

VLAN INSECURITY
VLANS WERE CREATED TO ISOLATE LANS, BUT NOT FOR THE PURPOSES OF SECURITY

Virtual LANs (VLANs) make it possible to isolate traffic that shares the same switch, and even groups of switches. The switch designers had something other than security in mind when they added this form of isolation. VLANs make it possible to share a switch among many LANs, by filtering and limiting broadcast traffic. But this form of isolation relies on software and configuration, not the physical isolation that security people like myself really like to see.

In the last couple of years, some firewalls have become VLAN aware, so that policies can be created that rely on the tags that identify a packet as belonging to a particular VLAN. While firewalls that are VLAN aware add a lot of flexibility useful to Web hosting sites, the tags that these firewalls rely on were not designed with security in mind. VLAN tags can be created by devices other than switches, and valid tags that will fool the firewall can easily be added to packets.

Let's take a look at VLANs, including how they work, why this has little to do with security, and failures of VLANs to maintain isolation. And, if you decide to use VLANs as part of your security architecture, what you should do to minimize the weaknesses involved.
PARTITIONS

The term "switch" today denotes a device that switches network traffic between interfaces, named ports. But not too long ago, switches were called bridges. Even today, if you read the IEEE standards used in switches, the term inevitably used is bridge. And if you are familiar with the way bridges work, you might want to skip ahead.

You use bridges to connect segments of the same LAN, that is, a local network that does not require routing. The bridge software learns which port that network devices have been connected to by examining the source MAC (Medium Access Control) addresses in the packets that the bridge passes. At first, the bridge
knows nothing, and must distribute all the packets it receives to every port. But over time, the bridge learns how to send packets out the correct interface by building spanning trees, an algorithm developed for choosing the right interface and avoiding loops. By sending packets out on a single port, the bridge reduces overall network traffic. Think of the bridge in highway terms, something that connects different roads, and only passes necessary traffic between these roads.

Although the use of bridges does reduce overall network traffic, making networks more efficient, bridges still need to send broadcast packets to all ports. Just as in any LAN, broadcasts mean just that, a message broadcast to all systems. ARP (Address Resolution Protocol) packets provide an important example of broadcast messages.

As bridge hardware grew more capable, with increasing number of ports and the addition of management software, a new feature appeared. You could partition a bridge, split a single bridge into multiple, virtual bridges. When split this way, broadcasts, instead of going to all ports, get limited to only those ports associated with the virtual bridge, and its virtual LAN.

Limiting broadcasts to a VLAN does not seem by itself to prevent a system on one VLAN from hopping to another VLAN-- that is, contacting a system on the same bridge, but a different VLAN. But remember that broadcasts get used to acquire the MAC address that is associated with a particular IP address, using ARP, and without the MAC address, one system cannot communicate with another on the same network. Routers, or switches that support layer three, support passing traffic between VLANs.

Over time, people have begun to consider switches as security devices rather than networking devices. Switches do make sniffing traffic destined for other systems more difficult (but not impossible, as exploits exist for doing so). And switches do produce a software-based isolation between VLANs. But that isolation is imperfect at best.

In a document found on the Cisco web site (See Resources), two scenarios are described where packets can hop VLANs, that is, pass between two VLANs on the same switch. In the first example, systems have established TCP/IP communications on the same VLAN, then the switch gets configured so that one system's port now belongs to a different VLAN. Communications continues between the two systems because each has the MAC address of the other in its ARP cache, and the bridge knows which destination MAC address gets directed to which port. In the second example, someone wishing to hop VLANs manually enters a static ARP entry for the desired system. Doing so requires that the person somehow learns the MAC address of the target system, perhaps through physical access to the target system.

Each of these two examples can be blocked by using switch software that removes the information necessary for passing packets between VLANs. In higher end Cisco switches, separate spanning trees, the tables that map MAC addresses to ports, exist for each VLAN. Other switches either have similar features, or can use configuration to filter the bridging information available to members of each VLAN.

Given the relative dearth of information about hopping VLANs within a single switch, this issue does not appear to be a serious problem.
TRUNKING

Multiple switches can share the same VLANs through configuration and tagging of the packets exchanged between switches. You can configure a switch so that a port acts as a trunk, an interface that can carry packets for any VLAN. When packets get sent between switches, each packet gets tagged, based on the IEEE standard for passing VLAN packets between bridges, 802.1Q. The receiving switch removes the tag and forwards the packet to the correct port or VLAN in the case of a broadcast packet.

802.1Q tags get added to Ethernet headers right after the source address and are four bytes long. The first two bytes contain 81 00, the 802.1Q Tag Protocol Type. The last two bytes contain a possible priority, a flag, and 12 bits for the VLAN Identifier (VID). VIDs can range from 0 to 4095, but both zero and 4095 are reserved values. The default value for the VID is one, and thus also the default value for unassigned ports in a switch configured with VLANs.

An administrator may configure a port to act as a trunk, although the default configuration for Cisco switches is that trunking is "desirable", and a port can negotiate trunking if it discovers that another switch is connected to that port. And, unless the administrator changes the configuration, a trunk port belongs to VLAN 1, which is called its native VLAN. Ports used for trunking can be assigned to any VLAN, and it turns out that putting trunk ports into a VLAN of their own is a good idea.

In 1999, David Taylor posted information to Bugtraq about tests he had run using Cisco switches, in attempts to force packets to hop VLANs. Taylor first attempted to use VLAN tagging to hop VLANs within a single switch, without success. The VLAN tags really have no purpose except for carrying VLAN information between switches, and get ignored if presented on non-trunk ports.

But when Taylor used two switches, he could force packets to hop VLANs under certain conditions. Just as in the early example from Cisco documentation, the MAC addresses of the target system had to be known in advance. The other key condition was that the initiating system, the "attacker", must belong to the same VLAN as the trunk used to connect the switches. In Taylor's first attempt, the attacker and the trunk were both in VLAN one, and the target in VLAN two.

Subsequent investigation by a Cisco employee (you can find this at http://online.securityfocus.com/archive/1/27062) pointed out that this behaviour was not only supported by the 802.1Q standard, but also worked on other, non-Cisco, switches as well.

You can easily prevent VLAN hopping by configuring trunk ports so that their native VLANs do not match the VID of any other VLANs that you have configured. Remember that by default, the native VLAN for a trunk will be VID one, the default for any VLAN. You can choose to set the native VLAN for trunks to be 1001, or any value that your switch supports and is not used for any other VLAN.
FIREWALLS AND VLANS

Now that I have discussed how switches share VLAN information, we can examine firewalls that support VLAN-related policy. Firewalls get packets from VLAN-supporting switches complete with 802.1Q tags in their headers. Although I have only mentioned Ethernet in examples, 802.1Q tagging also applies to other network media, such as ATM and FDDI. What the VLAN-aware firewall can do is extract the tags and use the information within the tags to make policy-based security decisions.

802.1Q tags do not provide authentication. Tags just provide a form of identification, added by switches, that a particular packet came from a particular VLAN. That a firewall would act on this information is no more ridiculous than acting on the source address of a packet, as IP source addresses are also an unauthenticated means of identification--and one that can be spoofed.

Spoofing IP source addresses has been done for many years, and spoofing VLAN tags can be done as well. The most recent Linux operating systems (kernels in the 2.4 vintage) include support for acting as VLAN switches, and can generate any VLAN tag that the local system administrator chooses. Other software exists for spoofing VLAN tags. Taylor used the Network Associates' Sniffer Pro v.2.0.01 to generate packets, and this can be done in software as well.

The key to safely using 802.1Q tags for policy decisions is to design a network where switch trunks get connected to the firewall interface where decisions will be made based on VLAN tags. If there are other routes to this firewall interface, the possibility that packets with spoofed VLAN tags increases. The switches themselves must be properly configured, with trunk ports specifically configured for trunking, and added to a non-default VID.

Implicit in any discussion of switches is protecting administrative access to the switches themselves. Switches and other network equipment typically expose three different means for administrative access: telnet, HTTP, and SNMP. You should always disable methods of administrative access that you don't use, as well as adding access control to the methods that you do use. While the firewall can control access to switches when the source of an attempt is external, the firewall can do nothing about an internal attacker--or one that has gained access to an internal system.

Switches were not designed as security devices. Their use as such simply evolved over time, and is ancillary to their main use as devices that improve network performance. If you use a switch for security reasons, you are relying on the correct configuration of the switch, including understanding not only the standards that the switch software is based upon, but also the correct implementation of those standards. The 802.1Q spec itself is 211 pages long, and is only one of a handful of standards that a compliant switch manufacturer must support.

Any time that you need to segregate networks for serious security purposes, I recommend that you not use a switch.