All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
pptpd automatic installer - "DoS" issue (pptp_ovz_debian.sh by dadi.me)
Hi Folks,
Those of you who run a VPS hosting business and use Nodewatch have probably seen Nodewatch suspending a customer's VPS for seemingly no reason at all.
The customer would tell you that they only got their VPS literally 5 minutes ago and installed pptp server. And yet, a few seconds later, VPS gets suspended by Nodewatch for a DoS attack (with a nice log showing a synflood attack where the VPS seems to be attacking itself).
In cases like this the customer is blaming the host, and the host is blaming Nodewatch for "false positives".
So we have finally found the culprit. It is a popular pptp autoinstaller script users use on their Debian servers. It can be downloaded from http://dadi.me/wp-content/uploads/dir/VPN/pptp_ovz_debian.sh
This script sets one incorrect iptables rule that makes a VPS "DoS" itself. Here it is:
iptables -t nat -A POSTROUTING -j SNAT --to $ip
($ip contains main VPS IP)
Long story short[er], the correct rule should be:
iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -j SNAT --to-source $ip
#10.1.0.0/24 - this subnet is what is assigned to pptp users according to this script.
Does anyone know how to contact the creator of this script?
Comments
Thank you for contributing!
As for your question, I don't know how to contact the creator of the script, tho, maybe you'll find someone here who has his contact.
But what's the deeper cause of the iptables rule that can incur a syn flood, eg. from which IP:port to which else, how ?
Loop.
Thanks for the info. A more popular script that has the same (incorrect) iptables rule here: http://www.putdispenserhere.com/pptp-debian-ubuntu-openvz-setup-script/
I went through and updated my templates with the new rule, thanks for letting us all know!
I would like to understand what goes trough the mind of people publishing those scripts...
Awesome service, by the way!
What about using this instead?
iptables -t nat -A POSTROUTING -s $VPN_SUBNET -o $NET_INTERFACE -j MASQUERADEI made a copy of the old version on Lowendguide.com when that site went offline. Even if I have it in use on multiple servers (and never noticed this behaviour) I will need to check the script.
Most providers don't have the masquerade module enabled by default, I can't remember why but it did cause an issue once in the past (CentOS 5.x) so I've never enabled it on our nodes since SNAT is a valid solution without any additional modules that I wouldn't normally be using anyways.
Strange as I spin up a KVM from DO, using the same script, tcpdump doesn't show any syn on either interface . Maybe more details or @dcc gives a proper check method ?
I see, also most sources say masquerade should be used with dynamic IP. Maybe I should update my tutorial to SNAT as well. (:
nodewatch is for OpenVZ only, I wish it was open source so I could see how it determines the PPS count for a VPS.
I've had the putdispenserhere pptp script on a VPS with a provider that uses nodewatch for years now and never been suspended O.o
Now that I think of it, I've seen problems with VPSs running pptpd and running a local DNS server (bind9). Removing bind9 fixes the issue and nodewatch stops suspending it after the next reboot.
It is polling /proc/net/dev of each VPS.
The "DoS" does not happen on every (re)boot. In our tests I'd say perhaps 1 out of 10 reboots results in such a synflood. Yes, you would often see "/bin/sh -e /etc/network/if-up.d/bind9" process running at the time of suspension as well as a bunch of SYN_SENT conntrack records to bind ports. But it is not related specifically to bind. As I type this I see another suspension on one of our nodes:
In this example, in the processes I am still seeing "/bin/sh -e /etc/network/if-up.d/bind9"
In our tests it made no difference whether or not bind was enabled on the VPS (as a service). Although we have not tried to completely removing it, perhaps we should have.
I'm sure @KuJoe would have suspended me if it was such a problem