[ntp:hackers] ntpd getting used for DDoS

TSG - personal tglassey at earthlink.net
Wed Nov 6 18:24:52 UTC 2013


On 11/06/2013 07:32 AM, Ulf Samuelsson wrote:

Ulf - the issue is whether you have the ability to put into place a 
number of filters which can stop these types of accesses. In the case of 
public services the issue is how to moderate public access to assure 
thew parties (the local users) who a timescale service is setup for can 
in fact get access to it.

So the use limitation allows a number of legal responses which are 
important today. Its not about technology its about making tech work 
with the processes culture set up for those matters to be controlled.

Todd

>
>
>
> 6 nov 2013 kl. 14:49 skrev TSG - personal <tglassey at earthlink.net>:
>
>> On 11/05/2013 04:18 PM, Hal Murray wrote:
>>> There was a discussion on the pool list earlier today.
>>>    [Pool] DDOS using my ntp server
>>>    http://lists.ntp.org/pipermail/pool/2013-November/006672.html
>>>
>>> What can we do to make ntpd not-useful for this purpose?
>> Hal
>> we could deal with the problems the Triple Handshake creates here by adding both split mode to the front end request process and a secondary proxy capability for that as well.
>>
>> The other thing we can do is actually write terms into the NTP USE LICENSE banning its use for any nefarious purposes. And while you say "so what" - the power the IETFG has is its license and so it seems like we almost have a responsibility to do this in todays world.
>>
>> Todd
> Will that really help you to change a license?
> You can modify a packet generator to generate NTP packets without using the ntp stack.
> I did this myself to test how different solutions handled DoS attacks for a customer this spring.
> (not released as open source :-)
> A single machine could easily achieve 10 Gbps linerate but will be limited by the outgoing internet connection...
> With a good broadband provider, a home user should be able to transmit at least 10 Mbps.
>
> If you can secretly install packet generators on 1000 machines you have filled up
> a 10 Gbps receiving port without breaking the license.
>
> Best Regards
> Ulf Samuelsson
>
>
>
>>
>>> Suggestions from the above thread include rate limiting in a firewall and
>>> using "restrict noquery".
>>>
>>> There is a "limited" option to the restrict config line.  Should we be
>>> encouraging distros to turn it on in their sample ntp.conf?  (There is no
>>> amplification this way, but this path will probably get interesting after all
>>> the low hanging fruit gets picked/patched.)
>>>
>>> That doesn't cover mode 6/7 packets which are used by ntpq.  Is it worth
>>> adding a similar mechanism to handle mode 6/7?  Or is ntpq from the big/bad
>>> internet so full of problems that everybody should use noquery?
>>>
>>> I think it would be nice if something like the pool monitoring system could use ntpq.  Pool servers could allow that with another restrict line (per monitoring IP Address), but that make it hard to move the monitoring systems and prevents good-guys from poking around to chase problems or collect statistics.
>>>
>>> We might need a slow mode in ntpq so it can fly under the radar.
>>>
>>> Crazy thought?  If you don't like the slow mode, is it good enough to exchange 3 packets at the start?  The idea is that the client asks the server for a random cookie, the server sends it back to the client, then the client sends it back to the server to verify that the return IP Address is valid.
>>>
>>>
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> http://lists.ntp.org/listinfo/hackers



More information about the hackers mailing list