Time-Based Access Control Lists on Cisco ASA Post-9.7: Simplified Configuration and Enhanced Features

In the world of network security, there are times when you need to control traffic flow based on specific time periods. This can be particularly useful for limiting access during off-hours or for enabling special access on certain days or weekends. With Cisco’s Adaptive Security Appliance (ASA), this kind of control can be achieved through time-based access control lists (ACLs). This feature has evolved over time, and starting from Cisco ASA version 9.7, new and more efficient methods have been introduced.

In this blog, we'll explore how time-based access control has improved in Cisco ASA (Post-9.7) versions, including how to configure it, and how it benefits network security.

---

### **The Legacy Approach to Time-Based ACLs (Pre-9.7)**

Before version 9.7, time-based access control lists on the ASA were set up using time-range objects. These objects could define two types of time ranges:

1. **Absolute time range** – A fixed start and end time/date for the rule to be active.

2. **Periodic time range** – A repeatable period such as specific hours of the day, or specific days of the week.

While this method worked well, it required you to manually create a time-range object and then associate it with each specific access control entry (ACE). It was heavily dependent on the device’s internal time or an external NTP server for accuracy, and though effective, the setup process could be cumbersome in more complex environments.

---

### **Time-Based ACLs in ASA Post-9.7**

Starting with ASA version 9.7, Cisco introduced a more streamlined and efficient approach to time-based access control, making it easier to implement and manage these rules. The key improvement lies in the more flexible and intuitive configuration process, along with an improved management experience.

Here’s what has changed and how to use it in ASA Post-9.7:

#### **1. Enhanced Time Range Object Configuration**

In ASA versions 9.7 and later, time-range objects are still used, but the process of creating and attaching them to an ACL has been simplified. The core configuration steps remain the same, but newer tools and interface options in ASDM (Adaptive Security Device Manager) make configuration more intuitive. Time ranges can still be of two types:

- **Absolute:** A one-time range with a fixed start and end.

- **Periodic:** Recurring time ranges that can repeat based on daily or weekly schedules.

However, from ASA 9.7 onwards, there’s better integration with the management tools, especially in ASDM, where creating time-based policies is easier with graphical input options for time and days.

#### **2. Simplified Time-Based ACLs with ASDM**

One of the key improvements in ASA Post-9.7 is the integration with ASDM. While CLI configurations are still possible, many administrators now find it much easier to manage time-based ACLs using ASDM. 

- **Step-by-Step via ASDM:**

  - Navigate to *Configuration > Firewall > Time Range*.

  - Create a new time-range object specifying the start and end times for absolute ranges or repeating patterns for periodic ranges.

  - Go to *Access Rules* under the firewall section and apply the time-range object to the desired rule.

  

This greatly reduces the manual effort of configuring and visualizing complex time-based rules. The ability to review time-based ACLs in a graphical interface has simplified operations, especially in large environments.

#### **3. Example Configuration via CLI**

Here’s an example of how to configure time-based ACLs using CLI in Cisco ASA post-9.7:

1. **Create a Time-Range Object**

   

   ciscoasa(config)# time-range WEEKEND_ACCESS

   ciscoasa(config-time-range)# periodic weekend 08:00 to 18:00

   

2. **Apply the Time-Range to an ACL**

   

   ciscoasa(config)# access-list OUTSIDE_ACL extended permit tcp any any eq www time-range WEEKEND_ACCESS

   

This configuration ensures that HTTP traffic will only be allowed during weekends between 8:00 AM and 6:00 PM.

#### **4. NTP Configuration for Time Accuracy**

While configuring time-based ACLs, ensuring accurate time settings on the device is crucial. Cisco ASA supports Network Time Protocol (NTP) for time synchronization. This allows the ASA device to automatically sync its clock with a reliable time source, ensuring that time-based ACLs function as expected.

Here’s a simple way to configure NTP on ASA:

ciscoasa(config)# ntp server 192.168.1.100 source outside prefer

ciscoasa(config)# clock timezone PST -8

ciscoasa(config)# clock summer-time PDT recurring

This configuration sets up an NTP server and ensures the ASA device stays accurate with Pacific Standard Time (PST) and accounts for daylight saving changes.

#### **5. Auditing Time-Based ACLs**

Another improvement in ASA Post-9.7 is better logging and auditing for time-based rules. Administrators can now view logs that detail when specific ACL entries are activated or deactivated based on time. This feature provides increased visibility into how time-based rules are impacting traffic and helps troubleshoot potential issues more effectively.

---

### **Use Cases for Time-Based ACLs**

1. **Office Hour Access Restrictions:** Time-based ACLs can be used to restrict access to certain services or servers during off-hours. For example, you can block employees from accessing internal resources like file shares after business hours.

   

2. **Weekend Access for Remote Workers:** Some organizations may want to provide special access during weekends. Time-based ACLs can allow remote workers to connect via VPN only on weekends, ensuring a more secure environment during weekdays.

3. **Maintenance Windows:** You can set time-based ACLs to allow certain maintenance traffic (such as software updates) to flow only during predefined maintenance windows, avoiding network disruptions during peak usage hours.

---

### **Conclusion**

Time-based access control has always been a powerful feature in Cisco ASA, allowing for granular control over network access. With the improvements introduced in ASA version 9.7 and beyond, it’s easier than ever to configure and manage time-based ACLs. The improved integration with ASDM, simplified configuration options, and enhanced logging and auditing make time-based ACLs more user-friendly while maintaining the robust security that Cisco ASA is known for.

If you're managing an ASA environment, upgrading to a newer version and leveraging these advanced features can significantly enhance your ability to control network traffic efficiently and securely.

---

**Remember:** Accurate time is key to time-based ACLs working as expected, so always ensure your ASA is synchronized with a reliable NTP server!

Enhanced ICMP Control on Cisco ASA Firewalls Post-9.7

With the introduction of Cisco ASA Software version 9.7, handling ICMP messages on the firewall saw a significant improvement. Previously, ICMP controls on ASA were rudimentary and not very granular. ICMP control was handled in an inbound direction only, and special commands were required to allow or deny specific ICMP messages on the interfaces. Moreover, the ASA could be pinged from any side by default, but broadcast pings were dropped. However, post-9.7, Cisco made changes that provided better control and flexibility for managing ICMP traffic.

In this blog, we will go over how ASA manages ICMP traffic in modern implementations, especially focusing on the improvements in ASA version 9.7 and later.

---

### 1. **ICMP Control in ASA Pre-9.7**

In the older versions of ASA, ICMP traffic controls were basic and mostly worked in the inbound direction. The firewall allowed ICMP messages on an interface, and by default, it was possible to ping the ASA from any interface except for broadcast pings. ICMP messages like echo requests could be allowed or blocked using access control lists (ACLs) and the `icmp` command. The configuration was done as follows:

- **Allow ICMP on Specific Interface**:

    

    icmp permit any outside

    icmp permit any inside

    

    This would allow all ICMP traffic inbound on both the outside and inside interfaces.

However, this approach had limitations, and there was no fine-tuned control over different ICMP types or how ICMP messages were managed in different directions. This limited functionality could be cumbersome in environments where granular control over ICMP was essential.

---

### 2. **Changes in ASA Post-9.7**

Starting with ASA version 9.7, Cisco introduced a more sophisticated way to handle ICMP traffic. Instead of relying solely on the old `icmp` command, administrators could now leverage access control lists (ACLs) for more granular control of ICMP traffic, including support for ICMP types, codes, and directions. The new method also simplifies the process and enhances security.

Key improvements include:

- **Granular Control**: ACLs now support ICMP message type and code filtering.

- **Inbound and Outbound ICMP Control**: ACLs can now be used to control ICMP messages in both inbound and outbound directions.

- **Enhanced Security**: ICMP can be restricted to specific hosts, subnets, or even particular ICMP message types, providing better security control.

Let’s walk through the modern approach to ICMP configuration on ASA post-9.7.

---

### 3. **Allowing ICMP on Specific Interfaces (Post-9.7)**

Post-9.7, ASA provides more refined controls using the familiar access-list commands to permit or deny ICMP traffic based on parameters like source, destination, ICMP type, and code.

#### **Example 1: Allowing ICMP (Ping) on the Outside Interface**

Instead of using the old `icmp` command, you now configure ICMP access through ACLs. For instance, to allow ICMP echo requests (ping) from a trusted network to the firewall on the outside interface:

1. **Create an ACL to allow ICMP echo requests**:

    

    access-list ICMP_ALLOW extended permit icmp any any echo-reply

    

2. **Apply the ACL to the outside interface**:

    

    access-group ICMP_ALLOW in interface outside

    

This configuration allows ICMP echo replies to be received on the outside interface, which permits ping responses from the ASA.

#### **Example 2: Denying Specific ICMP Types**

If you want to block certain types of ICMP traffic, such as timestamp requests or redirects, you can configure the ACL to deny these specific ICMP messages. For instance:

1. **Create an ACL to deny ICMP redirects**:

    

    access-list ICMP_BLOCK extended deny icmp any any redirect

    

2. **Permit other ICMP types or allow ping from a specific network**:

    

    access-list ICMP_BLOCK extended permit icmp any any echo-request

    

3. **Apply the ACL to the desired interface**:

    

    access-group ICMP_BLOCK in interface outside

    

This ensures that ICMP redirects are blocked, while allowing other ICMP types, such as echo requests (pings), to pass.

---

### 4. **Controlling ICMP on All Interfaces**

If you want to ensure uniform control of ICMP messages across all interfaces, you can define a global access-list and apply it globally.

#### **Example: Applying a Global ICMP Policy**

1. **Create a global ACL for ICMP**:

    

    access-list GLOBAL_ICMP extended permit icmp any any echo-reply

    access-list GLOBAL_ICMP extended deny icmp any any redirect

    

2. **Apply the ACL globally**:

    

    access-group GLOBAL_ICMP global

    

This global access-list applies the same ICMP controls across all interfaces of the ASA, simplifying management in larger, more complex environments.

---

### 5. **Best Practices for ICMP on ASA**

With these new capabilities in ASA 9.7+, you can implement best practices to manage ICMP traffic securely:

- **Use ACLs for Granular Control**: Leverage ACLs to control ICMP traffic with fine granularity, blocking unnecessary ICMP types like redirects or timestamp requests.

- **Limit ICMP to Trusted Networks**: Restrict ICMP messages to specific source IP addresses or subnets, reducing the attack surface.

- **Control ICMP in Both Directions**: Apply ACLs to both inbound and outbound traffic for better control over how ICMP messages traverse the network.

- **Monitor ICMP Traffic**: Regularly review ICMP logs to monitor for any unusual activity or potential threats, as ICMP can be used for reconnaissance or denial-of-service attacks.

---

### 6. **Conclusion**

Cisco ASA version 9.7 brought significant improvements to ICMP control. Administrators now have more granular, flexible, and secure ways to manage ICMP traffic using ACLs rather than the old, more limited `icmp` commands. Whether you need to allow pings to the firewall, block specific ICMP types, or apply global policies, ASA post-9.7 provides the tools necessary to fine-tune ICMP control to meet modern security requirements.

By following the guidelines and examples provided in this blog, you can effectively manage ICMP traffic on your ASA firewall, ensuring better security while allowing necessary diagnostics and network communications.

"Understanding Security Levels in Cisco ASA: A Guide to Basic Configuration"

### **Basic ASA Configuration: Interface Setup**

When configuring a Cisco ASA, one of the key steps is to set up the network interfaces. This setup includes defining:

1. **IP Address**

2. **Interface Name**

3. **Security Level**

### **Security Levels and Interface Naming**

- **Default Security Levels**:

  - When you name an interface as “inside,” the ASA automatically assigns it a security level of **100**.

  - If you name an interface “outside” (or anything other than "inside"), the ASA assigns it a security level of **0** by default.

- **Custom Security Levels**:

  - You can manually configure a different security level using the command:

    ```bash

    security-level <level>

    ```

    where `<level>` can be any number from 0 to 100.

### **Understanding Security Levels**

Security levels are a fundamental concept in ASA firewalls. They determine how traffic is handled between different network zones:

- **Outbound Connections**:

  - Defined as connections originating from a network behind an interface with a **higher** security level and destined for a network behind an interface with a **lower** security level.

  - **Automatic Traffic Inspection**: Outbound connections are automatically inspected, meaning the ASA allows return traffic without requiring explicit access control lists (ACLs).

- **Inbound Connections**:

  - Defined as connections originating from a network behind an interface with a **lower** security level and destined for a network behind an interface with a **higher** security level.

  - **Default Security Posture**: Inbound connections are considered untrusted. To allow such connections, you must configure explicit ACLs that permit the traffic.

### **Summary**

- **Security Level**: A numeric value between 0 and 100 assigned to each ASA interface that defines the trust level of that interface.

  - **100**: Most trusted (typically assigned to the internal or "inside" network).

  - **0**: Least trusted (typically assigned to the external or "outside" network).

- **Traffic Flow**:

  - **Outbound** (Higher to Lower security level): Allowed by default.

  - **Inbound** (Lower to Higher security level): Blocked by default unless explicitly allowed via ACLs.

By understanding and configuring security levels correctly, you can control how traffic flows through the ASA and ensure that your network remains secure according to your organization's policies.