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" Michael Stewart

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.

Some guidelines:

• 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

Concept

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

Use Vlans

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:

• 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

Virtual LAN Security: weaknesses and countermeasures

Use contexts

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

Debugging

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 ip inspect.

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

ASAConfigExamples

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

• consistent
• descriptive
• 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?)

ASANamingSchema

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

Technical tips

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

AsaTmplFailover

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

Initial setup

Start with a defined config (config)# clear configuration all

Optional features

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/

Links:

• Best Practice from checkthenetwork I II
• Best Practice from security-solutions
• Best practice from http://checkthenetwork.com/network-security-cisco-asa-firewall-best-practices-for-firewall-deployment