Hello everyone,
**If you share this information on your blog, forum, etc, be kind and please link back to this topic!**
Normally I'm not one to share stallion code, but after a discussion with a couple staffers we came to the conclusion that the following work must be made public for the 'greater good' and all that righteous crap.
What this does
The following blocks NTP monlist packets at the node (or router level if you're using a linux based setup), before they ever get to your customers. This means that it provides preemptive filtering, instead of after-the-fact-oh-god-my-bandwidth-bills. Stopping NTP amplification floods before the user gets them was the only way for us morally address users from being used in NTP floods be it now or later on.
What this doesn't do
This does not patch the users configuration files by any means. This is entirely node side done with iptables. You should still make it an effort to inform your customers about the dangers of using a bad version of NTP.
Lets get started!
First, you must add the following entry to your /etc/sysctl.conf. This makes it so all packets sent over a bridge (for XEN & KVM based VM's) are also filtered.
net.bridge.bridge-nf-call-iptables = 1
Once this is done, apply the changes
sysctl -p
The following rule is what does all the magic. You'll want to put this in /etc/rc.local above the exit 0 so it gets applied on reboot. You should also look at using iptables-save as well.
iptables -I FORWARD -p udp --dport 123 -m u32 --u32 "0x1C=0x1700032a && 0x20=0x00000000" -m comment --comment "NTP amplification packets" -j DROP
You can change the chain from FORWARD to INPUT in the off chance that you want to use this inside a VPS or something like that. It'd be smarter to simply ACL monlist or upgrade your version, but to each their own.
You should feel no performance impact from this rule being in place. Your node will still be smacked with the packets, but nothing will be sent out.
For obvious reasons, I won't be talking to Phill about including this in his node side SolusVM code, but if someone wishes to point him this way, they have my permission to include this.
For the greater good,
Francisco
Your friendly neighborhood hairyman
EDIT: Added the below quoted response upon request of OP. -MD
**If you share this information on your blog, forum, etc, be kind and please link back to this topic!**
Normally I'm not one to share stallion code, but after a discussion with a couple staffers we came to the conclusion that the following work must be made public for the 'greater good' and all that righteous crap.
What this does
The following blocks NTP monlist packets at the node (or router level if you're using a linux based setup), before they ever get to your customers. This means that it provides preemptive filtering, instead of after-the-fact-oh-god-my-bandwidth-bills. Stopping NTP amplification floods before the user gets them was the only way for us morally address users from being used in NTP floods be it now or later on.
What this doesn't do
This does not patch the users configuration files by any means. This is entirely node side done with iptables. You should still make it an effort to inform your customers about the dangers of using a bad version of NTP.
Lets get started!
First, you must add the following entry to your /etc/sysctl.conf. This makes it so all packets sent over a bridge (for XEN & KVM based VM's) are also filtered.
net.bridge.bridge-nf-call-iptables = 1
Once this is done, apply the changes
sysctl -p
The following rule is what does all the magic. You'll want to put this in /etc/rc.local above the exit 0 so it gets applied on reboot. You should also look at using iptables-save as well.
iptables -I FORWARD -p udp --dport 123 -m u32 --u32 "0x1C=0x1700032a && 0x20=0x00000000" -m comment --comment "NTP amplification packets" -j DROP
You can change the chain from FORWARD to INPUT in the off chance that you want to use this inside a VPS or something like that. It'd be smarter to simply ACL monlist or upgrade your version, but to each their own.
You should feel no performance impact from this rule being in place. Your node will still be smacked with the packets, but nothing will be sent out.
For obvious reasons, I won't be talking to Phill about including this in his node side SolusVM code, but if someone wishes to point him this way, they have my permission to include this.
For the greater good,
Francisco
Your friendly neighborhood hairyman
EDIT: Added the below quoted response upon request of OP. -MD
Last edited by a moderator:
