[unisog] Appropriate University/Internet blocks
r.fulton at auckland.ac.nz
Thu Jun 17 08:50:06 GMT 2004
On Thu, 2004-06-17 at 02:20, Tom Conley wrote:
> This is a hackneyed old question, but one we are still struggling with:
> What is the appropriate level of filtering or port blocking at A
> University/Internet border?
This is somewhat long winded but since this position is somewhat extreme
in this community I thought I would fill in the background as well.
We are somewhat lucky in that by the time the Internet made it out to NZ
(late '80s) it was already obvious that there were real security issues.
Also international traffic was expensive (around $1US per MB and those
were '88 dollars not '04 dollars) so if someone got into your UNIX box
and set up a warez site you might get a bill for $1000 at the end of the
Another consequence of the expensive nature of the traffic is that we
needed to control which machines could go out as well as what came in.
We started with CISCO ACL, then moved to TAMU Drawbridge and just last
Christmas to OBSD's pf.
We have always blocked netbios and MS rpc, Berkeley r* command, snmp,
tftp and X and a few others. We also block SMTP in and out except for a
handful of offical MTAs. These can not be over ridden (see below) except
Over the last ten years I have steadily cut down the *default* incoming
access that machine and now it is nothing. I.e by default IP addresses
are completely blocked from incoming Internet traffic. I was only able
to do that once we had installed pf which is a state full firewall
(unlike Drawbridge). Before that I had to allow incoming UDP traffic on
high numbered ports so we got hit by the MS SQL worm -- even though I
had blocked the TCP port :(
I also had to add ftpsesame to handle ftp state tracking.
The key word in the above paragraph is *default*. Any IT support person
can change these defaults but none (to my knowledge) do so with out good
reason. Of the 8000 systems that have entries in our firewall ( and
thus have some form of access to the Internet) less than 500 have any in
bound access configured and most of these have just http(s), ssh or rdp.
Note that the access controls are in the hands of the departmental IT
support people who suffer the consequences of any breaches. So far this
year we have had 5 windows machines compromised by hackers or network
borne 'bots' from off campus. In fact I think all were the result of
active hackers and all were within one faculty (and yes we are working
with them to get problems fixed).
The firewall access is configured though our home grown network
management system which also holds configuration for DNS, DHCP, etc. Its
a perl/apache/mysql app which allows departmental IT staff to do there
own host allocation and configuration.
I encourage SAs to cut outgoing access for servers and I have seen a
couple of cases where exploits have succeeded in breaching a server but
the hackers have then been stymied because they could not get their root
kit down loaded, or could not even get to the shell port left by the
exploit because the server only had port 80 exposed.
There is one exception to the above rule and that is CS who do their own
firewalling and network management and so long as they don't have
trouble I'm happy to leave them to it.
I am very happy with the way our system works, we have no complaints
from our users and we seem, so far (touch wood), to have kept most of
the nasties out.
The key thing is that (as Valdis points out) the problems are political,
not technical. We have been able to achieve a very good compromise by
handing a large chunk of control over to departmental IT people who have
a great incentive to keep things under control. Departments feel that
they are in control since their staff do the configuration. Academics
who get stroppy and cause trouble end up explaining to their HoD why the
IT staff are spending so much of their time cleaning up after them. We
(central IT) don't normally get involved unless we see a cluster of
incidents in one ares.
I keep an eye on things and every now and then I will ring someone up
and ask "Why is this configured this way?" and the usual response is
"Oops! we wanted to test xxx and forgot to tie it down again", but such
incidents are pretty few and far between. I intend to write some
monitoring software that will examine configs and flag things for
We are still exposed to malware that enters the network on laptops or
through the dial up/vpn systems, but that is a different story!
Russell Fulton, Computer and Network Security Officer.
The University of Auckland, New Zealand.
More information about the unisog