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

lordchariot_at_earthlink.net
Date: 10/31/03

  • Next message: Paul Robertson: "RE: [fw-wiz] Odd PIX / router behavior" 
    To: <firewall-wizards@honor.icsalabs.com>
Date: Fri, 31 Oct 2003 14:57:27 -0500

    Paul,
    When you saw the original spoofed traffic, what kind of packets were
    they?
    One of my customers is seeing similar behaviour on a significant amount
    of traffic and they are trying to pin it down.
    The packets we're seeing are
    Src: 127.0.0.1:80 Dst: X.X.X.X:<ephemeral> ACK flag only

    The firewall is blocking of course, but the traffic is unusually high.
    My first thought was a misconfigured internal host too, but sniffing the
    inside of the firewall show no sessions originating from any of the
    internal hosts.

    My second guess is some sort of misconfigured router that we are trying
    to pin down. We can't confirm this however.

    My last guess is an external attack which is why I'm wondering if the
    traffic is similar to what you saw?

    Regards,
    Erik

    -----Original Message-----
    From: firewall-wizards-admin@honor.icsalabs.com
    [mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf Of Melson,
    Paul
    Sent: Friday, October 31, 2003 9:19 AM
    To: Claussen, Ken; firewall-wizards@honor.icsalabs.com
    Subject: RE: [fw-wiz] Odd PIX / router behavior

    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

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

  • Next message: Paul Robertson: "RE: [fw-wiz] Odd PIX / router behavior"

    Relevant Pages

    • Re: Block martians with source address 127.0.0.1
      ... but my rules will not log or block these packets. ... interface, but when you test from an internal host, packets will arrive via ... the internal interface, and therefore bypass your iptables rules. ... The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." ...
      (Focus-Linux)
    • Re: PING to inside address goes thru translation and timesout
      ... :I have just installed a PIX 501 and I'm having an odd issue with PING ... The PIX will not operate as a router for packets on the same ... inside interface to 10.0.0.52. ...
      (comp.dcom.sys.cisco)
    • Re: Strange TFTP problem via Pix
      ... had to downgroade because 7.1causes the inside interface to no longer ... accept packets after about one hour :-( ... There are MANY TFTP related bugs in 7.x software. ... associated with TFTPing to/from PIX; ...
      (comp.dcom.sys.cisco)
    • Re: PING to inside address goes thru translation and timesout
      ... The PIX will not operate as a router for packets on the same ... inside interface to 10.0.0.52. ... you should have an internal router which is the gateway ...
      (comp.dcom.sys.cisco)
    • Re: PING to inside address goes thru translation and timesout
      ... The PIX will not operate as a router for packets on the same ... inside interface to 10.0.0.52. ... you should have an internal router which is the gateway ...
      (comp.dcom.sys.cisco)