[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: my isp is being told *i* am broadcasting spam?



Shawn,

I didn't mean to leave you defending firewalls on my behalf.  You've done
a good job!

After 40 years designing electronic circuits and programming computers,
some of which have been in mission critical applications like nuclear
subs, I've met many of the personalities which occupy those professions.
Some are rocks -- rocks don't learn much -- usually argue both sides of an
issue unknowingly, and spare no names for those who don't submit to their
logic. Others listen carefully, ask good questions and offer good advice.

Noah doesn't believe in firewalls.  Running secure servers directly off
the Internet is good, (better?) and besides firewalls don't do you any
good.  As proof of this, Noah quotes an instance of an NT server being
cracked via port 80 and that machine subsequently infected other machines
on its network.

The only proof I see here is the fact that the system design was
inadequate. A good design deals with failures in hardware or software with
minimal disruption of services, so rather than conclude that firewalls are
no good, let's look at the system design some more.  We'll say something
later about using machines in public space which have a history of
vulnerabilites.

Servers in the DMZ should not be serving up anything that isn't
permissable as public information.  They should have no content on them
which would be a liability if exposed to the public.  Servers in the DMZ
should not be allowed to initiate any connections -- except
surreptitiously. No server in the DMZ should listen to or accept any input
from other servers in the DMZ (shared applications aside).

So, your boss insists you run an insecure OS in the DMZ.  You know it will
be cracked before long, but it's pretty much contained with the
constraints stated above.  Provided the other servers are secure, as Noah
claims they can be, then all you have is a single failed server in the
DMZ, which all the other servers know has been compromised because it's
breaking the rules and trying to initiate contact.

Are the connections all severed and the system effectively disconnected?
No, servers in a trusted zone, connected to the DMZ via a firewall can
initiate connections to servers in the DMZ.  Obviously that should be done
using encryption.

Trusted servers, polling servers in the DMZ, is a bottleneck and,
depending on latency, may leave critical data on the DMZ servers long
enough to be cracked.  This is where we resort to surreptitious
communications.  One of the obvious things a server might do, when it is
processing on-line transactions, is to print them.  But printer isn't
listening on the other end, a trusted computer is.  To a cracker, what's
going out on the printer port looks pretty normal - transaction data.
Besides normal transactions going out the printer port, a regular time
tick is printed. Does a cracker dare turn off the printer?  Not likely.
Will a cracker wonder what some of those strange numbers are that get
printed? Maybe.  Will they figure out that those numbers are an encrypted
message which represents a spread spectrum shifted checksum of running
processes?  Not nearly as fast as the trusted listener will know that
something has gone wrong with the DMZ machine.

Besides providing that `ping' which the trusted server needs to hear on a
regular basis, the ping can also indicate that the trusted server needs to
initiate a connection and get/put some information.

I'll repeat, as near as memory allows me, that there are two kinds of
computers hooked to the Internet, those which have been cracked and those
that will be. Running a broad range of services on those Internet
connected machines only means they will be cracked sooner than later. I'm
aware that this is a `ridiculous' statement, so no further flames are
required.

Once again, I repeat that security will be better with a firewall, running
a minimal chunk of code.  Those machines which allow connections to be
made from the Internet should be in a DMZ -- including both web servers
and mail servers. Servers in a DMZ should not be able to talk to one
another unless they are sharing a common application.  Data collected on
the DMZ servers, which must not become public information, should be
quickly pulled off those servers by a trusted machine which initiates the
connection via a secure channel.

There are many ways to surreptitiously monitor servers in the DMZ to
detect their failures and/or compromises, the printer port being just one
of them. Operating an OS in the DMZ, which has a history of exploits, may
be a political necessity, but as a system designer, it's your job to
contain that expected exploit as quickly as possible - a trusted machine
can pull the power plug a lot faster than rousting the sys admin out of
bed to do it. Complaining that firewalls are little more than a false
sense of security doesn't do much to address the requirements of the
system or provide a design to meet those requirements.

As a consultant who spent more months than I want to remember as a key
player in the design of a double redundant communications and failover
system for multiple computers operating a uranium enrichment facility, I
have some ideas about what it takes for computers to share a sense among
themselves that they are working OK. I also know that there will always be
some uncertainty - two people with watches generally don't know what time
it is, though they generally know the time.

I've provided the method I would use for a secure and robust system.  If
it works properly, it will contain an exploit to a single DMZ server. That
exploit will be detected in a reasonable number of milliseconds by a
trusted machine. Corrective action will be automatic. With failover to
another server, the system will continue to operate without the loss of
any transactions.

Anyone who can improve on this model, or show that an alternative model is
more secure, can be sure I'm all ears.  If you don't understand the
presentation, ask me to elaborate or provide an example.

And yes, flames are welcome too.  Forest fire fighters use firewalls,
sometimes successfully, to contain flames, but for the rest of use there's
procmail and /dev/null.

-- 
Sincerely,

David Smead
http://www.amplepower.com.

On Sun, 21 Apr 2002, Shawn McMahon wrote:

> begin  Noah Meyerhans quotation:
> >
> > I just don't see how that gets you anything at all if only the "trusted"
> > ports have any services listening on them.  I have seen personally a
> > WinNT box, behind a firewall, with only port 80 visible to the world get
> > cracked.  Not only was it cracked, but it was then used as a launch pad
> > for an attack on another box that was also in the DMZ.  All that was
> > with only port 80 open.
>
> Ok, I don't see why "this has not been sufficient in some circumstances"
> translates to not getting you anything at all.
>
> Every security tool ever used fails this test you seem to be using.
>
> > Basically, my approach is to assume that all ports on all hosts are
> > visible to the world.  To me, this as a fundamental fact of networking.
>
> That probably works on a small network.  Try it with several thousand
> servers and 200,000 users, not counting internet customers.  Or try it
> with an ISP, where you can't control the configuration on ANY of the
> users' computers.
>
> I've worked in both situations.  Firewalls are a godsend.
>
>
>


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: