mystery martian source from 127.0.0.1

On Sat, 10 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<dnf293$jn4$1@news.hispeed.ch>, EricT wrote:

>I figured out, which system is responsible for these martian packets.

I don't think so, unless the Modem is behaving as a transparent bridge.
That's not impossible, but it's also not likely.

>I listened to the traffic of the cablecom net and this particular
>gateway is routing or forwarding or sending broadcasts (67 -> 68),
>which my firewall dropped without logging. Now after monitoring all
>the traffic, i have seen the MAC (and ip) in any packet of this type.

Here's how to tell if your modem is a bridge or not. While you are
looking at the traffic, do you see any OTHER MAC addresses - or is all
of the traffic using that same 00:09:7b:8d:98:70. Obviously, we don't
count your own MAC address in this mess - but what about all others?

>a traceroute to that ip will show this:
>traceroute to 80.219.88.1 (80.219.88.1), 30 hops max, 40 byte packets
> 1 * * *

[...]

>30 * * *

All that is saying is that there is a nearby host that is dropping
ICMP error messages, or that 80.219.88.1 has a firewall rule to "DROP"
rather than "REJECT" or none at all.

>After calling the ISP, they do not seem to be very interested in this
>matter.

You got to talk to someone who can spell "IP" ??? Wow - that doesn't
happen to often. ;-)

>I still do not know what (in detail) causes the martian packets, but i
>know where they come from and actually it is not my business anymore ;-).

You could set your own firewall to ignore packets with a source of
127.0.0.0/8 on the eth0 interface. RFC2827 (and RFC3704) recommend such
filtering.

2827 Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing. P. Ferguson, D. Senie.
May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated
by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE)

3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
BCP0084) (Status: BEST CURRENT PRACTICE)

Normally, your ISP should be doing this - looks as if they are falling
down on the concept.

Old guy

Hi Moe,

i will concatenate the last two posts from you...

>>>Moe Trin wrote:
> Find some command lines - in one, run 'tcpdump -ni eth0' to watch the
> traffic on your eth0 interface. In another, run the command '/sbin/arp -a'
> and (assuming you have been using the network recently), there should be
> a line looking something like
>
> - <some.ip.address> at 00:09:7b:8d:98:70 on eth0

yes,
80-219-224-1.dclient.hispeed.ch (80.219.224.1) at 00:09:7B:8D:98:70
[ether] on eth0

> That IP address is your modem. Now, telnet to that address as above,
> and look at where you are running the tcpdump - you should see some
> activity - look for a 'ttl' in the line where your router tells you to
> go away and not bother it.

A ping will show this:
64 bytes from 80.219.224.1: icmp_seq=1 ttl=255 time=7.01 ms

>>>The first hop while tracerouting any ip will always show up as (* * *):
>
>
> You'd have to look at the tcpdump while doing this. Some of these POS
> are configured to not sent ICMP errors, and that is what traceroute
> depends on. Note - I'm assuming a UNIX style traceroute which uses UDP
> to ports > 33434, and not the b0rken microsoft imitation which uses ICMP
> type 8 (ping).
>
>
>>>A ping to the cablecom gateway will show:
>>>
>>>PING tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1) 56(84) bytes of data.
>>>64 bytes from tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1):
>>>icmp_seq=1 ttl=252 time=8.48 ms
>
>
> Again - ttl=252. The gateway is probably three hops away, starting value
> was 255.

It is as you say.

>>>The MAC of the modem (shown on a label in the back of it) is far
>>>different than the one shown in the martian packets.
>
>
> The martian was showing 00:09:7b:8d:98:70 which is a Cisco - what does the
> label say? Cisco has (as of early October) 271 different blocks of MAC
> addresses from 00:00:0c to 00:e0:fe

The MAC starts with 00:0E:9B. Actually i think it is configured as a
bridge, but not sure about it.

------------

Moe Trin wrote:
> I don't think so, unless the Modem is behaving as a transparent bridge.
> That's not impossible, but it's also not likely.
>
>
> Here's how to tell if your modem is a bridge or not. While you are
> looking at the traffic, do you see any OTHER MAC addresses - or is all
> of the traffic using that same 00:09:7b:8d:98:70. Obviously, we don't
> count your own MAC address in this mess - but what about all others?
>

There is one more MAC shown where all the broadcasts come from, seems to
be another router.

> You got to talk to someone who can spell "IP" ??? Wow - that doesn't
> happen to often. ;-)

:-)

>>I still do not know what (in detail) causes the martian packets, but i
>>know where they come from and actually it is not my business anymore ;-).
>
>
> You could set your own firewall to ignore packets with a source of
> 127.0.0.0/8 on the eth0 interface. RFC2827 (and RFC3704) recommend such
> filtering.

I did already.

>
> 2827 Network Ingress Filtering: Defeating Denial of Service Attacks
> which employ IP Source Address Spoofing. P. Ferguson, D. Senie.
> May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated
> by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE)
>
> 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
> March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
> BCP0084) (Status: BEST CURRENT PRACTICE)

I surely will have a look at them.

>
> Normally, your ISP should be doing this - looks as if they are falling
> down on the concept.

Thanks a lot Moe for your advices. I have learned a lot. Too bad i
couldn't find out what the etherwhois is all about and where to get it,
but i assume it's one of yours, isn't it?

greetz,
Eric

On Mon, 12 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<dnks7p$43f$1@news.hispeed.ch>, EricT wrote:

>Moe Trin wrote:

>> In another, run the command '/sbin/arp -a' and (assuming you have
>> been using the network recently), there should be a line looking
>> something like
>>
>> - <some.ip.address> at 00:09:7b:8d:98:70 on eth0
>
>yes,
>80-219-224-1.dclient.hispeed.ch (80.219.224.1) at 00:09:7B:8D:98:70
>[ether] on eth0

That's the IP of the system you received the packet from, BUT:

>A ping will show this:
>64 bytes from 80.219.224.1: icmp_seq=1 ttl=255 time=7.01 ms

Again - this corresponds to the host being directly connected. But notice
the different ttl - here, it's 255, and the martian packet had a ttl of
126 (implying a start at 128, and two hops away).

]20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
]length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
]R [tcp sum ok] 0:0(0) ack 1704591361 win 0

So, the best guess would be that the owner of 80.219.224.1 has a system
behind it that is misconfigured.

>> The martian was showing 00:09:7b:8d:98:70 which is a Cisco - what does
>> the label say? Cisco has (as of early October) 271 different blocks of
>> MAC addresses from 00:00:0c to 00:e0:fe
>
>The MAC starts with 00:0E:9B.

[compton ~]$ etherwhois 00:0E:9B
00-0E-9B (hex) PRIVATE
000E9B (base 16)
[compton ~]$

Hmmm... Nope - just grabbed the latest OUI file - it's still listed as a
private address. Look in the ARP caches on your system (/sbin/arp -a),
and see if the address shows up as above.

>There is one more MAC shown where all the broadcasts come from, seems to
>be another router.

That infers a bridge. The fact that you saw it from a box on the net that
is one hop away, BUT the packet had a ttl indicating it had passed at least
one (most likely two) routers enroute to you

>Thanks a lot Moe for your advices. I have learned a lot. Too bad i
>couldn't find out what the etherwhois is all about and where to get it,
>but i assume it's one of yours, isn't it?

It's a dumb script that queries the OUI Database. It even has the pointer
to the source of the database:

[compton ~]$ cat /usr/local/bin/etherwhois
ETHER=`echo $1 | tr -d '\-:'`
zgrep -qi $ETHER /usr/doc/misc/MACaddresses.gz
if [ $? != "0" ] ; then
echo 'Non-existent address as of Nov 30 22:14:25 UTC 2005 OUI file'
echo ' http://standards.ieee.org/regauth/oui/oui.txt'
else
zgrep -i -B1 -A6 $ETHER /usr/doc/misc/MACaddresses.gz | sed '/^$/,/*/d'
fi
zgrep -i $ETHER /usr/doc/misc/macaddresses.txt.gz
[compton ~]$

The oui.txt file is huge - about 2.5 Megabytes, with nearly 9000 entries.
It's also a wide file - downloading it via lynx means resetting the nxterm
to a width in excess of 150 characters to avoid line wraps. The other one
files this script is looking for are a copy of an old file from Michael A.
Patton (don't know if it still exists - was http://map-ne.com/Ethernet/).
The IEEE data would be "official", while the other data has some hints of
the specific type of card - i.e. this is probably a 3C590 as opposed to a
3C900.

Old guy

Moe Trin wrote:
>>80-219-224-1.dclient.hispeed.ch (80.219.224.1) at 00:09:7B:8D:98:70
>>[ether] on eth0
>
>
> That's the IP of the system you received the packet from, BUT:
>
>
>>A ping will show this:
>>64 bytes from 80.219.224.1: icmp_seq=1 ttl=255 time=7.01 ms
>
>
> Again - this corresponds to the host being directly connected. But notice
> the different ttl - here, it's 255, and the martian packet had a ttl of
> 126 (implying a start at 128, and two hops away).
>
> ]20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
> ]length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
> ]R [tcp sum ok] 0:0(0) ack 1704591361 win 0
>
> So, the best guess would be that the owner of 80.219.224.1 has a system
> behind it that is misconfigured.
>

That's what i thought after the last posts.

>
>>The MAC starts with 00:0E:9B.
>
>
> [compton ~]$ etherwhois 00:0E:9B
> 00-0E-9B (hex) PRIVATE
> 000E9B (base 16)
> [compton ~]$
>
> Hmmm... Nope - just grabbed the latest OUI file - it's still listed as a
> private address. Look in the ARP caches on your system (/sbin/arp -a),
> and see if the address shows up as above.

No, so, it should be pretty clear, i have a bridge here connected to
the system.

>>There is one more MAC shown where all the broadcasts come from, seems to
>>be another router.
>
>
> That infers a bridge. The fact that you saw it from a box on the net that
> is one hop away, BUT the packet had a ttl indicating it had passed at least
> one (most likely two) routers enroute to you
>
>
> It's a dumb script that queries the OUI Database. It even has the pointer
> to the source of the database:
>
> [compton ~]$ cat /usr/local/bin/etherwhois
> ETHER=`echo $1 | tr -d '\-:'`
> zgrep -qi $ETHER /usr/doc/misc/MACaddresses.gz
> if [ $? != "0" ] ; then
> echo 'Non-existent address as of Nov 30 22:14:25 UTC 2005 OUI file'
> echo ' http://standards.ieee.org/regauth/oui/oui.txt'
> else
> zgrep -i -B1 -A6 $ETHER /usr/doc/misc/MACaddresses.gz | sed '/^$/,/*/d'
> fi
> zgrep -i $ETHER /usr/doc/misc/macaddresses.txt.gz
> [compton ~]$
>
> The oui.txt file is huge - about 2.5 Megabytes, with nearly 9000 entries.
> It's also a wide file - downloading it via lynx means resetting the nxterm
> to a width in excess of 150 characters to avoid line wraps. The other one
> files this script is looking for are a copy of an old file from Michael A.
> Patton (don't know if it still exists - was http://map-ne.com/Ethernet/).

It is still available.

> The IEEE data would be "official", while the other data has some hints of
> the specific type of card - i.e. this is probably a 3C590 as opposed to a
> 3C900.

Works fine, Thanks for the code and the references.

greetz,
Eric

On Thu, 15 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<dnsh61$cnm$1@news.hispeed.ch>, EricT wrote:

>Moe Trin wrote:

>> So, the best guess would be that the owner of 80.219.224.1 has a system
>> behind it that is misconfigured.
>
>That's what i thought after the last posts.

The ISP should take some interest in this, but I guess you were lucky
to even speak to someone who had heard of IP - going further probably
isn't worth the effort.

>> Look in the ARP caches on your system (/sbin/arp -a), and see if the
>> address shows up as above.
>
>No, so, it should be pretty clear, i have a bridge here connected to
>the system.

Transparent bridge - not uncommon. In theory, if you were able to figure out
what address it actually has...

[compton ~]$ whatis hping2
hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
[compton ~]$

(that might be able to let you ping the MAC address) you'd be able to
confirm this by trying to telnet to it. It will refuse, but that's fine.

>Works fine, Thanks for the code and the references.

Glad to help!!!

Old guy

Moe Trin wrote:
> The ISP should take some interest in this, but I guess you were lucky
> to even speak to someone who had heard of IP - going further probably
> isn't worth the effort.

All i did is pointing them to a possible problem. I really don't want to
force them ;-).

> Transparent bridge - not uncommon. In theory, if you were able to figure out
> what address it actually has...
>
> [compton ~]$ whatis hping2
> hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
> [compton ~]$
>
> (that might be able to let you ping the MAC address) you'd be able to
> confirm this by trying to telnet to it. It will refuse, but that's fine.

Right now, i am not able to compile hping2, nor hping3-alpha. I have to
investigate on that later on.

Thanks a lot anyway. After having hping installed, i will come back to
the post.

greetz,
Eric