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.

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

In comp.os.linux.networking Allen Kistler <(E-Mail Removed)> 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.

In comp.os.linux.networking Allen Kistler <(E-Mail Removed)> 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.

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 ?

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

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

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.

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.

In comp.os.linux.hardware Pascal Hambourg <boite-a-(E-Mail Removed)> 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.