On Fri, 27 Apr 2001, Karl J. Runge wrote:
> Yes, one drawback of a "safety shield" script like the one I am talking
> about is that it can encourage laziness.
I'm not so much worried about that (you can only do so much) as
misrepresentation. Any such script should be clearly documented with
glow-in-the-dark comments to the effect that a firewall alone is not
sufficient.
>> Datagrams destined for the current host are always reassembled, and thus
>> always processed by the firewall code.
>
> What you say makes sense, but I was playing around with this script a few
> weeks ago on the road with my laptop modem ...
Hmmm. Go figure. The docs for that option led me to believe that firewall
processing happened *after* normal destination host fragment reassembly.
I just looked at the code. File <net/ipv4/ip_input.c>, functions
ip_local_deliver() and ip_rcv(). ip_rcv() calls ip_defrag() if and only if
ip_always_defrag is true. Then the firewall code is processed. Then
ip_local_deliver() is called (if appropriate), which calls ip_defrag() if
ip_always_defrag is not set. So if ip_always_defrag is false, fragments are
not processed by the firewall code.
Important to know!
> Also note the odd way ipchains kernel code handles fragments. It seems to
> say fragments are port 65535 -> 65535!
That smells like a leftover from the old 2.0 IPFW code. To match fragments
with ipfwadm, you had to match on "port" number 65535 (0xFFFF).
> As far as the example script goes, I think I'll keep it ...
I would leave it on, regardless, because even if it did work as advertised,
there is always the possibility that forwarding might be turned on (either by
accident or on purpose).
> Unless I am mistaken, this will now ACCEPT a spoofed packet from
> 24.128.1.81:53 *into* 2049 (my NFS server).
Yes, which is fine if you know your NFS server is listening on 2049. But
like I said, there is nothing that guarantees RPC services will bind to any
particular port. A sample script which is going to be distributed should not
assume a particular NFS implementation detail will be the same elsewhere as it
is on your system.
> If I have missed what you are saying please let me know. ipchains does
> not seem to allow a list of ports like:
> --dport ! 0:1023 2049.
No, you are right there, a single entry in a chain has two ports for source
and destination, which specify a contiguous range. A single-port rule simply
has the same value for the min and max of the range. (<struct ip_fw>, defined
in file <include/linux/ip_fw.h>)
> Also, from the pedagogical angle, I think it might be easier for people
> to understand the UDP protection as 3 phases:
>
> 1) Protect "known" UDP service ports from *any* external access.
> 2) Let in a few UDP packets from "trusted" servers (e.g. DNS)
> 3) Deny everything else (both in and out).
This is a good strategy, except for the issue of not knowing what those
service ports are... :-)
> Note that I also choose to use no Bourne shell variables or looping ...
I actually think such variables can significantly clarify things; they
separate general rules from site-specific data. Personal preference, I guess.
The sample script you inspired me to write is using variables. ;-)
> True. As a partial solution in the past I have had a script use
> the list from:
>
> rpcinfo -p | grep udp | awk '{print $4}' | sort -u
>
> of course this is slightly prone to error since the person may
> reconfigure his UDP services without resetting the firewall, etc.
Indeed, a "good" firewall should start *before* the portmapper does, so that
is not so helpful.
My personal feeling is that there is nothing you can do about it. Even if
you could nail down RPC services, various other things (many GNOME apps, for
example) open more-or-less arbitrary listeners on various ports. Trying to
catch them all is (1) futile and (2) leads to a false sense of security.
Better to face the music: A packet spoofed to look like it is coming from an
external DNS can get through. If this bothers you (e.g., because you are
running NFS), run a locked down caching nameserver locally, set your
resolv.conf to localhost, have the nameserver send queries from a fixed port,
and firewall everything else. That is what I do at home.
We're fairly fortunate that to anyone running a portscanner, it is going to
look like those ports are closed. Someone would have to send spoofed packets
to random machines in the hopes of getting lucky. The chances of actually
succeeding at such an attack seem low enough to be sufficient protection.
Remember, Internet security, like automobile security, is mainly about being
a less interesting target then your neighbor. :-)
--
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or |
| organization. All information is provided without warranty of any kind. |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
