🚀 go-pugleaf

In article <MPG.1a3646c2d7662890989eb0@news-server.columbus.rr.com>,
Leythos  <void@nowhere.com> wrote:
|In article <bqh37g$6nd$1@canopus.cc.umanitoba.ca>, roberson@ibd.nrc-
|cnrc.gc.ca says...
|> We aren't mind-readers, Leythos, to know about your *intent*.

|Why would I post in this thread about using NAT if I wanted someone to 
|use NAT with forwarding?

I don't know, Leythos: I find your motives and logical reasonings
somewhat baffling to me, so I no longer ask myself -why- you post
what you do, and only address -what- you post.

:The intent is that if ISP's were to force NAT 
:(with no forwards) on home users that much of the worm / hacking 
:activity would be limited to web sites and email.

I do not believe that reality would match the intent you express.

|> There is nothing in any official definition
|> of 'NAT' that talks about duration of translations or restricting
|> translations to be usable to only returning traffic,

|And most NAT devices, in cable modems and in Home or SOHO units do not 
|leave any open forwards at all. In the vast majority of them they have 
|to be manually configured to open a hole in them.

|I will stand by it and say it again:
|> "Actually, if ISP's required users to install a router with NAT it would 
|> eliminate most of it. The hacks and worms could not infect new machines 
|> protected by NAT."

It appears to me that you do not understand how NAT works in practice.

When one of the inside systems wants to go out, the NAT device has to
temporarily allocate an outside address that it will map the inside
address to as it sends out the packets. In 1-to-1 NAT, when there is a
pool of private addresses to draw upon, use of a complete outside
address is allocated; in 1-to-many NAT (sometimes called PAT,
port-address-translation), use of a single port on an outside address
is allocated. Most cable modem and DSL home/SOHO users will only have
use of a single [possibly dynamic] outside address, so we will look
more closely at the PAT case.

Suppose then that inside system 192.168.0.2 wants to go out to outside
system 9.8.7.6 and that the outside interface address is 1.2.3.4.
Suppose the NAT box allocates port 33333 for this purpose, so that it
will send the packet out with source IP 1.2.3.4 and port 33333. When
the next packet was to be sent from the inside, how would the NAT box
know that it should use port 33333 again? The answer is that it creates
a temporary translation internally, that 192.168.0.2 -> 9.8.7.6 should
use port 3333. I am being deliberately vague here about the recorded
translation including the original source port and the original
destination port because not all NAT boxes handle these the same way.

So a packet goes out from 1.2.3.4 with source port 33333, hits 9.8.7.6,
and something replies; the reply packet will turn the source port
around to a destination port, so the reply will have destination
1.2.3.4 port 33333. The reply will hit the NAT device outer interface,
the NAT device will lookup port 33333 in its tables and see the
connection was initiated by 192.168.0.2, and the NAT device will do
the appropriate packet re-writing and will forward the packet on to
192.168.0.2 . Notice that there is no user-configured hole in
this procedure: the NAT device -automatically- created the hole back
to the originator, because if it didn't then normal replies would
not be able to get through.

The translation, that port 33333 reaches the original source port of
192.168.0.2, has to last at least as long as the connection lasts. If
it is a TCP connection, then the NAT device can in theory snoop on the
packets and notice a RST or do a SYN timeout, and thus figure out
(usually) when the connection ended. But if this is UDP then there is
no RST and no SYN timeout, and all that the NAT device can really do if
it wants to bother clearing out the old translation is to have a
time-since-last-traffic timeout. In other case, as long as the NAT
device has the translation on record, it will forward incoming packets
to the original source port. If that original source port was
udp 137 (because, say, the machine 192.168.0.2 is Windows machine
does DNS resolution as part of the NETBIOS process... which is the
default for some version of Windows), then that means that as
long as the translation persists, the NAT device will go ahead
and forward outside packets to 192.168.0.2's udp 137 port. Even
though no hole to do that was ever manually configured.


These packets addressed to 1.2.3.4 port 33333 that the NAT device is
forwarding over to 192.168.0.2: will the NAT device forward -any-
packet it receives (from anyone), or will it look in its tables, see
that the original destination address was 9.8.7.6, and reject packets
to 33333 that did not arrive from 9.8.7.6 ? If it only accepts packets
from the original destination and original destination port, then the
worms would indeed be much much slowed down (but there are still some
loopholes that can be exploited, so they would continue to be
-possible-.) The Cisco PIX is an example of a device that checks
the origin IP and port before passing packets on through the
translation.

But do -all- NAT devices do that kind of source/destination cross-
checking? It turns out that the lower end NAT devices do NOT do
source/destination cross-checking: for them, if any packet, from
-anywhere-, comes in addressed to port 33333 in this example, then 
as long as the translation lasts, that packet would be forwarded to 
the original source port of 192.168.0.2. That's because there are a
some exceptions where you -should- accept packets from elsewhere,
and handling those exceptions properly requires extra examination
and management layers and extra configurability, so lower end devices
often just skip that protection rather than try to deal with the
corner cases.


We are thusly in the situation where for lower-end NAT devices, if the
worm can somehow, from any machine anywhere, discover that ip 1.2.3.4
port number 33333 that leads back to 192.168.0.2 udp 137 then there is
an exploit avenue. And at first glance that would certainly look to be
orders of magnitude more difficult than just finding a single port
(137) directly on 1.2.3.4. "You would have to search 65536 times as
much space, and that would be slow enough that worms would effectively
be stopped!" It turns out, though, that in practice the port space to
be searched would not be anywhere -near- that big.

When a NAT device is choosing a port on its outside interface to use
map the original source port to, many implimentations will always
choose the -original- port number as long as it is not currently in
use. On one of those implimentations, 1.2.3.4 udp 137 is thus very
likely going to map into -some- machine's udp 137 if there is any
active port 137 translation. So worm scans for udp 137 specifically
would continue to find home/SOHO victims... perhaps not quite as
quickly as if those ports were always reachable, but sooner or later
the translate would get created and away your security goes. Other
things that NAT devices often do that reduces the search space
substantially are:

A) allocate ports sequentially (so if you know a port in use 'recently'
you can probe nearby)
B) allocate the first -available- port (so the lower port numbers
are much more likely have translations than the higher port numbers)
C) allocate from "pools".

The pools effect needs a bit of expansion. When port numbers were
being allocated, different ranges of ports were assigned different
meanings. Officially there is a high-numbered range for dynamic port
allocation, but it isn't uncommon for that range to be ignored. The
one distinction that -is- still kept is that port numbers 1 to 1023
are "privileged" ports, not to be assigned to any user process.
There are some programs (such as the rlogin daemon) that check the
source port and will refuse the connections if the source port is
not in the privileged port range. Because of this, NAT devices
that are translating an outgoing port in the privileged port range
will allocate an interface source port in the privileged port range.
This implies that if you are looking for a NAT'd translation of
outgoing port udp 137, that you are most productive searching at most
the range 1-1023, rather than the full range 1-65535. Combine this
with a routine that is smart about port allocation strategies and
about differentiating between "icmp unreachable" and
"icmp port-unreachable"...


In summary, a *good* NAT'ing firewall device does make it hard for
random machines to propogate a worm, but most consumer/SOHO devices
are NAT without firewall and do not necessarily provide very much
protection; smarter worms would get developed that would continue
to get through, sometimes with no more effort than before, sometimes
slowed but not by nearly as much as you would think at first.
-- 
   Cottleston, Cottleston, Cottleston pie.
   A bird can't whistle and neither can I.  -- Pooh