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

[Bryan J. Smith]

--=-lH3R6HC5KiO9hDcXVY3N
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2002-12-07 at 17:33, Jamie McCarthy wrote:=20
> 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?)

No.  Understand the following applies to IP service _clients_ (not just
servers):

1.  TCP/IP is the _only_ transport protocol that offers session
management that differentiates between "new connections" and existing
ones with a SYN packet.  UDP/IP, ICMP and proprietary/IP
packets/transports act no differently whether or not the packet is
incoming or outgoing.

2.  Many new Windows application protocols expect your network to be
very open.  As such, any=20

3.  Because of #1 and #2, many "simple hardware firewalls" allow various
ports to be directly addresses.  Not just those above 1024 either,
although that's bad enough.  And the proprietary/IP transport mechanisms
often don't use anything that is as "organized" as a port.=20

4.  People blindly believing NAT'ing protects them.  Not.  All NAT does
is associate private IPs transport ports to alternative transport
ports.  If an external host is able to vampire off one of these
mappings, watch out!

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

Yes.  So many things that aren't TCP/IP are just let right through by
default.  Ouch!

I'd rather shut off things and then address various programs as they
need them.

> I just don't receive files by DCC.  :)

???  DCC  ???

> Ditto trying to host a website or a game server.  I Just Say No.

Not just "host," but even a client!  Most people don't realize this!

=46rom the standpoint of _many_ "problematic" transports, there is
_no_difference_ between a "client" and a "server."  And many require the
"client" to _service_ports_ for connectivity!

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

Just believing you don't have them doesn't mean they don'' exist.

> It sounds like you're talking about punching a hole to a specific
> machine.

Get off the "punch a hole" stuff.  "Deny all" firewalls have holes all
over the place!  Why?  It's easier just to let clients work than try to
figure out how to handle problematic transports.

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

That's not "stateful."  "Stateful" means it can inter-relate packets of
different connections, not just change a single connection stream
between two hosts.

"Stateful" requires lots of memory, CPU and coding to maintain.  Orders
of magnitude more than stateless.

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

_Reread_ that section ... especially ...

   "*CASE-IN-POINT*:  All commerical networking software _and_
    hardware is usually 25-50% based on BSD-licensed
    UNIX/networking code."

I was only using Windows as just _one_ example.

Do you know how many of those "simple hardware firewalls" use BSD code?=20
Most small footprint/real-time OSes are just piecemeal 4.3BSD code!=20
Heck, most of them haven't been updated in a decade for such things!

> Didn't hurt though, esp. since my Airport Base Station was behind
> the firewall.

So you're letting wireless devices just access your internal LAN?

> Though I'm quite sure it was configured properly and intruders
> couldn't get in, I wasn't about to leave a buggy=20
> sshd running on my LAN.

SSHd is the _least_ of your worries.  Do you Windows on your 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!

Or just one of your Windows.  Again, SSHd is the _least_ of your
worries.

You keep missing the reality of the situation.  Most people do.

It's like your in a room full of murders and someone points out just one
of them.  So everyone focuses on just that one, while all the other
murders have a field day with the innocent.

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

Once again, you _totally_ missed the point!  Stop and listen!

I'm _not_ talking about a generic, full-blown OpenBSD distro/install.

I'm talking (and have been talking throughout this _entire_ thread! --
go back to the original posts and my responses before you "piped up")
about a small OpenBSD, Linux or other OS-based distribution that is
_just_ for firewalling.  In those cases, you only need to download the
small updates and fixes for them.  Because these distributions are
designed for _one_ application, firewalling.  And the community behind
them is only releasing fixes for that and that only.

Do you get what I'm driving at here?

=46rom your [flawed] viewpoint, there is only 2 firewall types:
- PC with full-blown OS install/distribution
- Proprietary, simple hardware firewall

And I'm pointing out there are dozens of other options, including:
- Firewall-specific OS distribution

> 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.  ... cut ... Again, hassle.

How many times do I have to go over this?  As I said before ...

   'I wouldn't trust _any_ "full OS install" as a firewall, even
   with 3rd party software loaded, no matter the OS!'

So don't tell me how good/bad a full-blown OS install is for
firewalling, I _know_ it sux!!!  That's what I've been trying to tell
you!  You're just not hearing me and you continue to make assumptions.

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

No.  You are exploitable by the things that your box does not bother to
address.  You do not have to be providing Internet services to use
transport protocols that request things from your box.

> I don't see how this relates.

I know you don't.

> And malfeatures are often posted to bugtraq, BTW.

Bugtraq recently admitted it only covers about 25% of exploits for
products.

And, again, a "malfeature" doesn't cover something that isn't promised.

> I didn't say that.

But you continue to make that point.

*SPECIFICALLY*

You make the point that "simple, hardware firewalls" are better than
PC-based firewalls based on your experience with a full-blown OpenBSD
install on a PC.

I make the counterpoint that you're experience with a full-blown OpenBSD
is the worst approach for a firewall.  Firewalls should _never_ sport a
full-blown OS!  But there are many, excellent and far more secure
PC-based firewalls with an OS distribution made _specifically_ for
firewalling and nothing else.

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

Ah, finally.

> I chose not to because the cheap boxes that I have that
> it would run on have fans (for power supplies and CPUs).

Actually, I have a couple of LPX/NLX systems that are extremely quite
with little-to-no active cooling.  Cost me under $50 in most cases.

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

We're talking wireless here, correct???  [ TheBS rolls his eyes ]

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

Of course, because you basically picked the worst PC-base solution you
could.

And the other point I want to make is that the worst security exploits
are those you don't know about.  When you are indeed compromized, you
don't know about it 98% of the time!  Which is what most people don't
realize.

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

Oh, and that's exactly what I'm trying to "force" you to do then in your
eyes, eh?  I'm just another Linux bigot?  And I don't believe in using
the right tools for the job if it's not Linux?

> Networks and networking hardware are tools to get me from Point A
> to Point B, securely and quickly.

The problem is that the last two attributes are often in conflict.  Now
you _can_ get security through only little-to-moderate effort by
understanding the technology.  But I find that 98% of companies not only
have "false security" but actually increase their risks by adopting
security products.

> This works for me, it's better in every respect from what I had
> before, and that's my experience.

So your view is that:

A.  You do not evaluate your options
B.  You base your experience on a solution that I have already informed
you is the worst for the application
C.  You assume great effort is required for adequate security
D.  You want effortless security
E.  A compromised system is considered not compromised if you don't know
about it

Use what you want.  I don't care about that.

What I care about is when you discredit a solution that you have not
correctly evaluated.  And that's where you came in here, which caused me
to discredit your view.



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

--=-lH3R6HC5KiO9hDcXVY3N
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

iD8DBQA98sH0DjEszaVrzmQRAhJOAJ9Q21FAyutpql0SD54z6wkxQk+2ZQCgwpJL
45gw77Y++R0kFsxU87hGCdw=
=MHeQ
-----END PGP SIGNATURE-----

--=-lH3R6HC5KiO9hDcXVY3N--