Converting from old to new with the PIX to ASA Migration Tool

Digging through Internet I’ve found a very good article from David Davis explaining how to make your life easier when migrating from PIX to ASA.

The important thing to note about PIX and ASA configurations are that they are different. In other words, to do one thing on a PIX requires a different command on an ASA. The ASA uses a more “IOS-like” configuration where the PIX has its own “PIX-OS” configuration. Here are just some of the differences between the two:

  • The ASA is different hardware and has different interface names.
  • The ASA uses sub-interface commands, like the Cisco IOS.
  • A PIX will use FIXUP commands for application inspection whereas the ASA will use policy maps.
  • On the PIX,outbound and conduit commands are used versus access lists on the ASA.

There are two ways to perform this conversion — manually or by using the automatic migration tool. You may want to perform the conversion manually if you want more granular control, but Cisco offers a PIX to ASA Migration Tool that can perform this automatically. Let’s look at how it works.

Read the full article at: Converting from old to new with the PIX to ASA Migration Tool


Cisco: How to use reflexive access-list and why they are useful

Reflexive access-list are one of the method that help us achive firewall functionality with a router hardware. The other methods that serve to the same purpose are Context-Based Access Control (CBAC) and TCP Intercept. For an introduction to CBAC with example please check my older post Cisco: Use CBAC to achieve firewall functionality on router device . For TCP Intercept check my blog in the next weeks.

Today, I will present Reflexive access-list and how can take advantage of their specific behavior. Reflexive access list commands are used to configure IP session filtering. IP session filtering provides the ability to filter IP packets based on upper-layer protocol “session” information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router. E.g. you want to allow a TCP connection from outside only is the initall packet was send from the inside. Take FTP active mode session on data port TCP 20. If you are doing FTP from inside the LAN port 20 will be allowed outbound and also inbound. But if somebody from outside try to reach one device on your LAN on port 20, the session will be dropped due to Access-list implemenation.

Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs. As a syntax Reflexive access-list are presented exactly like any normal ACL, with the implementation of two parameters “reflect” and “evaluate”.

Let have a look to this example topology. R2 will be the router where the Reflexive ACL has to be implemented.  The implementation is quite simple. You configure an outbound access-list which permit tcp sessions from any subnet to any subnet. The difference from this outbound ACL and a normal one, will be the “reflect” parameter at the end on the permit line. The “reflect” parameter will have the name OUT (it can be any name you want).

After the outbound list is completed configured, then we will configure an inbound access-list with a “permit tcp any any” statement followed by the parameter “evaluate OUT”. Below it’s a simple example how to configure this Reflexive ACL on the topology presented above, to permit UDP and TCP inside only if the session was initiated from inside:

ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT

ip access-list extended INBOUND
evaluate TO_REFLECT

interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in

So, the INBOUND ACL will evaluate OUTBOUND ACL to permit or deny TCP packet from outside. Remember that by default, packets generated by the router itself will not be
reflected. This is why if you have a routing protocol running towards outside,  on your router you have to permit static those packets.  Let’t take the example of the BGP routing protocol. Assume that you have a BGP peering between R2 and R3. On R2 you will have to permit static the BGP packets from outside, like in the example below:

ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT

ip access-list extended INBOUND
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate TO_REFLECT

interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in

In this way the BGP packets local generated on the router, will be allowed IN and OUT on the WAN interface. You will proceed in the same way for other packets that are generated on  the router and you want to allow them to pass through WAN interface.

For a live example please see the video presentation below. If you did not had a look to the example topology, now it would be a good time to do it. Already I have preconfigured BGP AS 300 on router R3 and BGP AS100 on R2 and R1, so the conectivity from R1 to R3 is not a problem. Also R1 and R3 have a  Loopback interface which is advertised into BGP. After implementing the Reflexive ACL on R2 I will be allow to telnet from R1 to R3, but not viceversa. Also the BGP packets between R2 and R3 will be static permited in ACL.

cisco-reflexive-acl

I hope that I could helped you to understand the importance on the Reflexive ACL. Sometime simple ACL would do the job and then I would suggest not to complicate things. But if you have something tricky to solve regarding access in your LAN, or you prepare for some exam like CCIE, then Reflexive ACL are quite useful and important.

Cisco: Use CBAC to achieve firewall functionality on router device

Sometimes, because of cost saving usually, the network engineers are forced to use a Cisco router as a firewall (instead of Cisco PIX or ASA). One of the big difference between router and firewall devices is that the ports have different characteristics. If on routers, ports are permitting by default traffic of any packets in and out, on the firewall devices, any packets are denied, if not explicit permitted.Also firewalls look at ports as Inbound at Outbound while for routers this has no meaning.

Anyway I don’t want to discuss here the differences between firewalls are routers, but to show you an example of how to achive firewall functionality by using Control-based Access Control (CBAC). CBAC intelligently filters TCP and UDP packets based on application-layer protocol session information. You can configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. (In other words, CBAC can inspect traffic for sessions that originate from the external network).CBAC inspects traffic and manage state information for TCP or UDP sessions, which allow it to create temporary openings in the access-lists, to allow returning traffic. Without CBAC, traffic filtering is limited to access list implementations that examine packets at the network layer, or at most, the transport layer.

The above explanation is a very technical one. Please have a look at the topology, to understand better what I’m explaining here and also to understand the example below. I will use telnet protocol in this tutorial. From the topology, imagine that you allow on the LAN interface of R2 (Fa0/0) telnet traffic to R3 and nothing else. Also to protect your environment on R2 WAN interface S1/0 you drop and inbound connection by using “deny ip any any” in an access-list. Good you are protected now. But what about the telnet connection? It will no work! Why? It is obivious that if the packet leaving from LAN on port 23 is allowed, the response from R3 is automatically dropped on S1/0 of R2 because of the deny anything access-list. By configuring “ip inspect” you enable CBAC which will keep track your session, so when you will open a telnet connection toR3, the return connection on random port (xxxxx) will be automatically opened by CBAC, despite the deny all access-list configured. In this way you are protected from outside (access is deny) but still able to use the connections you defined (open certain ports for certain session by CBAC).

So, to achieve firewall functionality on a router you have to follow some simple steps:
– use access list to deny any traffic on router’s ports (like firewall behavior)
– open in access-list traffic that you want to establish (remember that this line has to be above the deny line in ACL)
– enable ip inspect rules to open the connection back port

Please have a look into the example below for a better understanding:

Context-based Access Control