Coïncidence: NTP DOS?
Yesterday morning, Thomas Heim send out a warning on the OpenVMS SIG list that he had seen evidence on his systems of an exploit of a hole in older versions of NTP, and his warning was “Beware”.
That evening, when heading for bed, I heard my VMS server beep every few seconds. It normally does if a mail message comes in but at this rate, that means trouble.
And yes, I got loads of messages, that all concerend massive outgoing UDP traffic on port 123 – the NTP server, to a limited number of addresses but dirfferent ports on each of them. At times, there was a message concerning traffic to port 80 that was suspected to be torrent-based (quite unlikely to have UDP-traffic to a webserver…) so I got these as well.
Quite a coincidence?
Stopping the NTP server stopped the flood of messages, but after I restarted it, it restarted within a minute. So I turned my attention to the fireewall where port 123 (the standard NTP port) was still open. So I closed it and blocked all incoming traffic on port 123 – from any address.
Restarted NTP and after that, at least the flood of mail messages stopped so I wouldn’t be kept from sleeping. Whether I have to worry about time keeping remained to be seen. But a quick glance this morning reveled that time services still ru and do get an answer (the log states [Pass], so I think I don’t have to worry anymore for my time-keeping.
But there is still a lot of investigation to be done. The whole sequence styarted just after 21:00 and went on to justr after 22:00 when I stopped the NTP server; Restarted it at 22:10, the circus commenced so stopped it again at 22:11. Blocked the port in the firewall and restarted NTP at 22:16.
Just one (!) message blocked, and no problems ever since.
Next step is to investigate – as far as possible. I’ll keep the logfiles at hand (tonight they will be moved to the archives by the monthly maintenance job…).
Here’s a write-up on and a workaround for the NTP DDoS, pending an upgrade to a newer version of NTP:
https://isc.sans.edu/forums/diary/NTP+reflection+attack/17300
This is the US CERT alert:
https://www.us-cert.gov/ncas/alerts/TA14-013A
FWIW, I’m not particularly fond of exposing VMS boxes to the Internet. In your case, I’d (minimally) plug all of the TCP and UDP ingress at your gateway router firewall box, except for the ports minimally necessary.
The link refers to *x environments. AFAIK (but I;ll look into that later) there is no ntpdc command on VMS….
But on your objectrions: Of course the whole network is behind a firewall, I have limited externally originated access to just that what is needed, in terms of ports and protocols; Also I deny access through the router for notoriously misbehaving systemsand even networks, based on what I encounter in the different logfiles. And though it cannot be ruled out that the system can be compromised (mainly by (d)Dos attacks like this one), I consider VMS a far better system to be accesable from the internet than any other OS – that’s why all traffic into the network is passed to that system and that system alone. Whether it runs natively (Vax, AXP or Itanium) or emulated. Just check the CERT ratings.
That “there is no ntpdc command on VMS” comment?
Odd.
I have SYS$SYSTEM:TCPIP$NTPDC.EXE
While I’ve firewalled the OpenVMS boxes or have temporarily disabled the NTP servers entirely and this haven’t tested the workaround, I expect that the cited workaround also applies to OpenVMS. The OpenVMS implementation of NTP within TCP/IP Services is based on an older version of the common NTP code.
I also strongly disagree with your assumptions around the security of OpenVMS, but that’s fodder for a different time.