We've all heard about the recent NTP reflection attacks.  Last night I noticed a higher-than-normal traffic volume on nox, so I checked it out with tcpdump:

Note, the first and second octets have been anonymized to protect the victim.

21:07:07.999600 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
21:07:07.999608 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
21:07:07.999617 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
21:07:07.999625 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
21:07:07.999712 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
21:07:07.999722 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
21:07:07.999730 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48

Yes, nox is a public NTP server.  It's a member of the NTP Pool Project.  No, it's not susceptible to an NTP reflection attack.  It looks like some poor soul at 100.44.89.82 (looked like a SonicWALL when I poked around) was being attacked and the traffic above was being spoofed with the intention of having my server send back a reply that's much larger than the request.  Here's a decode of one of the packets:

21:07:07.772681 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 76)
    100.44.89.82.10084 > 64.16.214.60.123: [udp sum ok] NTPv3, length 48
        Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 10s, precision -19
        Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3604450027.692652940 (2014/03/21 21:07:07)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3604450027.692652940 (2014/03/21 21:07:07)

What's odd about this is the packet above looks like just a normal NTP query.  Unlike most of the NTP reflection attacks that exploit the monlist or similar commands, this wasn't really going to have the desired effect.  And, of course, if you look at the initial (before I blocked that source address with iptables) traffic volume, it certainly did not:

The desired effect, of course, should have been an outbound traffic volume that was greater than the inbound traffic volume, or amplified.  In this case, my server was just sending back a 48 byte packet for every 48 byte packet coming in, albeit apparently slightly ratelimited by the NTP daemon.

Was this a misconfigured DDoS bot?  Did the attacker really not know what he or she was doing or missed DDoS 101?  Or, was this traffic not actually spoofed and was a result of some broken NTP client?  Maybe.

Regardless, if this wasn't a misconfigured NTP client, BCP 38 would have prevented this from happening to begin with.  I don't know where the traffic was originating, but I do know that it was from a network that probably doesn't implement BCP 38.

Anyway, I thought this was a little odd so I figured I would share.

New comments are currently disabled for this entry.