On Thu, 11 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Mark Hobley wrote:

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

http://standards.ieee.org/regauth/ethertype/eth.txt

[compton ~]$ zgrep "^[0-9][0-9]14 " rfcs/ieee.ethertype.eth.gz
8114 - 8118 Software Consulting Services Protocol unavailable.
8914 Brocade FIP Storage Access Protocol
[compton ~]$

There is no 0x0614 type.

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

Please don't waste everyone's time this way.

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

Only if the attacker is already on your LAN. In that case it doesn't
matter, because it's far to late.

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

UDP is trivial to spoof - you might try using a packet sniffer to see
what's inside that packet. Don't bother posting it if you are going
to edit things. Then look at RFC0768, RFC0791 and RFC0894 help you to
interpret it. RFC1700 is obsolete, but you can look at that to
interpret variables within the packet headers.

0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT=5896
bytes) (Also STD0006) (Status: STANDARD)

0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
(Status: STANDARD)

0894 A Standard for the Transmission of IP Datagrams over Ethernet
Networks. C. Hornig. April 1 1984. (Format: TXT=5697 bytes) (Also
STD0041) (Status: STANDARD)

1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format:
TXT=458860 bytes) (Obsoletes RFC1340) (Obsoleted by RFC3232)
(Status: HISTORIC)

Old guy

Moe Trin wrote:

> Only if the attacker is already on your LAN. In that case it doesn't
> matter, because it's far to late.

No. There are other security related issues to be aware of.

> UDP is trivial to spoof - you might try using a packet sniffer to see
> what's inside that packet. Don't bother posting it if you are going
> to edit things.

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.

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

Mark Hobley wrote:

> Moe Trin wrote:
>
>> Only if the attacker is already on your LAN. In that case it doesn't
>> matter, because it's far to late.
>
> No. There are other security related issues to be aware of.

Please educate the group and provide some details.

On Fri, 12 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <3tsqp5-kti.ln1@neptune.markhobley.yi.org>, Mark Hobley wrote:

>Moe Trin wrote:

>> Only if the attacker is already on your LAN. In that case it doesn't
>> matter, because it's far to late.
>
>No. There are other security related issues to be aware of.

Then why are you posting anything? Your paranoia is preventing those
who do know something about networking from providing anything more
than handwaving suggestions. Fine. Work it out yourself.

>> UDP is trivial to spoof - you might try using a packet sniffer to see
>> what's inside that packet. Don't bother posting it if you are going
>> to edit things.
>
>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.

-rw-rw-r-- 1 gferg ldp 22582 Feb 6 2004 Reading-List-HOWTO

"TCP/IP Illustrated, Volume 1 - The Protocols", W. Richard Stevens,
Addison-Wesley, ISBN 0-201-63346-9, 1994, 1996, 576 pgs, US$79.99

That's out of print, but you should be able to find it in any decent
technical library, or on the web.

Old guy

Moe Trin a écrit :
>
> UDP is trivial to spoof

Right, but IP spoofing does not explain the non-IPv4 ethertype nor the
broadcast destination MAC address in the frame.

On Thu, 18 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Pascal Hambourg wrote:

>Moe Trin a écrit :

>> UDP is trivial to spoof

>Right, but IP spoofing does not explain the non-IPv4 ethertype nor
>the broadcast destination MAC address in the frame.

The non-IPv4 ethertype is explainable by the fact that the O/P was
altering the packet details, because he felt that information would
give every hacker the key to own his network. The destination MAC
being a broadcast, while the IP was a unicast suggested a crafted
packet - arping, or hping for example, but given that the data was
obviously falsified, it was a waste of time to analyze it further.
That's why I referred the O/P to the RFCs and Stevens' book, to
either let him learn that his paranoia was excessive, or so that he
could solve the problem on his own.

Old guy

Boon wrote:

> Please educate the group and provide some details.

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

Mark.

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

Moe Trin a écrit :
>
>>>UDP is trivial to spoof
>
>>Right, but IP spoofing does not explain the non-IPv4 ethertype nor
>>the broadcast destination MAC address in the frame.
>
> The non-IPv4 ethertype is explainable by the fact that the O/P was
> altering the packet details

This is what I thought first, but when I asked for confirmation the OP
replied in that he hadn't
altered the ethertype.

> The destination MAC
> being a broadcast, while the IP was a unicast suggested a crafted
> packet - arping, or hping for example

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.

On Fri, 19 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Pascal Hambourg wrote:

>Moe Trin a écrit :

>> The non-IPv4 ethertype is explainable by the fact that the O/P was
>> altering the packet details
>
>This is what I thought first, but when I asked for confirmation the OP
>replied in that he hadn't
>altered the ethertype.

The original post said:

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

and the "00:01:02:03:04:05:06" just screams "FALSIFICATION" - which is
why I was looking at the xx14 Ethertypes.

>> The destination MAC being a broadcast, while the IP was a unicast
>> suggested a crafted packet - arping, or hping for example
>
>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.

He would also have had to configure the router to forward UDP - either
all ports, or merely 80/udp - to this system. I would have to agree
that the more likely source is something on the internal LAN.

Old guy

Moe Trin wrote:

> He would also have had to configure the router to forward UDP - either
> all ports, or merely 80/udp - to this system.

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.

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

Moe Trin a écrit :
>
> The original post said:
>
> ][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
>
> and the "00:01:02:03:04:05:06" just screams "FALSIFICATION"

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.

Mark Hobley a écrit :
>
> I believe that it is possible to compromise a network if you know the internal
> MAC addresses and station IP addresses being used.
>
> Using the same provider, you could use someone elses internet connection
> under certain circumstances, if you have this information.

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 ?

On Sat, 20 Sep 2008 13:11:33 +0200, Pascal Hambourg rearranged some
electrons to say:


>
> 1) Your provider is a cable ISP who uses the client's MAC address as a
> means of - poor - authentification. Does this still exist ?

I belive my ISP (TWC) is looking for the MAC address of the cable modem;
but nothing beyond that.

On Sat, 20 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Pascal Hambourg wrote:

>Moe Trin a écrit :

>> The original post said:
>>
>> ][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

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

Not only that, but this also says that it's UDP and the 'LEN' numbers
look like IPv4. That would be a lot of coincidences. If that were
the case, he should be using the source to pick national lottery
numbers - it's hitting better odds than pure chance.

Old guy

On Sat, 20 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Pascal Hambourg wrote:

>Mark Hobley a écrit :

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

No - especially with NAT on the cable modem.

>Ah, now I think may have an idea of what you are talking about. Actually
> I have two different cases in mind.

But both of those only provide Denial Of Service - pretty easily
detected - not compromising the O/P's systems. It's the same as if
you were to have a duplicate MAC on the LAN.

>1) Your provider is a cable ISP who uses the client's MAC address as a
>means of - poor - authentification. Does this still exist ?

I'm not sure that has been the case for many years. The "bad guy"
would have to be able to hack the cable modem to mess with the DOCSIS
MIB signalling. Not impossible, but pretty easy to detect from the
"victim's" (and provider's) point of view.

>If your router does not filter incoming connections, the neighbour
>could reach your station.

I'm not using a Netgear RP614, but the advertisements for that unit
claims it does NAT and Stateful Packet Inspection. One would hope that
the manufacturer has heard of RFC2827 which is about 8 years old.

Old guy

david wrote:

> I belive my ISP (TWC) is looking for the MAC address of the cable modem;
> but nothing beyond that.

You might be right.

Mark.

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

Pascal Hambourg wrote:

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

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.

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

Pascal Hambourg wrote:

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

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.

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

Mark Hobley a écrit :
> Pascal Hambourg wrote:
>
>>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.
>
> He can do all sorts of things if he has your MAC address and IP address.

Your *external* address. He won't be able to do anything with an
internal MAC address.

> Feeling safe is not enough to protect you.

Obfuscation is not either. Security through obscurity does not work.