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

Bryan J. Smith members@kalamazoolinux.org
08 Dec 2002 00:52:53 -0500


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

On Sun, 2002-12-08 at 00:19, Robert G. Brown wrote:
> I claim a vulnerability is anythng that permits resouce use that is not=20
> desiable (meaning: required to acheive a goal that the facilities exist t=
o
> do. ...
> No, Bryan, these are vulnerabilities, even if they're designed in.

IMHO, it is undesireable to allow everything access to ports 1024 and
above.  That's exactly what these "simple, hardware firewalls" do.

That's the _original_point_ I made.  I'm not a security expert -- I'm
just a "white hat guy" who knows how protocols work at the lower layers
(even layer 1).  I don't follow a lot of the "gray hat" area -- it's
just too much to keep up with.  I start with an "anal" approach for
"deny all," then turn things on as needed.  That's the "safest
approach."

These "simple, hardware firewalls" do the opposite.  They start with
"allow all," then disable commonly known services.  They work with most
applications "out-of-the-box" as a result, and do nothing to combat
client-side desktop exploits.

E.g., IMHO, at a "bare minimum," a "deny all" firewall (without proxying
connections**) should start with:
- No ICMP,
  except type 3 inbound (destination unreachable)
- No UDP at all,
  except 53 and _only_ for the outgoing-dest/incoming-src=20
- No TCP-SYN at all,
  period
- No inbound _nor_ outbound traffic at all on numerous ports,
  both under 1024 as well as above
  (using a list of hundreds of "common service, trojan, etc..." ports)

This breaks a lot of things.  I then address specific services that are
required by evaluating them.

[ **Of course this would be ideal -- block and proxy _everything_.  I
understand this is not feasible on most home networks though.  Security
is all about weight the cost versus the potential for loss in a
compromise. ]

> This cripples your presentation, and makes eveything you're writing seems=
=20
> vague, general, lame, and half-baked. You are _mising_ _the_ _point_!
> I asked for an EXAMPLE, not a TOME or a TEXTBOOK. I few of us know a thin=
g or
> two about the topics you mention above. I suggest you proceed.

First off, I don't run into this much myself anymore, because I'm pretty
much 4 years removed from Windows software.  I'm not going to have many
personal examples, although I could spend a couple hours researching
some good ones from my past.  I don't profess to be a resource of
protocols other than basic FTP, HTTP, SMTP, etc... largely because I
haven't used Windows for over 4 years.

For the most part today, whenever my wife (a teacher) runs into them at
home -- e.g., some ActiveX/Java applet, or proprietary software program
for a public site/reource -- due to the configuration of my firewall, I
usually ask "do you really need this?"  Most times she says "no," so I
don't bother to research them and the possible exploits with punching a
hole in the firewall to freely allow their packets to move through.

If I just had a "simple, hardware firewall" they would work just fine,
without forcing me to take note that they expect things to just fly
through.

Now let's talk about the Quake/UT clients.  They are actual services
that require your client to service arbitrary ports from the game
server.  And many use ICMP packets liberally.

Now a stateful firewall usually can track these sessions between
connections.  A stateless firewall will only work if it leaves all ports
above 1024 open for UDP/TCP.  It would be far better to use a stateful
firewall IMHO.

Again, I'm not going to have any recent examples for you.  Heck, some of
you guys probably follow CM, BT and other lists far better than I.  I
just use a "White Hat anal" approach to firewalling, and don't deal with
programs that need extra access (except in rare, _temporary_ cases --
e.g., even I like UT, and accomodate it _temporarily_, as securely as
possible, when I want to play it ;-).

But I don't support the "I'm more secure because I don't have to mess
with it" attitude.  Especially when it's a "we allow this by default for
compatibility" approach to firewalling.

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


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

iD8DBQA98t41DjEszaVrzmQRAjdMAJ4z49kBHWvocCFvzXxpt5kaK9XkmACcCTF1
JnvKoYEGW+QZebIr1IQTWLo=
=IZUs
-----END PGP SIGNATURE-----

--=-dX6cMScaIKqbKz32UkOm--