Netgear RP614 leaking

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

  1. Mark Hobley

    Mark Hobley Guest

    No. There are other security related issues to be aware of.
    I am not going to publish addresses of machines with a security related query,
    or information about how to compromise networks within my care. I don't
    understand why you think I need to do this.

    Mark Hobley, Sep 12, 2008
    1. Advertisements

  2. Mark Hobley

    Boon Guest

    Please educate the group and provide some details.
    Boon, Sep 13, 2008
    1. Advertisements

  3. Moe Trin a écrit :
    Right, but IP spoofing does not explain the non-IPv4 ethertype nor the
    broadcast destination MAC address in the frame.
    Pascal Hambourg, Sep 18, 2008
  4. Mark Hobley

    Mark Hobley Guest

    Using the same provider, you could use someone elses internet connection
    under certain circumstances, if you have this information.

    Mark Hobley, Sep 18, 2008
  5. Moe Trin a écrit :
    This is what I thought first, but when I asked for confirmation the OP
    But then such a packet must have been sent directly from a host on the
    internal LAN. It could not have been sent from the outside and forwarded
    by the router, because the router would have written correct data in the
    MAC header.
    Pascal Hambourg, Sep 19, 2008
  6. Mark Hobley

    Mark Hobley Guest

    Hmmm. Port 80 is forwarded, but not to this station. Could it be that
    the web server station is somehow "reflecting" UDP traffic?

    (The webserver is thttpd, if that matters.)

    There is no option to specify port forwarded by protocol within this
    router. A port is either forwarded, or not forwarded on the Netgear RP614.

    Mark Hobley, Sep 20, 2008
  7. Moe Trin a écrit :
    Yes it does. :) This is also a reason why I asked for confirmation.
    Besides, the packet being logged by iptables means that the IPv4 stack
    picked it, and I may be wrong but I strongly doubt that the IPv4 stack
    would pick a packet without the IPv4 ethertype.
    Pascal Hambourg, Sep 20, 2008
  8. Mark Hobley a écrit :
    Ah, now I think may have an idea of what you are talking about. Actually
    I have two different cases in mind.

    1) Your provider is a cable ISP who uses the client's MAC address as a
    means of - poor - authentification. Does this still exist ? Note that it
    uses the external MAC address of your router, not the internal one
    (although they could be the same, depending on the model). A "neighbour"
    sharing the same link could spoof your external MAC address to be
    authenticated as if it were you - and possibly use your public IP
    address. However he does not use your connection, nor has access to your
    internal network.

    2) A "neighbour" sharing the same link could create a route to your
    station IP address using your external MAC or public IP address as
    gateway. Note that again it uses the external MAC address of your
    router. If your router does not filter incoming connections, the
    neighbour could reach your station.

    Are you in either of these situations ?
    Pascal Hambourg, Sep 20, 2008
  9. Mark Hobley

    david Guest

    I belive my ISP (TWC) is looking for the MAC address of the cable modem;
    but nothing beyond that.
    david, Sep 20, 2008
  10. Mark Hobley

    Mark Hobley Guest

    You might be right.

    Mark Hobley, Sep 21, 2008
  11. Mark Hobley

    Mark Hobley Guest

    He can do all sorts of things if he has your MAC address and IP address.

    Feeling safe is not enough to protect you. There are ships that have been sunk
    even though the crew felt safe (HMS Sheffield).

    Mark Hobley, Sep 21, 2008
  12. Mark Hobley

    Mark Hobley Guest

    Ok. That makes sense. However, I am not sure whether that behaviour is always
    desireable. Not all UDP packets require a reply, and looking quickly at
    the UDP header layout, there are no flags to determine whether or not a reply
    is desirable. If the remote host sends a UDP datagram (reply) to a host
    on the network following receipt of a UDP datagram from the host on the
    network, presumeably the UDP reply will be forwared to the local station,
    regardless of whether or not this was expected.

    I am wondering whether this gives a remote host the possibility of
    connecting to an internal UDP service on a local machine, because the
    local machine send a UDP message to the remote host seconds earlier.

    Say for example, a local station behind the router runs two unrelated
    services, foo and bar.

    foo is an internal service that is used on the LAN that sends out
    password information on receipt of a UDP datagram on port 10000.

    bar is an unrelated service that sends a UDP datagram to remotehost,
    for example a time signal.

    Say remotehost has been configured to send a UDP password request to
    port 10000, on receipt of a time signal.

    As service bar sends out the time signal, the router notes that remotehost has
    recently active UDP activity and can reply to the local station. The
    remotehost sends out a UDP password request to port 10000. The router
    receives this and forwards the password request to the local station (or
    does it know better?) The local station receives this request and sends
    the password to remotehost as requested.

    Could this happen or are there additional steps that the router takes to
    prevent this from happening?

    Mark Hobley, Sep 21, 2008
  13. Mark Hobley a écrit :
    Your *external* address. He won't be able to do anything with an
    internal MAC address.
    Obfuscation is not either. Security through obscurity does not work.
    Pascal Hambourg, Sep 23, 2008
  14. Mark Hobley a écrit :
    Indeed, UDP connection tracking and stateful NAT is primarily designed
    for session-oriented bidirectionnal (i.e. TCP-like) UDP flows.
    It depends on the design of the stateful UDP NAT, and what kind of
    packet is considered to be a reply. There are many variations in NAT
    behaviour ; some of them are described in RFC 2663 and 3489.

    There are more or less restrictive definitions of a UDP reply packet. A
    less restrictive definition is that an incoming UDP packet must match
    only the source and destination addresses of an outgoing UDP packet. A
    more restrictive definition is that it must match the source and
    destination addresses and ports. So a packet sent to port 10000 won't be
    considered as a reply to a packet sent from a different port. The
    connection tracking, and thus the stateful NAT, performed by
    Netfilter/iptables in Linux behaves this way. I don't know for sure, but
    my guess is that most SOHO routers behave the same way, because doing
    otherwise may have issues with multiple hosts being masqueraded behind a
    single external address.
    Pascal Hambourg, Sep 24, 2008
  15. Who cares? If this is not desired, then some security policy or
    firewall would prevent it.
    NAT is *NOT* a security scheme. It's a way to provide access, not to
    restrict it.

    If you want to prevent connectivity, you need firewalls and access

    This is a very common misunderstanding. NAT often prevents outside
    machines from reaching inside machines as an accidental side-effect.
    It's much the same way that switches keep some machines from seeing
    packets sent by other machines. It cannot be relied upon because it is
    not reliable.

    NAT is not a security policy.

    David Schwartz, Sep 24, 2008
  16. Mark Hobley

    Mark Hobley Guest

    So a hardware firewall router would have the facility to address this
    issue, whereas a conventional broadband router does not?

    Mark Hobley, Oct 4, 2008
  17. Some broadband routers might have this kind of capability. But in
    general, they default to allowing all traffic that might be wanted.
    This is generally true despite their misleading statements about their
    default policy or device capabilities. They get complaints when things
    don't work.

    NAT is sometimes an accidental firewall, it might happen to stop an
    attack, and that's great. But only an actual firewall is a *reliable*
    firewall. You cannot rely on NAT to block a packet, since NAT tries
    its best to get the packets through.

    David Schwartz, Oct 5, 2008
    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.