RE: cable modem access

["Joe Ippolito" <joe () joesnet com>]

If you are more inclined to Windowing you could put up MS Proxy on NT4.
Just make sure you add SP4, turn on packet filtering, disable IP forwarding
and disable the WINS client (NetBIOS) services on the external interface.
It makes an effective and easy to use firewall for the GUI types.

> -----Original Message-----
> From: owner-firewall-wizards () nfr net
> [mailto:owner-firewall-wizards () nfr net]On Behalf Of Bennett Todd
> Sent: Thursday, April 15, 1999 11:39 AM
> To: twalls - Troy Walls
> Cc: 'firewall-wizards () nfr net'
> Subject: Re: cable modem access
>
>
> 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.