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

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.

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.

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.

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

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.

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.

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.

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.

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

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.