0

I have a problem that my server got locked down because it was sending packets to private IPs.

My question is, what is the best solution to stop that?

Here is the log that I got from my hosting provider:

[Mon Jun  2 00:04:36 2014] forward-to-private:IN=br0 OUT=br0 
PHYSIN=vm-44487.0 PHYSOUT=eth0 MAC=78:fe:3d:47:3d:20:00:1c:14:01:4e:cd:08:00 
SRC=78.46.198.21 DST=192.168.249.128 LEN=1454 TOS=0x00 PREC=0x00 TTL=64 
ID=58859 DF PROTO=UDP SPT=41366 DPT=41234 LEN=1434 
[Mon Jun  2 00:17:15 2014] forward-to-private:IN=br0 OUT=br0 
PHYSIN=vm-44487.0 PHYSOUT=eth0 MAC=78:fe:3d:47:3d:20:00:1c:14:01:4e:cd:08:00 
SRC=78.46.198.21 DST=192.168.249.128 LEN=1456 TOS=0x00 PREC=0x00 TTL=64 
ID=52234 DF PROTO=UDP SPT=55430 DPT=41234 LEN=1436
Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
SlasherZ
  • 77
  • 1
  • 10

1 Answers1

1

Without understanding why your hosting provider does this*, you can filter this by iptables or by adjusting your routes.

If you have a private network (VPN, etc), you should add a proper route. Otherwise drop packets to these networks at the beginning of your ruleset:

iptables -N BLOCKPRIVATE
iptables -A BLOCKPRIVATE -d 192.168.0.0/16 -j DROP
iptables -A BLOCKPRIVATE -d 172.16.0.0/12 -j DROP
iptables -A BLOCKPRIVATE -d 10.0.0.0/8 -j DROP
iptables -I OUTPUT -j BLOCKPRIVATE
iptables -I FORWARD -j BLOCKPRIVATE

If you have private interfaces that do need these routes, you may also do more fine grained blocking by replacing the last two lines by this for example:

iptables -I OUTPUT -o eth0 -j BLOCKPRIVATE
iptables -I FORWARD -o eth0 -j BLOCKPRIVATE

* Your hosting provider shouldn't penalise you for this because if you don't have a private networks, your applications can by accident send packets by trying to connect to a private service. This is perfectly normal.

Janos Pasztor
  • 279
  • 2
  • 6
  • 1
    Shutting down connectivity due to sending packets to private IPs is not ok. They are supposed to send ICMP errors back in response to those packets, and in case the rate of packets is too high silently drop those, which go above the threshold. If there is sufficiently strong evidence that the host is compromised, it is a different story. In that case they need to prevent it from being used in further attacks as well as cut off the attackers connectivity to the compromised server. – kasperd Jun 02 '14 at 12:25
  • btw. the 172.16.0.0 block as by RFC 1918 has a subnet mask of `/12`, not `/20` – Thomas Jun 02 '14 at 12:57
  • Thanks, I fixed it. (You can actually file an edit to my answer, that's easier than commenting.) – Janos Pasztor Jun 03 '14 at 11:16
  • @kasperd why not? If you do not have any private IP's you need to send traffic to and your host penalises you for it, there is no reason to allow traffic towards these IP's. It's the same you would do if you had a private network, you wouldn't allow any traffic towards your private IP ranges on your public network interface. – Janos Pasztor Jun 03 '14 at 11:18
  • @Janoszen If you are not using any private IPs on your server, you should not be applying any special case to those IPs. There is a number of ways a third party could cause such a server to send packets toward private IPs. The expected behavior is that those packets follow the default path for the first few hops where a default path exist and the next router sends an ICMP error back. If the hosting provider is using private IPs in their network, the onus is on the hosting provider to ensure packets towards private addresses are treated appropriately. Usually that just means to drop them. – kasperd Jun 03 '14 at 11:29
  • @kasperd true, but in this case Hetzner penalises for sending packets to these ranges (hence the question), therefore the original poster should block them to avoid that. – Janos Pasztor Jun 03 '14 at 11:30
  • @Janoszen Sure blocking them on the server doesn't hurt. But Hetzner shouldn't require every customer to configure such rules on their servers. Hetzner haven't even included such rules in their default install images. – kasperd Jun 03 '14 at 11:41
  • @kasperd did you actually read my answer? That's the exact same thing I wrote. – Janos Pasztor Jun 03 '14 at 13:45
  • @Janoszen I am not disagreeing with your answer. I was elaborating on it and pointing out that the real reason for the blocking by Hetzner might be a bit more nuanced than what is explained in the question. – kasperd Jun 03 '14 at 13:52