[unisog] Firewall Administration

Russell Fulton r.fulton at auckland.ac.nz
Wed Jun 8 22:46:59 GMT 2005

On Wed, 2005-06-08 at 13:29 -0400, Hart, Lee Anne wrote:
> If you don't mind sharing, who maintains your firewalls - hardware and
> operating system, not the firewall software? Currently, our IT
> Security team are the only people with access to our firewalls, but
> our networking group is asking for some rights to maintain the
> hardware and to be able to reboot them. I have mixed feelings about
> this and wanted to know how other organizations handle this. Also,
> what are some of the pros and cons of this?  Thanks,

Hmmm.... it depends very much just what the function of the firewall is
and what it is designed to protect.

As for who actually manages it -- I don't see this as a big deal.  The
important thing is that responsibilities are clearly spelt out and that
those responsible have adequate training.

My preference is that Network engineering look after the box its self
(OS etc) -- it's just another bit of network infrastructure -- they are
also responsible for basic functionality (getting bridging or routing
set up).  Security then has oversight of the rules.   If I were a
network manager being held responsible for 7x24 performance of the
network I would feel twitchy if there was a vital bit of infratructure
in the middle of my network that I had no control over.

We have two firewall systems on campus. The first is the perimeter
firewall that separates us from the internet.   The management of the
firewall rule setis split between the security and faculty IT staff.
We (security) set up the basic framework list of banned ports etc which
can not be overridden (except by us).  We have a web based interface
that allows IT support staff to configure access for individual
machines.  THe default is no inbound and no outbound access.  You can
select external access from a popup list which allows outbound access
(subject to our list of banned ports).  THis is the way 95% of our
workstations are configured.  If you need to expose one or two ports
this is easily accomplished (the common ones have check boxes -- ssh,
ftp, rdp, http(s) etc).   At the next level IT staff can turn off all
access and individually configure detailed lists of inbound and out
bound ports for servers.

Some will no doubt be horrified by this set up -- you have no control!
and that's right but experience in *our* environment suggests that it
works well.   Several surveys of the actual rules have shown that
generally the configuration closely matches the actual requirements and
if academics want to do something wacky then they have to convince a
local IT tech (our IT support is devolved to faculties) who will
probably have to pick up the pieces if things get broken.  From the
academics point of view this is much better than having to deal with
faceless bureaucracy in the form of Security of network engineers.

We have access controls for 8000 individual systems and there is no way
we could centrally manage that.

The other key point here is that I do not view the perimeter firewall as
something that is going to deter a sophisticated attacker.  It's
explicit purpose is to keep out the ankle biters (worms and script

Our other firewall is just being implemented now.  This project aims to
provide separate security domains within the campus network.  We are
doing this using VLANS and FW1 equipment (and yes, I know the
limitations of VLANS).  This system will be managed like a classical
firewall in a commercial environment (full change control with all
changes being checked by security etc).  Again the infrastructure will
be managed by Networks and we will worry about the actual security side.

We actually have another firewall that the project above is to replace.
It was implemented several years ago over my protests that it was too
simple minded.  We ended up with two database servers behind a very
expensive swiss cheese PIX;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1905 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20050609/f1d0ac5d/smime-0001.bin

More information about the unisog mailing list