Netgear RP614 leaking - Networking

This is a discussion on Netgear RP614 leaking - Networking ; 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 44

Thread: Netgear RP614 leaking

  1. Netgear RP614 leaking

    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  2. Re: Netgear RP614 leaking

    Mark Hobley wrote:
    > 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.


    Your browser would use TCP, not UDP.
    So it's not your browser, even if you did have it running.

    > 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?


    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....

  3. Re: Netgear RP614 leaking

    In comp.os.linux.networking Allen Kistler wrote:

    > No. It means you have something that's connecting outbound to udp/80,
    > and you're seeing the return packet.


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


    > Apparently you have netfilter & > syslog configured to alert you on the
    > console. (Personally, I'd find that annoying. YMMV)


    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  4. Re: Netgear RP614 leaking

    In comp.os.linux.networking Allen Kistler wrote:

    > 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


    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  5. Re: Netgear RP614 leaking

    Hello,

    Allen Kistler a écrit :
    > Mark Hobley wrote:
    >
    >> 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

    [...]
    >> 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?

    >
    > No. It means you have something that's connecting outbound to udp/80,
    > and you're seeing the return packet.


    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 ?

  6. Re: Netgear RP614 leaking

    Mark Hobley wrote:
    > In comp.os.linux.networking Allen Kistler wrote:
    >
    >> No. It means you have something that's connecting outbound to udp/80,
    >> and you're seeing the return packet.

    >
    > Hmmm. I don't know what process that could possibly be. I will keep
    > monitoring.
    >
    >
    >> Apparently you have netfilter & > syslog configured to alert you on the
    >> console. (Personally, I'd find that annoying. YMMV)

    >
    > 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.


    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.

  7. Re: Netgear RP614 leaking

    Mark Hobley wrote:
    > In comp.os.linux.networking Allen Kistler wrote:
    >
    >> 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

    >
    > 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.)


    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.

  8. Re: Netgear RP614 leaking

    Pascal Hambourg wrote:
    > Hello,
    >
    > Allen Kistler a écrit :
    >> Mark Hobley wrote:
    >>
    >>> 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

    > [...]
    >>> 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?

    >>
    >> No. It means you have something that's connecting outbound to udp/80,
    >> and you're seeing the return packet.

    >
    > 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 ?


    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.

  9. Re: Netgear RP614 leaking

    Allen Kistler a écrit :
    >
    > I suspect the OP is anonymizing his data for the MACs.


    Please OPs, don't do that. Or at the very least tell that you did.

  10. Re: Netgear RP614 leaking

    In comp.os.linux.hardware Pascal Hambourg wrote:

    > 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.


    Ok. I deon't know why that is so.

    > Third, the ethernet source address 00:01:02:03:04:05 looks... unusual,


    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.

    > and the OUI 00:01:02 belongs to 3Com while the router is Netgear.


    Ok. That was probably the result of the edit.

    > - 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 ?


    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.

    > Are you sure these packets come from the router ?


    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  11. Re: Netgear RP614 leaking

    Allen Kistler wrote:

    > 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.


    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

    > netfilter logs to the "kern" syslog facility


    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  12. Re: Netgear RP614 leaking

    In comp.os.linux.networking Allen Kistler wrote:

    > No. It means you have something that's connecting outbound to udp/80,
    > and you're seeing the return packet.


    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  13. Re: Netgear RP614 leaking

    Mark Hobley a écrit :
    > Pascal Hambourg wrote:
    >
    >>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.

    >
    > Ok. I deon't know why that is so.
    >
    >>Third, the ethernet source address 00:01:02:03:04:05 looks... unusual,

    >
    > Those numbers were changed by editing.


    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" ?

    >>- 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 ?

    >
    > 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 *

    [...]
    > 11 a04.ext.isohunt.com (208.71.112.64) 147.318 ms 134.086 ms 137.951
    > ms


    Unless the routing is very asymmetric, this host is not next to your router.

    > 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.


    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.

  14. Re: Netgear RP614 leaking

    Mark Hobley a écrit :
    >
    > 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.


    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.

    > 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.


    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".

  15. Re: Netgear RP614 leaking

    Allen Kistler a écrit :
    >
    > 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.


    IMHO "iptables-save" provides a much more readable output.

  16. Re: Netgear RP614 leaking

    Pascal Hambourg wrote:
    >
    > 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 ?


    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.

    > By the way, what is the IP address of eth0 ? Can you post the output of
    > "ifconfig eth0" ?


    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

    > Unless the routing is very asymmetric, this host is not next to your router.


    You are correct. The host is not next to my router.

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  17. Re: Netgear RP614 leaking

    Pascal Hambourg wrote:
    > 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.


    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,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  18. Re: Netgear RP614 leaking

    Mark Hobley a écrit :
    >
    > 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?


    Yes.

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


    Only when the client uses the router as a DNS.

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


    As I said, it keeps track of outgoing packets. Incoming packets matching
    an outgoing packet are forwarded to the original sender.

  19. Re: Netgear RP614 leaking

    markhobley@hotpop.donottypethisbit.com (Mark Hobley) writes:

    > I believe that it is possible to compromise a network if you know
    > the internal MAC addresses and station IP addresses being used.


    I can see keepin the IP address private, expecially if there is no
    firewall. But if you have a firewall, then knowing your IP address is (say)
    192.168.1.2 doesn't make you vulnerable. People can;t attack internal nodes.

    They can attack your firewall, of course.

    As for the MAC, if one is on the local LAN, one can do ARP poisoning.
    But the attacker has to be on your LAN. I'm not sure it's a security threat.

    It might be a privacy threat....


  20. Re: Netgear RP614 leaking

    On Wed, 10 Sep 2008 21:40:05 +0200, Pascal Hambourg wrote for every to
    trash:

    > Hello,
    >
    > Allen Kistler a écrit :
    >> Mark Hobley wrote:
    >>
    >>> 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

    > [...]
    >>> 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?

    >>
    >> No. It means you have something that's connecting outbound to udp/80,
    >> and you're seeing the return packet.

    >
    > 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 ?


    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.

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast