Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path checkfrom x.x.x.x to x.x.x.x

Discussion in 'Cisco' started by zii kell, Jun 11, 2007.

  1. zii kell

    zii kell Guest

    Dear all,

    My PIX 501 6.3.5 log shows these errors. Would someone be able to
    explain what these mean in laymans' terms?


    106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    on interface inside
    106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on
    interface inside
    106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    on interface inside
    106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on
    interface inside
    106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    on interface inside
    106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on
    interface inside

    My internal network uses 10.9.9.0/24 and there are no devices that
    should be connected inside using 192.168.x.x.

    I decided to nmap the address 62.140.29.51 to see what sort of box it was:


    135/tcp filtered msrpc
    136/tcp filtered profile
    137/tcp filtered netbios-ns
    138/tcp filtered netbios-dgm
    139/tcp filtered netbios-ssn
    445/tcp filtered microsoft-ds
    1025/tcp open NFS-or-IIS
    4000/tcp open remoteanything
    12000/tcp open cce4x
    53/udp open|filtered domain
    69/udp open|filtered tftp
    135/udp open|filtered msrpc
    136/udp open|filtered profile
    137/udp open|filtered netbios-ns
    138/udp open|filtered netbios-dgm
    139/udp open|filtered netbios-ssn
    161/udp open|filtered snmp
    162/udp open|filtered snmptrap
    177/udp open|filtered xdmcp
    445/udp open|filtered microsoft-ds
    500/udp open|filtered isakmp
    1900/udp open|filtered UPnP
    4500/udp open|filtered sae-urn
    5000/udp open|filtered UPnP
    5002/udp open|filtered rfe
    5003/udp open|filtered filemaker
    Device type: general purpose
    Running: Microsoft Windows NT/2K/XP
    OS details: Microsoft Windows 2000 SP3
    OS Fingerprint:
    OS:SCAN(V=4.20%D=6/10%OT=1025%CT=1%CU=%PV=N%DS=15%G=Y%TM=466C733A%P=i686-pc
    OS:-windows-windows)T1(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)T1(Resp=Y%DF=Y
    OS:%W=FFFF%ACK=S++%Flags=AS%Ops=MNWNNT)T1(Resp=N)T2(Resp=Y%DF=N%W=C00%ACK=S
    OS:%Flags=AR%Ops=WNMETL)T2(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)T2(R
    OS:esp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)T3(Resp=Y%DF=N%W=400%ACK=S++
    OS:%Flags=AR%Ops=WNMETL)T3(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)T3
    OS:(Resp=Y%DF=N%W=1000%ACK=S++%Flags=AR%Ops=WNMETL)T4(Resp=Y%DF=N%W=C00%ACK
    OS:=S%Flags=AR%Ops=WNMETL)T4(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=WNMETL)T4
    OS:(Resp=Y%DF=N%W=C00%ACK=S%Flags=AR%Ops=WNMETL)T5(Resp=Y%DF=N%W=0%ACK=S++%
    OS:Flags=AR%Ops=)T6(Resp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)T6(Resp=Y%
    OS:DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)T6(Resp=Y%DF=N%W=400%ACK=S%Flags=AR
    OS:%Ops=WNMETL)T7(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)T7(Resp=Y%D
    OS:F=N%W=C00%ACK=S++%Flags=AR%Ops=WNMETL)T7(Resp=Y%DF=N%W=1000%ACK=S++%Flag
    OS:s=AR%Ops=WNMETL)PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UC
    OS:K=F%ULEN=134%DAT=E)

    Network Distance: 15 hops

    OS detection performed. Please report any incorrect results at
    http://insecure.org/nmap/submit/ .
    Nmap finished: 1 IP address (1 host up) scanned in 77.016 seconds
    Raw packets sent: 3468 (131.180KB) | Rcvd: 3296 (168.400KB)
     
    zii kell, Jun 11, 2007
    #1
    1. Advertising

  2. Re: Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path check from x.x.x.x to x.x.x.x

    * zii kell wrote:
    > My PIX 501 6.3.5 log shows these errors. Would someone be able to
    > explain what these mean in laymans' terms?
    >
    >
    > 106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    > on interface inside


    Due to errornous network design, routing or static rules the PIX receives
    the 192.168.255.1 addresses from the inside interface. The routing table of
    the PIX (show route) does not show an approbriate entry for this network
    pointing to interface "inside".
     
    Lutz Donnerhacke, Jun 11, 2007
    #2
    1. Advertising

  3. zii kell

    zii kell Guest


    > Due to errornous network design, routing or static rules the PIX receives
    > the 192.168.255.1 addresses from the inside interface. The routing table of
    > the PIX (show route) does not show an approbriate entry for this network
    > pointing to interface "inside".


    Why would the pix have a route for this subnet (192.168) when this range
    is not used inside? Could this indicate that someone has connected a
    device with 192.168.x.x onto the inside network?
     
    zii kell, Jun 11, 2007
    #3
  4. Re: Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path check from x.x.x.x to x.x.x.x

    * zii kell wrote:
    > Why would the pix have a route for this subnet (192.168) when this range
    > is not used inside? Could this indicate that someone has connected a
    > device with 192.168.x.x onto the inside network?


    Oh, sorry. I usually assume configurational errors first.

    Of course, there might be an internal client using this address.
     
    Lutz Donnerhacke, Jun 11, 2007
    #4
  5. zii kell

    AMR Guest

    Re: Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path check from x.x.x.x to x.x.x.x

    On Jun 11, 5:02 am, zii kell <>
    wrote:
    > Dear all,
    >
    > My PIX 501 6.3.5 log shows these errors. Would someone be able to
    > explain what these mean in laymans' terms?
    >
    > 106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    > on interface inside
    > 106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on
    > interface inside
    > 106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    > on interface inside
    > 106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on
    > interface inside
    > 106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    > on interface inside
    > 106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on
    > interface inside
    >
    > My internal network uses 10.9.9.0/24 and there are no devices that
    > should be connected inside using 192.168.x.x.
    >
    > I decided to nmap the address 62.140.29.51 to see what sort of box it was:
    >
    > 135/tcp filtered msrpc
    > 136/tcp filtered profile
    > 137/tcp filtered netbios-ns
    > 138/tcp filtered netbios-dgm
    > 139/tcp filtered netbios-ssn
    > 445/tcp filtered microsoft-ds
    > 1025/tcp open NFS-or-IIS
    > 4000/tcp open remoteanything
    > 12000/tcp open cce4x
    > 53/udp open|filtered domain
    > 69/udp open|filtered tftp
    > 135/udp open|filtered msrpc
    > 136/udp open|filtered profile
    > 137/udp open|filtered netbios-ns
    > 138/udp open|filtered netbios-dgm
    > 139/udp open|filtered netbios-ssn
    > 161/udp open|filtered snmp
    > 162/udp open|filtered snmptrap
    > 177/udp open|filtered xdmcp
    > 445/udp open|filtered microsoft-ds
    > 500/udp open|filtered isakmp
    > 1900/udp open|filtered UPnP
    > 4500/udp open|filtered sae-urn
    > 5000/udp open|filtered UPnP
    > 5002/udp open|filtered rfe
    > 5003/udp open|filtered filemaker
    > Device type: general purpose
    > Running: Microsoft Windows NT/2K/XP
    > OS details: Microsoft Windows 2000 SP3
    > OS Fingerprint:
    > OS:SCAN(V=4.20%D=6/10%OT=1025%CT=1%CU=%PV=N%DS=15%G=Y%TM=466C733A%P=i686-pc
    > OS:-windows-windows)T1(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)T1(Resp=Y%DF=Y
    > OS:%W=FFFF%ACK=S++%Flags=AS%Ops=MNWNNT)T1(Resp=N)T2(Resp=Y%DF=N%W=C00%ACK=S
    > OS:%Flags=AR%Ops=WNMETL)T2(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)T2(R
    > OS:esp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)T3(Resp=Y%DF=N%W=400%ACK=S++
    > OS:%Flags=AR%Ops=WNMETL)T3(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)T3
    > OS:(Resp=Y%DF=N%W=1000%ACK=S++%Flags=AR%Ops=WNMETL)T4(Resp=Y%DF=N%W=C00%ACK
    > OS:=S%Flags=AR%Ops=WNMETL)T4(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=WNMETL)T4
    > OS:(Resp=Y%DF=N%W=C00%ACK=S%Flags=AR%Ops=WNMETL)T5(Resp=Y%DF=N%W=0%ACK=S++%
    > OS:Flags=AR%Ops=)T6(Resp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)T6(Resp=Y%
    > OS:DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)T6(Resp=Y%DF=N%W=400%ACK=S%Flags=AR
    > OS:%Ops=WNMETL)T7(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)T7(Resp=Y%D
    > OS:F=N%W=C00%ACK=S++%Flags=AR%Ops=WNMETL)T7(Resp=Y%DF=N%W=1000%ACK=S++%Flag
    > OS:s=AR%Ops=WNMETL)PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UC
    > OS:K=F%ULEN=134%DAT=E)
    >
    > Network Distance: 15 hops
    >
    > OS detection performed. Please report any incorrect results athttp://insecure.org/nmap/submit/.
    > Nmap finished: 1 IP address (1 host up) scanned in 77.016 seconds
    > Raw packets sent: 3468 (131.180KB) | Rcvd: 3296 (168.400KB)


    Possible spoof/dos attempt. That error message tells me that uRPF is
    enabled and doing its job. Basically, any traffic that doesn't have a
    path back to the source is dropped. It's not a config error - you are
    seeing drops from (most likely) a spoof or DoS event. A legit packet
    is being sent from the external address with a spoofed IP to respond
    to (target.) Since the PIX can't verify the path back to 192.168 it
    drops it.

    That's what looks like is going on here.
     
    AMR, Jun 11, 2007
    #5
  6. Re: Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path check from x.x.x.x to x.x.x.x

    In article <>,
    AMR <> wrote:
    >On Jun 11, 5:02 am, zii kell <>
    >wrote:


    >> My PIX 501 6.3.5 log shows these errors. Would someone be able to
    >> explain what these mean in laymans' terms?


    >> 106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51
    >> on interface inside


    >A legit packet
    >is being sent from the external address with a spoofed IP to respond
    >to (target.) Since the PIX can't verify the path back to 192.168 it
    >drops it.


    >That's what looks like is going on here.


    No, then it would show "interface outside". The bad packets are
    on the inside. "capture" could be used to find out more about them
    (by looking at the MAC addresses.)
     
    Walter Roberson, Jun 11, 2007
    #6
  7. zii kell

    zii kell Guest

    I shall go and capture some packets. Hope to see some soon.
     
    zii kell, Jun 12, 2007
    #7
    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. Tom
    Replies:
    2
    Views:
    5,220
  2. AM
    Replies:
    2
    Views:
    15,261
    John Hart
    Mar 7, 2008
  3. CCGolfer
    Replies:
    0
    Views:
    3,922
    CCGolfer
    Jun 8, 2004
  4. Networking Student
    Replies:
    4
    Views:
    1,331
    vreyesii
    Nov 16, 2006
  5. Replies:
    5
    Views:
    2,587
Loading...

Share This Page