ufw log getting spammed with 224.0.0.1 every 3 minutes - how disable?

[The Cog]

If you use tcpdump -e it will show you the MAC address that sources the packets, as well as printing a decode.
The MAC address should help identify the sender.

[greg2lapa]

If you use tcpdump -e it will show you the MAC address that sources the packets, as well as printing a decode.
The MAC address should help identify the sender.

i did tcpdump but 224.0.0.1 isn't even showing in the output. And the log is still showing that 224.0.0.1 is being blocked by the firewall.
Anybody have any ideas? I'm not even sure if the router is the source as wireshark isn't exactly easy to use and understand.

[clearski]

Based on your network topology, I think you can find out who's the sender.

First of all, just erase the ufw rule which is now blocking the multicasts and reload the firewall on your host.

Then open a terminal and watch what's happening there:

sudo tail -f /var/log/ufw.log

Meanwhile, physically remove the cables that connect any other LAN devices to your router's ports (or switches or whatever intermediary devices you might have), leaving just your host connected. If you have any wireless devices that share this network at your location, turn all of them off. TV's, tablets, phones etc. Leave the WAN interface active, so your topology is now: HOST - ROUTER - WAN. Just two devices and two cables.

Check your log. Do you still receive multicasts? If the answer is Yes, just remove the cable from the WAN interface. Now it's between your host and your router. What does the log say?

If the answer is No (with or without the WAN interface), just add devices (turn them on and connect them to your network), one at a time, until you discover who's the sender.

In my case, it was the router sending multicast data to all my hosts. As the firmware was proprietary, I just blocked the sender with a simple ufw rule. The logs are silent now.

More about Multicast communication here:

http://www.firewall.cx/networking-to...multicast.html

[Update]

It seems that inside this document, from page 6 to 8, is an explanation of what's going on.

http://www4.ncsu.edu/~rhee/clas/csc4...cast-part1.pdf

It's probably the the router, trying "to update its knowledge of the group members present on each network interface" (hints: 224.0.0.1, IGMP, TTL: 1).

[greg2lapa]

Based on your network topology, I think you can find out who's the sender.

First of all, just erase the ufw rule which is now blocking the multicasts and reload the firewall on your host.

Then open a terminal and watch what's happening there:

sudo tail -f /var/log/ufw.log

As the firmware was proprietary, I just blocked the sender with a simple ufw rule. The logs are silent now.

When you say you blocked it, this prevents the logs from showing the traffic, but the traffic is still occurring on the network? Or did you block the traffic from even being on the network? I am wondering if there is a way to disable the traffic at its origin so that the traffic is not occurring.

[clearski]

When you say you blocked it, this prevents the logs from showing the traffic, but the traffic is still occurring on the network? Or did you block the traffic from even being on the network? I am wondering if there is a way to disable the traffic at its origin so that the traffic is not occurring.

Initially, I just blocked the traffic from being recorded in the firewall log file. Yesterday, after a few months, I removed the rule which blocked the multicast frames / datagrams to reach the interface because I wanted to capture some data and have a look at it. To my surprise, I had no entry. I checked the log now and it's still empty. It might be a service that I disabled on the router and was sending multicast data. I don't know... However, first you have to make sure about what device is the sender. In my case, I knew it was the LAN interface on the router that was used.

[bashiergui]

Just curious, what's your concern with the router sending multicast packets that your computer is dropping?

[Doug S]

In my case it is my ISP that sends the annoying packets. I have a specific iptables rule to DROP the packets without logging and a more generic one later on for anything else, but with logging.
Here is a segment:

doug@doug-64:~$ sudo iptables -v -x -n -L
[sudo] password for doug:
Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
   27169  2164555 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  108273  3465000 DROP       all  --  *      *       0.0.0.0/0            224.0.0.1
       6      312 LOG        tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID LOG flags 0 level 6 prefix "IINVALID:"
    1083   576045 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW LOG flags 0 level 6 prefix "NEW TCP no SYN:"
    1083   576045 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW reject-with icmp-port-unreachable
 2726300 211958179 ACCEPT     all  --  eth0   *       192.168.111.0/24     0.0.0.0/0
       0        0 LOG        all  --  eth1   *       192.168.0.0/16       0.0.0.0/0            LOG flags 0 level 6 prefix "Sub192:"
       0        0 DROP       all  --  eth1   *       192.168.0.0/16       0.0.0.0/0
       0        0 LOG        all  --  eth1   *       10.0.0.0/8           0.0.0.0/0            LOG flags 0 level 6 prefix "Sub10:"
       0        0 DROP       all  --  eth1   *       10.0.0.0/8           0.0.0.0/0
       0        0 LOG        all  --  eth1   *       172.16.0.0/12        0.0.0.0/0            LOG flags 0 level 6 prefix "Sub172:"
       0        0 DROP       all  --  eth1   *       172.16.0.0/12        0.0.0.0/0
       0        0 LOG        all  --  eth1   *       240.0.0.0/5          0.0.0.0/0            LOG flags 0 level 6 prefix "Sub240:"
       0        0 DROP       all  --  eth1   *       240.0.0.0/5          0.0.0.0/0
       0        0 LOG        all  --  eth1   *       224.0.0.0/4          0.0.0.0/0            LOG flags 0 level 6 prefix "Sub224:"
       0        0 DROP       all  --  eth1   *       224.0.0.0/4          0.0.0.0/0
...

I do not use ufw and do not know how to do the same with it.

[clearski]

In my case it is my ISP that sends the annoying packets. I have a specific iptables rule to DROP the packets without logging and a more generic one later on for anything else, but with logging.

Hello, Doug!

Since the multicast range 224.0.0.0 - 224.0.0.255 is reserved for local link addresses, what's the relationship between the IP address on the router's interface to your provider and the IP address of your provider (default-gateway)? Are they on the same subnet?

[Doug S]

Hello, Doug!

Since the multicast range 224.0.0.0 - 224.0.0.255 is reserved for local link addresses, what's the relationship between the IP address on the router's interface to your provider and the IP address of your provider (default-gateway)? Are they on the same subnet?

Really good question, one that is testing my memory. How did I originally figure this out? My ISP is telus and they seem to use the 10.0.0.0 non-public subnet for some internal stuff. My router is my externally facing Ubuntu server box and I have never been able to figure out the relationship between my external static IP address and the addresses on the 10.0.0.0 subnet that telus uses. These are examples of what I get on my external interface from the 10.0.0.0 subnet:

2014-05-13 11:53:29.748213 IP 10.197.248.13 > 224.0.0.1: igmp query v2
2014-05-13 11:53:59.746924 IP 10.197.248.13 > 224.0.0.1: igmp query v2
2014-05-13 11:54:29.746636 IP 10.197.248.13 > 224.0.0.1: igmp query v2
2014-05-13 11:54:59.746385 IP 10.197.248.13 > 224.0.0.1: igmp query v2
...
2014-05-13 12:01:02.087450 IP 10.0.0.138.28228 > 239.255.255.250.1900: UDP, length 274
2014-05-13 12:01:02.088358 IP 10.0.0.138.28228 > 239.255.255.250.1900: UDP, length 274
2014-05-13 12:01:02.095711 IP 10.0.0.138.28229 > 239.255.255.250.1900: UDP, length 285
2014-05-13 12:01:02.096663 IP 10.0.0.138.28229 > 239.255.255.250.1900: UDP, length 285
...
2014-06-09 11:54:10.767030 IP 10.31.202.1 > 173.180.45.4: ICMP time exceeded in-transit, length 38
2014-06-09 11:54:10.853533 IP 10.31.202.1 > 173.180.45.4: ICMP time exceeded in-transit, length 38
2014-06-09 11:54:24.526836 IP 10.31.202.1 > 173.180.45.4: ICMP time exceeded in-transit, length 38
2014-06-09 11:54:24.710153 IP 10.31.202.1 > 173.180.45.4: ICMP time exceeded in-transit, length 38

Hmmm... As a side note, I better look into those time exceeded things, as my server seems to have sent packets with a TTL of 1. With a TTL of just 2, I get time exceeded replies from "real" IP addresses. Anyway, I digress...

Did this help, or confuse things more?

[clearski]

These are examples of what I get on my external interface from the 10.0.0.0 subnet:

2014-05-13 11:53:29.748213 IP 10.197.248.13 > 224.0.0.1: igmp query v2
2014-05-13 11:53:59.746924 IP 10.197.248.13 > 224.0.0.1: igmp query v2
...
2014-05-13 12:01:02.087450 IP 10.0.0.138.28228 > 239.255.255.250.1900: UDP, length 274
...
2014-06-09 11:54:10.767030 IP 10.31.202.1 > 173.180.45.4: ICMP time exceeded in-transit, length 38

Same here. My ISP is using an address from the 10.0.0.0/8 range. When I connect using PPPoE, they automatically assign me a routable IP address.

The queries in your logs show both link local (224.0.0.1) and globally scoped (239.255.255.255) multicast addresses. As they say that globally scoped can be used to multicast data across the Internet, the query might have come from a point behind the first ISP router, but I'm not sure I understand exactly how it works, so it's just a guess.

I think this could explain the link local requests:

"Multicast routers use IGMP to learn which groups have members on each of their attached physical networks" (https://www.rfc-editor.org/rfc/rfc2236.txt)

"224.0.0.1 is assigned to the permanent group of all IP hosts (including gateways).This is used to address all multicast hosts on the directly connected network." (http://tools.ietf.org/html/rfc1112)

It should be the ISP's router trying to locate multicast members for some reason. I still don't understand how a non routable and a public address can be on the same logical network, however.

Hmmm... As a side note, I better look into those time exceeded things, as my server seems to have sent packets with a TTL of 1. With a TTL of just 2, I get time exceeded replies from "real" IP addresses. Anyway, I digress...

Did this help, or confuse things more?

What is the destination of the packets with TTL 1? I am curious. As far as I know, communication using link local addressing is set a TTL to 1 because the services are not forwarded by the routers.