Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

client behind NAT (low-port bug)

160 views
Skip to first unread message

Jason Lixfeld

unread,
Apr 15, 2012, 9:08:42 AM4/15/12
to
Hi,

Per http://groups.google.com/group/comp.protocols.time.ntp/msg/5a0f45eaecc06578 I checked ntp_proto.c and found that in the latest 4.2.7, the same issue seems to persist as what David was suggesting was the underlying issue.

/*
* Monitor the packet and get restrictions. Note that the packet
* length for control and private mode packets must be checked
* by the service routines. Some restrictions have to be handled
* later in order to generate a kiss-o'-death packet.
*/
/*
* Bogus port check is before anything, since it probably
* reveals a clogging attack.
*/
sys_received++;
if (SRCPORT(&rbufp->recv_srcadr) < NTP_PORT) {
sys_badlength++;
return; /* bogus port */
}


I'm wondering if there is another fix here? Do I manually change NTP_PORT above to 0 (not being a programmer by any stretch, not knowing the farther reaching effects of such a change) and recompile?

To circle back around, the main issue here is that the NAT box ahead of my internal NTP server changes the source port of the output NTP request to some low port < 123, which ntpd seems to reject. Modifying the configuration on my NAT box may be an option as well. I'm just trying to see where all my bases lie.

I've installed 4.2.7p272, but the issue still seems to be present there too.

As a sample. here's a packet dump from the NTP server affected by the low-port bug where you can see source ports 5 and 14 get no response from the NTP server, but 123 does.

05:40:17.596649 IP 66.207.193.249.5 > 206.108.0.132.123: NTPv4, Client, length 48
05:57:23.599748 IP 66.207.193.249.14 > 206.108.0.132.123: NTPv4, Client, length 48
06:14:27.599740 IP 66.207.193.249.123 > 206.108.0.132.123: NTPv4, Client, length 48
06:14:27.599766 IP 206.108.0.132.123 > 66.207.193.249.123: NTPv4, Server, length 48

Thanks in advance.

Rob

unread,
Apr 16, 2012, 10:52:34 AM4/16/12
to
Jason Lixfeld <jaso...@lixfeld.ca> wrote:
> To circle back around, the main issue here is that the NAT box ahead of my internal NTP server changes the source port of the output NTP request to some low port < 123, which ntpd seems to reject. Modifying the configuration on my NAT box may be an option as well. I'm just trying to see where all my bases lie.

I think it is not a good idea to use low-numbered ports as a dynamic port
in a NAT box. This may cause other complications as well.

Dave Hart

unread,
Apr 16, 2012, 2:24:34 PM4/16/12
to
On Sun, Apr 15, 2012 at 13:08, Jason Lixfeld <jaso...@lixfeld.ca> wrote:
> Hi,
>
> Per
> http://groups.google.com/group/comp.protocols.time.ntp/msg/5a0f45eaecc06578
> I checked ntp_proto.c and found that in the latest 4.2.7, the same issue
> seems to persist as what David was suggesting was the underlying issue.
>
>        /*
>         * Monitor the packet and get restrictions. Note that the packet
>         * length for control and private mode packets must be checked
>         * by the service routines. Some restrictions have to be handled
>         * later in order to generate a kiss-o'-death packet.
>         */
>        /*
>         * Bogus port check is before anything, since it probably
>         * reveals a clogging attack.
>         */
>        sys_received++;
>        if (SRCPORT(&rbufp->recv_srcadr) < NTP_PORT) {
>                sys_badlength++;
>                return;                         /* bogus port */
>        }
>
>
> I'm wondering if there is another fix here?  Do I manually change
> NTP_PORT above to 0 (not being a programmer by any stretch,
> not knowing the farther reaching effects of such a change) and
> recompile?

You're right. I'm baffled now how I managed to find code in 4.2.7
that isn't there, code I recall seeing a few days ago which allowed
anything but port 0. I don't make claims about the code without
verifying it, so this is also embarrassing.

Please file a bug report (and sign up for an account to do so if you
haven't one already) at http://bugs.ntp.org/

To work around it, change the test above to:

       if (0 == SRCPORT(&rbufp->recv_srcadr)) {

My apology for the misinformation.

Cheers,
Dave Hart

E-Mail Sent to this address will be added to the BlackLists

unread,
Apr 16, 2012, 4:55:44 PM4/16/12
to
Jason Lixfeld wrote:
> The main issue here is that the NAT box ahead of my
> internal NTP server changes the source port of the
> output NTP request to some low port < 123,
> which ntpd seems to reject.
> Modifying the configuration on my NAT box may be an option as well.

If you believe in RFCs
{which without at least something similar,
the internet would not have progressed as far
in usefullness or be as useable by so many}

If NTP is NOT using the Well Known System Port Assigned Number 123,
if should be using a User Port Number 1024-49151,
or a Dynamic / Ephemeral Port 49152-65535?

<BlockQuote> IP Network Address Translator (NAT) Terminology and Considerations
2.4. TU ports, Server ports, Client ports

For the reminder of this document, we will refer TCP/UDP ports
associated with an IP address simply as "TU ports".

For most TCP/IP hosts, TU port range 0-1023 is used by servers
listening for incoming connections. Clients trying to initiate a
connection typically select a source TU port in the range of 1024-
65535. However, this convention is not universal and not always
followed. Some client stations initiate connections using a source TU
port number in the range of 0-1023, and there are servers listening
on TU port numbers in the range of 1024-65535.

A list of assigned TU port services may be found in RFC 1700 [Ref 2].
</BlockQuote> <http://tools.ietf.org/html/rfc2663>

--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
0 new messages