Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


pptpd automatic installer - "DoS" issue (pptp_ovz_debian.sh by dadi.me)
New on LowEndTalk? Please Register and read our Community Rules.

pptpd automatic installer - "DoS" issue (pptp_ovz_debian.sh by dadi.me)

dccdcc Member, Host Rep

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?

Thanked by 2MikePT Gunter

Comments

  • MikePTMikePT Moderator, Patron Provider, Veteran

    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 ?

  • nullnull said: 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.

    Thanked by 1dcc
  • KuJoeKuJoe Member, Host Rep

    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! :)

    Thanked by 1dcc
  • NyrNyr Community Contributor, Veteran

    I would like to understand what goes trough the mind of people publishing those scripts...

    dcc said: Try ping.pe (beta)

    Awesome service, by the way!

    Thanked by 1dcc
  • NomadNomad Member

    What about using this instead?

    iptables -t nat -A POSTROUTING -s $VPN_SUBNET -o $NET_INTERFACE -j MASQUERADE

  • mikhomikho Member, Host Rep

    @KuJoe said:
    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 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.

  • KuJoeKuJoe Member, Host Rep

    @Nomad said:
    What about using this instead?

    iptables -t nat -A POSTROUTING -s $VPN_SUBNET -o $NET_INTERFACE -j MASQUERADE

    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.

  • @William said:

    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 ?

  • NomadNomad Member

    @KuJoe said:
    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.

    I see, also most sources say masquerade should be used with dynamic IP. Maybe I should update my tutorial to SNAT as well. (:

  • KuJoeKuJoe Member, Host Rep

    @nullnull said:
    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 ?

    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

  • KuJoeKuJoe Member, Host Rep

    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.

  • dccdcc Member, Host Rep

    @KuJoe said:
    nodewatch is for OpenVZ only, I wish it was open source so I could see how it determines the PPS count for a VPS.

    It is polling /proc/net/dev of each VPS.

    @KuJoe said:
    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.

    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:

    ipv4     2 tcp      6 115 SYN_SENT src=x.x.x.x dst=x.x.x.x sport=15885 dport=80 [UNREPLIED] src=x.x.x.x dst=x.x.x.x sport=80 dport=15887 mark=0 secmark=0 use=2
    ipv4     2 tcp      6 115 SYN_SENT src=x.x.x.x dst=x.x.x.x sport=8691 dport=80 [UNREPLIED] src=x.x.x.x dst=x.x.x.x sport=80 dport=8693 mark=0 secmark=0 use=2
    ...
    

    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.

  • mikhomikho Member, Host Rep

    I'm sure @KuJoe would have suspended me if it was such a problem :)

Sign In or Register to comment.