[unisog] Sightly OT: Re: [unisog] University virus-writing course?

Keith Schoenefeld schoenk at utulsa.edu
Tue Jun 3 15:02:18 GMT 2003

We have a very similar situation here at The University of Tulsa.  We
have a computer security group that appears to be doing many of the same
things that you report. When we recently  instituted our first firewall
(that covered the class B network we have), they wanted nothing to do
with it -- it blocked their ability to do some of the things that they
were used to doing.  We weren't really impressed with the idea of having
some subnets firewalled and others not firewalled since we use VLANs in
the local buildings, and that would put firewalled and non-firewalled
networks on the same hardware (only seperated by VLANs, which is not

I've found that if I try to fight academics, particularly academics that
bring in large quantities of research money, I loose way more often than
I win.  The solution we came up with protected our "production" network,
while allowing them to do whatever they want on their "research" network
(and we, we being the sys and net admins on campus, aren't responsible
for what they do on their research network -- that shifts the
responsibility off of the sysadmins and on up the chain of command).  We
set up an additional router just behind the border router (in addition
to our core routers).  We masked off a set of 15 subnets from our class
B, and routed all 15 subnets to this new "research" router.  

We configured the "production" firewall so that it allows all traffic
from our class B to access anything else on on the class B (including
allowing all traffic from research to pass into the production network
and visa versa.  We otherwise set up our rulesets on the firewall to
block outside traffic (traffic from somewhere other than our class B or
to somewhere other than our class B) in the manner set forth by policy.

We then went back to the "research" router, and set up rules so that the
research network's router blocked all traffic to and from our
"production" network in the same ways that our firewall blocked traffic
between the "production" network and the outside world.  We set these
blocks up on the research router instead of the production firewall so
we can add or relax restrictions on traffic between the research network
and the production network without making configuration changes on the
production network to do it.  This way we only have to make changes on
the research router.

Our central networking group still handles the management of all the
switches, routers etc. on the research network, but we do not monitor or
block any traffic to the research network, and we only block traffic
from the research network if it's destined for our own "production"

All that being said, you seem to want a political solution (how do I
convince these people not to do this) as opposed to a technical solution
(I understand they're going to do this no matter what I say, so what
hardware do I need to have quotes for when they come to me asking how
expensive this is going to be).  I can't (or won't) help you with the
political other than to say it's almost always better to determine the
"best" way to do something, including costs, and let the "higher powers"
decide what risks the university is and is not willing to take.  With
any luck, having something like this research project on your campus may
force the CS department to realize the fact that security needs to be
taught in more than "one or two courses", but rather should be taught
and emphasized in every CS course.

-- KS

More information about the unisog mailing list