Re: cable modem access

[Bennett Todd <bet () newritz mordor net>]

1999-04-14-13:50:21 Troy Walls:
> I know this group is dedicated to helping network administrators with
> firewall issues that they deal with at their workplace, however, I have
> a slightly different twist on my problem. It is not directly workplace
> related.

I don't think I agree with you; I think this group is for discussing
firewalls. It may be the case that most of the firewalls discussed are used at
work, but I don't think that's any part of the charter.

> I have a cable modem at home.  I have some concerns about the security of
> the setup.

Good for you!

> I have this installed on a stand alone machine whose only function is
> internet access. I want to change that and put three other machines on the
> cable modem through a network. I have installed Cat 5 cable, and purchased a
> 10/100 hub for this activity.

Sounds like a great plan.

> I have considered a linux server as a front end and firewall, however, it
> will be a learning experience to get it up an running. Is it the best option
> as a firewall? Are there better options? I have a win95, a win98, and a
> NT4.0 workstation that I want to put behind a firewall.

In general, a separate "bastion host" firewall box is a great idea if you
cannot secure the other boxes you want to allow to access the internet. For
your setting, you'd have two reasonable choices, and I think most people would
advocate the firewall only if choice #1 won't work for you for some reason.

#1: secure the individual machines. This is easy for a Unix admin to do with a
    Unix system; I've heard it claimed that Windows-savvy people can do this
    for Windows machines as well. I don't do Windows, I can't say. In
    principle all this requires is that for _Every_ network service --- every
    network port --- there should be one of (a) no daemon listening on that
    port at all; (b) low-level packet filtering guaranteeing that a daemon
    can't actually get any packets from that port, or (c) a daemon whose
    security is believed good, with a carefully-reviewed configuration.

    When pursuing this choice, it's a great help if you have a "netstat"
    command (that's its name under Unix, dunno if there's anything like it for
    Windows); this lists all open network ports on the local machine, along
    with info that can be used to help track down what daemon is doing the
    listening. Netstat checking should be your first line of defense. But just
    for an extra check, gives me the warm comfies, get yourself a port scanner
    and double-check to confirm that there are really no unexpected listeners
    running.

#2: If you can't secure the individual machines (commonest in a corporate
    setting), or you just want the redundant extra security of an extra layer
    of protection, you can set up a bastion host firewall. For that job I'd
    recommend a good open source OS. I prefer Linux, because I find software
    packaging an invaluable configuration control aid, and RPM is the best
    software packaging tool I've met yet; second choice would be OpenBSD,
    mostly if I wanted to set up the bastion using a hardware platform that
    was supported by OpenBSD and not by Linux (not so many of those these
    days:-).

    On your bastion host, you first secure it exaclty like #1 above, then add
    suitable provisions to let your traffic through. The least secure such
    provision is packet filtering; this lets your firewall enforce some kinds
    of policies restrictions (what src/dst port numbers will be permitted),
    but not others[1] (what protocol is talked over that port); and packet
    filtering also doesn't protect the client machines from weird packet
    formats, since it lets the original packet through, rather than
    re-wrapping the payload in a brand new packet header generated by the IP
    stack on the bastion.

    So when _I_ set up a bastion, I like to load up packet filtering on it, to
    provide a separate and independant reinforcement of policies that are
    specified and enforced elsewhere, but I do the real control work in
    proxies. What's more I prefer non-transparent proxies. This makes the base
    bastion host really easy to configure:

        (1) Load the latest Red Hat Linux, minimal config;
        (2) Strip out all daemons;
        (3) Check the updates page for any package containing
            security-critical fixes to stuff you will be using;
        (4) Add and configure packet filtering;
        (5) Add admin remote access if necessary (tightly-configured sshd);
        (5) Add proxies: qmail or Postfix for SMTP; http-gw from fwtk for http
            and proxied ftp.

    Additional frills can be tacked on as needed; for each frill, decide
    whether the resulting security will be satisfactory, and whether the
    implementation cost will be justified by the benefits of having the
    service available.

-Bennett

[1] Some fans of packet filtering love to argue that "stateful" packet filters
    can do absolutely anything that proxies can, on the grounds that a
    complete understanding of any policy statement can be encoded in a
    sufficiently large and baroque state transition table. Given sufficient
    table capacity, these fans are theoretically correct. Given limits on
    human abilities to create, understand, maintain, or audit really big state
    transition tables these fans are in practice wrong.