RE: [fw-wiz] Odd PIX / router behavior

From: Melson, Paul (PMelson_at_sequoianet.com)
Date: 10/31/03

  • Next message: je_at_sekure.net: "Re: [fw-wiz] Why blocking bogons buys you nothing"
    To: "Claussen, Ken" <Ken@kccweb.com>, <firewall-wizards@honor.icsalabs.com>
    Date: Fri, 31 Oct 2003 09:18:56 -0500
    
    

    Thanks Ken. It's definitely looking that way. I wanted to rule out
    that some packet with odd flags was slipping through the firewall's
    state table and onto the outside network before being sent back, so I
    added the following route to the PIX:

    route inside 127.0.0.0 255.255.255.0 10.0.0.1

    In this case, 10.0.0.1 is the inside interface of the PIX. This has the
    effect of dropping any traffic from the inside that is destined for
    127.0.0.0/24. The spoofing messages continued to appear in the log data
    after that change, so I'm going to put an access-list on their border
    router, which should knock it down. If it doesn't, you can bet I'll be
    back with more questions. :-)

    Thanks again,
    PaulM

    -----Original Message-----
    I would venture to say that the loopback address is configured on the
    ISP's router one or two hops upstream from your Pix. It is clearly not
    locally defined since you cannot ping it when specifying the inside
    interface. On a Pix 515 DMZ bundle the DMZ interface defaults to this
    address, but you are using the 506 which only has two interfaces. I
    agree with your assessment based on the trip times, the 1605 cannot have
    this configured either. It is most likely being used for BGP touting
    stability by the ISP. This is a common tactic to avoid route flapping in
    the BGP Internet routing tables. I suspect it is within your ISPs
    network because this traffic is usually not passed between ISPs, in my
    experience. As you suggested you could add access lists on the 1605
    outbound dropping the traffic, or you could add them on the Pix as well.
    However I would be curious to find out where the 127.0.0.1 traffic is
    actually being generated from. Dropping it via access list will stop it
    from being passed, but why is it there in the first place? Perhaps an
    internal machine's HOSTS file has been altered and this statement was
    removed, in which case the traffic would follow the default route. With
    some of the recent discussions about malicious HOSTS file entries, this
    seems like a plausible explanation. HTH.

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


  • Next message: je_at_sekure.net: "Re: [fw-wiz] Why blocking bogons buys you nothing"

    Relevant Pages

    • Re: Interesting problem with pix 515 UR
      ... Consider diabling Proxy arp on inside interface. ... This pix have only 2 ethernet interfaces; i have connected the ethernet0via a cross cable ... fixup protocol dns maximum-length 512 ... ntp server 194.100.206.70 source outside ...
      (comp.dcom.sys.cisco)
    • Interesting problem with pix 515 UR
      ... This pix have only 2 ethernet interfaces; i have connected the ethernet0via a cross cable ... interface FastEthernet0/21 ... fixup protocol dns maximum-length 512 ... ntp server 194.100.206.70 source outside ...
      (comp.dcom.sys.cisco)
    • Re: One internal network, VPN, 2 PIX
      ... all I can ping is the internal interface on the PIX that I'm VPN'ing in to. ... Do I need to add ACL's into the Corp PIX to allow the VPN traffic (I already ... the 192.168.200.* inside hosts, the inside hosts are going to ... so the interior hosts send responses to the 501); ...
      (comp.dcom.sys.cisco)
    • [fw-wiz] Double firewall setup (long)
      ... One PIX 515E w/ 3 interfaces: inside, outside, DMZ. ... access-list OUTB permit tcp 10.181.8.0 255.255.248.0 any eq www ... interface ethernet0 auto ...
      (Firewall-Wizards)
    • Firewall Questions (PIX)
      ... I am new at the PIX so please excuse... ... interface which is subnet 1, ... fixup protocol h323 1720 ...
      (comp.security.firewalls)