RE: [fw-wiz] Strange Pix behavior.

From: Paul Melson (psmelson_at_comcast.net)
Date: 06/13/05

  • Next message: R. DuFresne: "Re: [fw-wiz] Ok, so now we have a firewall, we're safe, right?" 
    To: "'George J. Jahchan, Eng.'" <Firewall-Wizards@Compucenter.org>, "'Firewall Wizards List'" <firewall-wizards@honor.icsalabs.com>
Date: Mon, 13 Jun 2005 12:48:29 -0400

    This is the typical behavior of most stateful firewalls expressed through
    log entries. What you're actually seeing is the firewall dropping the
    RST+ACK packet coming back from the remote web server at the end of the
    connection.

    A stateful TCP session works something like this:

    1. SYN packet leaves client and is picked up by firewall.

    2. Packet src/dst addresses and ports compared to directional access-list.

    3. Upon matching a 'permit' access-list, a state entry is created that acts
    like an implicit access-list for the corresponding return traffic. (This
    works by mapping information from the accepted packet to the new "state
    table entry" access-list, like so:
    inbound_if <-> outbound_if
    dst_addr -> src_addr
    dst_port -> src_port
    src_addr_after_nat -> dst_addr
    src_port_after_nat -> dst_port

    4. Firewall counts packets and watches for RST packet from either src or dst
    to know when the connection has ended.

    5. When the RST is seen, the state table entry from #3 is deleted and the
    process begins again.

    If the firewall successfully deletes the state table entry before the remote
    server can send an RST+ACK (which is what you want, you don't want your
    firewall waiting for an untrusted system's predicted response before it
    revokes its access), that packet will be compared to the access-lists that
    allow traffic from the outside and if no match is found, it will be dropped
    and logged.

    Your firewall is working just fine, or at least, it's working as it was
    designed to work. If you don't want to see it, I recommend using Kiwi or
    syslog-ng to remove these entries from the syslog stream before they reach
    your log analyzer.

    PaulM

    PS - Your reseller sucks.

    -----Original Message-----
    Subject: [fw-wiz] Strange Pix behavior.

    We are using a pair of failover Pix 515s, and are consistently seeing denied
    return traffic that theoretically should have been allowed.

    Three zones are defined: LAN, DMZ and WAN and the policy is default deny.
    For the allowed outbound protocols like http, we are seeing (on weekdays)
    anywhere between 25,000 and 45,000 denials originating from web server
    addresses on the Internet port 80 to the NAT'ed IP address of LAN users.
    This is the return traffic in response to requests that originated from the
    LAN.

    Sample log entry follows:
    ... Deny tcp src outside:<www-server-IP>/80 dst LAN:<NAT-IP>/31997 by
    access-group "WAN"

    The corresponding rule in the LAN access-group is:
    access-list LAN permit tcp host X.X.X.X gt 1023 any eq www

    Not all traffic is blocked, only part of it, seemingly at random, otherwise
    no one would have been able to surf the web, which is not the case.

    We are also seeing denials generated by the return traffic of other allowed
    outbound protocols such as pop3, imap4, smtp and dns (udp); in numbers that
    seem to be proportional to the overall number of requests for each protocol.

    On week-ends when the traffic is very low, we are still seeing denials, in
    numbers proportional to overall requests.

    We have monitored CPU and memory utilization on the Pix, they are low (CPU <
    10% and memory < 25%).

    The Cisco reseller has not come through with a credible explanation for this
    behavior or made suggestions on course of action for diagnosing the problem.

    Can anyone on this list help?

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: R. DuFresne: "Re: [fw-wiz] Ok, so now we have a firewall, we're safe, right?"

    Relevant Pages

    • Re: Kerio PFW 2.14 - Safe?
      ... >> down user interface. ... Then consider the fact that most packet ... If Kerio 'X' says it's stateful it most ... >> way to know for sure would be to stand between the firewall and the ...
      (comp.security.firewalls)
    • Re: Firewall questions -- what is ...?
      ... packet payload inspection. ... IDS is not a firewall and does not necessarily protect you. ... port number for a well known service and the destination port is above 1023, ... Firewalls and IDS are prone to frequent false alarms. ...
      (microsoft.public.security)
    • Re: Max iptables rules?
      ... Here is my understanding of how Iptables processes firewall rules, ... Lets say the above is our firewall with 1000 rules in it. ... The packet will be compared to the list. ... On the 3rd rule, iptables will find a match and will allow the packet, ...
      (comp.security.firewalls)
    • Re: Max iptables rules?
      ... Here is my understanding of how Iptables processes firewall rules, ... Lets say the above is our firewall with 1000 rules in it. ... The packet will be compared to the list. ... On the 3rd rule, iptables will find a match and will allow the packet, ...
      (comp.security.firewalls)
    • Re: Max iptables rules?
      ... Here is my understanding of how Iptables processes firewall rules, ... Lets say the above is our firewall with 1000 rules in it. ... The packet will be compared to the list. ... On the 3rd rule, iptables will find a match and will allow the packet, ...
      (comp.security.firewalls)