Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn st...@ntp.org wrote: David Lord writes: I have restrict -4 limited kod nomodify notrap nopeer noquery I've not checked most recent docs but thought limited was needed for kod. It is. There were also some posts indicating that kod could be counter productive leading to self inflicted DOS. I'd love to learn more about this. I can only see this happening if one has a seriously broken client. You need to understand that the client is the attacker and that he can make his software as broken as he likes. So your server needs to be written and configured in such a way that even a broken client can not damage anything. kod is useless. it is not implemented in the majority of clients, and some broken clients react in a counter-productive way. The well-behaved client that implements kod does not need it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Is there not a case for issuing 4.2.8 now, warts and all, and advising the world of the upgrade? 4.2.7p410 is working well on all my systems, and 4.2.7p411 is only a documentation update. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
David Taylor wrote: Is there not a case for issuing 4.2.8 now, warts and all, and advising the world of the upgrade? 4.2.7p410 is working well on all my systems, and 4.2.7p411 is only a documentation update. There's a very good case for doing so, the only formal stopper is the current list of blocking bugs! Some of us are trying to cut this down, then it is up to Harlan to declare whatever remains as not critical enough to keep the blocking status and demote them, and then he will stick a fork in it and declare it done. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn st...@ntp.org wrote: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. The data to report is not what ntpd connects to, but what is connecting to ntpd. Even when there is no server or anything else configured, others could still poll the machine and incoming connect data will accumulate. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On Wed, Jan 15, 2014 at 08:35:32PM +, Rob wrote: William Unruh un...@invalid.ca wrote: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. That only becomes meaningful when ntpd starts to actually work without config file. Of course that would be possible, but I don't think it is reality today. Or is it, in the latest versions? Servers can be now specified on the command line, so you don't really need a config file to have ntpd doing something useful. The following command seems to work as expected. ntpd -c /dev/null 0.pool.ntp.org -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn st...@ntp.org wrote: So please complain as much as you want. Please volunteer as much as you want. Please financially support Network Time as much as you want. I also invite folks to pay attention to what they want to get, and see how what they are and are not doing correlates to what they are and are not getting. In case you are not noticing it yourself (and it looks like it): Lots of people refrain from volunteering with the ntpd project because of the harsh and offensive attitude towards any change suggestions. I would not want to waste my time to convice people in your project that a correct example config file would be a boon to the project, and find team members against me that try to explain that it is not their business to know what the distributors want or what the users want. I have seen similar debates around change suggestions in the algorithms of the clock synchronization itself. Finding volunteers will probably be quite difficult. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Rob writes: Harlan Stenn st...@ntp.org wrote: So please complain as much as you want. Please volunteer as much as you want. Please financially support Network Time as much as you want. I also invite folks to pay attention to what they want to get, and see how what they are and are not doing correlates to what they are and are not getting. In case you are not noticing it yourself (and it looks like it): Lots of people refrain from volunteering with the ntpd project because of the harsh and offensive attitude towards any change suggestions. I'd sincerely appreciate seeing some concrete examples. I would not want to waste my time to convice people in your project that a correct example config file would be a boon to the project, and find team members against me that try to explain that it is not their business to know what the distributors want or what the users want. Then you've not been paying attention. I have seen similar debates around change suggestions in the algorithms of the clock synchronization itself. This particular issue should be resolved after the major rewrite planned for the next major release, as that will allow folks to run the stock synch algorithms or ones of their choosing. Finding volunteers will probably be quite difficult. It has been, and I'm pretty sure if we opened the gates wider the result of that would be something pretty unpleasant. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Greg Troxel g...@ir.bbn.com wrote: Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org Debian seems to ship the following (minus comments and disabled stuff): driftfile /var/lib/ntp/ntp.drift server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 And that seems to work quite well in practice. /ralph ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn wrote: Greg Troxel writes: Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. We do supply some sample config files in the conf/ directory. I don't know that anybody is really happy about them. I've just looked at these in current ntp-dev and found that there are only config files from some test machines at udel, with very specific configuration options. So these are not good examples for I am disinclined to distribute files like that because they stick around for far too long. I don't even believe those config files are still appropriate for current versions of ntpd and real configurations of current test machines, so I think they could simply be removed, at least from the published tarballs. On the other hand, if I look at the ntp.conf files shipped e.g. with different Linux distros I can see that most configurations try to achieve the same goal, e.g. make information available via mode 6 or mode 7 packets only available to localhost. As mentioned in some other post here, the task to set up a safe default configuration has to be done multiple times by different folks at different OS vendors. In fact the maintenance effort for OS vendors would be much easier if the original NTP tarball was shipped with a safe configuration. Otherwise the safety of a default configuration depends strongly on the level of knowledge the NTP package maintainer of a particular OS vendor has. So if ntpd should not be shipped with a sample config file then I agree the default config file to be maintained by the OS vendors should be as simple as possible to yield a safe configuration, as someone else has already mentioned. For example, if the default restrictions built into ntpd would be to allow monitoring requests only from local host then no restrict statements might be required in a simple default configuration file. OS vendors could just provide a file with some default servers, like it is actually common practice for some Linux distros. E.g. Fedora and Debian use pool configurations like server 0.fedora.pool.ntp.org iburst or server 0.debian.pool.ntp.org iburst with current stable ntpd. Sophisticated users who want some extra configuration could add some lines similar as they already have to do right now, e.g. if they want to use some specific refclock. It should not be too hard to change ntpd such that the default restrictions match what most admins would set up anyway. And 4.2.8 would be a good step for such change, similar as the default logging has changed from 4.2.4 to 4.2.6. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Ralph Aichinger writes: Greg Troxel g...@ir.bbn.com wrote: Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org Debian seems to ship the following (minus comments and disabled stuff): driftfile /var/lib/ntp/ntp.drift server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 And that seems to work quite well in practice. Those 'kod' directives don't do anything, and I think it would be better if it was: pool 0.debian.pool.ntp.org iburst instead, and I'd have to look up when the 'pool' directive was put in there. And I know I'm tweaking nits. The issue is when does it cross the line between nitpicking and making a significant improvement, statistically or otherwise. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Martin, I'm OK including updated ntp.conf files in the distribution, for 4.2.8 even. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn wrote: Martin, I'm OK including updated ntp.conf files in the distribution, for 4.2.8 even. How about changing the built-in default restrictions in in 4.2.8 so that they match what is commonly used nowadays, without having to specify the restrict lines? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn wrote: Ralph Aichinger writes: Debian seems to ship the following (minus comments and disabled stuff): driftfile /var/lib/ntp/ntp.drift server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 And that seems to work quite well in practice. Those 'kod' directives don't do anything, and I think it would be better if it was: pool 0.debian.pool.ntp.org iburst I bet the server options for pool servers are in there because this was used in earlier versions before the pool keyword was introduced, and it still works. instead, and I'd have to look up when the 'pool' directive was put in there. IIRC this is supported in 4.2.6, but has not been supported in 4.2.4p8 and earlier. If the ntp.conf file shipped with a particular OS has been initially created a long time ago and always been updated for newer NTP versions then I'm not surprised to see this. I'm sure a single sample ntp.conf file shipped with the NTP tarball, which is checked/updated before an NTP release to reflect enhancements like the pool command would definitely help. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Martin Burnicki martin.burni...@meinberg.de wrote: I bet the server options for pool servers are in there because this was used in earlier versions before the pool keyword was introduced, and it still works. instead, and I'd have to look up when the 'pool' directive was put in there. IIRC this is supported in 4.2.6, but has not been supported in 4.2.4p8 and earlier. If the ntp.conf file shipped with a particular OS has been initially created a long time ago and always been updated for newer NTP versions then I'm not surprised to see this. Sure. When the ntp.conf would have been included in the ntpd distribution and would only have required small patches like including the distributor name in the config lines for pool servers, the distributor would have archived those as a local patch and any changes/updates in the ntp.conf would appear in the packaged versions as well. It is only because all the work of creating an ntp.conf has been placed on the distributor that those distributors do not update it for every change or feature in the program. They don't have the resources to track all changes in all packages they distribute. I'm sure a single sample ntp.conf file shipped with the NTP tarball, which is checked/updated before an NTP release to reflect enhancements like the pool command would definitely help. Indeed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On Thu, Jan 16, 2014 at 02:28:32PM +0100, Martin Burnicki wrote: Harlan Stenn wrote: pool 0.debian.pool.ntp.org iburst I bet the server options for pool servers are in there because this was used in earlier versions before the pool keyword was introduced, and it still works. instead, and I'd have to look up when the 'pool' directive was put in there. IIRC this is supported in 4.2.6, but has not been supported in 4.2.4p8 and earlier. If the ntp.conf file shipped with a particular OS has been initially created a long time ago and always been updated for newer NTP versions then I'm not surprised to see this. IIRC the pool command in 4.2.6 uses quite a lot of servers, which probably is not an acceptable use of pool.ntp.org. I think it was improved later in 4.2.7. The page about recommended configuration doesn't mention it yet. http://www.pool.ntp.org/en/use.html Vendors should be careful with the pool command. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Miroslav Lichvar wrote: On Thu, Jan 16, 2014 at 02:28:32PM +0100, Martin Burnicki wrote: Harlan Stenn wrote: pool 0.debian.pool.ntp.org iburst I bet the server options for pool servers are in there because this was used in earlier versions before the pool keyword was introduced, and it still works. instead, and I'd have to look up when the 'pool' directive was put in there. IIRC this is supported in 4.2.6, but has not been supported in 4.2.4p8 and earlier. If the ntp.conf file shipped with a particular OS has been initially created a long time ago and always been updated for newer NTP versions then I'm not surprised to see this. IIRC the pool command in 4.2.6 uses quite a lot of servers, which probably is not an acceptable use of pool.ntp.org. I think it was improved later in 4.2.7. The page about recommended configuration doesn't mention it yet. http://www.pool.ntp.org/en/use.html Vendors should be careful with the pool command. Indeed. Personally I'm not using the pool command very often since in most cases I have to deal with specific refclocks. I'm biased. ;-) Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: I bet the server options for pool servers are in there because this was used in earlier versions before the pool keyword was introduced, and it still works. instead, and I'd have to look up when the 'pool' directive was put in there. IIRC this is supported in 4.2.6, but has not been supported in 4.2.4p8 and earlier. If the ntp.conf file shipped with a particular OS has been initially created a long time ago and always been updated for newer NTP versions then I'm not surprised to see this. Sure. When the ntp.conf would have been included in the ntpd distribution and would only have required small patches like including the distributor name in the config lines for pool servers, the distributor would have archived those as a local patch and any changes/updates in the ntp.conf would appear in the packaged versions as well. It is only because all the work of creating an ntp.conf has been placed on the distributor that those distributors do not update it for every change or feature in the program. They don't have the resources to track all changes in all packages they distribute. I completely understand and agree. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-16, Greg Troxel g...@ir.bbn.com wrote: Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, The majority use case for ntpd is to synchronize your clock to UTC (i.e. a leaf-node client). So an ntpd ought to have the following defaults: driftfile /path/to/ntp.drift pool pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 This would enable the majority use case without the need for a configuration file. while being usable as a s2/s3 to other nearby nodes. Operation as a LAN time server is probably a secondary use case. But the defaults listed above would also enable that usage. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. This. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Steve Kostecke wrote: On 2014-01-16, Greg Troxel g...@ir.bbn.com wrote: Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, The majority use case for ntpd is to synchronize your clock to UTC (i.e. a leaf-node client). So an ntpd ought to have the following defaults: driftfile /path/to/ntp.drift pool pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 This would enable the majority use case without the need for a configuration file. hi I have restrict -4 limited kod nomodify notrap nopeer noquery I've not checked most recent docs but thought limited was needed for kod. There were also some posts indicating that kod could be counter productive leading to self inflicted DOS. David while being usable as a s2/s3 to other nearby nodes. Operation as a LAN time server is probably a secondary use case. But the defaults listed above would also enable that usage. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. This. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 1/16/2014 3:45 PM, Steve Kostecke wrote: On 2014-01-16, Greg Troxel g...@ir.bbn.com wrote: Harlan Stenn st...@ntp.org writes: The majority use case for ntpd is to synchronize your clock to UTC (i.e. a leaf-node client). So an ntpd ought to have the following defaults: driftfile /path/to/ntp.drift pool pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 This would enable the majority use case without the need for a configuration file. I just tried that with 4.2.7p381 and it failed to get any servers. I added: restrict source and it still failed. I commented out the first two restrict lines and then it worked. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
David Lord writes: I have restrict -4 limited kod nomodify notrap nopeer noquery I've not checked most recent docs but thought limited was needed for kod. It is. There were also some posts indicating that kod could be counter productive leading to self inflicted DOS. I'd love to learn more about this. I can only see this happening if one has a seriously broken client. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-16, David Lord sn...@lordynet.org wrote: Steve Kostecke wrote: [---=| Quote block shrinked by t-prot: 25 lines snipped |=---] [snip: sample defaults] I have restrict -4 limited kod nomodify notrap nopeer noquery I've not checked most recent docs but thought limited was needed for kod. There were also some posts indicating that kod could be counter productive leading to self inflicted DOS. This is case of not being able to see the forest for the trees. The key issue here is having useful defaults which deliver the majority use case. i.e.: 1. A path/name to store the drift.file 2. A time source (e.g. 'pool pool.ntp.org') 3. Default permissions allowing only rate limited time service 4. Localhost permissions allowing debugging -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-16, Miroslav Lichvar mlich...@redhat.com wrote: IIRC the pool command in 4.2.6 uses quite a lot of servers, which probably is not an acceptable use of pool.ntp.org. I think it was improved later in 4.2.7. The page about recommended configuration doesn't mention it yet. http://www.pool.ntp.org/en/use.html Vendors should be careful with the pool command. I use the ntp-dev pool command here and see 8 remote time servers in my peers billboard. If this is considered to be too many then we should fix ntpd rather than depreccating a useful configration option. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-16, Steve Kostecke koste...@ntp.org wrote: On 2014-01-16, Greg Troxel g...@ir.bbn.com wrote: Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, The majority use case for ntpd is to synchronize your clock to UTC (i.e. a leaf-node client). So an ntpd ought to have the following defaults: driftfile /path/to/ntp.drift pool pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 This would enable the majority use case without the need for a configuration file. Then this should probably be made the default (all except the second perhaps) with the ability to override the defaults (NOt sure how you would override a restric default mind you) while being usable as a s2/s3 to other nearby nodes. Operation as a LAN time server is probably a secondary use case. But the defaults listed above would also enable that usage. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. This. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Greg Troxel wrote: Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org # IMHO, More like: restrict -4 default limited kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 default limited kod nomodify notrap nopeer noquery restrict ::1 restrict 224.0.1.1 mask 255.255.255.255 nomodify restrict source nomodify pool pool.ntp.org iburst preempt -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 27/12/13 10:24, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, David Woolley wrote: On 27/12/13 10:24, Rob wrote: There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. Upgrade _or_ use noquery _or_ disable monitor Information at http://support.ntp.org/security -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Steve Kostecke koste...@ntp.org wrote: On 2014-01-15, David Woolley wrote: On 27/12/13 10:24, Rob wrote: There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. Upgrade _or_ use noquery _or_ disable monitor Information at http://support.ntp.org/security Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
William Unruh un...@invalid.ca wrote: On 2014-01-15, Steve Kostecke koste...@ntp.org wrote: On 2014-01-15, David Woolley wrote: On 27/12/13 10:24, Rob wrote: There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. Upgrade _or_ use noquery _or_ disable monitor Information at http://support.ntp.org/security Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. The default config shipped with ntpd, usually mostly provided by the distributor, is often terrible. (remember the LOCAL clock?) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-01-15, Steve Kostecke koste...@ntp.org wrote: On 2014-01-15, David Woolley wrote: CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. Upgrade _or_ use noquery _or_ disable monitor Information at http://support.ntp.org/security Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. The default config shipped with ntpd, usually mostly provided by the distributor, is often terrible. (remember the LOCAL clock?) The root problem is the fact that certain functionality is globally enabled by default in the daemon. Prudence dictates that features which may be deemed as unsuitable for uncontrolled, or global, use ought to be disabled by default. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-01-15, Steve Kostecke koste...@ntp.org wrote: On 2014-01-15, David Woolley wrote: On 27/12/13 10:24, Rob wrote: There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. Upgrade _or_ use noquery _or_ disable monitor Information at http://support.ntp.org/security Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. The default config shipped with ntpd, usually mostly provided by the distributor, is often terrible. (remember the LOCAL clock?) I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. I agree that distros could well put in something to undo that and that they often do really stupid things (mainly because they do not understand things). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Rob writes: The default config shipped with ntpd, usually mostly provided by the distributor, is often terrible. (remember the LOCAL clock?) Yes, because there is no default configuration in the distribution. That is left to the vendor to provide, as they know more about their client base than we do. Some vendors do a better job than others at providing their ntp.conf file. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
William Unruh un...@invalid.ca wrote: On 2014-01-15, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2014-01-15, Steve Kostecke koste...@ntp.org wrote: On 2014-01-15, David Woolley wrote: On 27/12/13 10:24, Rob wrote: There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. CERT have just issued an alert about the monlist attack: https://www.us-cert.gov/ncas/alerts/TA14-013A (TA14-013A: NTP Amplification Attacks Using CVE-2013-5211). The advice is upgrade or use restrict. Upgrade _or_ use noquery _or_ disable monitor Information at http://support.ntp.org/security Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. The default config shipped with ntpd, usually mostly provided by the distributor, is often terrible. (remember the LOCAL clock?) I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. That only becomes meaningful when ntpd starts to actually work without config file. Of course that would be possible, but I don't think it is reality today. Or is it, in the latest versions? I agree that distros could well put in something to undo that and that they often do really stupid things (mainly because they do not understand things). This problem would probably not exist when a good default config file was shipped by the maintainers. Distro people don't have time on their hands and when a default config is available, they often use it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
William Unruh writes: Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. Because there is clear value in the monitoring information being made generally available. We provide a sufficiently robust mechanism to handle the various options. It's not our place to dictate the local policy choice of how the mechanism is configured. On the one hand we can change the default from open to closed, and then create a whole bunch of work for a lot of people to address that policy change. Some work should likely happen regardless - the issue goes to who and how many will have to do the work for each choice. http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Harlan Stenn st...@ntp.org wrote: Rob writes: The default config shipped with ntpd, usually mostly provided by the distributor, is often terrible. (remember the LOCAL clock?) Yes, because there is no default configuration in the distribution. That is left to the vendor to provide, as they know more about their client base than we do. Some vendors do a better job than others at providing their ntp.conf file. The latter would not be an issue if suitable sample configuration files were provided so that the vendors/aggregators/distributors had a sane starting point for the customization efforts. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. That only becomes meaningful when ntpd starts to actually work without config file. Of course that would be possible, but I don't think it is reality today. Or is it, in the latest versions? Both the current Production (i.e. stable) and the Development versions of ntpd require a configuration file. Some may view this as a bug. Others may view this as a feature. I agree that distros could well put in something to undo that and that they often do really stupid things (mainly because they do not understand things). This problem would probably not exist when a good default config file was shipped by the maintainers. Distro people don't have time on their hands ... The same could be said about the NTP Reference Implementation Developers; they're busy, too. Anyone interested in reviewing the ./conf directory in the distribution and contributing appropriate sample configuration files for various ntpd use cases (e.g. server, leaf-node pool client, etc.) is encouraged to do so. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Steve Kostecke koste...@ntp.org wrote: On 2014-01-15, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. That only becomes meaningful when ntpd starts to actually work without config file. Of course that would be possible, but I don't think it is reality today. Or is it, in the latest versions? Both the current Production (i.e. stable) and the Development versions of ntpd require a configuration file. Some may view this as a bug. Others may view this as a feature. I think it would be a win when a config file is not required for a standard leaf node that only syncs to NTP and does not provide NTP service to others. This means that many user who don't care at all do not become attackers of innocent DDOS victims. I agree that distros could well put in something to undo that and that they often do really stupid things (mainly because they do not understand things). This problem would probably not exist when a good default config file was shipped by the maintainers. Distro people don't have time on their hands ... The same could be said about the NTP Reference Implementation Developers; they're busy, too. The difference is that while there is only one developers team, there are many distributors that each have to do the same job. So overall it is more efficient to distribute an example config. And it improves quality as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Harlan Stenn st...@ntp.org wrote: William Unruh writes: Why does nptd not disable external monitoring or command by default. That way if someone wants to allow it, they have to actively do so, presumably knowing what they are doing. Because there is clear value in the monitoring information being made generally available. Especially to generators of DOS attacks. Why should the world know, by default, all of the details of your particular ntpd installation? We provide a sufficiently robust mechanism to handle the various options. It's not our place to dictate the local policy choice of how the mechanism is configured. It IS your place to set up reasonable defaults. Now, what is reasonable can of course be argued about, but given the DOS attacks, the current default are starting to look unreasonable. On the one hand we can change the default from open to closed, and then create a whole bunch of work for a lot of people to address that policy change. Some work should likely happen regardless - the issue goes to who and how many will have to do the work for each choice. Sorry, what fraction of the users of ntpd care if it is open or closed? I suspect that is small. In that case closed seems a more reasonable option than open. http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-15, Harlan Stenn st...@ntp.org wrote: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. That was why the sentence if nothing is set in the config file by which I meant nothing with respect to what we are discussing. I agree that the config file needs some server lines to know where to get the time base from (those should be pool directives). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
[invalid William has been trimmed from the cc list] Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, while being usable as a s2/s3 to other nearby nodes. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. And, as far as I can tell, seems to be as simple as 'restrict noquery' as a compiled-in default before any restrict statements are given. Yet that does not happen. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 1/15/2014 7:18 PM, Greg Troxel wrote: [invalid William has been trimmed from the cc list] Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, while being usable as a s2/s3 to other nearby nodes. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. And, as far as I can tell, seems to be as simple as 'restrict noquery' as a compiled-in default before any restrict statements are given. Yet that does not happen. By default, the dev branch software doesn't respond to mode 7 packets and even if mode 7 packets are enabled it still doesn't respond to monlist requests. So, if it is as simple as you say, then you've got your wish already. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Brian Utterback brian.utterb...@oracle.com writes: On 1/15/2014 7:18 PM, Greg Troxel wrote: [invalid William has been trimmed from the cc list] Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, while being usable as a s2/s3 to other nearby nodes. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. And, as far as I can tell, seems to be as simple as 'restrict noquery' as a compiled-in default before any restrict statements are given. Yet that does not happen. By default, the dev branch software doesn't respond to mode 7 packets and even if mode 7 packets are enabled it still doesn't respond to monlist requests. So, if it is as simple as you say, then you've got your wish already. That's good to know - thanks for clarifying. This has been unclear since I keep hearing that no defaults are acceptable and that anyone using ntpd needs to understand and configure it, as opposed to hearing that there are sane defaults and it's not a big deal. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Bill, For me, your information/attitude ratio (similar to a sigal/noise ratio) skews towards trolldom enough that I often just don't bother responding to what you write. I would have sent this privately but I have no idea what your real email address is. H -- William Unruh writes: On 2014-01-15, Harlan Stenn st...@ntp.org wrote: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. That was why the sentence if nothing is set in the config file by which I meant nothing with respect to what we are discussing. I agree that the config file needs some server lines to know where to get the time base from (those should be pool directives). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Greg Troxel writes: Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. We do supply some sample config files in the conf/ directory. I don't know that anybody is really happy about them. I am disinclined to distribute files like that because they stick around for far too long. I would much rather see an online config file generator, especially one that can take some core state information and generate a new config file that implements BCP. I'll also point out that it seems to me that there's a lot of bitching about the current situation, and Steve and I (and others) have pointed out that this is a volunteer effort, and in the past there has been no way for folks who want to contribute $ to do so. Now that Network Time Foundation exists, there *is* a vehicle that can accept funding and pay for improvements for Network Time. So please complain as much as you want. Please volunteer as much as you want. Please financially support Network Time as much as you want. I also invite folks to pay attention to what they want to get, and see how what they are and are not doing correlates to what they are and are not getting. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
A C wrote: On 1/8/2014 18:31, William Unruh wrote: But this sounds like it is shooting someone else in the foot. That is more serious. Ie, the default is that you should have to work quite hard to enable the system to run these amplification attacks (I assume that this is using the control system to send control/info packets, rather than ntp time protocol packets) It is unclear (or, more correctly, not publicly documented yet) whether the attack used the monlist function (outlined in a CERT advisory in December) or some other method utilizing NTP protocols. But it was enough of an attack to cripple the gaming servers for some time. It is indeed using the 'ntpdc -c monlist' mode 7 packet with a faked sender to do these attacks, we've added 'noquery' to our three external ipv4 pool servers. (This is after our CERT guys saw multiple attempts to use those servers as part of a DDOS attack.) My home ipv6 server still allows external users to ask for the monitor list, but only via the new 'ntpq -c mrulist' interface which is safe against fake sender/redirect attacks. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
http://arstechnica.com/security/2014/01/dos-attacks-that-took-down-big-game-sites-abused-webs-time-synch-protocol/ Here's a live amplification attack at work. On 12/29/2013 01:55, Terje Mathisen wrote: Steve Kostecke wrote: On 2013-12-28, Terje Mathisen terje.mathi...@tmsw.no wrote: Harlan Stenn wrote: The other ones I'd really like help with. I definitely want to see the network-related bugs fixed and 2367. I'd like to see some study done on 2016. I'm game to let the other ones slide. I've just gone through 2367 and I have to join Brian's side: I.e. if somebody adds NOSERVE to a client it would be perfectly fine to let that override PEER or anything else: NOSERVE should only be used on a pure end-node client, with no sideways or downstream communication. This is a case of not being able to see the forest for the trees. Please explain! As I wrote in another post I believe the time is ripe for a sensible default builtin configuration, which can then be overridden with ntp.conf. You suggestion in your previous message is very similar to what I wanted, i.e. the default is to have a pure client using the pool. As soon as you start writing detailed ntp.conf options I want you to have the ability to shoot yourself in the foot, if that is your wish. Terje ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2014-01-09, A C agcarver+...@acarver.net wrote: http://arstechnica.com/security/2014/01/dos-attacks-that-took-down-big-game-sites-abused-webs-time-synch-protocol/ Here's a live amplification attack at work. As I wrote in another post I believe the time is ripe for a sensible default builtin configuration, which can then be overridden with ntp.conf. You suggestion in your previous message is very similar to what I wanted, i.e. the default is to have a pure client using the pool. As soon as you start writing detailed ntp.conf options I want you to have the ability to shoot yourself in the foot, if that is your wish. But this sounds like it is shooting someone else in the foot. That is more serious. Ie, the default is that you should have to work quite hard to enable the system to run these amplification attacks (I assume that this is using the control system to send control/info packets, rather than ntp time protocol packets) Terje ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 1/8/2014 18:31, William Unruh wrote: On 2014-01-09, A C agcarver+...@acarver.net wrote: http://arstechnica.com/security/2014/01/dos-attacks-that-took-down-big-game-sites-abused-webs-time-synch-protocol/ Here's a live amplification attack at work. As I wrote in another post I believe the time is ripe for a sensible default builtin configuration, which can then be overridden with ntp.conf. You suggestion in your previous message is very similar to what I wanted, i.e. the default is to have a pure client using the pool. As soon as you start writing detailed ntp.conf options I want you to have the ability to shoot yourself in the foot, if that is your wish. But this sounds like it is shooting someone else in the foot. That is more serious. Ie, the default is that you should have to work quite hard to enable the system to run these amplification attacks (I assume that this is using the control system to send control/info packets, rather than ntp time protocol packets) It is unclear (or, more correctly, not publicly documented yet) whether the attack used the monlist function (outlined in a CERT advisory in December) or some other method utilizing NTP protocols. But it was enough of an attack to cripple the gaming servers for some time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
A C writes: http://arstechnica.com/security/2014/01/dos-attacks-that-took-down-big-game-s ites-abused-webs-time-synch-protocol/ Here's a live amplification attack at work. OK, and this problem is already fixed in ntp-dev and it doesn't have anything to do with NOSERVE. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
William Unruh writes: On 2014-01-09, A C agcarver+...@acarver.net wrote: http://arstechnica.com/security/2014/01/dos-attacks-that-took-down-big-game -sites-abused-webs-time-synch-protocol/ Here's a live amplification attack at work. As I wrote in another post I believe the time is ripe for a sensible default builtin configuration, which can then be overridden with ntp.conf. You suggestion in your previous message is very similar to what I wanted, i.e. the default is to have a pure client using the pool. As soon as you start writing detailed ntp.conf options I want you to have the ability to shoot yourself in the foot, if that is your wish. But this sounds like it is shooting someone else in the foot. That is more serious. Ie, the default is that you should have to work quite hard to enable the system to run these amplification attacks (I assume that this is using the control system to send control/info packets, rather than ntp time protocol packets) I'm not seeing any new information here. For DECADES people did not take malicious advantage of things like this. Now some folks are. The root problem is not an issue for ntp-4.2.7, and there is a simple solution for earlier versions. How about we limit discussion on this thread to actual new information? H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Steve Kostecke wrote: On 2013-12-28, Terje Mathisen terje.mathi...@tmsw.no wrote: Harlan Stenn wrote: The other ones I'd really like help with. I definitely want to see the network-related bugs fixed and 2367. I'd like to see some study done on 2016. I'm game to let the other ones slide. I've just gone through 2367 and I have to join Brian's side: I.e. if somebody adds NOSERVE to a client it would be perfectly fine to let that override PEER or anything else: NOSERVE should only be used on a pure end-node client, with no sideways or downstream communication. This is a case of not being able to see the forest for the trees. Please explain! As I wrote in another post I believe the time is ripe for a sensible default builtin configuration, which can then be overridden with ntp.conf. You suggestion in your previous message is very similar to what I wanted, i.e. the default is to have a pure client using the pool. As soon as you start writing detailed ntp.conf options I want you to have the ability to shoot yourself in the foot, if that is your wish. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Steve Kostecke wrote: On 2013-12-27, detha de...@foad.co.za wrote: A first step would be to have a default configuration where any functionality that can be used for reflection attacks with more than a say 2:1 ratio needs to be explicitly enabled, with warnings about this in the sample config file(s). The NTP Reference Implementation has no default use case. So there is no baked-in sensible default configuration. Some view this as a feature. With the current dev code it seems to me that, for the first time, it is possible to define a useful default configuration, maybe something like this: pool pool.ntp.org # Self-optimising set of network servers restrict source# Allow the same servers to query us back restrict default nopeer noquery limit (The default restrict is open for discussion!) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 28/12/2013 01:42, Brian Utterback wrote: [] But monlist doesn't work with the latest software. It was replaced by mrulist which requires a handshake at the beginning, so the request address can't be spoofed. That's what I meant by having to upgrade no matter what we do. Brian Utterback The next version must be quite close to release. Perhaps Harlan could remind any of us who need chasing for critical patches to complete our work? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
David Taylor writes: The next version must be quite close to release. Perhaps Harlan could remind any of us who need chasing for critical patches to complete our work? http://support.ntp.org/Dev/ReleaseSchedule has a link to the list of blockers for 4.2.8. Offhand, the ones I'm focusing on are the autogen/documentation issues, 2522, 2187, and 2177. The other ones I'd really like help with. I definitely want to see the network-related bugs fixed and 2367. I'd like to see some study done on 2016. I'm game to let the other ones slide. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn wrote: The other ones I'd really like help with. I definitely want to see the network-related bugs fixed and 2367. I'd like to see some study done on 2016. I'm game to let the other ones slide. I've just gone through 2367 and I have to join Brian's side: I.e. if somebody adds NOSERVE to a client it would be perfectly fine to let that override PEER or anything else: NOSERVE should only be used on a pure end-node client, with no sideways or downstream communication. Brian's one-line fix is definitely better than the current situation. If this leads to glitches for really funky conf setups, then so be it. It is NOT worth holding the new release! Re 2016: This one is really strange! I do agree that as soon as reach == 0 even a prefer server should be disallowed. The one thing I wonder about is the + vs * status: Can a '+' server steer the local clock at all, or will this only happen where there is a designated '*' winner? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Yeah, but the Meinberg installer for Windows, and the accompanying documentation including the Cheat Sheet, sure makes setting up a default configuration easier. However, I grant that almost nothing beats reading the NTP documentation, especially for novices. Charles Elliott -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of Steve Kostecke Sent: Friday, December 27, 2013 7:09 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] better rate limiting against amplification attacks? On 2013-12-27, detha de...@foad.co.za wrote: A first step would be to have a default configuration where any functionality that can be used for reflection attacks with more than a say 2:1 ratio needs to be explicitly enabled, with warnings about this in the sample config file(s). The NTP Reference Implementation has no default use case. So there is no baked-in sensible default configuration. Some view this as a feature. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
I looked up amplification attack. Such an attack occurs when an attacker can send a small UDP packet with a spoofed source address and elicit a many times larger response sent to the spoofed source. Doesn't that describe NTPD almost perfectly, considering what ntpdc and ntpq can do? But the same website that defined amplification attack also described the solution: Use TCP/IP. Is not that just one more reason to switch ntpd, nptq, and ntpdc from UDP to TCP for query processing? Charles Elliott -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of Rob Sent: Friday, December 27, 2013 11:50 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] better rate limiting against amplification attacks? Brian Utterback brian.utterb...@oracle.com wrote: On 12/27/2013 5:24 AM, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). In the current code monlist is replaced by mrulist. The mrulist command requires a handshake, so a spoofed address would not be possible. However, it might be wise to limit the number of packets sent per exchange. Currently the client sets the number but a man in the middle attack would still be possible. We could set the maximum number of packets sent per return packet to relatively small. The current implementation on the client sets it to 32, but we could allow a maximum of 4 or 8. Is a peer list really a big problem? It generally doesn't make sense to have much beyond 10 peers. Are there really a lot of servers with a lot of peers? Brian Utterback Are you doubting the fact that NTP is used for amplification attacks? It is a fact... and many ntp pool members have faced the consequences already. I think what has to be discussed is the countermeasures, not the fact. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn st...@ntp.org writes: Greg Troxel writes: Are you saying that a server (with the latest code) configured as server host1.example.com server host2.example.org server host3.example.net and nothing else in the ntp.conf will behave under current guidelines for best practices in terms of avoiding participating in DOS? No, because that's not without a conf file. If you are going to create a config file that allows arbitrary hosts to request query responses (which is, in general, a good thing) then that's what you'll get. You're assuming that people really understand all the subtleties and handing them the chain saw equivalent of a red chain. NTP culture has resulted in overly complicated configuration based on a belief/assumption that everything must be done inside the daemon, for various reasons/justification. (Few other programs have the complexity of restrict.) While there are reasons for a lot of that, the result is basically a bug (or an unfortunate necessity to be minimized) - which is why I'm focusing on what happens to users who are not spending extra hours digging in. I do want to discuss this and get a consensus for how to proceed. I'm not sure how much we'll actually win by changing the default to: restrict default ... noquery ... because people will just as easily create a new ntp.conf line that adds overrides to either particular hosts/nets (which is good) or they may just as easily remove the restruct default noquery and we're back in the same place. I don't understand the focus on query, perhaps because I'm unclear on the threat model. As I see it there are two things going on (focusing on DOS attacks, assuming spoofed source addresses): 1) packets that provide amplification, such as monlist, or anything else where significantly more bytes are returned than requested. 2) same-sized responses, such as the normal protocol operation I don't consider answering type 2 queries from the general internet to be a real bug; it's not that different from ICMP echo, a TCP RST, or an ICMP port unreachable or admin prohibited. But type 1 is a bug. So if the example config above (as might be written by someone who is fairly clueful but not paying attention to the details to set up a pair of roughly-s3 systems to sync their entire local infrastructure to) results in: attackers cannot succeed at amplification attacks random hosts can query time then I think all is well. I don't see any reason to permit administrative-style queries from other than localhost (both 127.0.0.1 and ::1, of course) by default. I think it would be unfortunate if security hysteria led to everyone's organizationl servers being firewalled from the internet and therefore unuseful to the community. (You said this, basically.) It seems monlist is going away in favor of mrulist (which is probably returning the same information, but in a way which requires returning a nonce and limits amplification even if nonces can be guessed), and it's not clear to me there are other amplification mechanisms. So perhaps that's the real fix, and nothing else is needed. There's a separate question about remedial configuration for software that isn't updated, and I wonder if that's just blocking monlist from other than localhost. So my big questions are: Of all the attacks actually happening, what mechanisms are they using, precisely? Is is just monlist? What other mechanisms are believed usable for attacks (with amplification, that are significantly more effective than ICMP Echo)? Do people think that simply replying to the basic time measurement protocol exchange is a security bug? If so, why? pgp8EwooTd1rt.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Steve Kostecke koste...@ntp.org writes: On 2013-12-27, detha de...@foad.co.za wrote: A first step would be to have a default configuration where any functionality that can be used for reflection attacks with more than a say 2:1 ratio needs to be explicitly enabled, with warnings about this in the sample config file(s). The NTP Reference Implementation has no default use case. So there is no baked-in sensible default configuration. Some view this as a feature. I think that's a bug. There are in my view two default cases: setting up the local machine to synchronize from organization/local s3 or so servers. setting up a few machines to be the above s3ish servers In both cases, there is no need to allow monlist-or-equivalent from other than localhost, and no real harm in answering time queries. The other significant use case is running a s1, but a) those people are expected to be more clueful and b) the above rules don't hurt that case either. pgpFv0dzYeYsJ.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 28/12/2013 12:06, Harlan Stenn wrote: David Taylor writes: The next version must be quite close to release. Perhaps Harlan could remind any of us who need chasing for critical patches to complete our work? http://support.ntp.org/Dev/ReleaseSchedule has a link to the list of blockers for 4.2.8. Offhand, the ones I'm focusing on are the autogen/documentation issues, 2522, 2187, and 2177. The other ones I'd really like help with. I definitely want to see the network-related bugs fixed and 2367. I'd like to see some study done on 2016. I'm game to let the other ones slide. H Thanks, Harlan. I've just looked through the list and at least I'm not in the critical path! Of the others, they either aren't relevant to me or don't bother me. I'm happy with 4.2.7p406 (just installed for testing on Windows, FreeBSD and Raspberry Pi Linux 3.6.11. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Terje, As I recall from my discussions with DLM, we all agree that the current code goes too far and needs to be changed. DLM's point (OK, more properly, my recollection is that DLM's point) is that he's concerned that Brian's fix is a bit too early and doing it that way will open the door to more problems from carefully-crafted malicious packets. This is what I'm saying in https://bugs.ntp.org/show_bug.cgi?id=2367#c9 . The reason this and all of the other open bugs haven't been fixed yet is because of lack of resources - there is *way* more work than the current number of volunteers can handle and there isn't enough $ to let me hire folks to work on these things. If Network Time Foundation got US$2, once, for every device that uses NTP we could fund the ongoing maintenance of and development for NTP off of the earned interest. This is a thumbnail estimate. Over the past 3 years' time we've raised about $US0.0003 per device per year, and the vast majority of the funds we raised came from only 3 companies. If we can generate enough smaller support from lots of other sources we'll be fine, and we need to double our current funding to be able to hire folks to begin that effort. This is what I've been working on doing for the past 3 years' time, in addition to my pure NTP work. Terje, you and many other folks have actively helped make NTP a really awesome project, and I greatly appreciate your efforts and the efforts of the other contributors. Folks have contributed code, joined NTF as individual members, and made cash donations. This is all incredibly helpful, and all I'm saying is that NTF needs to find a way to significantly increase the level of support it's getting in order to keep up the effort. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Brian Utterback wrote: On 12/27/2013 5:50 PM, Jochen Bern wrote: On 27 Dec 2013, Brian Utterback wrote: Is a peer list really a big problem? It generally doesn't make sense to have much beyond 10 peers. Are there really a lot of servers with a lot of peers? If you mean to ask whether such a setup exists at all, here's a real world example: # ntpdc -n -c monlist | wc -l 602 But monlist doesn't work with the latest software. It was replaced by mrulist which requires a handshake at the beginning, so the request address can't be spoofed. That's what I meant by having to upgrade no matter what we do. Well, in this specific instance, the use of noquery on our server supposedly disables all problematic request types without disabling any functionality that the appliances need to have available, so the question remains somewhat academic in any case - for now. Also, I don't see the appliances using any functionality beyond client mode synchronization - a very small, well-tested, likely pretty problem-free subset of the NTP protocol - anytime soon. (I'ld be grateful if someone could point me to case studies on large-scale autokey deployments, in particular using MV, though. Our server's *not* forcing use of NTPv3 keys for auth because we would have risked problems of scale with that.) However, having that said: Back when I was asked how we could provide out-of-the-box time sync for our appliances, I remembered a couple horror stories and told RD that the company'd better be prepared to run the server(s) themselves, on IPs as unchanging as possible (no re-resolving of FQDNs by the client 'til restart), providing support (including backward compatibility, of course) for *years* beyond the EOL of the relevant models/versions, yadda yadda. Now you tell me that, lest we become an unwilling contributor to online attacks, we have no other choice than to keep(?) updating the entire system to ntpd versions that are actually *ahead* of what the upstream OS distrib hands us, dropping entire request types on the floor when they're found to initially(!) have been implemented in an insecure manner. In our ears, that translates to much more QA effort with considerably less-tested 3rd-party-software versions, customers will complain about us effectively throwing a kill switch on their not-quite-new but still working appliances all the time, and the newest and bestest version will force customers to update even the most well-protected internal servers of theirs accordingly before they can successfully configure our appliance to use these instead of our default server. We see local sysadmins flat out *refusing* to update their appliances (sitting in well-protected internal networks) for fear of stumbling over some incompatible change in the actual production process. You're saying that if a problem-solving update is *available*, it's ipso facto the only countermeasure *needed*? Well, you're betting your reputation on *those* people updating faster than the security hole *on our server* will get exploited, then. (Or at least faster than other effective countermeasures.) My hopes would rather be on having fine-grained control of what requests the server does or doesn't answer, beforehand. And ideally a thought or two having been given about clients degrading *gracefully* as I'm forced to cut down on their server-side support. Kind regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2013-12-28, Greg Troxel g...@ir.bbn.com wrote:
Steve Kostecke koste...@ntp.org writes:
On 2013-12-27, detha de...@foad.co.za wrote:
A first step would be to have a default configuration where any
functionality that can be used for reflection attacks with more than a say
2:1 ratio needs to be explicitly enabled, with warnings about this in the
sample config file(s).
The NTP Reference Implementation has no default use case. So there is no
baked-in sensible default configuration. Some view this as a feature.
I think that's a bug. There are in my view two default cases:
There can only be one, unless ntpd can be started with a command line
switch to chose the case.
setting up the local machine to synchronize from organization/local s3
or so servers.
setting up a few machines to be the above s3ish servers
The default use case (i.e. the baked-in configuration) ought to support
the lowest common denominator: a pool client. Something like this would
suffice:
restrict default ignore
restrict localhost
pool pool.ntp.org
restrict source
These configuration directives should be selectively overridden by
ntp.conf.
In the case of an ntpd operating as an NTP client polling one or more
arbitrary time servers (as in your second case) it should be sufficient
to merely specify a server line, or lines, which would override the
baked-in pool directive.
In the case of an ntpd operating as an NTP server (as in your first
case) there could be a command line switch and/or ntp.conf directives to
clearly define authorized clients. e.g.
switch:
-client localnet
-client aaa.bbb.ccc.ddd/mm
-server or -client {all|global|*} to globally enable time service
conf file:
client localnet
client aaa.bbb.ccc.ddd/mm
client hostname.or.ip.address
In both cases, there is no need to allow monlist-or-equivalent from
other than localhost, and no real harm in answering time queries.
There are some who object to allowing there ntpd to respond to external
time polls. We see this periodically in the news-group and on irc.
If we start from the position that ntpd is by default only a client then
configuration becomes a simple matter of enabling desired functionality.
The other significant use case is running a s1, but a) those people are
expected to be more clueful and b) the above rules don't hurt that case
either.
s/s1/public time server/
This usage ought to require some configuration but could still
benefit from sensible defaults.
--
Steve Kostecke koste...@ntp.org
NTP Public Services Project - http://support.ntp.org/
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2013-12-28, Terje Mathisen terje.mathi...@tmsw.no wrote: Harlan Stenn wrote: The other ones I'd really like help with. I definitely want to see the network-related bugs fixed and 2367. I'd like to see some study done on 2016. I'm game to let the other ones slide. I've just gone through 2367 and I have to join Brian's side: I.e. if somebody adds NOSERVE to a client it would be perfectly fine to let that override PEER or anything else: NOSERVE should only be used on a pure end-node client, with no sideways or downstream communication. This is a case of not being able to see the forest for the trees. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Charles Elliott wrote: I looked up amplification attack. [...] But the same website that defined amplification attack also described the solution: Use TCP/IP. Is not that just one more reason to switch ntpd, nptq, and ntpdc from UDP to TCP for query processing? I'ld like to make another - possibly *mostly* identical - suggestion along more immediately relevant technical dependencies: -- Any requests where the timing of query and answer are relevant should use UDP (so as to keep the OS' TCP stack's packet resends out of the picture). -- Any requests where packets beyond the Internet's minimum usable MTU (current consensus 400 Byte IIRC) may be created should use TCP (so as to benefit from path MTU discovery without having to reimplement it). -- (Corrolary: Any requests that require both assembly of a lot of data *and* relevance of timing are a problem in and of themselves.) -- The remainder can be distributed in such a way as to smoothen the big picture. -- (Nonetheless, admins should be allowed to enable backward compatibility modes.) From the POV of amplification attacks mitigation, all challenge-response systems should work more or less the same - whether the challenge is a TCP sequence number, a random number, a HMAC(request,current time,PSK) that allows well-known requestors to know the PSK beforehand and solve the challenge right with the *first* request, a normal auth system of NTP, or whatever. Greg Troxel wrote: Do people think that simply replying to the basic time measurement protocol exchange is a security bug? If so, why? (Probably not what you meant, but there are platforms where manipulating the machines' time is a possible preparatory step for an attack - think CA. If so, being able to read back whether that step succeeded is, of course, helpful to the attacker.) Kind regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] better rate limiting against amplification attacks?
What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). The options to limit the replies to those responses are not very detailed. One can deny all queries, but that is about it. It would be useful to have configurable rate limiting like on the normal time queries, and preferably configurable as global. So the rate of all queries should be limited, not per source IP address. And it would be good if queries can be denied individually, so that the peer servers query can still be issued but the monlist query cannot. Of course all of this can be done in a good firewall, but it usually requires lots of knowledge about the protocol details. It would be nice if ntpd could filter this at application level. Is this being considered? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 12/27/2013 5:24 AM, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). In the current code monlist is replaced by mrulist. The mrulist command requires a handshake, so a spoofed address would not be possible. However, it might be wise to limit the number of packets sent per exchange. Currently the client sets the number but a man in the middle attack would still be possible. We could set the maximum number of packets sent per return packet to relatively small. The current implementation on the client sets it to 32, but we could allow a maximum of 4 or 8. Is a peer list really a big problem? It generally doesn't make sense to have much beyond 10 peers. Are there really a lot of servers with a lot of peers? Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Brian Utterback brian.utterb...@oracle.com wrote: On 12/27/2013 5:24 AM, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). In the current code monlist is replaced by mrulist. The mrulist command requires a handshake, so a spoofed address would not be possible. However, it might be wise to limit the number of packets sent per exchange. Currently the client sets the number but a man in the middle attack would still be possible. We could set the maximum number of packets sent per return packet to relatively small. The current implementation on the client sets it to 32, but we could allow a maximum of 4 or 8. Is a peer list really a big problem? It generally doesn't make sense to have much beyond 10 peers. Are there really a lot of servers with a lot of peers? Brian Utterback Are you doubting the fact that NTP is used for amplification attacks? It is a fact... and many ntp pool members have faced the consequences already. I think what has to be discussed is the countermeasures, not the fact. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 12/27/2013 11:49 AM, Rob wrote: Brian Utterback brian.utterb...@oracle.com wrote: On 12/27/2013 5:24 AM, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). In the current code monlist is replaced by mrulist. The mrulist command requires a handshake, so a spoofed address would not be possible. However, it might be wise to limit the number of packets sent per exchange. Currently the client sets the number but a man in the middle attack would still be possible. We could set the maximum number of packets sent per return packet to relatively small. The current implementation on the client sets it to 32, but we could allow a maximum of 4 or 8. Is a peer list really a big problem? It generally doesn't make sense to have much beyond 10 peers. Are there really a lot of servers with a lot of peers? Brian Utterback Are you doubting the fact that NTP is used for amplification attacks? It is a fact... and many ntp pool members have faced the consequences already. I think what has to be discussed is the countermeasures, not the fact. Not at all. I am asking the parameters of the attack. Is the current software solution sufficient to stop such attacks? If so, then the solution is for the servers to upgrade. Indeed, no solution we craft for the current software development will help sites that do not upgrade. So, if the current software is subject to attack, is the attack always via mrulist or does the peer command also cause a problem? If it is mrulist only, then scaling back the maximum packets should make it a less attractive vector. Indeed, you could easily make the amplification dynamic, scaling back to one or two packets per exchange when the rate is high. If peers are a problem too, then a more general solution might be in order, such as the rate limit you mentioned. Unfortunately, the exchange is specific to mrulist. Perhaps an uprev of the protocol so that an exchnage is always required. I think I outlined a scheme such as that earlier. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Brian Utterback brian.utterb...@oracle.com wrote: Not at all. I am asking the parameters of the attack. Is the current software solution sufficient to stop such attacks? If so, then the solution is for the servers to upgrade. Indeed, no solution we craft for the current software development will help sites that do not upgrade. When the problem of reflection attacks can be solved by an upgrade, that is a strong motive for people (and distributors!) to finally upgrade. But I am not aware of more finegrained rate limiting in the newest version. Is there any? So, if the current software is subject to attack, is the attack always via mrulist or does the peer command also cause a problem? If it is I don't know what methods exactly are used, I have not been a victim myself yet. But in principle any UDP protocol that replies with much larger packets than the request that triggers them is a potential victim, as has already been shown with DNS as well. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
In article 52bdbd18.9070...@oracle.com, Brian Utterback brian.utterb...@oracle.com wrote: Not at all. I am asking the parameters of the attack. Is the current software solution sufficient to stop such attacks? If so, then the solution is for the servers to upgrade. Indeed, no solution we craft for the current software development will help sites that do not upgrade. The current software solution is sufficient to stop many attacks, but requires significant protocol understanding in order to configure it correctly, and may (the documentation is unclear) be too draconian a solution. For example, my servers are currently configured with restrict default nomodify nopeer noquery notrap limited But I actually wouldn't mind allowing queries, provided they were subject to a reasonable rate limit (say, no more than 1 per client per five-second interval). Without noquery and limited, my servers were generating about 25 Mbit/s last week, but I don't know which of these options actually made the difference. Note that this does *not* completely stop the attack, but it mitigates the effect that it has on an individual NTP server's host network. Unfortunately, I had to completely block NTP crossing our border (except for six authorized servers) as there are far too many NTP servers on our network with a default configuration that I have no direct administrative control over. It would be better if ntpd defaulted to a non-exploitable configuration. -GAWollman -- Garrett A. Wollman| What intellectual phenomenon can be older, or more oft woll...@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Garrett Wollman writes: In article 52bdbd18.9070...@oracle.com, Brian Utterback brian.utterb...@oracle.com wrote: Not at all. I am asking the parameters of the attack. Is the current software solution sufficient to stop such attacks? If so, then the solution is for the servers to upgrade. Indeed, no solution we craft for the current software development will help sites that do not upgrade. The current software solution is sufficient to stop many attacks, but requires significant protocol understanding in order to configure it correctly, and may (the documentation is unclear) be too draconian a solution. For example, my servers are currently configured with restrict default nomodify nopeer noquery notrap limited But I actually wouldn't mind allowing queries, provided they were subject to a reasonable rate limit (say, no more than 1 per client per five-second interval). Without noquery and limited, my servers were generating about 25 Mbit/s last week, but I don't know which of these options actually made the difference. Id bet noquery. Note that this does *not* completely stop the attack, but it mitigates the effect that it has on an individual NTP server's host network. What packets remain? Unfortunately, I had to completely block NTP crossing our border (except for six authorized servers) as there are far too many NTP servers on our network with a default configuration that I have no direct administrative control over. It would be better if ntpd defaulted to a non-exploitable configuration. I'll do what I can on this. It will require cooperation and collaboration with various OS folks. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn st...@ntp.org writes: Garrett Wollman writes: Unfortunately, I had to completely block NTP crossing our border (except for six authorized servers) as there are far too many NTP servers on our network with a default configuration that I have no direct administrative control over. It would be better if ntpd defaulted to a non-exploitable configuration. I'll do what I can on this. It will require cooperation and collaboration with various OS folks. To first order, the default OS and package policy is to respect the upstream package defaults, unless they are clearly broken. So ntpd should, when started up with no or a minimal config file, do the right thing. Distributing a config file with complicated things in it that does the right thing, but having the bare binary do the wrong thing, is not a good approach in practice, even though it's theoretically equivalent in some sense. (I'm not claiming this has been done - just sugggesting that an ntp.conf that says peer server1\npeer server2 cause ntpd to behave reasonably.) pgpc1zGNWtJ9q.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On Fri, 27 Dec 2013 18:30:38 +, Rob wrote: Brian Utterback brian.utterb...@oracle.com wrote: Not at all. I am asking the parameters of the attack. Is the current software solution sufficient to stop such attacks? If so, then the solution is for the servers to upgrade. Indeed, no solution we craft for the current software development will help sites that do not upgrade. When the problem of reflection attacks can be solved by an upgrade, that is a strong motive for people (and distributors!) to finally upgrade. But I am not aware of more finegrained rate limiting in the newest version. Is there any? So, if the current software is subject to attack, is the attack always via mrulist or does the peer command also cause a problem? If it is I don't know what methods exactly are used, I have not been a victim myself yet. But in principle any UDP protocol that replies with much larger packets than the request that triggers them is a potential victim, as has already been shown with DNS as well. A first step would be to have a default configuration where any functionality that can be used for reflection attacks with more than a say 2:1 ratio needs to be explicitly enabled, with warnings about this in the sample config file(s). Better would be a per-IP-address request or rate limit. I realize that on a busy server this involves a huge chunk of memory to keep track of recent requests, but (apart from redesigning the protocol, or plainly not allowing anything but standard client traffic) it seems to be the only way to mitigate the use of NTP in reflection attacks. Given enough servers, an attacker could still mount an attack by staying just under the limit for each server, but (especially if that limit could be different for each server) it makes the attacker's task a lot harder. If the limit should be 'no more than n requests per source IP per minute', or 'not more than x kB/sec traffic to an IP' is another question. I'd say the latter - there are valid cases with multiple clients behind a single NATed IP, and a tight request limit could interfere with those. -d ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Greg Troxel writes: --=-=-= Content-Type: text/plain Harlan Stenn st...@ntp.org writes: Garrett Wollman writes: Unfortunately, I had to completely block NTP crossing our border (except for six authorized servers) as there are far too many NTP servers on our network with a default configuration that I have no direct administrative control over. It would be better if ntpd defaulted to a non-exploitable configuration. I'll do what I can on this. It will require cooperation and collaboration with various OS folks. To first order, the default OS and package policy is to respect the upstream package defaults, unless they are clearly broken. So ntpd should, when started up with no or a minimal config file, do the right thing. Distributing a config file with complicated things in it that does the right thing, but having the bare binary do the wrong thing, is not a good approach in practice, even though it's theoretically equivalent in some sense. (I'm not claiming this has been done - just sugggesting that an ntp.conf that says peer server1\npeer server2 cause ntpd to behave reasonably.) No default ntp.conf file has part of the stock distribution's installation for as far back as I can remember. If somebody starts ntpd without a conf file, ntpd will do nothing and if somebody sends it any tell me what you know packets the response would be quite minimal. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
detha writes: A first step would be to have a default configuration where any functionality that can be used for reflection attacks with more than a say 2:1 ratio needs to be explicitly enabled, with warnings about this in the sample config file(s). Better would be a per-IP-address request or rate limit. I realize that on a busy server this involves a huge chunk of memory to keep track of recent requests, but (apart from redesigning the protocol, or plainly not allowing anything but standard client traffic) it seems to be the only way to mitigate the use of NTP in reflection attacks. Given enough servers, an attacker could still mount an attack by staying just under the limit for each server, but (especially if that limit could be different for each server) it makes the attacker's task a lot harder. If the limit should be 'no more than n requests per source IP per minute', or 'not more than x kB/sec traffic to an IP' is another question. I'd say the latter - there are valid cases with multiple clients behind a single NATed IP, and a tight request limit could interfere with those. Patches are greatly appreciated. Financial support to pay folks to work on things volunteers aren't available to do is greatly appreciated. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
detha de...@foad.co.za wrote: Better would be a per-IP-address request or rate limit. No, better would be a global rate limit. We already have a per-IP-address rate limit but it does not help much in this case. There should be a per-IP-address rate limit for the normal time protocol, but the rate limit for queries should be for any query received. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 27 Dec 2013, Brian Utterback wrote:
Is a peer list really a big problem? It generally doesn't make sense to
have much beyond 10 peers. Are there really a lot of servers with a lot
of peers?
If you mean to ask whether such a setup exists at all, here's a real
world example:
# ntpdc -n -c monlist | wc -l
602
We ship appliances to SMBs whose factory-default setup points them to
this NTP server (i.e., no filtering by client IP). The local admin's
supposed to change the config to local NTP, SMTP, etc. etc. servers, but
not all of them do, to put it mildly. :-{
Typical? Certainly not. *Lots* of such servers? Hmmm, let's say
possibly enough (to still allow such attacks to happen unless they can
be prevented by careful configuration).
(FWIW, in the meantime, I added nopeer, which I had initially left out
in favor of several setvar ... defaults.)
Regards,
J. Bern
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Harlan Stenn st...@ntp.org writes: No default ntp.conf file has part of the stock distribution's installation for as far back as I can remember. If somebody starts ntpd without a conf file, ntpd will do nothing and if somebody sends it any tell me what you know packets the response would be quite minimal. Are you saying that a server (with the latest code) configured as server host1.example.com server host2.example.org server host3.example.net and nothing else in the ntp.conf will behave under current guidelines for best practices in terms of avoiding participating in DOS? pgpVdSUviJKWH.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 2013-12-27, detha de...@foad.co.za wrote: A first step would be to have a default configuration where any functionality that can be used for reflection attacks with more than a say 2:1 ratio needs to be explicitly enabled, with warnings about this in the sample config file(s). The NTP Reference Implementation has no default use case. So there is no baked-in sensible default configuration. Some view this as a feature. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Greg Troxel writes: Harlan Stenn st...@ntp.org writes: No default ntp.conf file has part of the stock distribution's installation for as far back as I can remember. If somebody starts ntpd without a conf file, ntpd will do nothing and if somebody sends it any tell me what you know packets the response would be quite minimal. Are you saying that a server (with the latest code) configured as server host1.example.com server host2.example.org server host3.example.net and nothing else in the ntp.conf will behave under current guidelines for best practices in terms of avoiding participating in DOS? No, because that's not without a conf file. If you are going to create a config file that allows arbitrary hosts to request query responses (which is, in general, a good thing) then that's what you'll get. I do want to discuss this and get a consensus for how to proceed. I'm not sure how much we'll actually win by changing the default to: restrict default ... noquery ... because people will just as easily create a new ntp.conf line that adds overrides to either particular hosts/nets (which is good) or they may just as easily remove the restruct default noquery and we're back in the same place. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 12/27/2013 5:50 PM, Jochen Bern wrote:
On 27 Dec 2013, Brian Utterback wrote:
Is a peer list really a big problem? It generally doesn't make sense to
have much beyond 10 peers. Are there really a lot of servers with a lot
of peers?
If you mean to ask whether such a setup exists at all, here's a real
world example:
# ntpdc -n -c monlist | wc -l
602
We ship appliances to SMBs whose factory-default setup points them to
this NTP server (i.e., no filtering by client IP). The local admin's
supposed to change the config to local NTP, SMTP, etc. etc. servers, but
not all of them do, to put it mildly. :-{
Typical? Certainly not. *Lots* of such servers? Hmmm, let's say
possibly enough (to still allow such attacks to happen unless they can
be prevented by careful configuration).
(FWIW, in the meantime, I added nopeer, which I had initially left out
in favor of several setvar ... defaults.)
Regards,
J. Bern
But monlist doesn't work with the latest software. It was replaced by
mrulist which requires a handshake at the beginning, so the request
address can't be spoofed. That's what I meant by having to upgrade no
matter what we do.
Brian Utterback
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
