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

[Bryan J. Smith]

--=-v2zzzNJ/BaF/KLavraHj
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2002-12-07 at 13:12, Jamie McCarthy wrote:
> True -- though it's a weaker and weaker correlation in recent years,
> I think.

Er, not true at all.  More and more proprietary UDP/IP and even
non-standard/IP transport and application protocols are being created
for Windows applications.  These protocols are often problematic with
regards to firewalls, requiring one to "punch" a hole in the basic case,
or, very often, allow SYN packets to traverse back into your network on
arbitrary ports (not always above 1024 either, but usually).

Now stateful firewalls help somewhat, but not completely.  This
compounded by the fact that I know _no_ "$100-200" device that offers a
stateful firewall (despite any "marketing" to the contrary) -- you need
processor and memory to support such operations and _none_ of them have
nearly enough to do so.

> 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.=20
"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."

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."  Many Windows users get really, really
nasty (which is why I don't blame Richard Morrell for being the way he
is when someone ignorant Windows user "bitches" for the 3rd time --
although he still needs to be mindful IMHO if he wants continued
community support ;-).

> 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.

> My only concern is that there will be discovered denial-of-service
> or compromise attacks on the hardware.  And I am more confident
> that my current setup is secure than the OpenBSD box before.
> Which may seem odd to say.  OpenBSD is considered the gold standard
> for security in PC-hardware unix operating systems.  Why does this
> single-purpose closed box inspire more confidence in me?

I don't expect Windows users to know.  But a Linux user _should_ strive
to understand out of sheer, technical accuracy and dedication to
technical reality.

Not marketing/"ease-of-use."

> 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).

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!

> 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.

> Then the official patch was released but I couldn't figure out what
> I was doing wrong because it obviously didn't apply to my system.
> Then I think the official patch for my version came out later but I
> had already screwed things up.

Again, see my first paragraph in the previous response.

> I was probably totally secure all that time, the most important
> thing would have been properly configuring sshd and my openssl
> daemons to only respond on the LAN NIC, not the internet NIC.

Exactomundo.

> 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."

But, again, be it a commercial or community-based hardware/software
product, there is no difference.

> 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.

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.

> 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 wouldn't trust _any_ "full OS install" as a firewall, even with 3rd
party software loaded, no matter the OS!

--=20
Bryan J. Smith, E.I. (BSECE)       Contact Info:  http://thebs.org
[ http://thebs.org/files/resume/BryanJonSmith_certifications.pdf ]
------------------------------------------------------------------
  The more government chooses for you, the less freedom you have.


--=-v2zzzNJ/BaF/KLavraHj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA98mH5DjEszaVrzmQRAvmdAKDGH/A/++4xhI1OMAMGIcTYNuI1yACgvuUH
AdSC9eJoZRnHB/FZUTBlyyA=
=RSMS
-----END PGP SIGNATURE-----

--=-v2zzzNJ/BaF/KLavraHj--