Re: [Ntp] Garbage NTP request packets

Miroslav Lichvar <mlichvar@redhat.com> Wed, 23 September 2020 08:44 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A53A0775 for <ntp@ietfa.amsl.com>; Wed, 23 Sep 2020 01:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.804
X-Spam-Level:
X-Spam-Status: No, score=-4.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HELgFgSii3tZ for <ntp@ietfa.amsl.com>; Wed, 23 Sep 2020 01:44:32 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541FF3A0E77 for <ntp@ietf.org>; Wed, 23 Sep 2020 01:44:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600850670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Dlbkbk1b7tAyk5eoq9hAerxZ7b+0ekRjlMuNdqERsS0=; b=fG1JAHCIhAnaWg6WdvFPvKsqvfhxwpvEDmQtWjutlF0Y0NrBojuiGiMka0eaYp6+iyTYTH AjhXQ/73tkdHT/3XGFKCqBFDAov/cI1Z6AyEZP30WOxgozLUgcrZdJEctmC/QckxELWXLL R32chOwgZ3yBoDyhgvw+pZLWNNU/zhU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-273-MuaB7oQgMxibZHJ3lLm6ew-1; Wed, 23 Sep 2020 04:44:27 -0400
X-MC-Unique: MuaB7oQgMxibZHJ3lLm6ew-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 61CB010060F1; Wed, 23 Sep 2020 08:44:26 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE8C173668; Wed, 23 Sep 2020 08:44:24 +0000 (UTC)
Date: Wed, 23 Sep 2020 10:44:23 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Hal Murray <hmurray@megapathdsl.net>
Cc: ntp@ietf.org
Message-ID: <20200923084423.GA1398053@localhost>
References: <20200923053414.07A4940605C@ip-64-139-1-69.sjc.megapath.net>
MIME-Version: 1.0
In-Reply-To: <20200923053414.07A4940605C@ip-64-139-1-69.sjc.megapath.net>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-lVrFGNNuS6N9DKTlgNdVyleKvA>
Subject: Re: [Ntp] Garbage NTP request packets
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 08:44:34 -0000

On Tue, Sep 22, 2020 at 10:34:13PM -0700, Hal Murray wrote:
> 
> I noticed that an error counter that was going off more than I expected, so I 
> hacked a server to print out a few garbage requests.

I think that's normal. On my public servers I see all kinds of weird
requests.

> Ones like this happen often enough to attract my attention.
>   e3000000 00000000 00000000 00000000
>   00000000 00000000 00000000 00000000
>   00000000 00000000 00000000 00000000
>   00000020 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
> 
> The first 3 lines look like a version 4 request.  The last line starts to look 
> like a MAC using key 20 (hex) but the HMAC/CMAC part is 28 bytes.  I haven't 
> setup key 20 and our code doesn't support bare MACs with a total length of 32 
> bytes.

This example looks like a valid NTPv4 request to me. It's not a MAC,
but an extension field (type 0, length 32 octets).

I have a script for monitoring pool.ntp.org servers that sends
requests like that (and others) to check various features of the
server like whether it can respond to an unknown extension field, what
implementation it is running, etc. FWIW, a server that doesn't respond
to a request that has an unknown extension field makes it more
difficult for clients to detect whether the extension field is
supported.

-- 
Miroslav Lichvar