OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: David P. Maynard (dpmflametree.com)
Date: Sat Feb 02 2002 - 18:34:13 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    clathemskyhawke.com said:
    > Problem: NetScreen ScreenOS 2.6.1 subject to Trust Interface DoS
    > Attack
    >...
    > Exploit: Someone within the trusted side of the network can attempt a
    > portscan on an external IP address. When the scan runs it appears to
    > consume all of the available sessions. This, in turn, causes a DoS
    > to the entire trusted interface.

    For what it's worth, the instructions that Cisco publishes on how to
    configure the PIX firewall will make many users subject to a similar DOS
    attack.

    Cisco's published examples (at least the ones I have seen) on how to
    configure NAT for the PIX all show the following command:

    nat (inside) 1 0.0.0.0 0.0.0.0 0 0

    The "1" is the global NAT pool identifier and the "0.0.0.0 0.0.0.0" is the
    address and netmask of addresses that are allowed to use the pool. In
    other words, any source IP on the inside interface is allowed to use
    global NAT pool 1.

    Given this configuration and a limited NAT pool, any machine on the inside
    network can create a DOS situation by launching a large number of outbound
    connections using random source IPs. Each random source IP will occupy
    one slot on the NAT table until they are all exhausted. Adding an
    "overload" or "PAT" address will mitigate the situation, but still isn't a
    "fix."

    A much better configuration is to restrict access to the NAT pool to valid
    source IPs on your local network. For example, if your inside network
    uses 192.168.0.0/24 and 192.168.5.0/24, then use:

    nat (inside) 1 192.168.0.0 255.255.255.0 0 0
    nat (inside) 1 192.168.5.0 255.255.255.0 0 0

    With all of the publicity over the past few years about proper egress
    filtering at border routers, you would think that more people would catch
    this problem. Unfortunately, I can safely say that I have never seen a
    PIX configured by anyone else that restricted NAT access to valid source
    IPs. Some of these boxes had been configured by end-users who were just
    reading the docs and wouldn't know any better. Unfortunately, a fair
    number of them had been configured by high-dollar network consultants (who
    apparently didn't know any better either).

    It is possible that PIX OS has a recent feature that can mitigate the
    impact of this problem, but I have seen it take down entire sites back
    when smurf attacks first came around. In any event, it is always a good
    idea to validate the source IPs leaving your network.

    -dpm

    -- 
     David P. Maynard, CTO
     OutServ.net, Inc. -- Managed IT Operations Solutions [TM]
     EMail: dmaynardoutserv.net,  Tel: +1 512 977 8918,  Fax: +1 512 977 0986
    --