David -- Some random, fragmentary responses to your concerns. Take them for
what they are worth.
At 05:26 PM 12/29/00 -0600, David Douthitt wrote:
..
>* Protected net: what about limiting internal users access to outside?
What about it? One method is to block outgoing packets to and replies from
certain ports (e.g., DENY all traffic on the external interface *to* and
*from* port 23 to block telnets). Another is not to MASQ the entire LAN,
just the addresses of the hosts that you want to have outgoing access. The
tightest approach is not to route at all, but to use proxy servers on the
firewall instead.
None of this is bulletproof. What to do depends on the kinds of limits you
want to impose and who you want to impose them on. (Me, I'm particularly
interested in cron jobs that modify the firewall based on time of day, so,
for example, kids can use the Web from 6 to 9 pm but not later.) How
sophisticated are the users you are trying to limit?
...
>* Servers on the firewall: this isn't as odd as it sounds. The first
>is ssh.
Not odd at all. DHCP and DNS (forwarding) are the other (perhaps even more)
obvious ones. I can imagine LANS where the firewall handles SMTP and POP3 as
well (as well as imagining the arguments against doing so, so please let's
not get into that).
>* Servers in the unprotected net....!
>
>The BIG question: how do you ACCOUNT for all these?
>
>In particular, I'm implementing Oxygen as a firewall for an internal
>private network, so this really IS relevant. I also want to set it
>up at home, sooner or later, if I can get the modem and then PPP to
>work. I don't trust serial communications - it almost certainly
>never works the first time.
We've had DSL for a year now, so I'm vert rusty on dialup. But we did have a
Debian-Slink-based router/firewall here handling our PPP dialup account for
a year or so before we got DSL. Worked like a charm ... the unreliability
was at the ISP end, not at our end.
>Regarding firewalls, consider these problems/examples:
>
>* Internal firewall inside: now you can't reject all private IPs from
>the unprotected net.... since it also uses private IPs.
Right. You put the rules that REJECT or DENY private addresses *after* the
ones that ACCEPT appropriate traffic to/from the actual address ranges used
on the LANs.
>* Masquerading: on a standard Internet firewall, you would masquerade
>the internal network - but what about a firewall INSIDE a
>firewall....?
You can double MASQ; I've done it here for test purposes, with a setup like
this:
NAT'ing NAT'ing
workstation <--> router <--(LAN)--> router <--> DSL <--> Internet
#1 #2
Worked fine. Router #1 used ipchains (kernel 2.2.17), #2 ipfwadm (kernel
2.0.36), from Debian Potato and Slink respectively.
>Another thing - which HURTS:
>
>* When I define a TCP transmission path, the two directions are
>defined in separate chains/rules whatever; you can't define a rule
>which says: "allow an outbound TCP connection on this port" - this is
>actually TWO steps - outgoing, and incoming.
