Re: SURVEY: Research Institutions / Border Firewalls

[Deke Kassabian <deke () ISC UPENN EDU>]

--On Monday, February 12, 2007 5:38 PM -0600 Chris Green 
<cmgreen () UAB EDU> wrote:
> Good day,
>
>
> In part of proposing campus firewall solutions, we wish to include
> some perspective on what other Research Universities are doing for
> border firewalls.   Please reply directly to myself and I'll
> summarize replies back to the list.  I will remove your identity
> from your answer if you request it.
>
> I'm primarily interested in what other research-focused institutions
> are doing.

Let's see if this is controversial on this particular list  :-)

My tendency leans towards securing end-points, services, and data. 
I'm not much of a fan of drawing large perimeters and applying policy 
there.

After discussion with our security folks and network design folks, 
here's a set of answers for Penn.   I'd be glad to hear discussion on 
these points.

> 1)      Do you require central server registration?

You might mean do we require registration of any machine acting as a 
server in any way.  We don't do this, even in dorms.  We do, however, 
require registration of machines storing critical data.

> 2)      Do you require VPN for off-campus access?
No.

> 3)      Do you have a firewall on your primary internet link?

No, other than router filters involving a small number of well-known 
service ports (maybe 5-10) and also simple IP spoof protections.

> 4)      Do you have a firewall on your I2/Research Links?

Same answer as above.

> 5)      Do you use primarily use [private] IP addressing?

No we use globally routable address space for the majority of 
endpoints.

> 6)      Is your IT structure centralized or decentralized?

A mix.  Penn has many centrally provided IT services, including 
virtually all networking.  Support and local services are provided by 
local IT staff.

> 7)      Do you use a web proxy or SOCKS?
No.

> 8)      What scenario best describes your firewall policy:
> a.       "one size fits all"  (such as allow only port 80 and 443
> traffic)
> b.       customized in place; Don't have to change the IP address and
> any services requested are allowed.
> c.       customized DMZ": You can get whatever you want as long as
you
> move your server into a DMZ.
> d.      Other: Please describe

Our preference is to bring the protection mechanisms as close to the 
resource that needs protection as is possible.  Then the protection 
(eg, a firewall policy) can be as customized as the application set 
requires.

> 9)      How do you handle folks doing videoconferencing or legitimate
> peer-to-peer (BitTorrent Linux downloads)

We let them do it.

> 10)   Are there any things about your setup you would have done
> differently with 20-20 hindsight?

No.  Our network architects believe in open transparent networking and 
strong local security.  We have a document on this at:
<http://pobox.upenn.edu/~deke/writing/fwatpenn.html>

Like many large research organizations, we run a very open network to 
promote research computing and innovation, and to preserve the 
end-to-end model that has made historical Internet innovation 
possible.  Anecdotal data on rates of security problems indicate that 
our open network has no greater rate of security problems than those 
that use inline security mechanisms that break or badly compromise the 
end-to-end model.

We do use local firewalls in front of some server groups, and some 
workgroups firewall their local areas.  But in most cases our security 
strategy is to harden the OS and the application.  This has worked 
very well for a very long time for many of our most visible systems.

> Thanks for taking the time to reply
>
> --
> Chris Green
> UAB Data Security, 205-975-0842

Regards,

-------
Deke Kassabian,  Senior Technology Director
Information Systems and Computing, University of Pennsylvania

Attachment: _bin
Description: