Contents

Configuring ASPF· 1

About ASPF· 1

Main functions· 1

ASPF application· 1

Basic ASPF concepts· 1

ASPF inspection principles· 2

Restrictions and guidelines: ASPF configuration· 4

ASPF tasks at a glance· 4

Configuring an ASPF policy· 4

Applying an ASPF policy to a zone pair 5

Sending ICMP error message upon packet dropping by interzone policies applied to zone pairs· 5

Enabling real-time log sending mode· 6

Display and maintenance commands for ASPF· 6

ASPF configuration examples· 7

Example: Configuring ASPF FTP application inspection· 7

 

Configuring ASPF

About ASPF

Advanced Stateful Packet Filter (ASPF) is proposed to address the issues that a packet-filter firewall cannot solve.

Main functions

An ASPF provides the following main functions:

·     Application layer protocol inspection—ASPF checks the application layer information of packets, such as the protocol type and port number, and inspects the application layer protocol status for each connection. ASPF maintains the status information of each connection, and based on the status information, determines whether to permit a packet to pass through the firewall into the internal network. In this way, ASPF defends the internal network against attacks.

·     Transport layer protocol inspection—ASPF checks the transportation layer information of packets. Transportation layer protocol includes TCP, UDP, UDP-Lite, SCTP, Raw IP, ICMP, ICMPv6, and DCCP. For example, ASPF checks a TCP/UDP packet's source and destination addresses and port numbers to determine whether to permit the packet to pass through the firewall into the internal network.

·     ICMP error message dropping—ASPF inspects the connection information carried in an ICMP error message. If the information does not match the connection, ASPF drops the packet.

·     TCP SYN check—ASPF checks the first packet of a TCP connection to determine if it is a SYN packet. If it is not a SYN packet, ASPF drops the packet. When a router attached to the network starts up, it can receive a non-SYN packet of an existing TCP connection for the first time. If you do not want to interrupt the existing TCP connection, you can disable the TCP SYN check. The router allows the first non-SYN packet that is used to establish a TCP connection to pass. After the network topology becomes steady, you can enable TCP SYN check again.

ASPF application

At the border of a network, ASPF can work with a packet-filter firewall to provide the network with a more comprehensive security policy that better meets the actual needs. The packet-filter firewall permits or denies packets according to ACL rules. The ASPF records information about the permitted packets to ensure that their return packets can pass through the packet-filter firewall.

Basic ASPF concepts

Single-channel protocol and multichannel protocol

·     Single-channel protocol—A single-channel protocol establishes only one connection to exchange both control messages and data for a user. SMTP and HTTP are examples of single-channel protocols.

·     Multichannel protocol—A multichannel protocol establishes more than one connection for a user and transfers control messages and user data through different connections. FTP is one example of multichannel protocols.

Zone pair

A zone pair specifies the source zone and destination zone of a traffic flow to be inspected:

·     Source zone—A security zone from which the first packet of a traffic flow originates.

·     Destination zone—A security zone for which the first packet of a traffic flow is destined.

For information about security zones, see "Configuring security zones."

ASPF inspection principles

This section introduces the basic idea of ASPF inspection on application layer and transport layer protocols.

Application layer protocol inspection

As shown in Figure 1, ACLs on the edge device deny incoming packets to the internal network. The ASPF application layer protocol inspection allows return packets from the external network to the internal network.

Figure 1 Application layer protocol inspection

 

ASPF inspects all application layer sessions as follows:

·     For a single-channel protocol, such as HTTP, the inspection process is simple.

ASPF creates a session entry immediately after it detects the session's first packet sent to the external network, and ASPF removes the entry when the connection is terminated.

The session entry helps record outgoing packets and their return packets. It can maintain the session status and determine whether state transitions of the session are correct. All packets that match a session entry can pass through the packet-filter firewall.

·     For a multichannel protocol, ASPF creates session entries, and one or more associated entries to associate the sessions initiated by the same application layer protocol. Associated entries are created during the protocol negotiation and are removed after the negotiation. ASPF uses the associated entries to match the first packets of the sessions. All packets of the sessions matching the associated entries can pass through the packet-filter firewall.

The following uses FTP to explain the process of multichannel application layer protocol inspection.

Figure 2 FTP inspection

 

As shown in Figure 2, FTP connections are established and removed as follows:

1.     The FTP client initiates an FTP control connection from port 1333 to port 21 of the FTP server.

2.     As a result of negotiation, the server initiates a data connection from port 20 to port 1600 of the client.

3.     When data transmission times out or ends, the data connection is removed.

ASPF implements FTP inspection during the FTP connection lifetime as follows:

1.     ASPF checks the IP packets the FTP client sends to the FTP server to identify TCP-based FTP packets. Based on the port number, ASPF identifies the control connection between the FTP client and server and creates a control connection session entry.

2.     ASPF checks each FTP control connection packet, and examines their TCP status based on the control connection session entry. ASPF analyzes the FTP instructions in the control connection packet. If the packet contains a data channel setup instruction, ASPF creates an associated entry for the data connection.

3.     For return FTP control connection packets, ASPF examines their TCP status based on the control connection session entry to make packet forwarding decisions.

4.     When the FTP data passes through the device, ASPF is triggered to create a session entry for the data connection and remove the associated entry.

5.     For returned FTP data packets, ASPF examines their TCP status based on the data connection session entry to make packet forwarding decisions.

6.     When the data transmission ends, ASPF removes the data connection session entry. When the FTP connection is removed, ASPF removes the control connection session entry.

Transport layer protocol inspection

The transport layer protocol inspection creates session entries to record the transport layer information of the packets to dynamically filter packets. The transport layer information includes source and destination addresses and port numbers.

The transport layer protocol inspection requires that return packets must match the corresponding packets that are previously sent out of the external interface. The return packets must have the same source/destination addresses and source/destination port numbers as the outgoing packets (but reversed). Otherwise, the return packets are blocked. For multichannel application layer protocols like FTP, the deployment of TCP inspection without application layer inspection leads to failure of establishing a data connection.

Restrictions and guidelines: ASPF configuration

ASPF inspection is required to ensure successful data connections for multichannel protocols when either of the following conditions exists:

·     The ALG feature is disabled in other service modules (such as NAT).

·     Other service modules with the ALG feature (such as DPI) are not configured.

ASPF inspection is optional for multichannel protocols if ALG is enabled in other service modules or if other service modules with the ALG feature are configured.

Application protocols supported by the detect command (except HTTP, SMTP, and TFTP) are multichannel protocols.

ASPF inspection for transport layer protocols is always enabled and is not configurable.

ASPF also supports protocol status validity check for application layer protocols of DNS, FTP, H323, HTTP, SCCP, SIP, and SMTP. ASPF deals with packets with invalid protocol status, depending on the actions you have specified. For other application layer protocols, ASPF does not perform the protocol status validity check, and it only maintains connection status information.

 

ASPF tasks at a glance

To configure ASPF, perform the following tasks:

1.     Configuring an ASPF policy

2.     Applying an ASPF policy to a zone pair

3.     (Optional.) Sending ICMP error message upon packet dropping by interzone policies applied to zone pairs

4.     (Optional.) Enabling real-time log sending mode

Configuring an ASPF policy

1.     Enter system view.

system-view

2.     Create an ASPF policy and enter its view.

aspf-policy aspf-policy-number

After an ASPF policy is created, ASPF inspection for transport layer protocols is always enabled and is not configurable.

3.     (Optional.) Configure ASPF inspection for application layer protocols.

detect { dns [ action { drop | logging } * ] | { ftp | h323 | http | sccp | sip | smtp } [ action drop ] | gtp | ils | mgcp | nbt | pptp | rsh | rtsp | sqlnet | tftp | xdmcp }

By default, ASPF inspection for FTP is configured.

The action keyword enables protocol status validity check for application protocols. ASPF takes the predefined actions on packets with invalid protocol status.

4.     (Optional.) Enable ICMP error message dropping.

icmp-error drop

By default, ICMP error message dropping is disabled. ASPF does not drop faked ICMP error messages.

5.     (Optional.) Enable TCP SYN check.

tcp syn-check

By default, TCP SYN check is disabled. ASPF does not drop the non-SYN packet when it is the first packet to establish a TCP connection.

Applying an ASPF policy to a zone pair

About this task

You can apply an ASPF policy to a zone pair to inspect traffic from the source zone to the destination zone. ASPF compares all packets with session entries. If a packet that is permitted by packet filtering does not match any existing session entries, ASPF creates a new session entry.

ASPF for a zone pair takes effect only when it functions with a packet filter:

·     The packet filter allows only solicited access from the source zone to the network that the destination zone connects.

·     The ASPF policy compares the packets against session entries and allows matching packets from the source zone to the destination zone. The policy also allows return packets from the destination zone to the source zone.

Procedure

1.     Enter system view.

system-view

2.     Enter zone pair view.

zone-pair security source source-zone-name destination destination-zone-name

For information about configuring a zone pair, see "Configuring security zones."

3.     Apply an ASPF policy to the zone pair.

aspf apply policy aspf-policy-number

By default, the predefined ASPF policy is applied to the zone pair.

With the predefined policy, ASPF inspects FTP packets and packets of all transport layer protocols, but it does not perform ICMP error message check or TCP SYN packet check.

Sending ICMP error message upon packet dropping by interzone policies applied to zone pairs

About this task

By default, the device drops packets that do not match interzone policies applied to zone pairs, and it does not send ICMP error messages for the dropping events. This mechanism reduces useless packets transmitted over the network and saves bandwidth.

Enable this feature when you use traceroute because ICMP error messages in this situation are required.

Procedure

1.     Enter system view.

system-view

2.     Enable the device to send ICMP error messages upon packet dropping by interzone policies applied to zone pairs.

aspf icmp-error reply

By default, the device does not send ICMP error messages when the device drops packets that do not match interzone policies applied to zone pairs.

Enabling real-time log sending mode

About this task

Real-time log sending mode takes effect only on logs sent by the security policy, object policy, and packet filtering features.

The device supports the following log sending modes:

·     Cache log sending mode—When the first packet of a flow matches a policy, the device generates a log and caches it and starts a five-minute timer at the same time. If the log matches traffic within five minutes, the device sends the log when the timer expires. If the log does not match any traffic within five minutes, the device deletes the log. The device stops generating logs if the number of cached logs reaches the upper limit.

·     Real-time log sending mode—When the first packet of a flow matches a policy, the device sends a log immediately. For a policy that permits specific packets, the device sends only one log for a flow that matches the policy. For a policy that denies specific packets, the device sends a log for each packet of a flow that matches the policy. The number of logs is not limited.

For more information about logging configuration of the security policy, object policy, and packet filtering features, see "Configuring security policies," "Configuring object policies," and ACL and QoS Configuration Guide.

Procedure

1.     Enter system view.

system-view

2.     Enable real-time log sending mode.

aspf log sending-realtime enable

By default, real-time log sending mode is disabled. Logs are cached before they are sent.

Display and maintenance commands for ASPF

 

Execute display commands in any view and reset commands in user view.

 

Task	Command
Display the configuration of all ASPF policies and their applications to interfaces.	display aspf all
Display the configuration of an ASPF policy.	display aspf policy { aspf-policy-number | default }
Display ASPF sessions.	display aspf session [ ipv4 | ipv6 ] [ slot slot-number ] [ verbose ]
Clear ASPF session statistics.	reset aspf session [ ipv4 | ipv6 ] [ slot slot-number ]

 

ASPF configuration examples

Example: Configuring ASPF FTP application inspection

Network configuration

Configure an ASPF policy on the device to inspect the FTP traffic flows passing through the device. Only return packets for FTP connections initiated by users on the internal network are permitted to pass through the device and get into the internal network. All other types of packets from the external network to the internal network are blocked.

Figure 3 Network diagram

‌

Procedure

# Assign IP addresses to interfaces and configure routes. Make sure the network connections are available. (Details not shown.)

# Configure ACL 3500 to permit IP packets.

<Device> system-view

[Device] acl advanced 3500

[Device-acl-ipv4-adv-3500] rule permit ip

[Device-acl-ipv4-adv-3500] quit

# Add GigabitEthernet 1/0/2 to security zone Trust.

[Device] security-zone name trust

[Device-security-zone-Trust] import interface gigabitethernet 1/0/2

[Device-security-zone-Trust] quit

# Add GigabitEthernet 1/0/1 to security zone Untrust.

[Device] security-zone name untrust

[Device-security-zone-Untrust] import interface gigabitethernet 1/0/1

[Device-security-zone-Untrust] quit

# Create ASPF policy 1 for FTP inspection.

[Device] aspf policy 1

[Device-aspf-policy-1] detect ftp

[Device-aspf-policy-1] quit

# Create a zone pair and enter its view.

[Device] zone-pair security source trust destination untrust

# Apply the ACL to filter to permit outgoing packets in the zone pair.

[Device-zone-pair-security-Trust-Untrust] packet-filter 3500

# Apply the ASPF policy to the zone pair.

[Device-zone-pair-security-Trust-Untrust] aspf apply policy 1

[Device-zone-pair-security-Trust-Untrust] quit

Verifying the configuration

# Verify that an ASPF session has been established for the FTP connection between the host and the server.

<Device> display aspf session ipv4

Slot 0:

Initiator:

  Source      IP/port: 192.168.1.2/1877

  Destination IP/port: 2.2.2.11/21

  VPN instance/VLAN ID/Inline ID: -/-/-

  Protocol: TCP(6)

  Inbound interface: GigabitEthernet1/0/1

    Source security zone: Trust

Total sessions found: 1

# Verify that only return packets that match the entries can enter the internal network. (Details not shown.)