• Announcements

    • MannDude

      Current state of vpsBoard   02/04/2017

      Dear vpsBoard members and guests:

      Over the last year or two vpsBoard activity and traffic has dwindled. I have had a change of career and interests, and as such am no longer an active member of the web hosting industry.

      Due to time constraints and new interests I no longer wish to continue to maintain vpsBoard. The web site will remain only as an archive to preserve and showcase some of the great material, guides, and industry news that has been generated by members, some of which I remain in contact to this very day and now regard as personal friends.

      I want to thank all of our members who helped make vpsBoard the fastest growing industry forum. In it's prime it was an active and ripe source of activity, news, guides and just general off-topic banter and fun.

      I wish all members and guests the very best, whether it be with your business or your personal projects.

      -MannDude

Search the Community

Showing results for tags 'ntp'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • vpsBoard
    • Announcements & Contests
    • Industry News
  • Virtual Private Servers
    • General Talk
    • Operating a VPS Business
    • Tutorials and Guides
    • Questions and Answers
  • The Lounge
    • The Pub (Off topic discussion)
    • Coding, Scripting & Programming
    • SBC, ARM, Home Automation
  • Marketplace & Reviews
    • Reviews
    • VPS Offers
    • Other Offers
    • Service Requests

Found 2 results

  1. 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
  2. Update your NTP servers

    http://support.ntp.org/bin/view/Main/SecurityNotice https://rhn.redhat.com/errata/RHSA-2014-2024.html