5

I get the following in my VPS logs

Aug 11 11:29:22 sv1254 kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:f6:f3:49:7e:0a:54:08:00 SRC=178.162.203.19 DST=255.255.255.255 LEN=131 TOS=0x00 PREC=$ PREC=0x00 TTL=128 ID=6067 PROTO=UDP SPT=17500 DPT=17500 LEN=111

Aug 11 11:29:22 sv1254 kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:f6:f3:49:7e:0a:54:08:00 SRC=178.162.203.19 DST=178.162.203.127 LEN=131 TOS=0x00 PREC=$ PREC=0x00 TTL=128 ID=6068 PROTO=UDP SPT=17500 DPT=17500 LEN=111

Neither the SRC nor the DST are mine. After googling around I found this explanation here and came to know that port 17500 has to do with dropbox's broadcasting and that I can get rid of it by disabling LANSync in the application or uninstalling it altogether. Still, I'm getting the error in my log file. Any ideas on this would be appreciated.

1
  • You could modify your iptables rules to DROP/REJECT those packets before they hit the log line, so they'd still be refused but your logs would quieten down. If that interests you, please edit the output of iptables -L -n -v --line-numbers into your question.
    – MadHatter
    Commented Aug 11, 2014 at 7:20

2 Answers 2

10

You can't "get rid of" these so easily. You're seeing this because other customers of your VPS provider are running Dropbox LAN sync.

Personally I just drop traffic from other nodes in the same subnet without bothering to log it. For example, if your VPS's IP address is 203.0.113.148 and prefix 24:

-A INPUT -s 203.0.113.0/24 ! -d 203.0.113.148 -m comment --comment "Noisy neighbors" -j DROP
4
  • In case the router propagates broadcast traffic without NAT-translation, this rule won't match. It depends if global (coming from WAN) broadcasts are acceptable to you. If they are not, you should remove the source filter. Also: any reason why the destination use a logical inversion not to my IP address rather than to the broadcast address of my network (-d 203.0.113.255 for your 203.0.113.0/24 network example)? You would then need to adapt the comment ofc. Commented Dec 5, 2015 at 14:16
  • @BernardRosset This statement makes no sense: "In case the router propagates broadcast traffic without NAT-translation, this rule won't match." What do you mean by this? Second, "not to my IP address" filters unicast packets which are intended for other hosts on the network. Commented Dec 5, 2015 at 14:20
  • If a broadcast to a superseeding network has been done and its routers forward brodcasts to subnetworks, my statement make sense, since the source address will be the originator's one, thus not belonging to the subnetwork and not matching your rule. Second, receiving packets corresponding to unicast traffic intended for another IP address is probably more than wrong if the network uses switches rather than hubs (crafted packet?). You might want to catch that and log it rather than silently discarding it. Commented Dec 5, 2015 at 14:30
  • Well you can replace 'superseeding network' with the more general 'another network', provided the router in-between is configured for broadcasts forwarding... Commented Dec 5, 2015 at 14:38
0

As to remove them from you'r log (and drop/reject/accept them) :

iptables -A INPUT -p udp --dport 17500 -j DROP -m comment --comment "dropbox lan"

You must log in to answer this question.

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