Home > Articles > Cisco Network Technology > General Networking > Cisco PIX: Advanced Features and Attack Guards

Cisco PIX: Advanced Features and Attack Guards

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Dec 28, 2001.

Chapter Description

This sample chapter from Cisco Secure PIX Firewalls introduces the concepts and configuration elements of the Cisco Secure PIX Firewall features necessary to securely handle multichannel TCP applications. You will learn about advanced protocol handling, multimedia support, and attack guards.

From the Book

Cisco Secure PIX Firewalls

Cisco Secure PIX Firewalls


Attack Guards

This section discusses the Attack Guards features put in place to mitigate attacks via e-mail; Domain Name System (DNS); fragmentation; authentication, authorization, and accounting (AAA); and SYN flooding.


MailGuard provides a mechanism to safeguard Simple Mail Transfer Protocol (SMTP) connections from the outside to an e-mail server. MailGuard allows a mail server to be deployed on a network protected by the PIX without it being exposed to known security problems with certain mail server implementations. Bearing this in mind, Cisco recommends placing mail servers on a DMZ interface and not on the inside network.

Only the SMTP commands specified in RFC 821 section 4.5.1 are allowed on a mail server. These are: HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. When the PIX Firewall observes an SMTP command not in the preceding list, the PIX Firewall proxies a response of "500 command unrecognized" to the remote device and drops the packet before it reaches the protected mail server.

MailGuard isn't a panacea. While it proxies connections, limits the types of SMTP messages that reach your mail server, and hides the SMTP banner that indicates the type and version of the protected mail server, MailGuard can't protect your mail server from all known attacks. Even protected by MailGuard, your mail server needs to be properly configured and patched against known threats.

Also, certain configurations of Microsoft Exchange Server require the use of commands not allowed by MailGuard. In this scenario, MailGuard must be disabled using the no fixup protocol smtp 25 command.

By default, the PIX Firewall inspects port 25 connections for SMTP traffic. If you have SMTP servers using ports other than port 25, you must use the fixup protocol smtp port-number command to have the PIX Firewall inspect these other ports for SMTP traffic. The syntax of the fixup protocol smtp command is as follows:

fixup protocol smtp port [-port ]
no fixup protocol smtp port [-port ]
clear fixup protocol smtp

where port[-port] is a single port or port range that the PIX Firewall will inspect for SMTP connections.

Use the no form of the command to disable the inspection of traffic on the indicated port for SMTP connections. If the fixup protocol smtp command is not enabled for a given port, then potential mail server vulnerabilities are exposed. Example 9-7 illustrates configuration and removal of the MailGuard feature with standard and non-standard ports.

Using the clear fixup protocol smtp command without any arguments causes the PIX Firewall to clear all previous fixup protocol smtp assignments and set port 25 back as the default.

Example 9-7 Adding and Deleting Standard and Non-standard Ports for Mail Guard

pixfirewall(config)# fixup protocol smtp 25

pixfirewall(config)# fixup protocol smtp 2525

pixfirewall(config)# no fixup protocol smtp 25

pixfirewall(config)# no fixup protocol smtp 2525

DNS Guard

DNS Guard identifies an outbound DNS query request and allows only a single DNS response back to the sender. A host may query several servers for a response in case the first server is slow in responding; however, only the first answer to the specific question will be allowed back in. All the additional answers from other servers are dropped. After the client issues a DNS request, a dynamic conduit allows UDP packets to return from the DNS server. The default UDP timer expires in two minutes. Because DNS is frequently attacked, leaving the conduit open for two minutes creates an unnecessary risk. DNS Guard is enabled by default and cannot be configured or disabled. DNS Guard performs the following actions:

  • Automatically tears down the UDP conduit on the PIX Firewall as soon as the DNS response is received. It doesn't wait for the default UDP timer to close the session.

  • Prevents against UDP session hijacking and denial of service (DoS) attacks.

Figure 9-7 illustrates the PIX's involvement in DNS queries.

Figure 9-7 DNS Guard

Fragmentation Guard

Use the sysopt security fragguard command to enable the Fragmentation Guard (FragGuard) feature. This feature enforces two additional security checks on IP packets in addition to the security checks recommended by RFC 1858 against the many IP fragment-style attacks: teardrop, land, and so on. The first security check requires that each non-initial IP fragment be associated with an already-seen valid initial IP fragment. As of PIX OS version 5.1, an initial fragment is not required. This is because fragments may arrive out of order. For the second security check, IP fragments are rated 100 full IP fragmented packets per second to each internal host. This means the PIX can process 1200 packet fragments a second. The FragGuard feature operates on all interfaces in the PIX Firewall and cannot be selectively enabled or disabled by interface.

FragGuard and Virtual Reassembly

The following virtual reassembly features are new in version 5.1:

  • Version 5.1 enhances IP fragment protection and performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the PIX Firewall. The previous restriction with the FragGuard feature that the initial fragment must arrive first has been lifted.

  • A new teardrop syslog message has been added to notify of any fragment overlapping and small fragment offset anomalies.

  • Syslog message, %PIX-2-106020: Deny IP teardrop fragment (size = num, offset = num) from IP_addr to IP_addr was added in this release to log teardrop.c attacks. This message occurs when the PIX Firewall discards an IP packet with a teardrop signature with either a small offset or fragment overlapping. You should treat this event as a hostile attempt to circumvent the PIX Firewall or the Cisco Secure Intrusion Detection System.

  • IP packets fragmented into more than 12 elements cannot pass through the PIX Firewall. Twelve is the maximum number of 1500 byte fragments required to assemble a 16 KB payload. 16,384 bytes is the maximum IP MTU for Token Ring.

The PIX Firewall uses the sysopt security fragguard command to enforce the security policy determined by an access-list permit or access-list deny command to permit or deny packets through the PIX Firewall. The sysopt security fragguard command is disabled by default. The syntax for the sysopt security fragguard command is as follows:

This command has no arguments.


Use of the sysopt security fragguard command breaks normal IP fragmentation conventions. However, not using this command exposes PIX Firewall-protected hosts to the possibility of IP fragmentation attacks. Cisco recommends that packet fragmentation not be permitted on the network if at all possible.


If the PIX Firewall is used as a tunnel for FDDI packets between routers, the FragGuard feature should be disabled.


Because many Linux and UNIX implementations send IP fragments in reverse order, fragmented Linux packets will not pass through the PIX Firewall with the sysopt security fragguard enabled. By sending the final fragment first, the Linux/UNIX host knows the final offset of the payload and can pre-allocate an interface buffer.

AAA Floodguard

While using AAA with the PIX to identify, authorize, and monitor your users helps mitigate the problem of unauthorized access to information resources, it also provides a hacker with an opportunity for mischief. If all connections must be authenticated, what would happen if someone forged so many authentication requests that the PIX's AAA resources were overwhelmed? Denial of service!

The floodguard command allows you to automatically reclaim PIX Firewall resources if the user authentication (uauth) subsystem runs out of resources. If an inbound or outbound uauth connection is being attacked or overused, the PIX actively reclaims TCP user resources. When resources are depleted, the PIX Firewall lists messages indicating that it is out of resources or out of TCP users. If the PIX Firewall uauth subsystem is depleted, TCP user resources in different states are reclaimed depending on urgency in the following order:

  1. Timewait
  2. FinWait
  3. Embryonic
  4. Idle

The floodguard command is enabled by default.

The syntax of the floodguard command is as follows:

where enable enables the AAA Floodguard and disable disables the AAA Floodguard.

SYN Floodguard

SYN flood attacks, also known as TCP flood or half-open connections attacks, are common DoS attacks perpetrated against IP servers. SYN flood attacks are perpetrated as follows:

  1. The attacker spoofs a nonexistent source IP address or IP addresses and floods the target with SYN packets pretending to come from the spoofed host(s).

  2. SYN packets to a host are the first step in the three-way handshake of a TCP-type connection; therefore, the target responds as expected with SYN-ACK packets destined to the spoofed host or hosts.

  3. Because these SYN-ACK packets are sent to hosts that do not exist, the target waits for the corresponding ACK packets that never show up. This causes the target to overflow its port buffer with embryonic or half-open connections and stop responding to legitimate requests.

Figure 9-8 illustrates this type of attack.

Figure 9-8 SYN Flood Attack

To protect internal hosts against DoS attacks, use the static command to limit the number of embryonic connections allowed to the server. Use the em_limit argument to limit the number of embryonic or half-open connections that the server or servers you are trying to protect can handle without being attacked by a DoS.

In version 5.2 of the PIX OS the TCP Intercept feature was added to the SYN Floodguard. The TCP Intercept feature improves the embryonic connection response of the PIX Firewall. When the number of embryonic connections exceeds the configured threshold, the PIX Firewall intercepts and proxies new connections.

Prior to version 5.2, the PIX did not allow new connections after the embryonic connection threshold was exceeded. While it protected the internal host from having all of its TCP connection slots filled, it still resulted in DoS.

This feature requires no change to the PIX Firewall command set, only that the embryonic connection limit on the static command has a new behavior.

The syntax used in the static command for enabling the SYN Floodguard is as follows:

Table 9-1 provides descriptions for the static command arguments.

Table 9-1 static Command Arguments




The internal network interface name.


The external network interface name.


The global IP address for an outside interface. This address cannot be a PAT IP address.


The local IP address on an inside network.


The network mask for the global_ip and local_ip.


The maximum connections permitted to the local_ip. The default = 0 (unlimited).


The maximum embryonic connection permitted to the local_ip. The default = 0 (unlimited).

Setting the max_conns and em_limit arguments should not be taken lightly. If you set the limit too high, you risk overloading the IP stack of your statically translated host and falling victim to a DoS attack. If the limits are set too low, there is the risk of denying service to legitimate users. Example 9-9 demonstrates setting the maximum connection and embryonic connection limits on two hosts. The command shown in Example 9-9 is for illustration purposes only and should not be arbitrarily used. While no firm guidelines exist for setting these limits, the general rule is to set the em-limit and max_conn parameters to a value that won't have a negative impact on the host. Contact the company that wrote the IP stack of your hosts for information on the maximum number of TCP connection slots available and set the em_limit lower than the maximum.

The show local-host command assists you in characterizing your "normal" load on a statically translated host, both before and after setting limits.

The show local-host command shows you the current number of connections and embryonic connections against any limit you have set using the static command.

Example 9-8 shows sample output from the show local-host command, indicating that this host has no embryonic connection limit set.

Example 9-8 show local-hosts Command Output

show local-host

local host: <>, conn(s)/limit = 2/0, embryonic(s)/limit = 0/0


PAT Global Local

PAT Global Local

PAT Global Local

PAT Global Local

PAT Global Local


TCP out in idle 0:00:20 Bytes 449 flags UIO

TCP out in idle 0:00:10 Bytes 359 flags UIO

The Xlate(s) field describes the translation slot information and the Conn(s) field provides connection state information.

Example 9-9 demonstrates how you would configure maximum connections and embryonic connection limits to statically translated hosts.

Example 9-9 Configuring Maximum Connections and Embryonic Connection Limits to Statically Translated Hosts

pixfirewall(config)# static (inside, outside)

netmask 1000 1500

pixfirewall(config)# static (inside, outside)

netmask 2000 2500

In order to protect external hosts against DoS attacks and to limit the number of embryonic connections allowed to the server, use the nat command. Use the em_limit argument to limit the number of embryonic or half-open connections that the server or servers you are trying to protect can handle without being attacked by a DoS.

The syntax used in the nat command for enabling the SYN Floodguard is as follows:

Table 9-2 provides descriptions for the nat command arguments.

Table 9-2 nat Command Arguments




The internal network interface name.


A number used for matching with a corresponding global pool of IP addressees. The matching global pool must use the same nat_id.


The internal IP address or networks that will be translated to a global pool of IP addresses.


The network mask for the local_ip.


The maximum connections permitted to hosts accessed from local_ip. The default = 0 (unlimited).


The maximum embryonic connection permitted to hosts accessed from local_ip. The default = 0 (unlimited).

Setting the maximum connection and embryonic connection limits on outbound traffic must be considered carefully. If you set the limit too high, you risk giving individuals in your organization the ability to perpetrate a DoS attack. If the limits are set too low, there is the risk of denying service to legitimate internal users. Example 9-10 demonstrates how to set the maximum connection and embryonic connection limits for the Inside and DMZ interfaces. The DMZ interface uses much lower limits due to the low number of connections initiated from that interface

Example 9-10 Configuring Maximum Connections and Embryonic Connection Limits to Protect Against Initiating DoS Attacks

pixfirewall(config)# nat (inside) 1 5000 5000

pixfirewall(config)# nat (dmz) 1 500 500

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020