Threat Level: green Handler on Duty: Manuel Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Cyber Security Awareness Month - Day 28 - ntp (123/udp)

Published: 2009-10-28
Last Updated: 2009-10-28 13:51:38 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

With projects like DShield, I have spend a lot of times around logs. One of the challenges in collecting logs from multiple sources is correlation and with that, correlating time. In addition to logs, some authentication systems like Kerberos will not work unless participating systems are synchronized to the same clock.

Luckily, ntp provides for a rather simple and quite accurate way to keep time on networked systems. NTP Version 3, which is the version you will find currently implemented, is defined in RFC 1305 [1]. Even though ntp isn't terribly complicated, there is a simpler version called SNTP (simple NTP). SNTP is defined in RFC 2030 [2].

Synchronizing time starts out with a primary reference source. This is a "standard clock" we use as a reference. If all you need is internal synchronization, you may just define some clock as your standard clock. But more likely then not, you are interested in synchronizing your clocks with the outside world. Various government standard organizations operate such standard clocks, and synchronize them with each other. The time to which all these national clocks are synchronized is referred to as UTC ("Universal Coordinated Time"). Occasionally, UTC is adjusted by adding leap seconds in order to match the rotation of the earth which is not exactly regular.

Now back from time to ntp. We established that we start with a master clock. All of our clocks are synchronized with this "master clock" using ntp. In order to do so, we need an ntp server connected to the master clock, and a ntp client on our system to connect to the master clock's ntp server. Usually, you end with an internal ntp server (or a couple of them for redundancy)  that is synchronized to an external source. All your internal hosts will then synchronize to your own internal standard.

Now what about the NTP protocol? How does it work? NTP deviates a bit from the standard port use. Most clients will pick an ephemeral port (>1023) and connect to the server's fixed port. For NTP however, the connection will usually be from UDP port 123 to UDP port 123 (but can be from high port to udp/123 ).

The client will connect to one or more servers, receive the time from each server. Next, the client will calculate a "drift" indicating what adjustment needs to be made to the internal clock to keep it in sync. One of the nice features of ntp is that adjustments are applied gradually, and large "jumps in time" are avoided. The ntp protocol definition explains in a lot of details various algorithms that should be used to pick the "best time" from a set of time servers.

NTP expresses time as 64bit numbers. The first 32 bits are the number of seconds from January 1st 1900. The remaining 32 bits express the fraction of seconds. 32 bits = 4 billion seconds or about 136 years. On Februrary 7th 2036, at 6:28:16 (if my math is right), ntp will "overflow". Lets hope we will have a 128 bit version of ntp implemented by then.

How is NTP secured? By default not at all. Some of its security comes from its distributed nature and by using multiple time servers. Encryption and authentication is optional with NTP. Most of the time, access to ntp servers is just controlled by IP address. But a shared secret may be used as a password and to help authenticating the response. The most recent version of ntp does allow for PKI support. For more about ntp security, see the GIAC Gold paper by Matt Willman [5]

Couple words on finding an appropriate time server: For a reasonably large network, it may be appropriate to get your own dedicated time server. There are some reasonably inexpensive products that will synchronize with non-network external clocks like GPS (usually requires an external antenna), cell phone networks (works well if you have cell phone reception in your datacenter. Does not require a monthly subscription to a cell phone service) or the governments time radio signal.

If you are concerned with too many clients connecting to your ntp server: ntp has an option to broadcast or multicast ntp data. That way, you can easily serve an entire network with time information without having to support individual connections. Multicast ntp uses the IP address 224.0.1.1.

Other time servers: Many ISP's routers have pretty good time servers build in. Check the router your network is connected to. Windows systems usually have "time.microsoft.com" pre-set, OS X systems use "time.apple.com" by default. Linux addapted pool.ntp.org over the last few years. pool.ntp.org is a set free reachable time servers [3]. Or you may refer to a list of public time server [4].

 

[1] http://tools.ietf.org/html/rfc1305
[2] http://tools.ietf.org/html/rfc2030
[3] http://www.pool.ntp.org/en/
[4] http://support.ntp.org/bin/view/Servers/WebHome
[5] http://www.giac.org/certified_professionals/practicals/gsec/2115.php

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

6 comment(s)
Firefox 3.5.4 released. Lots of security bug fixes. (thanks Gilbert!)

Sniffing SSL: RFC 4366 and TLS Extensions

Published: 2009-10-28
Last Updated: 2009-10-28 12:04:27 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

About once a week, we have a reader complain about a bad certificate for "incidents.org". Many years ago, this site was  known as "incidents.org", not "isc.sans.org" or "dshield.org". As a result, you may still come across a reference to "https://www.incidents.org". The domain still points to the same IP address as isc.sans.org, but our SSL certificate is issued for "sans.org", not "incidents.org", which causes the bad certificate warnings.

This is a common issue: It is trivial to use "Name Based Virtual Hosting" for regular web sites. The browser will send a "Host" header indicating which host it would like to connect to. This host header is mandatory ever since HTTP/1.1. But for https, this doesn't work. The host header is now encrypted, and in order to decrypt it, the server needs the correct key... if the key is different for each host, then you got a catch 22. As a result, each https host needs a dedicated IP (or port, but that's ugly).

In order to solve this problem, the Internet gods brought us RFC 4366 and "TLS Extensions" . Or as the RFC will tell us right in the beginning:

Allow TLS clients to provide to the TLS server the name of the server they are contacting. This functionality is desirable in order to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. [1]

More and more browsers and web servers start to support RFC 4366. With this, we solve another problem (at least partially): Monitoring https traffic. It was always possible to log the IP address. But with RFC 4366, the host name is now transmitted in the clear, as the following fragment of a packet capture shows:

19:28:02.363758 IP browser.60299 > dshield.org.https: Flags [P.], ack 1, win 32850, length 167
        0x0000:  4500 00cf cb8c 4000 4006 0000 0000 0000  E.....@.@.......
        0x0010:  41ad da4b eb8b 01bb 8537 8bc0 6340 3c7a  A..K.....7..c@<z
        0x0020:  5018 8052 26dd 0000 1603 0100 a201 0000  P..R&...........
        0x0030:  9e03 014a e782 0201 a72f 0250 7a55 ec2d  ...J...../.PzU.-
        0x0040:  9878 d405 65b2 402d e00e 0054 70a1 9c7e  .x..e.@-...Tp..~
        0x0050:  72e0 8e00 0044 c00a c014 0088 0087 0039  r....D.........9
        0x0060:  0038 c00f c005 0084 0035 c007 c009 c011  .8.......5......
        0x0070:  c013 0045 0044 0033 0032 c00c c00e c002  ...E.D.3.2......
        0x0080:  c004 0041 0004 0005 002f c008 c012 0016  ...A...../......
        0x0090:  0013 c00d c003 feff 000a 0100 0031 0000  .............1..
        0x00a0:  0017 0015 0000 1273 6563 7572 652e 6473  .......secure.ds
        0x00b0:  6869 656c 642e 6f72 6700 0a00 0800 0600  hield.org.......
        0x00c0:  1700 1800 1900 0b00 0201 0000 2300 00    ............#..

In this case, I connected to "secure.dshield.org". Wireshark will recognize the extension (so does tshark). The following display filter will select all packets with the "sever_name" ssl extension: ssl.handshake.extension.type == 0x0000 .

Now you may ask: Is this a problem? Well, if you want to keep the host name secret, then it is. But without it, there is a one-to-one relationship between hostname and IP address, so not much is lost, and the host name is revealed in clear text in the server's certificate. Is there the possibility of a known plain text attack? Maybe... (e.g. we know there has to be a "Host: ..." header with known content). But I am not enough of a crypto geek to know. From my perspective, there is plenty of known plain text in https traffic.

But there is also an opportunity here. Maybe a tool to log the hostname. Or a tool that compares the certificate coming back to the host name requests and alerts of a mismatch.

Of course, once I get around to it, incidents.org may get its own, valid, SSL certificate.

[1] http://tools.ietf.org/html/rfc4366

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

4 comment(s)
Diary Archives