[Dshield] The internet -- testing platform, or production environment?

KeithTarrant@spamcop.net KeithTarrant at spamcop.net
Tue Oct 29 23:59:59 GMT 2002

1.  Academia and ISPs just don't understand the scope of the problem.  The
outstanding issue isn't the security of the system I have full control

In production, you need a safe environment for the sites connecting to
you.  In banking, for example, it does no good if my banking system is
totally secure if my customer has a trojan keystroke logger.  In B2B, it
does no good if my system is totally secure but my supplier has been
cracked.  In retail, as a customer, it does no good if my PC is totally
secure but Land's End's server is wide open.

Think about it and you'll see this is your problem too.  For the systems
that are open to them, it is pretty usually true that you are only as
secure as the computers your student's and staff have at home.

2.  Is it an academic right to do what you want on the roads?

Is it academic freedom to be able to test theoretical or test-built
automobile braking systems on freeways?

I think you'll find most engineers, unless they want to argue the
semantics of the wording, will agree that public safety comes first.

Well, in my opinion, the internet is like the public roads.

I say separating unit and system testing from production is proper
professional practice in information technology and electronics

However, as with vehicle testing, the internet is suitable for final
testing (beta testing).

3.  It does no good to say that users need to know more about computers.

We have technology with usability much like that of a Model-T Ford's.
Great for tinkerers.  You can go out and buy the physical parts or
download the modules and build your own working computer.  And spend hours
each week keeping it secure and working.

Where we need to go is the usability of automobiles after 1970, where cars
run for months without attention and years without heavy maintenance, and
you don't need to know anything about vehicle maintenance in order to be a
competent driver.

- Keith

----- Original Message -----
From: "Lauro, John" <jlauro at umflint.edu>
To: <list at dshield.org>
Sent: Monday, October 28, 2002 10:28 PM
Subject: RE: [Dshield] Secure computing (was: Port 135)

> Just adding my ramblings as someone from another academic
> organization...
> > We've had 20 years of no laws but rather consent standards with no
> teeth,
> > and few firewalls installed on a voluntary basis -- and look where
> we are.
> Almost all, if not all firewalls have been installed on a voluntary
> basis, and it has been far more then a few...

Few addresses are firewalled compared with what should be.  Also, I'm
including egress filtering in this.  IMO it should be mandatory that
egress filtering be applied that retail customers connections be subject
to egress filters that at least ensure their source IPs in their packets
are from somewhere on their ISP.
> > Clearly the time for that experiment has runs its course.
> It is far from over.  There will be plenty of new applications and
> services for the internet that haven't even been dreamed about yet.
> That is why many educational institutions don't like firewalls or run
> them default open instead of default closed.  Here I run several
> firewalls with different levels of protections to/from different nets.
> I have better things to do then constantly determining what ports to
> open for the latest experiment on the net.

You run unit tests and system using the real internet?

This is why we need rules-of-the-road with the force of law.  If it isn't
illegal it is okay in the minds of many people.

I can see using the internet to run user acceptance tests, and beta tests
obviously, but not unit, integration, and system tests.

We get new skid-proof steering systems from auto-makers.  The auto
companies do not develop them by doing their initial and development
testing on our freeways.

> Most of our servers are
> blocked for very limited incoming traffic (and more importantly
> outgoing traffic such that a compromised machine is useless).
> However, most end-users only have the standard incoming trouble ports
> (www, telnet, ssh, ftp, etc) blocked unless they request them open.
> If no OS ships with it on by default, we rarely block it on user nets.
> > People are trying to use the Internet in production, but in reality
> the
> > Internet is just in beta test with organizations playing around
> seeing how
> > little they can do (and by "organizations" I mean organizations, not
> > simply academic organizations).
> How little???  That's a cynical point of view...

Are you saying conclusively that nobody tries to see how little they can
get away with?  Or are you playing with connotative words.

> Many people from
> academic organizations look at it as how much they can do.  They do
> not want to be "limited" by a firewall.  It's a subtle philosophical
> difference, but a very important one.

Exactly, not how much good they can do.  And little do some of them know,
let alone care, about the problems the cause for others.

> If you want to change anyone's
> position on the matter, it helps if you first understand their point
> of view.  Although spending as few resources on it is sometimes a
> factor for academic organizations, it's rarely the main one why
> firewalls are avoided by many in academia.

I don't want to focus on academia, because we don't just see this there, a
total resistance to the idea that the internet is a shared public resource
where 99% of users are expecting a production environment.

> There is little you can't block with host based filter rules, and
> access lists in a router (which some would argue is a firewall).  That
> said, personally I find it far easier to have a firewall already in
> place, with better support for logging, and generally easier to make
> live changes to...

In production, you need a safe environment for the sites connecting to
you. I have to rely on their service suppliers to do what our highway
departments do in the physical world -- attempt to make the service they
provide as safe as possible.

Would your campus physical facilities department let the engineers build
test pot holes in the road?

> If your real goal is to get junk packets and hackers off the net, then
> firewalls might not be your best bet anyways.  Your time might be
> better spent recommending passive IDS.  It may not instantly block the
> abusers, but it also does not go so sharply against academic freedom.

It wouldn't stop intrusions but it might be better because it wouldn't go
against so-called academic freedom.  ;)

> In many ways it can be better then firewalls in terms of protecting
> the internet from a sites users, assuming it's configured right and
> the logs are checked...  A hacker stuck behind a firewall quickly
> figures out how to get around it, and one wide open is more likely to
> just create more log "evidence" on the IDS of their questionable
> activities.

Huh?  Not if it is a good firewall.  In fact a lot of times they don't
even know their is a network behind it.  It all depends on how the
firewall is configured.

And what good is evidence if the criminal is in a foreign country, or has
routed through a foreign country?

And what good is an IDS or firewall on my system if my customer is hacked
and is running a trojan keystroke logger?

> > > We trust that our machines are
> > > patched and as secure as we can make them (but still
> > > operational).
> >
> > The new security patches you applied last week -- they weren't on
> two
> > weeks ago were they.
> >
> > So two weeks ago your system wasn't secure was it.
> >
> > The basic principle of security is defense in depth.  Do not depend
> on any
> > one thing because an attacker can defeat it unexpectedly, and be in,
> and
> > you won't have any chance of stopping them.
> Here is one option...  assuming you know he is in...
> Unplug the network cable....  :)

So I want to be safe on the public highways, and you say I should keep my
car in the driveway?

I say, keep the experimental vehicles to the test tracks.

Build your own intranet, as another academic posted his institution does,
and do your testing there.

> Here is one thing to think about as a reason not to use a firewall...
> Your entire network becomes one big honey pot.  If you have any holes
> in your servers, the hackers on the internet will find them for you.
> A hack from the outside will often be easier to detect and less likely
> to alter sensitive data, compared to if someone internally hacks you.
> With thousands of students potentially wanting to hack your system
> from within, you can harden your servers better by just running them
> without a firewall to your network.  (I am not recommending this, just
> throwing it out as something to think about).

If you want a honeypot you build it next to your production system and
typically leave out one layer of protection, so you can watch how they go
after the other layers.

A firewall doesn't turn a system into a honeypot.  A firewall can hide
what services (meaning applications services, not necessarily system
services) are provided where and by what.  A firewall can the system


More information about the list mailing list