7

We have a /28 block from our ISP. Let's say 1.1.1.240/28 with a gateway of 1.1.1.241. We are getting martian packets from another customer over at 1.1.1.214. They are sending broadcasts to 1.1.1.255. Should we be getting those packets? I don't understand broadcasting in this scenario.

syslog message

martian source 1.1.1.255 from 1.1.1.214, on dev eth0
ll header: ff:ff:ff:ff:ff:ff:00:XX:f3:XX:69:ad:08:00

network interface:

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:1.1.1.243  Bcast:1.1.1.255  Mask:255.255.255.240
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15161982 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1627243 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1028191733 (1.0 GB)  TX bytes:140279903 (140.2 MB)
          Memory:fbde0000-fbe00000

Or maybe the interface is misconfigured? The Bcast is listed there as 1.1.1.255. If this is normal behavior I don't think the kernel should be spewing hundreds of these to syslog every minute.

UPDATE

These packets are constantly coming in 2-3 per second. I have captured them and they UDP src/dst port 15001: 10:00:91:13:00:00:39:22:23:02:00:00:00:00:00:01:3c:62:65:61:63:6f:6e:2f:3e

Improve this question

1 Answer 1

Reset to default
8

That's scary - smells like your ISP isn't isolating customers' broadcast domains, and this other customer simply has their netmask misconfigured as /24.

If this is the case, then it's a pretty serious security risk, as they can effectively knock your devices offline or get traffic bound for your systems, either accidentally or maliciously.

You can test by ARPing for the other customer's system (which could be a little tricky without a reconfiguration of your router's interface), or just watching ARP on the line and seeing if you're getting ARP requests for their subnet.

If the broadcast domains are indeed joined, you need to have a heart to heart with your ISP.

Improve this answer
5
  • Hmm, I'm trying to monitor the ARP traffic on the interface using tcpdump 'arp' -e -i eth0 -n -p -t -vv . not seeing any requests for anything other than whats in our /28. I toggle on and off the martian logging on the interface to be sure it's still going on, and indeed it is.
    – Jeremy
    Feb 6, 2014 at 4:40
  • @Jeremy Since their system's passing traffic all the time, ARP's probably not needed between their router and the ISP very often.. maybe try pinging something else in their network range (.215 or something) from some other ISP uplink to force an ARP from the ISP's router for that address?
    – Shane Madden
    Feb 6, 2014 at 5:34
  • The router is ISP managed, so I'm limited there. I tried spoofing a ping: hping3 --icmp -a 1.1.1.215 1.1.1.214 but didn't get any ARP requests. (.214 pings with no spoofed address). I wonder if that's any good reason to not worry about it. I also tried pinging .215 from a different ISP with the same results.
    – Jeremy
    Feb 6, 2014 at 16:46
  • @Jeremy Hmm, yeah, sounds like you aren't sharing a broadcast domain, which is good. Maybe the ISP just has some novel filtering which is missing these specific packets? One other thing to check on if you can would be to capture one of these martian packets to get a look at what it actually is - are they coming in regularly enough that you might be able to capture one?
    – Shane Madden
    Feb 6, 2014 at 17:01
  • My question has been answered, which is basically "this should not happen." Thanks for the help. Sending it up the flag pole.
    – Jeremy
    Feb 6, 2014 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .