"Deny IP spoof from 0.0.0.x" - Causing PIX to "ignore" legitimate traffic !!!

Discussion in 'Cisco' started by HisNameWasRobertPaulson, Apr 28, 2004.

  1. Hey gang, recently our PIX has been logging about 1,500 of these
    messages per day for the past 2 days:
    ((2004-04-27 01:42:00 Local4.Critical 10.10.1.2 Apr 27 2004 01:41:36:
    %PIX-2-106016: Deny IP spoof from (0.0.0.22) to 82.83.129.244 on
    interface inside))

    This only occures early in the morning, for about 15 minutes or so,
    then stops.

    The bad part, when these packets are hitting the PIX, the inside
    interface will NOT even respond to a ping request!!! So it seems that
    whatever these packets are, they are hitting the PIX pretty heavy -
    enough for the PIX to be too busy to respond to any legiimate traffic,
    including a ping!!

    This is not good : (

    Alas, I could not find anything relevant about this on the net or in
    the groups. What I have determinded, is that this is a possible trojan
    we have on our internal network. (thats all I can think of)

    So, my question is: what can I do about this? I suppose my goal is to
    obtain the MAC address of the offending station, but how do I do that
    on the PIX?? Will these ip's show up in the arp table, or is there
    some other way for the PIX to give me the MAC address of the offending
    station?? (Or any other method of obtaining the MAC address for that
    matter???)

    Anyway, I am at a loss, any help would be GREATLY appreciated!

    Thanks,

    -Mike
    HisNameWasRobertPaulson, Apr 28, 2004
    #1
    1. Advertising

  2. In article <>,
    HisNameWasRobertPaulson <> wrote:
    :Hey gang, recently our PIX has been logging about 1,500 of these
    :messages per day for the past 2 days:
    :((2004-04-27 01:42:00 Local4.Critical 10.10.1.2 Apr 27 2004 01:41:36:
    :%PIX-2-106016: Deny IP spoof from (0.0.0.22) to 82.83.129.244 on
    :interface inside))

    0.0.0.22 as a source IP would be detected as being in a reserved IP
    address range and complained about.

    Do you happen to be running 6.2 or later? If you are, then you could use
    the newish 'capture' facility. You create an ACL that matches the
    interesting traffic, and then you tell it to start capturing traffic
    that matches the ACL; you can later dump them to the screen.
    The facility was enhanced in 6.3 to allow the captured packets to
    be exported in pcap format for external analysis.

    If you are running 6.1 or earlier, then you don't have much to go on
    other than doing an interface level packet 'debug', but that can get
    pretty overwhelming. (The debug packet options for selecting
    particular protocols don't work in any version I've tried.)


    :I suppose my goal is to
    :eek:btain the MAC address of the offending station, but how do I do that
    :eek:n the PIX??

    show arp

    if you can do that before the arp entry times out.
    --
    *We* are now the times. -- Wim Wenders (WoD)
    Walter Roberson, Apr 28, 2004
    #2
    1. Advertising

  3. Re: "Deny IP spoof from 0.0.0.x" - Causing PIX to "ignore" legitimatetraffic !!!

    Program ended abnormally on 28/04/2004 18:22, Due to a catastrophic
    HisNameWasRobertPaulson error:

    > Hey gang, recently our PIX has been logging about 1,500 of these
    > messages per day for the past 2 days:
    > ((2004-04-27 01:42:00 Local4.Critical 10.10.1.2 Apr 27 2004 01:41:36:
    > %PIX-2-106016: Deny IP spoof from (0.0.0.22) to 82.83.129.244 on
    > interface inside))
    >


    I've seen it happen coming from a router doing NAT. For some wierd reason, its
    nat table would get scrambled and it would start putting 0.0.0.0 as a source ip.
    "Clear ip nat translation *" fixed it, but it would come back. An IOS upgrade
    on the offending router resolved the issue.

    I've also come across NT servers with badly configured NICs that would send
    packets via their properly configured NICs, but use the IP address of the bad
    one as a source IP.

    >
    > The bad part, when these packets are hitting the PIX, the inside
    > interface will NOT even respond to a ping request!!! So it seems that
    > whatever these packets are, they are hitting the PIX pretty heavy -
    > enough for the PIX to be too busy to respond to any legiimate traffic,
    > including a ping!!
    >
    > This is not good : (
    >


    Indeed.

    Can you put a packet sniffer on your lan? Ethereal is very, very cheap. If the
    solution provided by Walter can not work because you can't access your PIX, it
    might be worth it.

    > So, my question is: what can I do about this? I suppose my goal is to
    > obtain the MAC address of the offending station, but how do I do that
    > on the PIX?? Will these ip's show up in the arp table, or is there
    > some other way for the PIX to give me the MAC address of the offending
    > station?? (Or any other method of obtaining the MAC address for that
    > matter???)


    If the offender is on the same segment as the PIX, yes, "show arp" should tell
    you where it is. If it's on a remote subnet, no. In that case, your only
    recourse is to put an access list on the router nearest the pix to block those
    packets; adding "log" to the ACL entry to help locate the source. e.g.:

    interface fastethernet0/0
    description TO PIX
    ...
    interface fastethernet0/1
    description TO HQ lan
    ip access-group FromHQ in
    ...
    interface fastethernet1/0
    description TO Shop lan
    ip access-group FromShop in
    ...
    ip access-list extended FromHQ
    deny ip 0.0.0.0 0.0.0.255 any log
    permit ip any any
    ip access-list extended FromShop
    deny ip 0.0.0.0 0.0.0.255 any log
    permit ip any any

    This way, you'll know if the offending station in on the "HQ" subnet or the
    "Shop" subnet and then it's only a question of putting your sniffer there.

    Hope this helps.

    --
    Francois Labreque | The surest sign of the existence of extra-
    flabreque | terrestrial intelligence is that they never
    @ | bothered to come down here and visit us!
    videotron.ca | - Calvin
    Francois Labreque, Apr 29, 2004
    #3
  4. Hello, Walter!
    You wrote on 28 Apr 2004 22:55:08 GMT:

    WR> The facility was enhanced in 6.3 to allow the captured packets
    WR> to be exported in pcap format for external analysis.

    Export in pcap format is available on 6.2(3). I wasn't able to access it via
    https://pix_ip/capture/name/pcap though and end up copying it via TFTP.

    WR> :I suppose my goal is to :eek:btain the MAC address of the
    WR> offending station, but how do I do that :eek:n the PIX??

    WR> show arp

    Even if offender is on the same sub-net somehow I doubt that it will be
    answering on arp requests.

    With best regards,
    Andrey.
    Andrey Tarasov, Apr 29, 2004
    #4
  5. In article <c6q3e2$c2i$>, Andrey Tarasov <> wrote:
    : WR> show arp

    :Even if offender is on the same sub-net somehow I doubt that it will be
    :answering on arp requests.

    'show arp' does not place ARP requests: it shows the PIX arp tables.
    For outgoing packets (the rejected packets are trying to go out
    of the network), the PIX arp tables are constructed by the PIX looking
    at the IP addresses and MACs of the outgoing packets. Thus, the PIX
    -will- know a MAC and IP pair in this case, at least for a few moments
    until the ARP entries expire. The question becomes one of whether the
    MAC is a meaningful one -- whatever is causing the problems might be
    supplying a bogus or changing MAC as well as a bogus IP.
    --
    Everyone has a "Good Cause" for which they are prepared to spam.
    -- Roberson's Law of the Internet
    Walter Roberson, Apr 29, 2004
    #5
  6. Here, it gets weirder:

    The "spoofed" ip's appear to be alternating addresses in the 0.0.0.0
    subnet, so that the ip address listed can be from 0.0.0.1 to 0.0.0.254
    AND the destination ip is always the same, 82.83.129.244 (I traced
    this to a network in Europe somewhere)

    So I doubt this is a misconfigured router or NT box... this leads me
    to believe it is some kind of trojan.

    In any case, these packets are arriving on the "inside" interface - my
    LAN. I have NO routers on my LAN, only the pix "inside" interface,
    (there are no alternate routes into my network.) So, only workstations
    and servers are on my LAN, and switches - one of these must be the
    offending station.

    Unfortunatly, I have PIX IOS version 6.1(4)

    I will try to show arp, but - I am not sure there will be any entries
    for all these ficticous ip's.. but we will try. (this source HAS to be
    on my LAN, so an arp entry should appear... however, does the PIX
    record mac addresses for spoofed packets??)

    Other than that, it appears that a 3rd party sniffer may be the way to
    go, I will let you know what I find out!

    HAS anybody seen this before???

    Thanks for all your input,
    -Mike

    Francois Labreque <> wrote <text removed...>
    HisNameWasRobertPaulson, Apr 29, 2004
    #6
  7. HisNameWasRobertPaulson

    Rik Bain Guest

    On Wed, 28 Apr 2004 17:55:08 -0500, Walter Roberson wrote:

    > Do you happen to be running 6.2 or later? If you are, then you could use
    > the newish 'capture' facility. You create an ACL that matches the
    > interesting traffic, and then you tell it to start capturing traffic
    > that matches the ACL; you can later dump them to the screen. The
    > facility was enhanced in 6.3 to allow the captured packets to be
    > exported in pcap format for external analysis.
    >



    Just an FYI, the capture command has been able to export to pcap
    since it's introduction (6.2).

    Rik Bain
    Rik Bain, Apr 29, 2004
    #7
  8. Hello, Walter!
    You wrote on 29 Apr 2004 17:26:18 GMT:

    WR> :Even if offender is on the same sub-net somehow I doubt that
    WR> it will be :answering on arp requests.

    WR> 'show arp' does not place ARP requests: it shows the PIX arp
    WR> tables.
    WR> For outgoing packets (the rejected packets are trying to go
    WR> out of the network), the PIX arp tables are constructed by the
    WR> PIX looking at the IP addresses and MACs of the outgoing
    WR> packets.

    Do you happen to have URL or something where this algorithm is described? I have
    a hard time to believe that security device will trust MAC addresses in incoming
    packets instead of using normal way of populating arp cache - via arp
    requests/responses.

    With best regards,
    Andrey.
    Andrey Tarasov, Apr 30, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Bailey

    Who is causing traffic on 506e

    Mike Bailey, Mar 24, 2006, in forum: Cisco
    Replies:
    3
    Views:
    479
    NETADMIN
    Mar 25, 2006
  2. SpooderStank

    Ignore + TEST + Ignore

    SpooderStank, Apr 8, 2004, in forum: Computer Support
    Replies:
    2
    Views:
    596
    PuddleNuts
    Apr 8, 2004
  3. Replies:
    0
    Views:
    3,197
  4. Jeff
    Replies:
    11
    Views:
    3,014
  5. Ramon F Herrera
    Replies:
    6
    Views:
    1,169
Loading...

Share This Page