224.0.0.1 in ufw logs

[histographik]

I have a bare bones ubuntu oneiric installation running on a virtual server.

I have disabled ipv6 and implemented some security measures in sysctl.conf:

/etc/sysctl.conf

# Kernel options 
kernel.printk = 3 4 1 3  

# Disable Ping 
net.ipv4.icmp_echo_ignore_all = 1  

# Spoof protection (reverse-path filter) 
net.ipv4.conf.default.rp_filter = 1 
net.ipv4.conf.all.rp_filter = 1  

# Enable TCP SYN Cookie Protection 
net.ipv4.tcp_syncookies = 1  

# Do not accept ICMP redirects (prevent MITM attacks) 
net.ipv4.conf.all.accept_redirects = 0 

# Do not send ICMP redirects (we are not a router) 
net.ipv4.conf.all.send_redirects = 0  

# Do not accept IP source route packets (we are not a router) 
net.ipv4.conf.all.accept_source_route = 0 

# Log Martian Packets 
net.ipv4.conf.all.log_martians = 1  

# Disable IPV6 
net.ipv6.conf.all.disable_ipv6 = 1 
net.ipv6.conf.default.disable_ipv6 = 1 
net.ipv6.conf.lo.disable_ipv6 = 1

I have ufw setup in the following way:

# sudo ufw status verbose

Logging: on (low) Default: deny (incoming), allow (outgoing) 
New profiles: skip  
22/tcp      LIMIT IN      Anywhere

When checking logs i see the following block:

#sudo tailf /var/log/ufw.log

[UFW BLOCK] IN=eth0 OUT= MAC=* SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

I did the following:

# sudo ifconfig -multicast

Then i checked the ufw logs again and the block above was still being logged.

The blocking action is good, i just don't know what it is that is causing it!

I asked my virtual server provider what this ufw log meant and they said they didn't know!

Can anyone tell me what this block represents?

[UFW BLOCK] IN=eth0 OUT= MAC=* SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

I will be using this virtual server to run a web server with drupal so i want to make sure i understand the setup before i install the lamp server.

I just need to understand what is being blocked and why. The logs show this blocking action every few seconds - continuously.

Anyone?

[Doug S]

Have a look here: http://tldp.org/HOWTO/Multicast-HOWTO-2.html
It is a multicast address. I block it also, but rarely, if ever, do I actually get any hits on the block.
I hope this helps.

[histographik]

Have a look here: http://tldp.org/HOWTO/Multicast-HOWTO-2.html
It is a multicast address. I block it also, but rarely, if ever, do I actually get any hits on the block.
I hope this helps.

Thanks for the info Doug, read through it.

Could you tell me how you explicitly blocked it yourself?

I have tried:

sudo ufw insert 1 deny to 224.0.0.1 (trying to block outgoing to 224.0.0.1)

But the logs show no change.

Perhaps there is a more robust way of disabling multicast routing, perhaps in /etc/network/interfaces?

[Doug S]

I do not use ufw, so do not know how with it. I only use iptables directly, here is the segment for the INPUT chain (for all undesireable sub-nets):

# remote interface, RFC 1918, private internet packets, and some others.
#
$IPTABLES -A INPUT -i $EXTIF -s 192.168.0.0/16 -d $UNIVERSE -j LOG --log-prefix "Sub192:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 192.168.0.0/16 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 10.0.0.0/8 -d $UNIVERSE -j LOG --log-prefix "Sub10:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 10.0.0.0/8 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 172.16.0.0/12 -d $UNIVERSE -j LOG --log-prefix "Sub172:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 172.16.0.0/12 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 240.0.0.0/5 -d $UNIVERSE -j LOG --log-prefix "Sub240:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 240.0.0.0/5 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 224.0.0.0/4 -d $UNIVERSE -j LOG --log-prefix "Sub224:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 224.0.0.0/4 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 169.254.0.0/16 -d $UNIVERSE -j LOG --log-prefix "Sub169:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 169.254.0.0/16 -d $UNIVERSE -j DROP

And I have similar in the FORWARD table (My server is also my router) (small portion only shown):

$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 224.0.0.0/4 -j LOG --log-prefix "F224:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 224.0.0.0/4 -j DROP
$

[histographik]

Many thanks i'll translate these rules into ufw-speak and see if this works.

[histographik]

I don't seem to be having any joy with this. No amount of dropping gets rid of the above log entry. As a newbie i guess i have lots more reading to understand what is happening here!!

Here's another interesting point: The supplier of the server is 6sync.

Nov 26 21:56:01 monash kernel: [97526.759532] 
[UFW ALLOW] 
IN= 
OUT=eth0 
SRC=204.62.15.XXX (MY IP ADDRESS)
DST=204.62.14.YYY  (NOT MY IP ADDRESS!!)
LEN=72 TOS=0x00 
PREC=0x00 
TTL=64 
ID=58369 
DF 
PROTO=UDP 
SPT=45429 
DPT=53 
LEN=52

What does this mean? It looks like the my virtual server (204.62.15.XXX) is initiating an outgoing packet to another server in the 6sync group (204.62.14.YYY).

As a newbie I am probably reading this wrong?? Could anyone point me to a good read on understanding iptable/ufw logs?

I use dyn.com for name resolution not 6sync. The destination port is 53 (DNS).

Is the above a legitimate transaction for a server locked down with only an ssh port open and public/private keys used to login?

[JKyleOKC]

It looks as if your virtual server is sending a packet out to another address, and receiving a multicast reply that is being blocked and logged. This may be related to your use of dyn.dns; all of the dynamic dns services presumably must maintain a dialog with your machine in order to detect any change of its IP address and correct their own tables. I use a different service myself so cannot say for sure how dyn.dns handles things, but a multicast response seems reasonable.

The only way I know to tell for sure what is going on is to run "wireshark" on your system and examine the actual packets. The wireshark program can interpret packet contents for you and make things quite a bit more clear. It's in the repositories...

[Doug S]

It looks as though your 224.0.0.1 log entiers are because the UFW iptable rule blocked the packet, so I think that is doing what you want (and, sorry I perhaps added confusion yesterday, by not reading your original post thoroughly). It lookas though the packets are incoming, perhaps somehow related to your hosting service.
Yes it does look as though your server is doing a DNS inquiry to 6 sync.
There is a very good thread that Dangertux wrote here: http://ubuntuforums.org/showthread.php?t=1876124
There are also some good references at the end of the DNS chapter in the Ubuntu server guide. (I prefer the PDF version)
Oh, I see a reply from JKyleOKC was added. And yes, I agree it is proably time to use wireshark to gain further insight.

[histographik]

Many thanks for the answers Doug S & JKyleOKC. Will investigate wireshark. The links were very helpful. I see light at the end of the tunnel...

[The Cog]

If you can't get wireshark to work (no reason why you shouldn't, except that it needs root privileges to perform packet capture) the tcpdump will work.
Like this:

tcpdump -p -w capture.cap host 224.0.0.1

Your first post says that the log says PROTO=2. Protocol 2 is IGMP - Internet Group Management Protocol. My guess is that it's the local router asking if there are any hosts interested in receiving multicasts - nothing to worry about. Tcpdump (without the -w option) will possibly print enough to tell you. Failing that, opening the capture file in wireshark will tell you.