BA-2001-02 Firewall rule exposure on ACK based filters

 

Original release date: May 26, 2001
Last revised: May 27, 2001

A complete revision history is at the end of this file.

Systems Affected

Any firewall configured to block inbound packets without the ACK bit set.

Severity

Low – Enumeration

Overview

Any firewall system configured to block (not respond to) inbound packets without the ACK bit set may be vulnerable to an information gathering attack that could reveal a portion of the firewall ruleset and suggest the presence of listening daemons.

I. Description

It is sometimes policy to configure a firewall not to respond to inbound packets for a specified port unless the ACK bit is set. This will protect against connections initiated by a remote server. An example of this sort of policy is sometimes used with DNS servers to add extra protection against zone transfers (which use TCP instead of UDP).

A SYN packet, the first packet of a TCP connection, sent to the filtered port would receive no response. However, a packet could be constructed with both the SYN and ACK bits set, spoofing the second part of the three-way handshake. With the ACK bit set, the packet would pass through the firewall. Since the packet is not part of a real connection, the target server would respond by issuing a reset (RST).

By sending both a SYN and a SYN/ACK packet, the attacker can compare results and determine whether ACK based filtering is in place on the target system. An RST does not confirm or deny the presence of a listening daemon, but this type of filtering is suggestive.

Possible conclusions if response differs:

  • A daemon is currently running on the specified port.
  • A daemon ran on the port at one time, but the firewall rules have not yet been updated.
  • Firewall rules have been created in preparation for the installation of a daemon on the specified port.

Possible conclusions if the responses are the same:

  • No daemon exists on the port, filtering is not in place.
  • No daemon exists on the port, filtering is in place, packets being rejected not denied.
  • A daemon exists on the specified port, filtering is in place, packets are being rejected not denied.

No clear determination can be made about the presence of a daemon on the port, however if ACK filtering can be confirmed this may be sufficient foundation for a “best guess” that the port is open and a daemon is listening.

II. Impact

On its own, this does not pose a significant threat. This vulnerability is primarily an information gathering issue. The results of a scan may cause an attacker to give additional attention to the target system/port.

III. Solution

While this issue is really an artifact of TCP/IP, there are steps that can be taken to minimize exposure.

Rather than denying (not responding to) inbound packets without the ACK bit set, the firewall could be configured to reject them (send an RST). In this case, the responses for the SYN and SYN/ACK packets would match, and no conclusion could be drawn from the results. Compare Demonstration sections A and B.

IV. Demonstration

To properly demonstrate this issue, a linux system with iptables is used. Additionally, a demonstration using ipchains is included to demonstrate a possible misconception surrounding the –syn flag.

A. IPTABLES – DROP

[[email protected] bswopes]# /sbin/iptables -L INPUT | grep domain
DROP tcp — anywhere anywhere tcp dpt:domain flags:!ACK/ACK

This iptables rule will drop (not respond to) all packets without the ACK flag set.

[[email protected] /root]# nmap -sS 10.0.0.2 -p 53 -v

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Host shiva.the-well.lan (10.0.0.2) appears to be up … good.
Initiating SYN Stealth Scan against shiva.the-well.lan (10.0.0.2)
The SYN Stealth Scan took 2 seconds to scan 1 ports.
Interesting ports on shiva.the-well.lan (10.0.0.2):
Port State Service
53/tcp filtered domain

Nmap run completed — 1 IP address (1 host up) scanned in 4 seconds

Nmap sent a SYN packet to the filtered port and did not receive a response. Filtering is determined to be in place on the target port.

[[email protected] /root]# nmap -sA 10.0.0.2 -p 53 -v

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Host shiva.the-well.lan (10.0.0.2) appears to be up … good.
Initiating ACK Scan against shiva.the-well.lan (10.0.0.2)
The ACK Scan took 0 seconds to scan 1 ports.
The 1 scanned port on shiva.the-well.lan (10.0.0.2) is: UNfiltered
Nmap run completed — 1 IP address (1 host up) scanned in 1 second
[[email protected] /root]#

Nmap sent an ACK packet to the filtered port and received an RST in response. Port is determined to be unfiltered.

B. IPTABLES – REJECT

[[email protected] bswopes]# /sbin/iptables -L INPUT | grep domain
REJECT tcp — anywhere anywhere tcp dpt:domain flags:!ACK/ACK reject-with tcp-reset

This iptables rule will reject all packets without the ACK flag set by responding with an RST.

[[email protected] /root]# nmap -sS 10.0.0.2 -p 53 -v

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Host shiva.the-well.lan (10.0.0.2) appears to be up … good.
Initiating SYN Stealth Scan against shiva.the-well.lan (10.0.0.2)
The SYN Stealth Scan took 0 seconds to scan 1 ports.
The 1 scanned port on shiva.the-well.lan (10.0.0.2) is: closed
Nmap run completed — 1 IP address (1 host up) scanned in 0 seconds

Nmap sent a SYN packet to the filtered port and received an RST in response. Filtering is not determined to be in place on the target port.

[[email protected] /root]# nmap -sA 10.0.0.2 -p 53 -v

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Host shiva.the-well.lan (10.0.0.2) appears to be up … good.
Initiating ACK Scan against shiva.the-well.lan (10.0.0.2)
The ACK Scan took 0 seconds to scan 1 ports.
The 1 scanned port on shiva.the-well.lan (10.0.0.2) is: UNfiltered
Nmap run completed — 1 IP address (1 host up) scanned in 0 seconds
[[email protected] /root]#

Nmap sent an ACK packet to the filtered port and received an RST in response. Port is determined to be unfiltered.

C. IPCHAINS – DENY

[[email protected] /root]# ipchains -L input -n | grep 53
DENY tcp !y—- 0.0.0.0/0 0.0.0.0/0 * -> 53

This ipchains rule will deny (not respond to) all packets with the SYN flag set and without the ACK and FIN flags set. This means that the only packet that would be allowed through would be the close of a connection. 

iptables is a better tool for demonstrating this issue, as it allows more control over flag settings.

[[email protected] /root]# nmap -sS 127.0.0.1 -p 53 -v

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Host roto-router (127.0.0.1) appears to be up … good.
Initiating SYN Stealth Scan against roto-router (127.0.0.1)
The SYN Stealth Scan took 0 seconds to scan 1 ports.
The 1 scanned port on roto-router (127.0.0.1) is: closed
Nmap run completed — 1 IP address (1 host up) scanned in 1 second

Nmap sent a SYN packet to the filtered port and did not receive a response.

[[email protected] /root]# nmap -sA 127.0.0.1 -p 53 -v

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Host roto-router (127.0.0.1) appears to be up … good.
Initiating ACK Scan against roto-router (127.0.0.1)
The ACK Scan took 2 seconds to scan 1 ports.
Interesting ports on roto-router (127.0.0.1):
Port State Service
53/tcp filtered domain

Nmap run completed — 1 IP address (1 host up) scanned in 4 seconds

Nmap sent an ACK packet to the filtered port and did not receive a response. This is due to the fact that the !y flag on ipchains also requires the FIN flag be set.

V. Credit

This advisory was inspired by messages to the Incidents mailing list at securityfocus.com by Paul DeCamp and Ryan Russel, May 25, 2001, on the subject of “SYN/ACK to port 53”. My initial response can be found here.

 

BhodiSoft Contact Information

Email:

 

[email protected]

Getting security information

BhodiSoft publications and other security information are available from our web sitehttps://www.bhodisoft.com/

Copyright 2001 Blake R. Swopes.


Revision History

May 26, 2001: Initial Release
May 27, 2001: Demonstration added.