Have you all seen this?
Here are some suggested fixes;
Confusing writeup & title (+5, Informative)
bill_mcgonigle 3 days ago
The real story is buried under a pile of confusing crap.
Basically what's going on, for linux, is this:
You have a NIC, say eth0, with IP 184.108.40.206 . You connect to a VPN and get a tun0 with IP 220.127.116.11 .
Here is the problem: Somebody who can send packets to your NIC (wifi, unswitched ethernet, arp-poisoned switched Ethernet) can send a packet destined for 18.104.22.168 to your eth0 and it will RESPOND back out eth0 as if it had come in tun0.
net.ipv4.conf.default.rp_filter = 1
should turn that off for ipv4. They claim this setting works for now but may not under further attacks, though I don't see what they're planning to do. They also recommend iptables rules to drop appropriately. I've configured my bsd routers this way forever and performance is fine there.
At this point, they know your IP and can do what sounds like a massively luck-required attack to figure out what the remote host is that you are talking to over the network and from there your current sequence number and from there do packet injection. Remember, they're injecting on your eth0 for the address on tun0. They are penetrating some of the security the VPN should be providing but they are not hijacking your VPN - they are guessing about the traffic tunneled inside of it.
A VPN's variable packet size helps narrow the scope of the latter attack, so if you're concerned then you should see if your VPN software allows packet padding so all packets are at your MTU size. That's slower and more secure; ideally they would also all be constant-time as well.
Simple fix (+1)
dskoll 3 days ago
Suppose your VPN interface is vpn0 and your VPN IP address is 10.0.8.1. Then this should fix it:
iptables -I INPUT --destination 10.0.8.1 -i ! vpn0 -j DROP
Re: Simple fix (+4, Interesting)
dskoll 3 days ago
Ugh, I should have read the man page.
iptables -I INPUT --destination 10.0.8.1 ! -i vpn0 -j DROP