Re: OpenNTPProject.org
Rate limitings been in place for quite some time, but I believe it's only for actual time queries. This DDOS uses monlist, which isn't subject to the same rate limits. You've disabled monlist now, so I bet you'll no longer need all the rate limiting IPTables rules. (Though, you'll still see the incoming garbage for awhile, but NTPD will just discard it so it shouldn't cause problems). On 2/17/2014 2:23 AM, Pete Ashdown wrote: On 2/16/14, 7:38 PM, Brian Rak wrote: Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). Thanks for the tip, monitoring is off. I was under the impression that rate-limiting hadn't made it into a stable version of ntpd yet. Is that incorrect?
Re: OpenNTPProject.org
I’ll note that this is less than 140 chars, and therefore fits nicely in a tweet. If you’re on twitter, Signal boost the PSA, please. My edited example: https://twitter.com/wesgeorge/status/435404354242478080 Wes George On 2/16/14, 10:03 PM, Kate Gerry k...@quadranet.com wrote: add these to your ntp.conf restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery Anything below this line has been added by my company’s mail server, I have no control over it. --- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: OpenNTPProject.org
Better yet, why is your ntp server even reachable off net? Providing a public clock service needs a lot more configuration effort than a simple, default one -- as just demonstrated. (However, this is not to say that private servers should have management queries enabled.) On 2/17/2014 9:03 AM, Kate Gerry wrote: Just add these to your ntp.conf configuration then restart the service: (Works with all default installations that I've found) restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery -- Kate Gerry Network Manager k...@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -Original Message- From: Brian Rak [mailto:b...@gameservers.com] Sent: Sunday, February 16, 2014 6:38 PM To: Pete Ashdown; NANOG list Subject: Re: OpenNTPProject.org Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). $ ntpdc -c monlist -n clock.xmission.com remote address port local address count m ver code avgint lstint === 173.209.207.23342422 198.60.22.240 4727 3 3 0 0 0 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 107.0.41.2 48625 198.60.22.240264 3 4 0 5 0 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 103.7.36.3851618 198.60.22.240 4 3 3 0 8 0 173.209.207.21850616 198.60.22.240 4731 3 3 0 0 0 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 75.82.183.104123 198.60.22.240 1 3 4 0 0 0 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 65.201.33.150151 198.60.22.240393 3 2 0 3 0 124.228.119.10524687 198.60.22.240 31 3 3 0 4 0 64.191.150.130 319 198.60.22.2404494361 3 2 0 0 0 76.102.124.27123 198.60.22.240 2 3 4 0 0 0 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 63.64.124.144 26984 198.60.22.2405823740 3 4 0 0 0 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 143.112.64.21320 198.60.22.240182 1 3 0 6 0 72.235.19.125123 198.60.22.240 1 3 4 0 0 0 198.237.66.2 10471 198.60.22.240499 3 3 0 3 0 12.108.21.226357 198.60.22.240 10 1 3 0 14 0 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 67.136.57.101026 198.60.22.240243 3 3 0 5 0 64.199.163.5 306 198.60.22.240231 3 4 0 4 0 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. On 2/16/2014 1:29 PM, Pete Ashdown wrote: Just in case you run a legitimate open NTP server, this iptable stanza helps immensely: ## rate limit ntp $IPTABLES -N NTP $IPTABLES -N BLACKHOLE $IPTABLES -A BLACKHOLE -m recent --set --name ntpv4blackhole --rsource $IPTABLES -A BLACKHOLE -j DROP $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 20 --name ntpv4 --rsource -j BLACKHOLE $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name ntpv4blackhole --rsource -j DROP $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP I've found that blocking TCP destination NTP to client servers/networks blocks legitimate NTP synchronization for their clients. Although I wish they'd all just use my on-network NTP server, I can't assume they will. Does anyone have a list or source of pool and vendor (Apple/Microsoft/etc) servers so I can permit based on source before blocking based on destination port?
Re: OpenNTPProject.org
Kate Gerry writes: Just add these to your ntp.conf configuration then restart the service: (Wo= rks with all default installations that I've found) restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery KOD only works with limited in the release of NTP you are using. H
Re: OpenNTPProject.org
If somebody has contacts at Juniper who is involved in this, I'd like to get their contact information. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member!
Re: OpenNTPProject.org
Just for the reference, here is a more complete solution for Junos (took me
a while searching the web to figure it out), hope it helps someone.
policy-options {
prefix-list lo0.0-inet-address {
apply-path interfaces lo0 unit 0 family inet address *;
}
prefix-list ntp-servers {
apply-path system ntp server *;
}
}
firewall {
family inet {
filter lo-filter {
term ntp-allow {
from {
source-prefix-list {
ntp-servers;
lo0.0-inet-address;
}
protocol udp;
destination-port ntp;
}
then accept;
}
term ntp-other-discard {
from {
protocol udp;
destination-port ntp;
}
then {
discard;
}
}
term zz-accept {
then accept;
}
}
}
}
On Sun, Feb 16, 2014 at 8:42 PM, Mark Tinka mark.ti...@seacom.mu wrote:
On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg
wrote:
I was suggesting it as an alternative to just chopping
off NTP at your border. Presumably it would be a
one-off thing until Juniper issues a patch.
In Junos, applying the right filters to your router's
control plane will fix the issue. You don't need to block
NTP in the data plane.
Mark.
Re: OpenNTPProject.org
On 2/17/14, 7:26 AM, George, Wes wrote: I’ll note that this is less than 140 chars, and therefore fits nicely in a tweet. If you’re on twitter, Signal boost the PSA, please. My edited example: https://twitter.com/wesgeorge/status/435404354242478080 Wes George On 2/16/14, 10:03 PM, Kate Gerry k...@quadranet.com wrote: add these to your ntp.conf restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery I seem to recall some issue with older Windows clients using peer for synchronization. Does not having nopeer contribute to DDoS amplification?
Re: OpenNTPProject.org
Peer means it considers the other side an equal and they will mutually skew time together. If you have peer on for devices you don't consider your time servers, you're opening yourself up to problems. -Blake On Mon, Feb 17, 2014 at 9:14 AM, Pete Ashdown pashd...@xmission.com wrote: On 2/17/14, 7:26 AM, George, Wes wrote: I'll note that this is less than 140 chars, and therefore fits nicely in a tweet. If you're on twitter, Signal boost the PSA, please. My edited example: https://twitter.com/wesgeorge/status/435404354242478080 Wes George On 2/16/14, 10:03 PM, Kate Gerry k...@quadranet.com wrote: add these to your ntp.conf restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery I seem to recall some issue with older Windows clients using peer for synchronization. Does not having nopeer contribute to DDoS amplification?
Re: OpenNTPProject.org
On Feb 17, 2014, at 10:14 PM, Pete Ashdown pashd...@xmission.com wrote: Does not having nopeer contribute to DDoS amplification? No: http://www.kb.cert.org/vuls/id/348126 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: OpenNTPProject.org
Blake: Just to make sure I've got this down, listing a device as a peer in the ntp.conf file will create a situation where both devices are saying, I know what time it is and splitting the difference? Whereas when you list a device as a server, it's using that as the authority on the correct time? Example: -- # peer192.168.1.1 iburst peer192.168.1.2 iburst # server ntp.colby.edu minpoll 6 maxpoll 10 iburst server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst On 2/17/2014 10:28 AM, Blake Dunlap wrote: Peer means it considers the other side an equal and they will mutually skew time together. If you have peer on for devices you don't consider your time servers, you're opening yourself up to problems. -Blake
Monday BCP38.info reminder
Standard[1] Monday[2] Reminder[3]: DDOS attacks are bad. DDOS attacks that you can't tell where they're coming from are worse. BCP38 helps eliminate the latter, which helps markedly with the former. BCP38 is usually relatively easy to implement. Most of you people know how to do it already, and we'd really like your help in teaching the rest. http://www.bcp38.info If you know something, write something[4]. Cheers, -- jra [1] Until we move 75% up to like 95%, at least. [2] Unless I forget. [3] And apparently we need one; 3 Really Smart Guys *including Ferg* posted on BCP38 this morning, and none promoted the page. [4] Slogan stolen from a much stupider Security Theatre And Paranoia slogan -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: OpenNTPProject.org
On Feb 17, 2014, at 10:38 AM, Anthony Williams alby.willi...@verizon.com wrote: Blake: Just to make sure I've got this down, listing a device as a peer in the ntp.conf file will create a situation where both devices are saying, I know what time it is and splitting the difference? Whereas when you list a device as a server, it's using that as the authority on the correct time? That is not exactly correct. Listing a system as peer or server means that the time from that system will be used as input to the synchronization algorithm. The selection process may discard data depending on various criteria regardless of peer/server designation. The operations implications are the requirement for your own robust group of peers 3 and lots of servers. See • RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification • RFC 5906: Network Time Protocol Version 4: Autokey Specification • RFC 5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) • RFC 5908: Network Time Protocol (NTP) Server Option for DHCPv6 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenNTPProject.org
If you're trying to actually run a ntp server setup as opposed to just trusting the world, I strongly suggest reading the documentation for the service, as most people don't deploy it correctly while they think they have. At minimum, you want a cluster of 3 - 4 servers internally, configured as peers of each other, and listening to some source of time, preferably multiple like a few on the internet from the big public pool, and if you really care about time, set up a GPS receiver or two. You can definitely go farther than the above, but that's the start to doing it right. Anything short of the above is just trusting the world at large, and you'll likely happily follow along with any time skew like that thing a few months/year ago with either tick or tock. Without the above, you don't have enough sane sources to discredit bad advisers (you need 3 for a time lock). -Blake On Mon, Feb 17, 2014 at 9:38 AM, Anthony Williams alby.willi...@verizon.com wrote: Blake: Just to make sure I've got this down, listing a device as a peer in the ntp.conf file will create a situation where both devices are saying, I know what time it is and splitting the difference? Whereas when you list a device as a server, it's using that as the authority on the correct time? Example: -- # peer192.168.1.1 iburst peer192.168.1.2 iburst # server ntp.colby.edu minpoll 6 maxpoll 10 iburst server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst On 2/17/2014 10:28 AM, Blake Dunlap wrote: Peer means it considers the other side an equal and they will mutually skew time together. If you have peer on for devices you don't consider your time servers, you're opening yourself up to problems. -Blake
[NANOG-announce] ARIN+NANOG on the Road San Diego reminder
Colleagues: A reminder note for those who are, or know of someone local, to San Diego; do not delay, ARIN+NANOG on the Roadhttp://www.cvent.com/events/arin-nanog-on-the-road-san-diego/event-summary-f8a281cd63184dd1a410b894a873431b.aspxis fast approaching. We have a great program https://www.nanog.org/meetings/road2/home/agenda planned for the Tuesday, February 28, 2014 at the Handerly Hotelhttp://www.cvent.com/events/arin-nanog-on-the-road-san-diego/location-f8a281cd63184dd1a410b894a873431b.aspx. There is no fee to attend, however registration for the event is requested. We are expecting strong attendancehttp://www.cvent.com/events/arin-nanog-on-the-road-san-diego/attendees-f8a281cd63184dd1a410b894a873431b.aspx and hope to see many NANOGers next week. Be sure to add your name and registerhttp://www.cvent.com/events/arin-nanog-on-the-road-san-diego/event-summary-f8a281cd63184dd1a410b894a873431b.aspxtoday. All best. Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 ___ NANOG-announce mailing list nanog-annou...@mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Work Practices of Cyber Security Professionals
Dear Sir/Madam, I am a university researcher who is investigating the development of new, usable tools that will improve the work practices of cyber security professionals. As a first step to achieve this goal, I am undertaking a survey to gain an in-depth understanding of the day-to-day activities of cyber security professionals. The targeted participants for this survey are those who perform security related activities as a part of their job (e.g. security analysts, network administrators, penetration testers). I would be very grateful if you could spare some time and complete this short (10 minutes) survey for me. It can be accessed at the following link: http://edu.surveygizmo.com/s3/1536165/Work-Practices-of-Cyber-Security-Professionals If you have questions or concerns about this research, please contact me ( muhammad.ad...@gcu.ac.uk) or my Ph.D. supervisor Dr. Mike Just ( mike.j...@gcu.ac.uk), both at the Interactive and Trustworthy Technologies research group (http://www.ittgroup.org/), Glasgow Caledonian University, UK. Kind regards, Adnan
