Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Wireless ethernet?



On Mon, Aug 13, 2001 at 09:12:18PM -0400, Ron Peterson wrote:

> On Mon, 13 Aug 2001, Derek D. Martin wrote:
> > It seems to me that perimeter security -- limiting the traffic which
> > can enter your network from unknown and untrusted parties on the
> > outside to only that which is absolutely essential for your business
> > or personal needs -- is an essential part of securing any site.
> > Firewalls are a proven tool to accomplish this goal.  I'm unable to
> > imagine a reason why someone would not want to have one, given today's
> > network landscape and the (lack of) ethics rampant amongst a certain
> > subset of the people who hang out there.
> 
> In an academic environment, it's difficult to advocate running a firewall,
> because it involves making a value judgement about what is and isn't
> acceptable.

I disagree with your statement, at least in part.  I agree with the
notion you give as your reason, but I don't agree that your assertion
follows from it.  Most universities state in various documents that
the computing resources of the university are for the use of the
students and faculty of the university.  Certainly mine did.  It
follows then that no more than you MUST do you want to limit the use
by legitimate users, i.e. the students and faculty, who can and should
be able to use those resources to obtain whatever services they need
to obtain.  However the institution also has a responsibility, to
those same students and faculty, to ensure the availability of those
computing resources that are owned by the university, which means they
must protect them.  Students and taxpayers spend millions of dollars
each year on these computing resources, so that the students have
resources on which they may study and work.  And after all, if the
systems are down for days because they have been compromised by
malicious intruders, this also constitutes a restriction on the
freedom of the users to use those computing resources that they (and
we!) have paid good money for.  It is the responsibility solely of the
institution which owns that equipment to guarantee its availability to
its users, and keeping those systems secure is an essential part of
that process.  As the people who own the systems, and who are
responsible for maintaining those systems in a usable condition for
their customers, the institution does and should have the right to set
policy as to what services will be made available from those systems.

Every firewall I've used, software or hardware, allows itself to be
configured such that no outgoing services are blocked, but leave
some/many/all incoming services blocked.  For institution-owned
computing assets, this is well and good.  Students should be allowed
via firewall policy to make any and all outgoing requests, but they
should have an expectation that resources owned and managed by the
institution should have necessary limits placed on what services can
be PROVIDED to the Internet at large, because there are inherent and
potentially grave risks in doing so.  Professionals employed by the
institution should manage those services, so that the institution can
meet reasonable expectations of the students and faculty members for
the availability of the computing resources which are necessary for
them to do perform their respective functions at said institution.

Now, students and faculty members will likely also have their own
computing resources which are not owned by the institution, and I
would agree with you here that those systems should not be firewalled
but by request of the individual who owns it.  Or, perhaps better yet,
the institution should have a policy of filtering by default, but
opening up upon request of the individual.  This helps to ensure that
no judgement be made about how students should or shouldn't use
available resources, but with the understanding that if ill comes to
those systems, it is the student's responsibility to clean up the
mess.

These two networks should be seperated, preferably by their own
firewall.  Clearly the firewall in the first scenario should be the
most restrictive.  The firewall between the two networks should be the
next most restrictive, and the firewall between the Internet and the
student's private networks should be the least restrictive, and
subject to the needs and desires of the students.  It should be
considered a service to the students, and dispensed with as desired by
the students, as you say, to avoid making a value judgement about how
their systems should be used.  Academia has long been one of the last
bastions of personal freedom, and I'll be the last one to advocate
tearing it down.  But one must weigh the loss of freedom of a firewall
against the loss of freedom of having your system repeatedly ravaged
by intruders.  On the one hand (if you use the scenario that I've laid
out) you have a very limited loss of functionality, at least for
students with thier own computing resources.  On the other hand, you
have a complete lack of availability for computing resources for ALL
users of the compromised system(s) while the institution's staff
repairs the damage.

I think the tri-firewall option is clearly preferable to the
no-firewall option for virtually everyone, and I have no trouble
whatsoever advocating it.  And more and more universities are agreeing
with me, though unfortunately some are a lot more restrictive than I
think they ought to be.


-- 
---------------------------------------------------
Derek Martin          |   Unix/Linux geek
ddm at pizzashack.org    |   GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org