[KLUG Members] Re: Broadband firewalls -- flawed logic and analysis ...

[Jamie McCarthy]

Whoa.  I'm not sure what I said here.  I'll try not to say it
again.  :)

Some background may help.  First, I'm pretty savvy when it comes
to security;  I actually know what I'm doing.  Second, this is
just a home network, I'm not maintaining a whole roomful of
business machines and I'm not recommending anyone else follow my
example.  I'm just explaining my reasoning for this one decision
for my home LAN.


b.j.smith@ieee.org (Bryan J. Smith) writes:

> > Certainly there's no inherent necessity that bad UI design
> > and good security design need to travel together!
> 
> Yes, I understand that point.  And that's great for us
> sysadmins.  Using an automated "rule creator" and a
> "point-n-click" list of common rules helps prevent us from
> writing an incorrect rule which might be exploitable.  I agree.
> 
> *BUT* 98% of "end-users" just want a "Plug-n-Play" solution.
> "Plug-n-Play" means, "oh, users will bitch about
> 'incompatibility' if we don't let this protocol through from
> the get-go, so we won't block it by allowing this through."

Doesn't apply to me (nor to this particular model of firewall).
By default no protocols are allowed through.  If you want them you
have to click on the "DMZ" link and specify what connections from
the outside go to which of your internal machines.  (We're talking
about the same thing, right?)

Personally I don't give a rip.  Eh, people can't DCC me files in
IRC.  I don't care enough to figure out how to punch a hole in
the firewall to enable it;  I just don't receive files by DCC.  :)
Ditto trying to host a website or a game server.  I Just Say No.

> I know, I've been on various lists and try to explain these
> concepts to the non-technical.  When I try to explain the
> application design is at fault, their return attitude is, "this
> is broken, fix it, people run this app, so you need to fix it."

I'm both the netadmin and the user, so I don't have these issues :)

> > For my needs, it doesn't matter.  I don't have a DMZ, I'm not
> > running any servers that are visible to the outside.  Nothing
> > gets onto my home network except in response to connections I
> > initiate.
> 
> ???  Yes, stateful firewalls _do_matter_ even for outgoing-only
> connections!
> 
> We're not just talking Source v. Destination NAT here. Stateful
> firewalls do _so_much_ more!  They often remove the requirement
> that you leave ports 1024+ "wide open" for various, poorly
> designed Windows application protocols to work.

It sounds like you're talking about punching a hole to a specific
machine.  As far as I know the MR314 is stateful in that -- here's
the one example I know of, there may be more -- it detects when my
FTP client makes a PORT request in non-passive mode and allows the
response to come back in.  No "wide open" ports required.

> > Because OpenBSD is also fairly complex.  In the two or three
> > years I had it running, my version (2.8) got left behind.
> > Instructions for keeping up with the latest patches were not
> > terribly clear and sometimes contradictory.  When the big
> > ssh/ssl attack came out (earlier this year I think),
> 
> Okay, stop right there.
> 
> First off, your mis-understanding of what a "firewall" is the
> problem right there.  You do _not_ want to run _any_
> Internet-available services on a firewall.  As such, a
> "firewall" would _not_ and should _not_ be running _any_
> services that require SSL (except maybe SSH, and then it should
> be _only_ answering requests from "trusted" interfaces like the
> LAN).

As I noted, I wasn't running any internet-available services.

> Secondly, OpenSSL is BSD and many _proprietary_ Windows
> _applications_ were affected by the OpenSSL bug!  I
> _hate_hate_hate_ the IT media for missing this point!!!  I was
> on the OpenSSL list and _damn_ if different, proprietary
> Windows software developers didn't "pipe up" about the issue.
> 
> [ NOTE:  This is a _exact_repeat_ of the LibZ hole found, where
> the IT media "bashed" the Open Source world for letting such a
> hole go unnoticed in such a common app.  Even Microsoft is
> using LibZ code in the _core_ of Windows and was suseptible!!!
> Pisses me off! ]
>
> *CASE-IN-POINT*:  All commerical networking software and
> hardware is usually 25-50% based on BSD-licensed
> UNIX/networking code.  And I'm not just talking "legacy" code,
> even Windows itself sports a lot of _current_ BSD software
> code.  And once you factor in all the other software that
> people use, even in embedded devices, ouch!

That is all irrelevant to me as I don't use Windows.

> > I applied what I believed to be a preventative patch, by
> > hand, and recompiled and reinstalled by hand.
> 
> Again, see my first paragraph in the previous response.  You
> probably didn't need to do this.

Didn't hurt though, esp. since my Airport Base Station was behind
the firewall.  Though I'm quite sure it was configured properly
and intruders couldn't get in, I wasn't about to leave a buggy
sshd running on my LAN.  The black hats could have parked on my
driveway at 4 AM, used an unpublished exploit on the Base Station
and r00ted my firewall!

No, I'm not much paranoid :)

> > But I just wasn't sure I was applying patches properly and
> > that's when people get into trouble.
> 
> Correct.  Which is why support for a _specific_ application, be
> it commercial or community-based, is always best because it
> "pools" the support resources and drastically reduces the
> effort you yourself have to make to "stay current."

What I would have had to do is keep upgrading to recent versions
of OpenBSD.  Which is a hassle I didn't need.

My version of OpenBSD, by the way, is the one that got its
firewall software yanked out a year after release because of a
licensing feud/misunderstanding.  It was replaced with something
else that started out not very robust.  "Staying current" would
have meant not only upgrading the OS to 2.9, 3.0, 3.1, 3.2, but
learning a brand-new configuration of the firewall itself.
Again, hassle.

> > Now I just watch bugtraq.  If something about any NetGear
> > product comes over the wire, I'll notice. and I'll update the
> > firmware. Searching for past problems with similar NetGear
> > products turns up a workaround for its censorware (which I
> > don't use) and a note about how passwords appear in plaintext
> > if you dump the firmware to disk (and I would always treat
> > those backups securely anyway, there's other sensitive info
> > besides passwords).  So the track record looks pretty good
> > and I think I'll be fine.
> 
> Er, that's because the device _only_ does certain things.  You
> cannot fix a "hole" in a product that is inherit in its design.

Sure, but the only things it does are the only things I need.

> E.g., Windows itself has an "inherit bug" (which most users
> would bitch if it didn't have) that blindly executes _any_ file
> that has the MZ/execute "file magic" as an executable.  This is
> a problem because the Windows explorer will pass on a file to
> the "launcher" based on extension or MIME Type, not checking to
> see if that "file magic" exists.  And you never see a "bug
> report" on that, because it is _inherit_ to Windows design. 
> You just see "bug reports" on _other_ products, or literally
> hundreds of thousands of "viruses" that take advantage of it
> that would _not_ show up on Bug Traq.

I don't see how this relates.

And malfeatures are often posted to bugtraq, BTW.

> > The big win is that there's no hard drive on this box and
> > there are no rootkits for it.
> 
> You can easily do the same with Linux too.
>
> In fact, there are lots of free, Linux-based firewalls that
> offer this capability, combined with the "easy update"
> mentality that you like about those simplistic hardware
> firewalls.
> 
> Your logic is flawed because you make these false assumptions
> about the available options.  You think it's only a choice is
> either a "simplistic hardware firewall" or a box with a "full
> OS load."

I didn't say that.

Look, you can point out other choices, that's fine.  I'm well
aware that I could build an x86 box with no hard drive and run
a floppy-based Linux distro that doesn't have a shell to drop
into.  I chose not to because the cheap boxes that I have that
it would run on have fans (for power supplies and CPUs).  I have
tinnitus, so I'm trying to reduce noise in my office, and
replacing a PC with solid-state electronics helps a lot.  Also,
there's the Airport Base Station factor;  replacing that meant a
simpler network architecture, which is a big security win, and
there are other advantages too.

I appreciate that you have experience with this.  I don't
appreciate being told my logic is flawed, because it isn't.  All
I'm saying is, the closed $100 box works for me and overall it's
better now than it was before.

I'm a perl hacker, not a kernel junkie.  I don't think I have to
prove my love for the penguin by getting out screwdriver and
soldering iron to build myself a custom solution to every
low-level problem that I have.  Networks and networking hardware
are tools to get me from Point A to Point B, securely and quickly.
This works for me, it's better in every respect from what I had
before, and that's my experience.