Netgear RP614 leaking

Discussion in 'Linux Networking' started by Mark Hobley, Sep 10, 2008.

  1. Mark Hobley

    Mark Hobley Guest

    I have a computer behind an RP614 Web Router Gateway. My kernel is
    echoing a message to the console as follows:

    [nnnnnnn,nnnnn] Inbound IN=eth0 OUT=
    MAC=ff:ff:ff:ff:ff:ff:00:01:02:03:04:05:06:14 SRC=208.71.112.64
    DST=10.0.0.101 LEN=72 TOS=0x00 PREC=0x00 TTL=254 ID=nnnnn PROTO=UDP
    SPT=80 DPT=38458 LEN=52

    Looking at the router configuration, the port number 38458 is not
    forwarded, and I my internet browser is not running at this time.

    Does that mean that there is a bug in the Netgear router that is causing
    it to leak externally sourced UDP traffic across to the internal LAN?

    Mark.
     
    Mark Hobley, Sep 10, 2008
    #1
    1. Advertisements

  2. Your browser would use TCP, not UDP.
    So it's not your browser, even if you did have it running.
    No. It means you have something that's connecting outbound to udp/80,
    and you're seeing the return packet. Apparently you have netfilter &
    syslog configured to alert you on the console. (Personally, I'd find
    that annoying. YMMV)

    According to DNS, 208.71.112.64 is a04.ext.isohunt.com.

    According to ARIN, 208.71.112.64 is
    CustName: isoHunt Web Technologies, Inc.
    Address: 820 Broadway West
    City: Vancouver
    StateProv: BC
    PostalCode: V8Q-4K1
    Country: CA
    NetRange: 208.71.112.0 - 208.71.112.255
    CIDR: 208.71.112.0/24

    Got any reason to go there? Skype? BitTorrent? ... etc....
     
    Allen Kistler, Sep 10, 2008
    #2
    1. Advertisements

  3. Mark Hobley

    Mark Hobley Guest

    Hmmm. I don't know what process that could possibly be. I will keep
    monitoring.

    Yes. It is annoying. I haven't done this. It must be a change made in
    Debian Lenny. This did not happen when using Etch.

    Any ideas on how to switch this off? I am not doing any internal filtering on
    this machine.

    Mark.
     
    Mark Hobley, Sep 10, 2008
    #3
  4. Mark Hobley

    Mark Hobley Guest

    Ok. That means nothing to me. I don't know why I have UDP traffic exchanges
    taking place between this machine and there. (There are other addresses
    too. That just happened to be one I caught on screen, prior to posting.)

    Mark.
     
    Mark Hobley, Sep 10, 2008
    #4
  5. Hello,

    Allen Kistler a écrit :
    Hmm... It does not look like a regular packet.
    - Its ethernet destination address ff:ff:ff:ff:ff:ff is broadcast but
    its destination IP address 10.0.0.101 is unicast.
    -Its ethertype is 0x0614 while it should be 0x0800 for an IPv4 packet.
    Third, the ethernet source address 00:01:02:03:04:05 looks... unusual,
    and the OUI 00:01:02 belongs to 3Com while the router is Netgear.
    - The TTL is 254 which means it traversed at most one hop before
    reaching your box. How far is 208.71.112.64 from you ?

    Are you sure these packets come from the router ?
     
    Pascal Hambourg, Sep 10, 2008
    #5
  6. netfilter would be configured to log a packet. If you haven't
    configured netfilter yourself, you can view the configuration with
    "iptables -L" to see what it logs and how. netfilter logs to the "kern"
    syslog facility at (I think) "info" priority by default (I change mine
    to debug).

    syslog (vs. rsyslog vs. syslog-ng vs. ...) and netfilter configuration
    (where it's stored, how it's started, ...) varies a bit from distro to
    distro. I'm not a Debian guy, so I'll let others answer that part.
     
    Allen Kistler, Sep 10, 2008
    #6
  7. If there's a bunch of udp to a bunch of random different places, that's
    a reason to believe you've got some peer-to-peer type of software
    installed, either by intention or rootkit. Stay rational. Don't jump
    to the rootkit conclusion until you're really sure there's no intention
    on your part or the distro packager. Don't dismiss it, though, either.
    There are tools out there that can help.
     
    Allen Kistler, Sep 10, 2008
    #7
  8. I suspect the OP is anonymizing his data for the MACs. His router would
    NAT the destination to his private IP address.

    Good catch on the TTL, though. That's curious.
     
    Allen Kistler, Sep 10, 2008
    #8
  9. Allen Kistler a écrit :
    Please OPs, don't do that. Or at the very least tell that you did.
     
    Pascal Hambourg, Sep 10, 2008
    #9
  10. Mark Hobley

    Mark Hobley Guest

    Ok. I deon't know why that is so.
    Those numbers were changed by editing. I never noticed whether this was
    an internal or external MAC address, I just assumed it was the internal
    address of one of my routers.
    Ok. That was probably the result of the edit.
    traceroute 208.71.112.64

    1 mercury.markhobley.yi.org (10.0.0.1) 1.068 ms 1.111 ms 1.229 ms
    2 10.81.48.1 (10.81.48.1) 15.800 ms 16.138 ms *
    3 * * *
    4 * * *
    5 * * *
    6 * * *
    7 * * *
    8 s3-1-1-6-0.ar1.CHI1.gblx.net (204.246.200.177) 62.151 ms 65.228 ms
    68.800 ms
    9 64.214.150.82 (64.214.150.82) 179.153 ms
    INTERNAPToronto.ge-0-1-0.401.ar1.YYZ1.gblx.net (64.214.196.26) 183.232
    ms 64.210.12.62 (64.210.12.62) 187.204 ms
    10 border1.pc1-bbnet1.tor001.pnap.net (70.42.24.132) 348.848 ms * *
    11 a04.ext.isohunt.com (208.71.112.64) 147.318 ms 134.086 ms 137.951
    ms

    Hop 2 looks odd:

    2 10.81.48.1 (10.81.48.1) 15.800 ms 16.138 ms *

    I guess that must be the cable modem address.
    I don't know where they come from. I got the information from a message
    that is being echoed to screen by the kernel.

    Mark.
     
    Mark Hobley, Sep 11, 2008
    #10
  11. Mark Hobley

    Mark Hobley Guest

    Ok. That is interesting. I get different results on this machine to
    other machines using the same distribution:

    This machine gives:

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT tcp -- ns1-gat.blueyonder.net anywhere tcp
    flags:!FIN,SYN,RST,ACK/SYN
    ACCEPT udp -- ns1-gat.blueyonder.net anywhere
    ACCEPT tcp -- ns2-kno.blueyonder.net anywhere tcp
    flags:!FIN,SYN,RST,ACK/SYN
    ACCEPT udp -- ns2-kno.blueyonder.net anywhere
    ACCEPT tcp -- ns1-udd.blueyonder.net anywhere tcp
    flags:!FIN,SYN,RST,ACK/SYN
    ACCEPT udp -- ns1-udd.blueyonder.net anywhere
    ACCEPT all -- anywhere anywhere
    ACCEPT icmp -- anywhere anywhere limit: avg
    10/sec burst 5
    DROP all -- BASE-ADDRESS.MCAST.NET/8 anywhere
    DROP all -- anywhere BASE-ADDRESS.MCAST.NET/8
    DROP all -- 255.255.255.255 anywhere
    DROP all -- anywhere default
    DROP all -- anywhere anywhere state
    INVALID
    LSI all -f anywhere anywhere limit: avg
    10/min burst 5
    INBOUND all -- anywhere anywhere
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere LOG level
    info prefix `Unknown Input'

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT icmp -- anywhere anywhere limit: avg
    10/sec burst 5
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere LOG level
    info prefix `Unknown Forward'

    Chain OUTPUT (policy DROP)
    target prot opt source destination
    ACCEPT tcp -- venus.markhobley.yi.org ns1-gat.blueyonder.net tcp
    dpt:domain
    ACCEPT udp -- venus.markhobley.yi.org ns1-gat.blueyonder.net udp
    dpt:domain
    ACCEPT tcp -- venus.markhobley.yi.org ns2-kno.blueyonder.net tcp
    dpt:domain
    ACCEPT udp -- venus.markhobley.yi.org ns2-kno.blueyonder.net udp
    dpt:domain
    ACCEPT tcp -- venus.markhobley.yi.org ns1-udd.blueyonder.net tcp
    dpt:domain
    ACCEPT udp -- venus.markhobley.yi.org ns1-udd.blueyonder.net udp
    dpt:domain
    ACCEPT all -- anywhere anywhere
    DROP all -- BASE-ADDRESS.MCAST.NET/8 anywhere
    DROP all -- anywhere BASE-ADDRESS.MCAST.NET/8
    DROP all -- 255.255.255.255 anywhere
    DROP all -- anywhere default
    DROP all -- anywhere anywhere state
    INVALID
    OUTBOUND all -- anywhere anywhere
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere LOG level
    info prefix `Unknown Output'

    Chain INBOUND (1 references)
    target prot opt source destination
    ACCEPT tcp -- anywhere anywhere state
    RELATED,ESTABLISHED
    ACCEPT udp -- anywhere anywhere state
    RELATED,ESTABLISHED
    LSI all -- anywhere anywhere

    Chain LOG_FILTER (5 references)
    target prot opt source destination

    Chain LSI (2 references)
    target prot opt source destination
    LOG_FILTER all -- anywhere anywhere
    LOG tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix
    `Inbound '
    REJECT tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,ACK/SYN reject-with icmp-port-unreachable
    LOG tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix
    `Inbound '
    REJECT tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,ACK/RST reject-with icmp-port-unreachable
    LOG icmp -- anywhere anywhere icmp
    echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound '
    REJECT icmp -- anywhere anywhere icmp
    echo-request reject-with icmp-port-unreachable
    LOG all -- anywhere anywhere limit: avg
    5/sec burst 5 LOG level info prefix `Inbound '
    REJECT all -- anywhere anywhere reject-with
    icmp-port-unreachable

    Chain LSO (0 references)
    target prot opt source destination
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    5/sec burst 5 LOG level info prefix `Outbound '
    REJECT all -- anywhere anywhere reject-with
    icmp-port-unreachable

    Chain OUTBOUND (1 references)
    target prot opt source destination
    ACCEPT icmp -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere state
    RELATED,ESTABLISHED
    ACCEPT udp -- anywhere anywhere state
    RELATED,ESTABLISHED
    ACCEPT all -- anywhere anywhere

    I didn't set any of the above up, so something in Debian must have done
    that. I'll dig through some scripts to see if I can track this down.

    My other machines give:

    Chain INPUT (policy ACCEPT)
    target prot opt source destination

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    Ok. For some reason my syslog is echoing to all /dev/tty* devices. I would
    only expect this on the system console, (which I have not yet configured on
    /dev/tty9). I will have a look at that separately.

    Mark.
     
    Mark Hobley, Sep 11, 2008
    #11
  12. Mark Hobley

    Mark Hobley Guest

    I am confused about protocols here. I thought that UDP was
    connectionless, and that there could not be a "returned packet", except
    by the remote host making a UDP transmission to a listening port at the
    destination. Because I have no listening ports forwarded at the router
    side, I would have expected the UDP reply datagram to be dropped at the
    router. I will do some reading up of UDP, to clarify this.

    Mark.
     
    Mark Hobley, Sep 11, 2008
    #12
  13. Mark Hobley a écrit :
    Please don't edit. This is useless and confuse people here. The scope of
    a MAC address is limited to the connected ethernet link, so you won't be
    attacked because you posted it. What else did you edit ? If you edited
    the ethertype 06:14, what is the original value ?

    By the way, what is the IP address of eth0 ? Can you post the output of
    "ifconfig eth0" ?
    Unless the routing is very asymmetric, this host is not next to your router.
    No, the round trip time is too long. It is probably an ISP's router at
    the other end of the cable. Unfortunately some ISPs use private
    addresses on their public network.
     
    Pascal Hambourg, Sep 11, 2008
    #13
  14. Mark Hobley a écrit :
    UDP is connectionless but may be used in a connected way : the client
    sends a request from source port A to a server's destination port B and
    expects a reply from the server's source port B to destination port A.
    That's how DNS queries over UDP work.
    Then how would UDP traceroute or DNS queries work ? The router keeps
    track of outgoing UDP packets as if they created a connection, and
    allows incoming reply packets that match that "connection".
     
    Pascal Hambourg, Sep 11, 2008
    #14
  15. Allen Kistler a écrit :
    IMHO "iptables-save" provides a much more readable output.
     
    Pascal Hambourg, Sep 11, 2008
    #15
  16. Mark Hobley

    Mark Hobley Guest

    I did not edit the ethertype. However, the internal MAC address and
    internal station IP have been falsified.

    I believe that it is possible to compromise a network if you know the internal
    MAC addresses and station IP addresses being used.
    eth0 Link encap: Ethernet HWAddr 01:02:03:04:05:06 (falsified)
    inet addr 10.0.0.101 (falsified) Bcast: 10.0.0.255 Mask 255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
    RX Packets: 301795735 errors: 0 dropped: 7 overruns: 0 frames: 0
    TX Packets: 256353593 errors: 0 dropped: 0 overruns: 0 frames: 0
    collisions: 0 txqueuelen: 1000
    RX bytes: 3299537700 (3.0 GiB) TX bytes: 528071502 (503.18 MiB)
    Interrupt: 23 Base: 0xe800
    You are correct. The host is not next to my router.

    Mark.
     
    Mark Hobley, Sep 11, 2008
    #16
  17. Mark Hobley

    Mark Hobley Guest

    So you are saying that a DNS query to an external nameserver traverses
    the router, and the external name server can send a reply directly to
    the station, even though there is no port forwarded for this on the
    router side?

    I thought that the router DNS resolver received the reply from the
    external nameserver, and then the router issues the resolution to the station.

    How does the router know whether incoming UDP is to be dropped or forwarded to
    a station?

    Mark.
     
    Mark Hobley, Sep 11, 2008
    #17
  18. Mark Hobley a écrit :
    Only when the client uses the router as a DNS.
    As I said, it keeps track of outgoing packets. Incoming packets matching
    an outgoing packet are forwarded to the original sender.
     
    Pascal Hambourg, Sep 11, 2008
    #18
  19. Mark Hobley

    Chill Out Guest

    Are you sure thats what it says??

    I read that packet came from MAC ff:....06:14 which is most likely the
    ethernet port on the Netgear 614rp, as a returned normal WWW request
    from 208.71.112.64 to the user at 10.00.0.101.

    Probably a left over reply response from connecting to a web address.

    I don't know how he configured his firewall but I suspect his firewall is
    configured incorrectly and bouncing messages normally dropped to his
    console.
     
    Chill Out, Sep 11, 2008
    #19
  20. Chill Out a écrit :
    Yes, quite.
    The 14-byte hexadecimal string after MAC= is the MAC *header* and not
    only the source MAC address of the received packet. The first 6 bytes
    are the destination address, the next 6 bytes are the source address and
    the last 2 bytes are the ethertype (or the data length when its value is
    less than decimal 1500).
    No, as someone already said an HTTP communication would use TCP instead
    of UDP.
     
    Pascal Hambourg, Sep 11, 2008
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.