Checkpoint SecurePlatform Virtual Appliance

I've just downloaded and setuped the Checkpoint SecurePlatform virtual appliance in my laptop. This is perfect for anyone trying to learn the Checkpoint firewall like me. This must be the equivalent of Dynamips in the Checkpoint world.

Among the recent developments in the IT world, virtualization must be the coolest thing happening. VMWare is spearheading this revolution and their online library of virtual appliance is a panacea for labrats like me. In theory, with enough CPU and memory, you can build a virtual datacenter inside a PC!!!

Quick, Learn More ! from Cisco's QLM

If you're preparing for a CC*P exam or just want to learn about a certain feature, you'll surely find this short tutorials or what Cisco calls Quick Learning Modules (QLM) very useful. They are available on the following links.

Security and VPN QLMs
Cisco IOS Software
CCNP Prep Center Exam Study Section (Login required)
more modules are available from the Cisco Learning Connection Main Page

Be clued on Protocol Analysis

It pays to know how to read packet captures when troubleshooting network problems like latency problems. Like there was one time when we were investigating why a server response became slow after moving it behind a firewall. Finger pointing ensues until we decided to do sniff the traffic in the firewall to know whats happening. From the capture, we see the server sending reverse DNS lookup for every client request it receives. So before processing the client requests, it waits for the reverse DNS result until it times out because the firewall is blocking the DNS requests. After understanding what was going on, the administrator turned off the reverse DNS lookup in the server.

Most of the time, people will be looking at bandwidth utilization issues/network congestion but it is rarely the cause if application response over the network is slow. Sure there are peer-to-peer traffic and worm scans to watch out for especially on slow links but there are more possible factors that can cause slow application access. Slow backend server response, problematic SQL queries (those long, long SELECT statements) and chatty applications are some possibilities that I can think of. The point is you should know how to push the blame on others. :)

Here's a helpful presentation slide from Laura Chappell that should help you get started in analysing slow networks. While you're at it, browse through the Protocol Analysis Institute website and you'll see more articles from Laura Chappell.

Router: Scripting in Cisco routers and Management Enhancements

Cisco IOS have features available which enables you to create custom commands and scripts which will aid in managing IOS routers using the TCL scripting command.
Tool Command Language

With embedded management tools, you can even monitor events or set thresholds that will trigger a script or CLI applet.
Embedded Event Manager (EEM)
Embedded Syslog Manager (ESM)
Embedded Resource Manager (ERM)

To automate tasks, you can schedule EXEC commands to run periodically Unix Cron-style.
Command Scheduler (KRON)

You can archive multiple versions of the config, then either replace or rollback configurations.
Configuration Replace & Rollback

Using the command "show archive config differences", the router can do a line-by-line comparison of two versions of the configurations ie. between the startup config and the running config.
Contextual Configuration DIFF utility

Wow! All this I unearthed after chancing upon this page for the Embedded Event Manager (EEM) Scripting Community. Proceed with caution. This is the domain of the Cisco l33t.

It's a feature!!!

Overheard from the office.

Phone rings.

Help Desk: Sir, remote office in Manila reported a downtime.
Manager: Let me check... I see.. the router rebooted, tell them it's a feature!

Help desk follows obediently.

Free Treats from Cisco and IPExpert

Here are a couple of free study resources available.
On Feb. 1, Cisco’s CCNA TV will air IP Addressing, Subnetting, & Variable-Length Subnet Masks (VLSM), that will cover basic IP addressing, subnetting and VLSM concepts, and route summarization. You have to register first in the CCNA Prep Center to view the broadcast.
"IP Addressing, Subnetting, & Variable-Length Subnet Masks (VLSM)" on CCNA TV

Also, IPExpert is offering all their eScenarios for free. This used to be a product that you have to pay (previously worth $100+ i think).
IPEXPERT Free CCIE Lab eScenarios

Take note: Recently announced Cisco Vulnerabilities

Well, I got this from our company's trusty security advisory system but I'm sure it will be all over the Internet by now based on the seriousness of these security bulletins.

Crafted TCP Packet can cause denial of service (cisco-sa-20070124-crafted-tcp)
Crafted IP Option vulnerability (cisco-sa-20070124-crafted-ip-option)
IPv6 Routing Header vulnerability (cisco-sa-20070124-IOS-IPv6)

After going through the security advisory, continue reading through these documents:
Detecting and mitigating cisco-sa-20070124-crafted-tcp
Detecting and mitigating cisco-sa-20070124-crafted-ip-option
Detecting and mitigating cisco-sa-20070124-IOS-IPv6

It will give you wealth of information on the features and capabilities that Cisco IOS have in dealing with these issues. Previously, I didn't know about IP Options Selective Drop , Control Plane Policing and ACL Support for Filtering IP Options. Makes me feel like a n00b.

Some notes I learned:

1. On Cisco PIX Security Appliances, Cisco ASA Adaptive Security Appliances, and Firewall Service Modules (FWSM) for Cisco Catalyst 6500 Switches and Cisco 7600 Routers, packets with IP Options are dropped by default.
2. Configure Policing then apply the service-policy to the Control Plane to protect the router itself from attacks directed to it. The control plane and the management plane handle such packets as routing updates, keepalives, and network management.
3. IP Protocol 103 = PIMv2
4. IP Protocol 113 = PGM Reliable Transport Protocol
5. Resource Reservation Protocol (RSVP) (Multiprotocol Label Switching traffic engineering [MPLS TE]), Internet Group Management Protocol Version 2 (IGMPv2), and other protocols that use IP options packets may not function when IP Options are filtered.
6. Configuring Access Lists to Filter Packets That Contain IP Options
7. Protecting Your Core: Infrastructure Protection Access Control Lists
   

I remember a similar bug last 2003 (Cisco IOS Interface Blocked by IPv4 Packets) that caused much furor and panic to upgrade routers. I wonder how Cisco customers will react to this one.

Time to bring out the console cable and fire up TFTP!

CCIE or bust

I've been eyeing on being a CCIE for several years now and I've finally decided to take on this monster this year. It's no secret that CCIE is one of the toughest vendor certification exam and it's been the ultimate goal for all Cisco professionals. Besides being tough, it is also an expensive endeavor.

I always hear that if you want to take the CCIE, your budget should be at least good for two takes. The idea is that if you fail your first attempt, you should still have enough money to immediately follow-up with a second take while the exam is still fresh in your memory.
For me, being the poor soul that I am, I cannot afford to fail my first take. The budget for one exam is hard enough for me to allocate. I've been convincing myself..."Just one take! Just one take! ..."

Another resource that I'm lacking besides money is time. I hardly have time to study. I use every available time (even at work) to read and study. I stay up late in the evening and I have been conditioning my body to get used to four hours of sleep per day. A Rob Schneider-encouragement would surely help. "YOU CAN DO IT!!!"

Come near the examination date, I plan to totally seclude myself away from distractions. That means I have to find a way to keep away from my wife, son and PC games. Am I overdoing it? Well, it is better to be over-prepared than to be sorry and realize too late in the exam that I have not prepared enough. I need to push myself hard because I CAN'T AFFORD TO FAIL!!!

Enough said...I'm going to study now.

Lab: RTBH

This is something I setup in my desktop lab (Dynamips) based on the REMOTELY TRIGGERED BLACK HOLE FILTERING—DESTINATION BASED AND SOURCE BASED white paper available from Cisco website.

Configurations
Target
Edge
Trigger
RR-BGP
PE1
PE2
Smurf

In the diagram, the provider network is enclosed in the blue area. The Target router is the victim and Smurf is the attacker network. Let's say we're seeing massive amount of traffic coming from Smurf network with destination as the Target router. We identify these as a dos attack on the Target network so as Service Provider we must: 1. Protect our customer and 2. Protect the provider network.
RTBH provides a method of telling the provider edge routers to block an identified traffic just by adding the source or destination address to a sort of blacklist. These blacklist are actually static routes added to the Trigger router that are propagated throughout the network via iBGP. These routes points to a null interface as its next-hop, so effectively dropping the bogus traffic.

Lab: Integrated DMVPN and EZVPN with IPSec Stateful Failover

Here's something I setup in my desktop "lab" using DYNAMIPS. I created two DMVPN hubs also acting as a EZVPN server with Stateful Failover. Since both DMVPN and EZVPN configuration is using 0.0.0.0 address to map to the pre-shared key, a ISAKMP Profile is configured to differentiate the DMVPN spokes and the EZVPN clients.

Previously, if your router talk to a combination of remote spokes and vpn client (software or ezvpn remote) that have dynamic ip addresses, your only option is to use certificates for your IKE authentication. If you use pre-shared keys, you cannot distinguish which IKE peers should have extended authentication and which one should not use it. Well that was before ISAKMP Profile was available. ISAKMP Profile should be used for any router with two or more IPSec connections that requires different phase 1 parameters for different sites (for example, configuring site-to-site and remote access on the same router). You can configure to authenticate one peer using certificates while another peer is authenticated using pre-shared keys.

Here are the configs.
Hub1 Configuration
Hub2 Configuration
EZVPN Remote Client Configuration
DMVPN Spoke1 Configuration
DMVPN Spoke2 Configuration

You can refer to Cisco's Deployment Guide for more detailed info.

Pix/ASA: DNS rewrite and Packet U-Turns part II

Network

Internet----(outside)pix/asa(inside)----client
                    (dmz)
                      I
                      I
                    server

Now let's consider a pix/asa with three interfaces: inside, outside and dmz. Client PC in the inside network cannot access the server in the dmz eventhough we have the correct nat configuration in the firewall. We soon found out that the client PC is resolving server's hostname to its public ip. Problem is the pix/asa will forward the packet to the outside interface because the destination in the packet header is the server's public ip.

Solution 1:
DNS doctoring to the rescue

global (outside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
static (inside,dmz) 192.168.100.0 192.168.100.0 netmask 255.255.255.0
static (dmz,outside) 172.20.1.10 10.10.10.10 netmask 255.255.255.255 dns

By adding the dns keyword in the static nat for the server, we are telling the pix to rewrite the dns query response so that the client pc will resolve the server's hostname to its private ip. So then the pix will correctly route to the dmz interface when client PC sends a packet to the server.
Make sure that you have DNS inspection configured for DNS Doctoring to work.

policy-map global_policy
class inspection_default
...
inspect dns

Solution 2:
Another way to get around the problem is to configure the pix to do a nat translation for packets from inside hosts going to the server in the dmz. But instead of natting the source address in the packet header, we tell it to nat the destination address.

!
! Nat for inside-to-outside traffic
!
global (outside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
!
! Nat for inside-to-dmz traffic to server
!
static (inside,dmz) 192.168.100.0 192.168.100.0 netmask 255.255.255.0
!
! Nat for dmz-to-outside traffic to server
!
static (dmz,outside) 172.20.1.10 10.10.10.10 netmask 255.255.255.255
!
! Destination Nat for the server's IP
!
static (dmz,inside) 172.20.1.10 10.10.10.10 netmask 255.255.255.255


More detailed info from the Cisco sample configuration.

Pix/ASA: DNS rewrite and Packet U-Turns part I

Topology

                                    I--Client
Internet----(Outside)ASA(Inside)----I
                                    I--Server

Problem

An internal host cannot reach the a public server in the DMZ arm of the pix/asa. The reason is because the public server's hostname is resolved by DNS to its public ip address and the pix/asa will not route a packet to the outside interface then u-turn it back to its inside interface.

Solution 1: We tell the pix/asa to hack into the DNS query response such that the client host will resolve the server's hostname to it's private ip address.
Make sure that you have DNS inspection configured for DNS Doctoring to work.

policy-map global_policy
class inspection_default
...
inspect dns

! Nat/Global for outbound traffic
!
global (outside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
!
! Static nat for inbound traffic to the server.
! The DNS keyword at the end enables DNS Doctoring
!
static (inside,outside) 172.20.1.10 192.168.100.10 netmask 255.255.255.255 dns
!

It beats going to each and every workstation on your network and adding the server's hostname/ip address in their etc/hosts file.

Solution 2.
On pre-7.2 verion of the security appliance software, the pix/asa will not forward clear (unencrypted) traffic back the same interface where it was recieved from. On 7.1, it will allow the packet to take a U-turn but only for encrypted traffic.
So if the firewall is running 7.2 software, we can get around these limitations and allow the client host to access the server using the resolved public ip address.

! To allow packet U-turn
!
same-security-traffic permit intra-interface
!
! global statement for outbound traffic
!
global (outside) 1 interface
!
! global statement for intra-interface traffic
!
global (inside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
!
! Static nat for inbound traffic
!
static (inside,outside) 172.20.1.10 192.168.100.10 netmask 255.255.255.255
!
! To map the public ip of the server to its private ip
! for intra-interface traffic.
!
static (inside,inside) 172.20.1.10 192.168.100.10 netmask 255.255.255.255
!

For a more detailed explanation, read this sample configuration from Cisco.

Router: Test Crypto Initiate-session Command

It used to be that the only way to initiate vpn establishment is by passing traffic matching the crypto ACLs. What's usually done is you ping the remote network from a host behind the router. But there are cases where you don't have access to any of the computers on both sides of the tunnel.
By using the test crypto initiate-session command, you can manually bring up the tunnel just by entering this command from the router.

The syntax is
test crypto initiate-session src-ip-addr dst-ip-addr map-name seq-num

After issuing this command, use the show crypto cisco connections command to verify the status of the connection just created.

Router1# show crypto cisco connections
Connection Table
PE UPE Conn_id New_id Alg Time
192.168.3.10 192.168.204.100 1 0 10 Mar 01 1993 00:02:00
flags:TIME_KEYS

If the Conn_id is a positive value, then it means the vpn session is established.

Note that this only verifies your vpn configuration so you still have to check your routing, nat and ACL configuration to make sure that packets are correctly routed and encrypted.

Router: Zone-based Firewalls part III

Now let's look at an example where we have three zones: inside, outside and dmz. There are servers in the DMZ zone that needs to be accessible from the inside and outside network. We will restrict Outside to DMZ traffic only to ip 192.1.1.1 via http.

! we define the zones
!
 zone security Inside
 zone security Outside
 zone security DMZ
!
! we apply the zones to the interfaces
!
interface FastEthernet0/0
 ...
 zone-member security Inside
!
interface FastEthernet0/1
 ...
 zone-member security DMZ
!
interface Serial0/0.100 point-to-point
 description Link to the Internet
 ...
 zone-member security Outside
!
! Match any traffic going to the Webserver
!
access-list 199 permit ip any host 192.1.1.1
!
! match traffic to be inspected
!
class-map type inspect insp-traffic
 match protocol http
 match protocol icmp
 match protocol tcp
!
! match http traffic going to the webserver
!
class-map type inspect match-all http_traffic
 match access-group 199
 match protocol http
!
class-map type inspect match-all toDMZfromInside
 match access-group 199
 match class-map insp-traffic
!
class-map type inspect match-any DNS
 match protocol dns
!
policy-map type inspect out_traffic
 class type inspect insp-traffic
  inspect
!
policy-map type inspect toDMZfromInsideTraffic
 class type inspect toDMZfromInside
  inspect
!
policy-map type inspect webtraffic
 class type inspect http_traffic
  inspect
!
policy-map type inspect DNSTraffic
 class type inspect DNS
  inspect
!
! security policy for inside to outside traffic
!
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect out_traffic
!
! security policy for outside to dmz traffic
!
zone-pair security OutsideToDMZ source Outside destination DMZ
service-policy type inspect webtraffic
!
! security policy for inside to dmz traffic
!
zone-pair security InsideToDMZ source Inside destination DMZ
service-policy type inspect toDMZfromInsideTraffic
!
! security policy for dmz to outside traffic
!
zone-pair security DMZToOutside source DMZ destination Outside
service-policy type inspect DNSTraffic
!

Notice that there is no security policy for traffic going from Outside to Inside or from DMZ to Inside. This configuration will drop any traffic going to the Inside network.

Zone-based Firewall is modular making the configuration much more easier to read. You can add more zones or you can add more interfaces to each zone without cluttering the configuration and thus easing troubleshooting. It removes the firewall's dependency on access-lists and allows you to configure one policy for any given traffic.

For more info, check out Cisco documentation (of course!) and discussion slide on zone-based firewall and the excellent ebook Deploying Zone-Based Firewalls (Digital Short Cut) from Ivan Pepelnjak.

Router: Zone-based Firewalls part II

In the first installment of this document, I showed you a simple two-zone configuration where inside users have unrestricted access to the outside zone.

If you need to limit the services that the inside users are allowed to access, we have to define the traffic classes that will later be used in the policy-map commands to define the desired firewall policy. The traffic classes are defined with the class-map command augmented with the type inspect keyword.

!
! These are the Class maps to define
! the outgoing traffic that are permitted.
!
class-map type inspect match-any MailAndDNS
match protocol dns
match protocol smtp
match protocol pop3
class-map type inspect match-all ISP_Traffic
match class-map MailAndDNS
match access-group name ISPServers
class-map type inspect match-any InternetTraffic
match protocol http
match protocol ftp
match protocol icmp
match protocol https
!
!
policy-map type inspect InsideToOutside
!
! Action for defined class-map is inspect
!
class type inspect ISP_Traffic
 inspect
class type inspect InternetTraffic
 inspect
!
! Action for all other traffic are dropped and logged
!
class class-default
drop log
!
! we define the zones
!
zone security Inside
zone security Outside
!
! we define the security policy
!
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect InsideToOutside
!
! we apply the zones to the interfaces
!
interface FastEthernet0/0
...
zone-member security Inside
!
interface Serial0/0.100 point-to-point
description Link to the Internet
...
zone-member security Outside
!
ip access-list extended ISPServers
permit ip any host 192.1.1.1
permit ip any host 192.1.1.2

This time we used the action drop and log for the class class-default.
With this configuration, outbound traffic are restricted to those services defined in the class-maps. Matching traffic are permitted and inspected while those that does not match are dropped. There is still no security policy defined for inbound traffic (outside-to-inside) so it will be dropped by the router.

Router: Zone-based Firewalls part I

A new configuration enhancement has been introduced in IOS 12.4(6)T called Zone-based policy firewall. Rather than configuring multiple access-lists to filter traffic between multiple router interfaces, you follow the zone-based design and only have to specify the traffic permitted between zones. Zone-based policy firewall also adds more granularity to inspection policies comapared to CBAC.

Here are some notes:

1. The zone-based policy firewall can coexist with Cisco IOS Firewall stateful inspection. You can still use the ip inspect command on interfaces that are not members of security zones.
   
2. Traffic can never flow between an interface assigned to a zone and an interface without a zone assignment.
   
3. The default interzone policy is to drop all traffic unless specified otherwise in the zone-pair configuration command.
   
4. The router never filters the traffic between interfaces in the same zone.
   
5. If two interfaces are not in zones, traffic flows freely between them.
   
6. The zone-member command does not protect the router itself (traffic to and from the router is not affected) unless you configure the zone pairs using the predefined self zone.
   

Examples are available on this slide.

Here's a simple example.

! Create the zones. for this example we only have two zones
!
zone security Inside
 description This is the Internal network

zone security Outside
 description This Internet zone
!
! Using policy-map, we specify the action to do
! on the traffic matching the class-maps
! For this example, we use the default class
! class-default = match all
!
policy-map type inspect InsideToOutside
 class class-default
 inspect
!
! Apply the policy to traffic between a pair of zones
!
 zone-pair security InsideToOutside source Inside destination Outside
 service-policy type inspect InsideToOutside
!
! Assign the interfaces to each zones
!
interface FastEthernet0/0
 zone-member security Inside
!
interface Serial0/0/0.100 point-to-point
 zone-member security outside

This is a simple two-zone configuration where a security policy is defined for outbound traffic (inside-to-outside). Inbound traffic will be dropped since there is no security policy defined for outside-to-inside traffic.

Router: Surfing without Split-tunnelling

Scenario: Users connect remotely via Cisco VPN client. They connect to your router. They need to access the Internet while logged-in but you don't want to configure split-tunnelling. You want the VPN client to access the internet thru the router and not by split-tunneling so that you can later enable url-filtering or use audit-trail to monitor their browsing activities.
Config:

username cisco password cisco123
aaa new-model
!
!
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
crypto isakmp policy 3
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group RAS
key cisco123
domain cisco.com
pool ippool
!
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto dynamic-map dynmap 10
set transform-set myset
!
!
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
! User's traffic will be redirected to this loopback interface
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip nat inside
!
interface Ethernet0/1
ip address 192.168.20.1 255.255.255.0
ip nat inside
!
interface Ethernet0/0
...
ip nat outside
ip policy route-map redir

crypto map clientmap
!
ip local pool ippool 192.168.1.100 192.168.1.200
ip nat inside source list NAT interface Ethernet0/0 overload
!
ip access-list extended NAT
deny ip 192.168.20.0 0.0.0.255 192.168.1.0 0.0.0.255
permit ip 192.168.20.0 0.0.0.255 any
permit ip 192.168.1.0 0.0.0.255 any
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
!
! This route map redirects vpn client traffic to Loopback0
!
route-map redir permit 10
match ip address 101
set interface Loopback0



On the pix/asa, check this sample configuration from Cisco for a similar "vpn-on-a-stick" setup.

Pix/ASA: Packet Tracer

This new feature is very useful in troubleshooting or verifying your configuration. It is available in ASDM and CLI.
Syntax:

packet-tracer input [src_int] protocol src_addr src_port dest_addr dest_port [detailed] [xml]

It is a good complement to the capture command when troubleshooting. To use it, you just enter the source and destination ip and port address and the packet-tracer will provide detailed information on how the security appliance will process that packet and will also show you why it will fail based on your firewall's configuration.

Example from the command reference:
To enable packet tracing from inside host 10.2.25.3 to external host 209.165.202.158 with detailed information, enter the following:

hostname# packet-tracer input inside tcp 10.2.25.3 www 209.165.202.158 aol detailed

Learn more about the packet-tracer tool from the Quick Learning Module available from Cisco.

Pix/ASA: View interface status

One of the first command that you usually learn on IOS is the useful command 'show ip interface brief'. This command will allow you to see the list of available interfaces on the router and their status.

Do you know that the pix have an equivalent command? It's easy to miss it because those folks at PixOS Development have rearrange the words a bit. Well the command on the pix or ASA is 'show interface ip brief'.

hostname# show interface ip brief

Interface                  IP-Address      OK? Method  Status                Protocol

Control0/0                 127.0.1.1       YES CONFIG  up                    up

GigabitEthernet0/0         209.165.200.226 YES CONFIG  up                    up

GigabitEthernet0/1         unassigned      YES unset   administratively down down

GigabitEthernet0/2         10.1.1.50       YES manual  administratively down down

GigabitEthernet0/3         192.168.2.6     YES DHCP    administratively down down

Management0/0              209.165.201.3   YES CONFIG  up

Nifty eh. It's a good thing that the Pix/ASA commands are slowly becoming similar in syntax as IOS commands. So that we don't have to go through the confusion again like learning the difference between the conduit and the access-list command.

Rant: We don't need no stinkin' GUI !!!

Lately I have been learning how to configure the Checkpoint firewall because majority of the firewalls on the company I'm working for are Checkpoints. Like many of the firewalls available on the market it is GUI-based. What sets it apart though is that it is not html-based and use a client software called SmartDashboard instead to configure their firewall.
I really find its interface pretty intuitive and convenient. You can drag and drop objects and besides the toolbars and the menus, right-clicking reveals more options. And the most important thing, it is stable.

Too bad I cannot say the same thing about the Pix Device Manager (PDM) or the ASA Device Manager (ASDM). When I first used the PDM about three years ago, it was slow, counter-intuitve and was plagued with bugs.

Yes, it is relatively easier to delete, move and insert access-list entries using the PDM. But it is a different story when make use of the comments section. Somehow the comments get messed up when you move and delete the access-lists. Don't even think about using the PDM to configure object groups. Once you push the configurations, it will lock up the pix.

What's surprising is that just recently, I tried out the latest version of ASDM and guess what, the bugs are still there. I was editing and moving the access-lists and the comment section is still messy and when I pushed the configuration, the PDM hanged. Even the CLI was unusable. So I have to reload a production pix and this made me look bad to the bosses.

Well, it does look prettier though but sorry no brownie points for that. It's back to the command line for me.

Pix/ASA: Inserting Access-list Entries

My boss didn't know that on the Pix you can insert an access-list in between previous entries. He have always relied on the ASDM to do that.
As showed to him, you can do it via CLI and this has always been possible on the pix since version 6.3.
The first step is to do a show access-lists.

PIX# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300
access-list ACLIN; 3 elements
access-list ACLIN line 1 extended permit tcp any host 172.31.0.10 eq www (hitcnt=0)
access-list ACLIN line 2 extended permit tcp any host 172.31.0.10 eq ftp (hitcnt=0)
access-list ACLIN line 3 extended permit icmp any host 172.31.0.10 (hitcnt=0)

As you can see, it will show you the sequence number of each access-list entries. You can then use this numbers to insert your new access-list anywhere. Creating a new 'access-list ACLIN line 1' will push the existing first entry down.

PIX# conf t
PIX(config)# access-list ACLIN line 1 extended deny tcp 10.0.0.0 255.0.0.0 host 172.31.0.10 eq www
PIX(config)# access-list ACLIN line 2 extended deny tcp 172.16.0.0 255.255.0.0 host 172.31.0.10 eq www
PIX(config)# access-list ACLIN line 3 extended deny tcp 192.168.0.0 255.255.0.0 host 172.31.0.10 eq www
PIX(config)# ! Without specifying the line number, the PixOS will
PIX(config)# ! place the entry at the end of the access-list
PIX(config)# access-list ACLIN extended deny ip any any log
PIX(config)# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300
access-list ACLIN; 7 elements
access-list ACLIN line 1 extended deny tcp 10.0.0.0 255.0.0.0 host 172.31.0.10 eq www (hitcnt=0)
access-list ACLIN line 2 extended deny tcp 172.16.0.0 255.255.0.0 host 172.31.0.10 eq www (hitcnt=0)
access-list ACLIN line 3 extended deny tcp 192.168.0.0 255.255.0.0 host 172.31.0.10 eq www (hitcnt=0)
access-list ACLIN line 4 extended permit tcp any host 172.31.0.10 eq www (hitcnt=0)
access-list ACLIN line 5 extended permit tcp any host 172.31.0.10 eq ftp (hitcnt=0)
access-list ACLIN line 6 extended permit icmp any host 172.31.0.10 (hitcnt=0)
access-list ACLIN line 7 extended deny ip any any log informational interval 300 (hitcnt=0)

Access-lists on the IOS also have sequence numbering so you can do the same thing on routers.

RTFM first !!!

I work with Cisco boxes and when faced with a task of configuring something unfamiliar to me, there is usually 5 options:

1. RTFM
2. Search Cisco website for a sample configuration
3. Search the Internet, hoping that a kind soul have posted a solution to what you are trying to achieve
4. Ask the experts in mailing lists, study groups and forums.
5. Ask my more senior colleagues.

Most of the time, I'll find myself on my own. But sometimes, I find bits and pieces of useful information in the web, selflessly shared online. I can usually get away by copying from Cisco documentation or Cisco configurations posted by some generous netizens. Copy, paste and ready to go!

I have been a beneficiary of this information pool for quite some time now and figured it's time I give back to the community. Expect to see here tips and tricks, sample configurations, workarounds and whatever I think would be useful to my fellow Cisco professionals.

Having said that, let me end my first post with a DISCLAIMER:

No Warranty of any kind is expressed or implied with respect to the information contained in the documents found in this blog! The information found here is compiled for the convenience of anyone looking for general guidelines, reference materials and peer advice. Use this information at your own risk!