Very Computer

On my computer I have set up a very restrictive
firewall. If I try traceroute to my computer it
will not respond to the UDP packets. OTOH if I
use the -I option my computer will respond
because I allow echo requests.

I want my computer to respond to traceroutes,
but don't want to allow UDP packets with
arbitrary destination port to get through my
firewall.

Is it possible to get iptables to respond to
UDP packets as if the port was not in use, and
not deliver the packet to the port even if a
process is listening?

--
Kasper Dupont

REJECT udp packets where the destination port is between 33456 and 33546.
Otherwise just carry on denying stuff as normal.

~Tim
--

And re-awakes the memory                    |http://spodzone.org.uk/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The ports used in the implementation of traceroute are not written in
stone, AFAIK. The way traceroute works is it send a packet with a "Time To
Live" of 1 to the destination. The next hop away from the source decrements
the TTL, leaving it at 0 which means it must be discarded and an error
response is returned to the sender. The traceroute sender then increments
the same target to a TTL of 2 and that gets the second hop to do the same
thing. So on and so on until it gets to the destination.

Using iptables:
...DROP all...
iptables -I INPUT -p udp --dport 1024: --sport 1024: -i eth0 -m state \
        --state NEW -m ttl --ttl 1 -j ACCEPT

Match on TTL of 1 and you catch all traceroutes. Personally, I think it
makes sense to discard all very low TTL (less than 3) because that might
indicate an attempt to map the inside the network. I don't see any reason
to respond to traceroute at the firewall.

Blocking low TTL whould not be a problem for most remote hosts:

        +--------------------+-------+---------+---------+
        | OS Version         |"safe" | tcp_ttl | udp_ttl |
        +--------------------+-------+---------+---------+
          AIX                     n      60        30            
          DEC Pathworks V5        n      30        30
          FreeBSD 2.1R            y      64        64
          HP/UX  9.0x             n      30        30            
          HP/UX 10.01             y      64        64            
          Irix 5.3                y      60        60
          Irix 6.x                y      60        60
          Linux                   y      64        64
          MacOS/MacTCP 2.0.x      y      60        60
          OS/2 TCP/IP 3.0         y      64        64
          OSF/1 V3.2A             n      60        30
          Solaris 2.x             y     255       255
          SunOS 4.1.3/4.1.4       y      60        60
          Ultrix V4.1/V4.2A       n      60        30
          VMS/Multinet            y      64        64
          VMS/TCPware             y      60        64
          VMS/Wollongong 1.1.1.1  n     128        30
          VMS/UCX (latest rel.)   y     128       128  
          MS WfW                  n      32        32
          MS Windows 95           n      32        32
          MS Windows NT 3.51      n      32        32
          MS Windows NT 4.0       y     128       128

-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.

iD8DBQE7vQWbwBVKl/Nci0oRAmaLAKDULLfbMpzg5S7venIlB744sB/mwACgn+BG
fSVh18TRtr7twYqGrIUBYMo=
=/AW6
-----END PGP SIGNATURE-----

yes they are, if the design of the original traceroute is followed.  at
the same time that the ttl is incremented so is the destination port.

--
okay, have a sig then

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quote:>>>> I want my computer to respond to traceroutes, but don't want to allow
>>>> UDP packets with arbitrary destination port to get through my firewall.

>>> REJECT udp packets where the destination port is between 33456 and
>>> 33546. Otherwise just carry on denying stuff as normal.

>>The ports used in the implementation of traceroute are not written in
>>stone, AFAIK.

> yes they are, if the design of the original traceroute is followed.  at
> the same time that the ttl is incremented so is the destination port.

Actually, no. They are not.

RFC 1393 suggests a traceroute (record route) IP option which is not
actually used. The primary recommendation of that RFC suggests an ICMP
echo, making non-unix hosts a little closer to the original recommendation.
Admittedly, the original implementation by Van Jacobson:

[Stevens, 1994]
"chooses the UDP port number to be an unlikely value (larger than 30,000)
making it improbable that an application at the destination is using that
port."

The reason for this is obviously so that the sender gets back an ICMP port
unreachable from the sender when it finally lands. The incrementing of the
port numbers is merely a convenience to the coder because it makes
distinguishing the returned error messages easier.

If you actually want to match traceroutes and not just traceroutes from
unix-like hosts implementing the original methods of Mr. Van Jacobson you
need to match on TTL and not on UDP port number.

If you wanted to you could even implement traceroute using TCP, but that
would be considered wasteful of resources.

Note to the OP: allow icmp type 3 code 3 in your OUTPUT chain if you want
people to traceroute to your firewall (the wisdom of that notwithstanding)
and get a successful measure of hops.

-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.

iD8DBQE7vSyOwBVKl/Nci0oRAstHAJ4re6p8A1Mq+hY0sS/y7n0ibCUOSgCgxZzs
NHtfPdMKnjRCX6tC78wbawA=
=jAWJ
-----END PGP SIGNATURE-----

Nice bit of analysis Ian.  You have to get up a bit early and do your
homework to do something as neatly as you just did...

I am getting soooo old.  I like to sleep in late and I am afraid I
just don't do my homework like I should anymore.

-m-

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Very kind of you Michael, but between my battered copy of Stevens and
Google I am just the mouth. The brains were borrowed. As for work...never
touch the stuff ;)

-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.

iD8DBQE7vzZ0wBVKl/Nci0oRAu9dAJsHdLcjf04XPSOTPOwS3KZ2++ELhwCgv2wN
umT3/GQW9xHdlWMMsxBdB7E=
=Stat
-----END PGP SIGNATURE-----

Thanks. I'll just use that but replace ACCEPT with REJECT
as Tim suggested. I couldn't get the ttl part working, but
I guess I just have to load some module to get it working.

--
Kasper Dupont

If you figure it out, post back. I get an iptables error for 'ttl', and
"modprobe: Can't locate module ipt_ttl" in my logs. I don't have such a
module, and all the netfilter stuff is activated in .config.

--
Hal Burgiss

--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You probably couldn't get ttl working because it probably wasn't built into
your kernel. It is now a standard part of the kernel so it is not
considered experimental. What kernel version are you at right now?

As for REJECT...it sounds odd, but REJECT and ACCEPT are the exactly the
same in this situation. If you ACCEPT a UDP traceroute (ttl == 1) your
machine will generate an ICMP port unreachable to the sender. If you REJECT
it without any `reject-with' options your machine will generate an ICMP
port unreachable to the sender :)

There is no reason I can think of that you would allow people on the net to
diagnose and map your network. Tools like traceroute are a benefit to you
the admin, but are not a needed part of external connectivity. I say DROP
them.

Of course if you have some tight filtering in your OUTPUT chain you are
probably not letting it out wither way...which is a good thing.

-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.

iD8DBQE7wIewwBVKl/Nci0oRAsluAJ9LJAcBb3v8yF58nntvlZr2+vIq+ACguecy
EYMbd26slvJDBOKw0mcqcVE=
=s4F3
-----END PGP SIGNATURE-----

I'm using kernel version 2.4.9. I have compiled all netfilter
options as modules, but there is no ipt_ttl module. Where do
I find this module? Does it exist in the 2.4.9 kernel?

Quote:

> As for REJECT...it sounds odd, but REJECT and ACCEPT are the exactly the
> same in this situation. If you ACCEPT a UDP traceroute (ttl == 1) your
> machine will generate an ICMP port unreachable to the sender. If you REJECT
> it without any `reject-with' options your machine will generate an ICMP
> port unreachable to the sender :)

They will be the same as long as no process is listening on
the port. But if a process is listening on the port there
should be a difference. I use reject-with

Quote:

> There is no reason I can think of that you would allow people on the net to
> diagnose and map your network. Tools like traceroute are a benefit to you
> the admin, but are not a needed part of external connectivity. I say DROP
> them.

This particular computer is a standalone connected directly
to the internet. It only has to protect itself, so there is
no internal network to map anyway. I have been considereing
how this could be done if there is an internal network. I
think the firewall could be configured to just send an
icmp-port-unreachable, perhaps with the source IP set to the
actual target. That way all traceroutes from outside will
stop at the firewall and will think they have reached their
destination.

In my case it makes no sense to try preventing traceroutes.
A traceroute will see the route until the last hop before
the computer, the only thing I could hide is the fact that
the computer is actually alive. But you could get that
information by using ssh instead.

Quote:

> Of course if you have some tight filtering in your OUTPUT chain you are
> probably not letting it out wither way...which is a good thing.

I don't have any reasons to filter my OUTPUT chain, except
from protecting my cable modem which would otherwise let
any user change its configuration through a http server.

Quote:

> -----BEGIN PGP SIGNATURE-----
> Comment: Keeping the world safe for geeks.

> iD8DBQE7wIewwBVKl/Nci0oRAsluAJ9LJAcBb3v8yF58nntvlZr2+vIq+ACguecy
> EYMbd26slvJDBOKw0mcqcVE=
> =s4F3
> -----END PGP SIGNATURE-----

--
Kasper Dupont

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It has existed since the 2.3.x kernels. I believe it was considered
"experimental". Perhaps it still is. Enable CONFIG_EXPERIMENTAL in
your kernel and try again. Perhaps that is where it is. It might even
be a part of p-o-m.

Quote:> > As for REJECT...it sounds odd, but REJECT and ACCEPT are the
> > exactly the same in this situation. If you ACCEPT a UDP traceroute
> > (ttl == 1) your machine will generate an ICMP port unreachable to
> > the sender. If you REJECT it without any `reject-with' options
> > your machine will generate an ICMP port unreachable to the sender
> > :)

> They will be the same as long as no process is listening on the
> port. But if a process is listening on the port there should be a
> difference. I use reject-with

Fair enough. But if you have some UDP thing listening on a high port
you have bigger problems ;)

Quote:> > Of course if you have some tight filtering in your OUTPUT chain
> > you are probably not letting it out wither way...which is a good
> > thing.

> I don't have any reasons to filter my OUTPUT chain, except from
> protecting my cable modem which would otherwise let any user change
> its configuration through a http server.

!  I consider OUTPUT filtering to be a pretty important part of my
strategy. At the very least put some sanity check in there.

-----BEGIN PGP SIGNATURE-----
Comment: Keeping the world safe for geeks.

iD8DBQE7wa0bwBVKl/Nci0oRArHmAKD5J99g07Ndk1VCzdcYGdSq89Y7HQCfT0R6
I4i5vxEe9IqKKwmT20S6SMk=
=dIfC
-----END PGP SIGNATURE-----