BW use and attempted DOS?

1

This is a new one on me.

A few days ago I noticed the network usage for one of my servers had increased substantially and had got a bit excessive. As the server has limited BW, and I’d already dropped the pool bandwidth down to the minimum 384k, I didn’t have much choice other than to shut down the ntp service and drop myself out the pool.

I checked again this morning and was a bit surprised to find I was still receiving 3mbit/sec of NTP traffic …

from a single host :astonished:

Looking back on my traffic stats, its easy to see why the network usage had gone up, it appears this host has been banging away since the 24th; effectively doubling my average incoming BW usage.

screencapture-sunflower-spiderspace-co-uk-secure-stats-d-iokWtKsmz-host-status-2019-01-29-11_51_22
screencapture-sunflower-spiderspace-co-uk-secure-stats-d-iokWtKsmz-host-status-2019-01-29-11_51_22.png1170×617 180 KB

The IP address resolves to something generic, I won’t post the whole hostname here, but it’s in the osk3.eonet.ne.jp domain; which looks to me like a residential ISP. My guess is a compromised computer attempting to DOS something through my server. Obviously, that was never going to work, but the host shows no sign of giving up.

I guess my only option here is to complain to the ISP and see if they’ll take action.

2

Well… Since NTP uses UDP packets, it is quite easy to forge a packet source, especially since so many ISPs still don’t enforce BCP38… However, it is definitely worthwhile to send your firewall logs to the “supposed” ISP and if the traffic is coming from their customer they can take action. That IP might not be the source, but the intended target.

Seeing as how your outbound traffic stayed low it looks like your NTP is configured correctly (most importantly having the “noquery” default). There are (sadly) still tons of NTP services on the internet mis-configured and are vulnerable to being used in an amplification attack.

I’m also going to assume you have the “KOD LIMITED” statements added to your default?

Have you captured any packets to see exactly what they are sending? Are they just time requests, or are they possibly mode 6 (ntpq) or 7 (ntpdc) packets trying to query other info (for amplification)?

3

I’m using chrony, but more importantly, it’s also currently shutdown :slight_smile:. You can see whilst chrony was up that the traffic wasn’t symmetric, that rate limiting was taking place and incoming traffic wasn’t being amplified.

tcpdump of a packet looks like this:

<removed>.63991 > <removed>.ntp: [udp sum ok] NTPv4, length 48
    Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
    Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
      Reference Timestamp:  0.000000000
      Originator Timestamp: 0.000000000
      Receive Timestamp:    0.000000000
      Transmit Timestamp:   3215733504.060745350 (2001/11/26 03:18:24)
        Originator - Receive Timestamp:  0.000000000
        Originator - Transmit Timestamp: 3215733504.060745350 (2001/11/26 03:18:24)

and in hex:

<removed>.63991 > <removed>.ntp: NTPv4, Client, length 48
            0x0000:  4530 004c 59fc 0000 3511 7a25 77e6 afa6
            0x0010:  ac5d dd65 f9f7 007b 0038 fcd6 2300 0000
            0x0020:  0000 0000 0000 0000 0000 0000 0000 0000
            0x0030:  0000 0000 0000 0000 0000 0000 0000 0000
            0x0040:  0000 0000 bfac 31e8 31bc 1093
4

That looks like a basic initial packet for a system that doesn’t have the correct time (note the initial transmit time).

Doesn’t really make sense… Stupid people doing stupid things I guess…

5

In case it’s just a badly written client: you might be able to get rid of them by resuming chronyc, and setting it to use the local clock with a high stratum (12?). That would cause most sane clients to switch to a different ntp server.