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.

ajax20
  • 110
  • 1
  • 1
  • 6
  • 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 Aug 11 '14 at 07:20

2 Answers2

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
Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • 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. – Bernard Rosset Dec 05 '15 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. – Michael Hampton Dec 05 '15 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. – Bernard Rosset Dec 05 '15 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... – Bernard Rosset Dec 05 '15 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"
SvennD
  • 749
  • 5
  • 18