Cisco Firewall (ASA/PIX) Best Practice
work in progress
das gleiche in deutsch
(the same in german)
Start with a policy
A written policy is a security map. With that map you can measure, reference and validates your security.
"Without a written policy, you have no security"
Use ASDM if you like, but also try to be proficient with the CLI
ASDM is the java based GUI tool for the Cisco ASA.
- ASDM and CLI are both good and you can make nearly everything in both ways
- The preferred tool for CCxx certificates is ASDM
- Initial configs are better made with CLI and editor
- Interface configurations are better made with CLI
- Small changes and documentation are better made with ASDM
- Overview and changing the order of ACLs are much easier in ASDM
- Logging and monitoring are better made with ASDM
- NAT rules are sometimes easier with ASDM (since 8.4 and the new NAT grammar, CLI is much easier)
- Update your java with caution (ASDM is sometimes picky with that)
- Do not use comma separated services or groups in ACLs with ASDM, because ASDM emulates this feature with some autogenerated object-groups which is difficult to understand in the text config
- ASDM doesn't support every feature (depending on version -> have a look in Tool menu > Show Commands ignored and ASDM User Guide)
- You can manage several ASAs simultaneously with ASDM
Avoid NAT/PAT as long as possible
Changing IPs or Ports in a packet is not as easy as you might think. Several protocols use IPs also in their payload, and the firewall needs to rewrite these payload depending on the meaning. This probably works for the famous ftp-protocol, but will it work on modern streaming or other seldom used protocols?
Backup your config
In former times Firewalls and VLANs are a no go. In a security environment you liked to have physikal seperated switches. Today VLANs are considered an adequate security risk if you follow some best practice rules:
Virtual LAN Security: weaknesses and countermeasures
- Disable trunking on all access ports
- Enable port fast on all access ports
- Enable port security on all access ports
- Do not use VLAN 1 for valid traffic
- Dedicated native VLANs on trunk ports
- Configure allowed VLANs on trunk ports manually
- Shut down all unused ports and put them in an unused VLAN
Use disjunct (not overlapping) IP-ranges (private) even for separate failover networks (you never know ...)
Try to consolidate your ACLs
Configure ACLs on your firewall and not on the router or on a host firewall, this is much easier for debugging and logging.
Update your ASA OS to the latest patchlevel of your release
Allow ping and traceroute
If you have no very high security level allow distinct icmp packets in both directions. If you don't like ping form the outside allow these icmp packets from the inside and let manage the returning packages from
Config template for ping and traceroute
Use packet tracer to verify your rules
Put an explicit deny at the end of your access-list
By default all ASA access lists end with an implicit "deny all" - anything that is not explicitly permitted is dropped at the end of the access list. Unfortunately the implicit deny is not logged. If you like to see what is implicit denied, put an explicit
access-list deny ip any any
at the end.
Configure DarkIPRanges (for filtering and/or logging)
IPs that cannot possibly reach your firewall for example IPs not allowed in your network or IPs forbidden by IANA should be logged. Because traffic targeting these IPs are
- Port scanning or Host scanning
- Backscatter of DDoS
- Configuration mistakes
Configuration template for Dark IPs or bogon IPs
It is a good idea to have some intentionally unused (sensor-) IPs or networks in your IP range for detecting bad traffic.
Avoid to delete ACLs
For debugging it is sometimes very usefull to set a ACL inactive instead of deleting it
Syncronise the clock with ntp
Clean and easy to read configuration
Try to use similar configurations as in Ciscos configuration guides or examples
This is also best practice and a new deputy cisco admin will be familiar with the config.
Overcome the temptation to use every or lot of ASA features
Very often it is more secure not to use every security feature but to have a simpler and cleaner config (complexity vs. security)
Use object-groups and templates of object-groups for common services
Cisco introduced the concept of object groups in PIX version 6.2.
You could group a list of IP addresses, protocols, services or ICMP types into logical entities and refer to it by name in your access lists.
If you use object-groups you should get shorter and cleaner acls. Idealy you should have no numbers (IPs or Ports) in your access-lists.
In general use templates for common parts of the config
Keep the config as simple as possible
use description and remark
- In the description of object-groups you can use up to 200 characters
- remarks in ACLs can contain up to 100 characters
- Start every description or remark with two dashes
- If you are not allone, put a signature into the description
- Put a date into your description, if you make changes (not in the initial config)
- Put the TroubleTicket-Number of the change request into the description
- Put a expiry date into the description, if it is a temporary modification or use dirctly the
time-range absolute command
- Put a "v" or "^" in your remark between the acls, so that it is absolute clear that you describe the following line or the line above. ASDM puts the remark in front of the ACL, so if you use ASDM and CLI in parallel put your remark in front of the ACL.
Use Naming Conventions for names (interfaces, object-groups ...)
It doesn't matter what
convention you use, but it should be
- simple and easy to type
- distinct so that you need not to check the name of a interface/object-group every time, you just type a presumably name and it should match
- try to avoid redundant information
The names of object-groups can use up to 64 characters containing [A-Za-z0-9.-_] (in some doku [,] is also allowed?)
Do not use outbound acls
You will lose the overview very fast and any advantage (if any) will be gone.
Normally you have something like:
access-group acl-1 in interface inside
Do never ever configure something like:
access-group acl-1 out interface inside
Implement temorary filter with
access-list ... permit ... time-range ...
Put the most matched ACLs in the first lines
The ASA tries to match each packet with a rule. The sooner the ASA find a matching rule the faster it is ready for the next packet.
Use the same interface for failover lan and failover state
Keep in mind that the failover state link needs in case of very small packets more or less the same bandwidth than the regular interface! You can consider the same effect for logging.
Although it seems to be a waste of high speed interfaces, reserve the fastest interfaces for failover and logging, otherwise you will only have a "fair weather" firewall. Or in other words: "you will have fine logs as long as you have nothing interesting in your logs".
Start with a defined config
(config)# clear configuration all
activate reverse path checks
Depending on the setup it makes sense to activate this check. But maybe this can be a performance problem (every icmp packet is checked, possible DOS)
Concider private VLANs and VACL for DMZs
With private VLANs (Source-port filtering with Procurve) you can deny traffic between hosts inside a VLAN. This can be usefull within a DMZ for several server. With this feature you can design larger and simpler, but never the less secure networks (DMZ). http://blog.alwaysthenetwork.com/tutorials/private-vlan-tutorial/