[Micronet] Campus Firewall and Public IPs

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[Micronet] Campus Firewall and Public IPs

Bill Clark
I've wondered this for a while, and was recently prodded into asking here
by a co-worker:

Why isn't there a campus-wide firewall in place, and why do we have public
routable IP addresses on nearly every machine, desktop or otherwise?
Neither of these things seems like a particularly good idea from a
security standpoint, and the "benefit" of individual units being able to
set up their own webservers and such without having to go through any
central channels seems a dubious one at best.

-Bill Clark


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
Or -- since it just occurred to me that we probably DO have a campus
firewall but with particularly permissive defaults -- why isn't the
default to filter out all inbound traffic except that headed for
registered services?

-Bill Clark

> I've wondered this for a while, and was recently prodded into asking here
> by a co-worker:
>
> Why isn't there a campus-wide firewall in place, and why do we have public
> routable IP addresses on nearly every machine, desktop or otherwise?
> Neither of these things seems like a particularly good idea from a
> security standpoint, and the "benefit" of individual units being able to
> set up their own webservers and such without having to go through any
> central channels seems a dubious one at best.
>
> -Bill Clark
>
>
>
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe
> from its mailing list and how to find out about upcoming meetings, please
> visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and
> the list's archives can be browsed and searched on the Internet.  This
> means these messages can be viewed by (among others) your bosses,
> prospective employers, and people who have known you in the past.
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Forrest St. John Smalley
Hi Bill,

>From the IST Cloud team perspective, I would at least recommend leveraging the cloud as much as possible for servers at least. You will get firewall support as well as the ability to put systems on our colo or managed RFC1918 address spaces.  Hosting management bastion hosts or management desktops for sensitive data also makes sense in the cloud, as this privileged access point will be behind the data center firewall systems at least.  In some cases, for our managed servers at least in the cloud, load balancer options, and a management proxy for patching RFC1918 machines are available.

In your more generic question about routable vs. non-routable, that probably has a lot of viewpoints. I think the consensus has always been that network firewalls are good, but great host firewall systems are really the only protection. Non-routable wherever possible probably makes sense, but I wouldn't count on the network firewall. Hosts need to be locked down at the host themselves. Once someone is on the network, it doesn't matter if you are on RFC1918 really, at least not that much. It does add some hurdles, and sometimes that might buy us enough time.

Forrest

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Clark
Sent: Tuesday, May 25, 2010 12:32 PM
To: Bill Clark
Cc: Micronet-UCB microcomputer support user group
Subject: Re: [Micronet] Campus Firewall and Public IPs

Or -- since it just occurred to me that we probably DO have a campus
firewall but with particularly permissive defaults -- why isn't the
default to filter out all inbound traffic except that headed for
registered services?

-Bill Clark

> I've wondered this for a while, and was recently prodded into asking here
> by a co-worker:
>
> Why isn't there a campus-wide firewall in place, and why do we have public
> routable IP addresses on nearly every machine, desktop or otherwise?
> Neither of these things seems like a particularly good idea from a
> security standpoint, and the "benefit" of individual units being able to
> set up their own webservers and such without having to go through any
> central channels seems a dubious one at best.
>
> -Bill Clark
>
>
>
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe
> from its mailing list and how to find out about upcoming meetings, please
> visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and
> the list's archives can be browsed and searched on the Internet.  This
> means these messages can be viewed by (among others) your bosses,
> prospective employers, and people who have known you in the past.
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
We do make use of IST-hosted services as much as possible, and those are
all very nicely locked-down -- but I'm just wondering why the campus
itself is essentially completely open.  No other large organization I've
worked at (or even heard of!) has such a completely unprotected network.

I agree about the need for host-based security, and in fact that's what
prompted the discussion with my co-worker earlier today -- his remark
about the ridiculous number of scans his local software firewall logs on a
daily basis.  But firewalls aren't a host vs. network / either-or
situation.  Why don't we have both?  At the very least from a traffic
perspective it seems like a no-brainer to just stop most of these scans
right at the edge.

-Bill Clark

> Hi Bill,
>
> From the IST Cloud team perspective, I would at least recommend leveraging
> the cloud as much as possible for servers at least. You will get firewall
> support as well as the ability to put systems on our colo or managed
> RFC1918 address spaces.  Hosting management bastion hosts or management
> desktops for sensitive data also makes sense in the cloud, as this
> privileged access point will be behind the data center firewall systems at
> least.  In some cases, for our managed servers at least in the cloud, load
> balancer options, and a management proxy for patching RFC1918 machines are
> available.
>
> In your more generic question about routable vs. non-routable, that
> probably has a lot of viewpoints. I think the consensus has always been
> that network firewalls are good, but great host firewall systems are
> really the only protection. Non-routable wherever possible probably makes
> sense, but I wouldn't count on the network firewall. Hosts need to be
> locked down at the host themselves. Once someone is on the network, it
> doesn't matter if you are on RFC1918 really, at least not that much. It
> does add some hurdles, and sometimes that might buy us enough time.
>
> Forrest
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Bill Clark
> Sent: Tuesday, May 25, 2010 12:32 PM
> To: Bill Clark
> Cc: Micronet-UCB microcomputer support user group
> Subject: Re: [Micronet] Campus Firewall and Public IPs
>
> Or -- since it just occurred to me that we probably DO have a campus
> firewall but with particularly permissive defaults -- why isn't the
> default to filter out all inbound traffic except that headed for
> registered services?
>
> -Bill Clark
>
>> I've wondered this for a while, and was recently prodded into asking
>> here
>> by a co-worker:
>>
>> Why isn't there a campus-wide firewall in place, and why do we have
>> public
>> routable IP addresses on nearly every machine, desktop or otherwise?
>> Neither of these things seems like a particularly good idea from a
>> security standpoint, and the "benefit" of individual units being able to
>> set up their own webservers and such without having to go through any
>> central channels seems a dubious one at best.
>>
>> -Bill Clark
>>
>>
>>
>> -------------------------------------------------------------------------
>> The following was automatically added to this message by the list
>> server:
>>
>> To learn more about Micronet, including how to subscribe to or
>> unsubscribe
>> from its mailing list and how to find out about upcoming meetings,
>> please
>> visit the Micronet Web site:
>>
>> http://micronet.berkeley.edu
>>
>> Messages you send to this mailing list are public and world-viewable,
>> and
>> the list's archives can be browsed and searched on the Internet.  This
>> means these messages can be viewed by (among others) your bosses,
>> prospective employers, and people who have known you in the past.
>>
>
>
>
>
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe
> from its mailing list and how to find out about upcoming meetings, please
> visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and
> the list's archives can be browsed and searched on the Internet.  This
> means these messages can be viewed by (among others) your bosses,
> prospective employers, and people who have known you in the past.
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Jon Forrest
I can think of several possible reasons:

1) The "Maginot Line" effect. If there were
one campus firewall then people might be lured
into thinking that they don't have to keep their
computers up to date because the Great Firewall
is keeping them safe.

2) The administrative load of managing such
a firewall. There are *lots* of hosts on campus
that would require special rules of one
sort or another. It would be a huge job
to manage this globally.

3) People who feel strongly that they should
be behind a firewall can choose to do so
now by signing up with IST. (Info at
http://ist.berkeley.edu/services/is/net/firewall).

I'm sure there are other reasons too.

Cordially,
--
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
[hidden email]

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Adam Carlson-2
In reply to this post by Bill Clark
Bill,
        I suspect that you will hear from the campus network people shortly with a more authoritative answer but you are correct, there is no campus-wide firewall and I believe this openness is both intentional and out of research/performance/network health reasons.  However, incoming connections to some ports/services that have caused problems in the past are not routed at the campus border meaning they are effectively blocked.  I believe these services are just SNMP and the common Microsoft ports.
        From what I understand, UCLA has a similar "open" model but departments on that campus have been much more aggressive in implementing their own firewalls at the departmental level rather than relying on a campus-wide firewall.  Reportedly, UC Irvine has taken a different approach and implemented a default deny rule for inbound traffic at the campus border.  Based on my understanding, any person can request a hole be poked in the firewall via some type of self-service web application so there is a very low bar for allowing connections, but most things are blocked by default (I do not have intimate knowledge of their configuration so take what I say with a grain of salt).
        We as a campus are definitely not following the principle of least privileges with this approach as there are certainly a lot of unnecessary services listening for connections from the Internet.  Who is to blame for this will probably depend on who you talk to.  I'm sure the network folks will say it is the departments responsibility to prevent unnecessary services from listening by either using a host-based firewall or disabling the service all together.
        I strongly believe that a host-based firewall is not a substitute for a hardware firewall, especially when the host has been compromised.  Layers of security is always ideal, and a hardware firewall is a very standard layer of security found in almost every enterprise environment that this campus has still been very slow to adopt.  Based on my interactions in CISPC, I think the chances of a campus-wide network firewall are slim-to-none, but again I will let the campus network group speak to that.  I believe we do get a pretty amazing deal on Cisco equipment through the campus purchasing program so you may want to consider a departmental hardware firewall (or the IST FWSM option) as there is definite value in having a central point of control for all network traffic.  It would be great if this cost could be shared and addressed with a campus-wide firewall, but I'm not hopeful that this type of setup will get implemented or is even feasible.

-Adam

Bill Clark wrote:

> We do make use of IST-hosted services as much as possible, and those are
> all very nicely locked-down -- but I'm just wondering why the campus
> itself is essentially completely open.  No other large organization I've
> worked at (or even heard of!) has such a completely unprotected network.
>
> I agree about the need for host-based security, and in fact that's what
> prompted the discussion with my co-worker earlier today -- his remark
> about the ridiculous number of scans his local software firewall logs on a
> daily basis.  But firewalls aren't a host vs. network / either-or
> situation.  Why don't we have both?  At the very least from a traffic
> perspective it seems like a no-brainer to just stop most of these scans
> right at the edge.
>
> -Bill Clark
>
>> Hi Bill,
>>
>> From the IST Cloud team perspective, I would at least recommend leveraging
>> the cloud as much as possible for servers at least. You will get firewall
>> support as well as the ability to put systems on our colo or managed
>> RFC1918 address spaces.  Hosting management bastion hosts or management
>> desktops for sensitive data also makes sense in the cloud, as this
>> privileged access point will be behind the data center firewall systems at
>> least.  In some cases, for our managed servers at least in the cloud, load
>> balancer options, and a management proxy for patching RFC1918 machines are
>> available.
>>
>> In your more generic question about routable vs. non-routable, that
>> probably has a lot of viewpoints. I think the consensus has always been
>> that network firewalls are good, but great host firewall systems are
>> really the only protection. Non-routable wherever possible probably makes
>> sense, but I wouldn't count on the network firewall. Hosts need to be
>> locked down at the host themselves. Once someone is on the network, it
>> doesn't matter if you are on RFC1918 really, at least not that much. It
>> does add some hurdles, and sometimes that might buy us enough time.
>>
>> Forrest
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Bill Clark
>> Sent: Tuesday, May 25, 2010 12:32 PM
>> To: Bill Clark
>> Cc: Micronet-UCB microcomputer support user group
>> Subject: Re: [Micronet] Campus Firewall and Public IPs
>>
>> Or -- since it just occurred to me that we probably DO have a campus
>> firewall but with particularly permissive defaults -- why isn't the
>> default to filter out all inbound traffic except that headed for
>> registered services?
>>
>> -Bill Clark
>>
>>> I've wondered this for a while, and was recently prodded into asking
>>> here
>>> by a co-worker:
>>>
>>> Why isn't there a campus-wide firewall in place, and why do we have
>>> public
>>> routable IP addresses on nearly every machine, desktop or otherwise?
>>> Neither of these things seems like a particularly good idea from a
>>> security standpoint, and the "benefit" of individual units being able to
>>> set up their own webservers and such without having to go through any
>>> central channels seems a dubious one at best.
>>>
>>> -Bill Clark
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> The following was automatically added to this message by the list
>>> server:
>>>
>>> To learn more about Micronet, including how to subscribe to or
>>> unsubscribe
>>> from its mailing list and how to find out about upcoming meetings,
>>> please
>>> visit the Micronet Web site:
>>>
>>> http://micronet.berkeley.edu
>>>
>>> Messages you send to this mailing list are public and world-viewable,
>>> and
>>> the list's archives can be browsed and searched on the Internet.  This
>>> means these messages can be viewed by (among others) your bosses,
>>> prospective employers, and people who have known you in the past.
>>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> The following was automatically added to this message by the list server:
>>
>> To learn more about Micronet, including how to subscribe to or unsubscribe
>> from its mailing list and how to find out about upcoming meetings, please
>> visit the Micronet Web site:
>>
>> http://micronet.berkeley.edu
>>
>> Messages you send to this mailing list are public and world-viewable, and
>> the list's archives can be browsed and searched on the Internet.  This
>> means these messages can be viewed by (among others) your bosses,
>> prospective employers, and people who have known you in the past.
>>
>
>
>
>  
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
>

--
Adam Carlson
Chief Security Officer
Information Technology
Residential and Student Service Programs
Tel: 510-643-0631
Email: [hidden email]

"Most of the things worth doing in the world had been declared impossible before they were done." ~Louis D. Brandeis


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
In reply to this post by Jon Forrest
Point #2 is what I suspected was the main factor (in combination with the
political issues involved) although I'm not entirely convinced that the
extra workload would outweigh the benefits -- simply knowing what services
are being opened to the public is such valuable information in and of
itself that keeping track of it centrally would make a lot of other
security and/or network related tasks easier.

As for point #3 -- I should read IS&T's service offerings more closely,
since I had no idea that service existed.  Thanks!

-Bill Clark

> I can think of several possible reasons:
>
> 1) The "Maginot Line" effect. If there were
> one campus firewall then people might be lured
> into thinking that they don't have to keep their
> computers up to date because the Great Firewall
> is keeping them safe.
>
> 2) The administrative load of managing such
> a firewall. There are *lots* of hosts on campus
> that would require special rules of one
> sort or another. It would be a huge job
> to manage this globally.
>
> 3) People who feel strongly that they should
> be behind a firewall can choose to do so
> now by signing up with IST. (Info at
> http://ist.berkeley.edu/services/is/net/firewall).
>
> I'm sure there are other reasons too.
>
> Cordially,
> --
> Jon Forrest
> Research Computing Support
> College of Chemistry
> 173 Tan Hall
> University of California Berkeley
> Berkeley, CA
> 94720-1460
> 510-643-1032
> [hidden email]
>
>
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe
> from its mailing list and how to find out about upcoming meetings, please
> visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and
> the list's archives can be browsed and searched on the Internet.  This
> means these messages can be viewed by (among others) your bosses,
> prospective employers, and people who have known you in the past.
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Erik Klavon
In reply to this post by Bill Clark
On Tue, May 25, 2010 at 12:21:09PM -0700, Bill Clark wrote:

> I've wondered this for a while, and was recently prodded into asking here
> by a co-worker:
>
> Why isn't there a campus-wide firewall in place, and why do we have public
> routable IP addresses on nearly every machine, desktop or otherwise?
> Neither of these things seems like a particularly good idea from a
> security standpoint, and the "benefit" of individual units being able to
> set up their own webservers and such without having to go through any
> central channels seems a dubious one at best.
>
> Or -- since it just occurred to me that we probably DO have a campus
> firewall but with particularly permissive defaults -- why isn't the
> default to filter out all inbound traffic except that headed for
> registered services?

Most of what I would write in response to your questions is identical
to what you'll find in a very well written document from the
University of Washington at the following URL.

http://staff.washington.edu/gray/papers/credo.html

Erik

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
Interesting.. I had been assuming that most of the reasons were political
(i.e. non-technical) and that the campus networking folks would've
preferred  to lock everything down at the edge of our network by default
(given adequate resources to implement such a policy, of course.)

I'm still not entirely buying into this "either-or" mentality regarding
firewalls though.. I always make it a point to lock down any of the
computers I'm responsible for, but it's still good practice (IMHO) to ALSO
lock everything down at the network level, if only to cut down on the
"noise" of the endless botnet scanning, so that more serious threats are
easier to identify.

Arguing that enterprise-wide firewalls are bad because they give a false
sense of security is akin to arguing that seatbelts encourage reckless
driving.

Of course, I've never actually worked as a network engineer and only
rarely act even as a sysadmin anymore, so if the current conventional
wisdom among the professionals is "open networks, closed servers,
protected sessions" (the last two I agree with anyway) then I'll accept
that perhaps I'm just behind the times.

-Bill Clark


> On Tue, May 25, 2010 at 12:21:09PM -0700, Bill Clark wrote:
>> I've wondered this for a while, and was recently prodded into asking
>> here
>> by a co-worker:
>>
>> Why isn't there a campus-wide firewall in place, and why do we have
>> public
>> routable IP addresses on nearly every machine, desktop or otherwise?
>> Neither of these things seems like a particularly good idea from a
>> security standpoint, and the "benefit" of individual units being able to
>> set up their own webservers and such without having to go through any
>> central channels seems a dubious one at best.
>>
>> Or -- since it just occurred to me that we probably DO have a campus
>> firewall but with particularly permissive defaults -- why isn't the
>> default to filter out all inbound traffic except that headed for
>> registered services?
>
> Most of what I would write in response to your questions is identical
> to what you'll find in a very well written document from the
> University of Washington at the following URL.
>
> http://staff.washington.edu/gray/papers/credo.html
>
> Erik
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Michael Sinatra
In reply to this post by Adam Carlson-2
On 05/25/10 13:29, Adam Carlson wrote:
> Bill, I suspect that you will hear from the campus network people
> shortly with a more authoritative answer

See the end of this message.

> but you are correct, there
> is no campus-wide firewall and I believe this openness is both
> intentional and out of research/performance/network health reasons.
> However, incoming connections to some ports/services that have caused
> problems in the past are not routed at the campus border meaning they
> are effectively blocked.  I believe these services are just SNMP and
> the common Microsoft ports.

This is basically correct.

> From what I understand, UCLA has a similar "open" model but
> departments on that campus have been much more aggressive in
> implementing their own firewalls at the departmental level rather
> than relying on a campus-wide firewall.

I don't agree with this.  UCLA has a very open network, but each
department runs its own network.  Departments have had to decide how to
do that, since there is no standard model on campus.  Some departments
have employed NAT, and some departments are wide open, with no
firewalls.  (Several departments have broken DNS and other network
services, even now.)

> Reportedly, UC Irvine has
> taken a different approach and implemented a default deny rule for
> inbound traffic at the campus border.  Based on my understanding, any
> person can request a hole be poked in the firewall via some type of
> self-service web application so there is a very low bar for allowing
> connections, but most things are blocked by default (I do not have
> intimate knowledge of their configuration so take what I say with a
> grain of salt).

UC Irvine is the only major research university that I know of that
actually does this.  All of the other major research universities on the
caliber of UC Berkeley have basically the same setup that we do.  (Note
that a number of them no longer block the Microsoft ports.)

> We as a campus are definitely not following the principle of least
> privileges with this approach as there are certainly a lot of
> unnecessary services listening for connections from the Internet.
> Who is to blame for this will probably depend on who you talk to.
> I'm sure the network folks will say it is the departments
> responsibility to prevent unnecessary services from listening by
> either using a host-based firewall or disabling the service all
> together.

I really don't understand how the principle of least privileges (which
is fundamentally an *access* control issue) has anything to do with
network ports and IP addresses.  I see a lot of conflation between the
notion of network filtering and actual access control, with which there
is not a really congruent relationship.  (And note that "network access
control" really refers to technologies like 802.1x and not firewalls.)

The campus does have policies that attempt to prohibit the use of
unnecessary services, but at a research university, the definition of
unnecessary services will tend to vary.  The most significant variation
will be between research and administrative enterprises.  We are already
seeing calls for entirely separate research and administrative networks.
  Where such a need exists, the use of distributed firewalls that can be
tailored to an individual department's need is preferred over a
big-brother style border firewall.  This is to attempt to balance the
trade-offs inherent in what Terry Gray calls the "Perimeter Protection
Paradox": see <http://staff.washington.edu/gray/papers/fff-final.htm>.

> I strongly believe that a host-based firewall is not a substitute for
> a hardware firewall, especially when the host has been compromised.

It's a little late then, isn't it?  Moreover, a large-perimiter firewall
won't help much in the case of a compromised host either.  A *hardware*
firewall might help, but only if it's connected directly to the host.
It _is_ therefore useful to have one or two little Linksys or similar
broadband firewall/routers that you can hook up to a host if necessary.
  Otherwise, having SNS block the host at the local router will also work.

> Layers of security is always ideal, and a hardware firewall is a very
> standard layer of security found in almost every enterprise
> environment that this campus has still been very slow to adopt.

Again, let me repeat that it is not just "this campus"--I know of *zero*
campuses of our size and caliber that do a full-on campus border
firewall, and our campus has actually been ahead of the curve in
offering distributed firewalls.  (University of Washington has probably
been ahead of us in this respect, but they are completely open at the
border.)

> Based on my interactions in CISPC, I think the chances of a
> campus-wide network firewall are slim-to-none, but again I will let
> the campus network group speak to that.  I believe we do get a pretty
> amazing deal on Cisco equipment through the campus purchasing program
> so you may want to consider a departmental hardware firewall (or the
> IST FWSM option) as there is definite value in having a central point
> of control for all network traffic.  It would be great if this cost
> could be shared and addressed with a campus-wide firewall, but I'm
> not hopeful that this type of setup will get implemented or is even
> feasible.

We are purchasing the very highest-end cisco firewall for use in the
campus data center.  Those devices, redundantly connected, will cost
over $150,000 just for hardware alone, and they cannot support the
amount of potential traffic and the range of redundant connections at
the campus border.  (It's unlikely that they will even be able to
support all of the data center traffic, namely storage replication
traffic between UCB and UCLA/UCSD.)  In my opinion, you'll get a lot
more bang for the buck with the distributed firewall service we have.
Hardware firewalls just can't keep up.

I also don't see why it's necessary to have *a* campus-wide firewall to
distribute costs.  The distributed FWSMs already do a good job of
distributing costs *and* functionality.  They can't do everything, but
they can do more than a monolithic campus-wide firewall could.

Bill also asked why most campus hosts have routable IP addresses.
Again, this would likely require one giant NAT box at the campus border.
  NAT boxes--like stateful firewalls--must keep a connection state on
*every* connection that goes through the campus border.  If the state
table overflows, a large number of connections will be terminated.  NAT
also assumes a client/server model and it basically destroys the
end-to-end principle of TCP/IP.  This may not seem horrible from an
administrative, but it can create big problems with certain types of
research.  This is an unsound and unscalable model, and again, I know of
no major research university that operates this way.

To sum up the various reasons:

1. Border firewalls are not particularly effective compared to
distributed firewalls closer to the hosts.

2. Border firewalls are not as cost-effective as more distributed firewalls.

3. NAT has basically been proven not to work on large scales.  NAT was
supposed to be the "IPv6 killer" but it has ended up being the IPv4
killer, in that the general dissatisfaction with NAT has helped speed
depletion of IPv4 address space at a greater-than-linear rate.

4. We regard "defense-in-depth" not as "many layers of firewalls" but as
"many ways of mitigating or removing the same vulnerabilities."
Defense-in-depth means writing secure code (and testing it), controlling
access through variant means, carefully-configured firewalls by people
who understand *all* of the applications and services running
immediately behind the firewall, patching of standard OS and software
packages, etc.  A firewall at the border adds very little
defense-in-depth and increases all types of costs dramatically.

In addition to the URL that Erik included, there are some interesting
presentations to look at that depict the evolving view toward firewalls
and other security mechanisms in the research and education (R&E) community.

This presentation from Eli Dart of LBNL and ESNet is particularly good
on a number of levels:

http://events.internet2.edu/2010/jt-slc/agenda.cfm?go=session&id=10001008&event=1111

Joe St. Sauver of the the University of Oregon and Internet2 covers some
similar topics:

http://www.uoregon.edu/~joe/architectures/architecture.pdf

michael

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Tom Holub
In reply to this post by Bill Clark
There was a Firewalls Task Force a few years back (2002) which looked at
the question of firewall implementations on campus.  The report appears
to no longer be online (never break URLs, people), but you can get it
from archive.org:

http://web.archive.org/web/20070626151624/http://fwtf.berkeley.edu/

The list of participants is either amusing or depressing, depending on
your perspective: by my count, only 9 of 21 participants remain on
campus.  Those who are still around are apparently still interested in
talking about the issue.

On 5/25/10 1:30 PM, Bill Clark wrote:

> Point #2 is what I suspected was the main factor (in combination with the
> political issues involved) although I'm not entirely convinced that the
> extra workload would outweigh the benefits -- simply knowing what services
> are being opened to the public is such valuable information in and of
> itself that keeping track of it centrally would make a lot of other
> security and/or network related tasks easier.
>
> As for point #3 -- I should read IS&T's service offerings more closely,
> since I had no idea that service existed.  Thanks!
>
> -Bill Clark
>
>> I can think of several possible reasons:
>>
>> 1) The "Maginot Line" effect. If there were
>> one campus firewall then people might be lured
>> into thinking that they don't have to keep their
>> computers up to date because the Great Firewall
>> is keeping them safe.
>>
>> 2) The administrative load of managing such
>> a firewall. There are *lots* of hosts on campus
>> that would require special rules of one
>> sort or another. It would be a huge job
>> to manage this globally.
>>
>> 3) People who feel strongly that they should
>> be behind a firewall can choose to do so
>> now by signing up with IST. (Info at
>> http://ist.berkeley.edu/services/is/net/firewall).
>>
>> I'm sure there are other reasons too.
>>
>> Cordially,
>> --
>> Jon Forrest
>> Research Computing Support
>> College of Chemistry
>> 173 Tan Hall
>> University of California Berkeley
>> Berkeley, CA
>> 94720-1460
>> 510-643-1032
>> [hidden email]
>>
>>
>> -------------------------------------------------------------------------
>> The following was automatically added to this message by the list server:
>>
>> To learn more about Micronet, including how to subscribe to or unsubscribe
>> from its mailing list and how to find out about upcoming meetings, please
>> visit the Micronet Web site:
>>
>> http://micronet.berkeley.edu
>>
>> Messages you send to this mailing list are public and world-viewable, and
>> the list's archives can be browsed and searched on the Internet.  This
>> means these messages can be viewed by (among others) your bosses,
>> prospective employers, and people who have known you in the past.
>>
>
>
>
>
> -------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:
>
> http://micronet.berkeley.edu
>
> Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.


--
Tom Holub ([hidden email], 510-642-9069)
Director of Computing, College of Letters & Science
249 Campbell Hall
<http://LS.berkeley.edu/lscr/>

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Erik Klavon
In reply to this post by Bill Clark
On Tue, May 25, 2010 at 02:16:35PM -0700, Bill Clark wrote:
> Interesting.. I had been assuming that most of the reasons were political
> (i.e. non-technical) and that the campus networking folks would've
> preferred  to lock everything down at the edge of our network by default
> (given adequate resources to implement such a policy, of course.)

I do very much prefer that everything be locked down at the edge
(which is to say, as close to the host) of our network as possible.
 
> I'm still not entirely buying into this "either-or" mentality regarding
> firewalls though.

Please define what you mean by "either-or mentality".

> I always make it a point to lock down any of the computers I'm
> responsible for, but it's still good practice (IMHO) to ALSO lock
> everything down at the network level, if only to cut down on the
> "noise" of the endless botnet scanning, so that more serious threats
> are easier to identify.

You, and anyone else on campus is free to do so for the systems under
your control. And, if this isn't what you want, you're free not to do
it (to the degree that policy allows).

> Of course, I've never actually worked as a network engineer and only
> rarely act even as a sysadmin anymore, so if the current conventional
> wisdom among the professionals is "open networks, closed servers,
> protected sessions" (the last two I agree with anyway) then I'll accept
> that perhaps I'm just behind the times.

I don't know you well enough to say this with any certainty, but my
guess is that your view is less out of date than it is of a different
environment than the one you now find yourself in.

Erik

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
In reply to this post by Michael Sinatra
Thanks, Michael, for your in-depth explanation!

It hadn't occurred to me that our network was actually too big for a
border firewall to be cost effective and/or efficient.  The more I've read
about the FWSM option, the more I think it addresses my concerns
perfectly.

My point regarding public addresses wasn't meant as a call for a
campus-wide NAT but more for something similar to the FWSM option, so that
individual units could set up their own non-routable local networks.  I
had been under the impression that the use of private address space for
workstations was actually discouraged by campus policy, perhaps for
reasons relating to how network charges are set up.  Perhaps (hopefully?)
I'm mistaken there.

-Bill Clark

> On 05/25/10 13:29, Adam Carlson wrote:
>> Bill, I suspect that you will hear from the campus network people
>> shortly with a more authoritative answer
>
> See the end of this message.
>
>> but you are correct, there
>> is no campus-wide firewall and I believe this openness is both
>> intentional and out of research/performance/network health reasons.
>> However, incoming connections to some ports/services that have caused
>> problems in the past are not routed at the campus border meaning they
>> are effectively blocked.  I believe these services are just SNMP and
>> the common Microsoft ports.
>
> This is basically correct.
>
>> From what I understand, UCLA has a similar "open" model but
>> departments on that campus have been much more aggressive in
>> implementing their own firewalls at the departmental level rather
>> than relying on a campus-wide firewall.
>
> I don't agree with this.  UCLA has a very open network, but each
> department runs its own network.  Departments have had to decide how to
> do that, since there is no standard model on campus.  Some departments
> have employed NAT, and some departments are wide open, with no
> firewalls.  (Several departments have broken DNS and other network
> services, even now.)
>
>> Reportedly, UC Irvine has
>> taken a different approach and implemented a default deny rule for
>> inbound traffic at the campus border.  Based on my understanding, any
>> person can request a hole be poked in the firewall via some type of
>> self-service web application so there is a very low bar for allowing
>> connections, but most things are blocked by default (I do not have
>> intimate knowledge of their configuration so take what I say with a
>> grain of salt).
>
> UC Irvine is the only major research university that I know of that
> actually does this.  All of the other major research universities on the
> caliber of UC Berkeley have basically the same setup that we do.  (Note
> that a number of them no longer block the Microsoft ports.)
>
>> We as a campus are definitely not following the principle of least
>> privileges with this approach as there are certainly a lot of
>> unnecessary services listening for connections from the Internet.
>> Who is to blame for this will probably depend on who you talk to.
>> I'm sure the network folks will say it is the departments
>> responsibility to prevent unnecessary services from listening by
>> either using a host-based firewall or disabling the service all
>> together.
>
> I really don't understand how the principle of least privileges (which
> is fundamentally an *access* control issue) has anything to do with
> network ports and IP addresses.  I see a lot of conflation between the
> notion of network filtering and actual access control, with which there
> is not a really congruent relationship.  (And note that "network access
> control" really refers to technologies like 802.1x and not firewalls.)
>
> The campus does have policies that attempt to prohibit the use of
> unnecessary services, but at a research university, the definition of
> unnecessary services will tend to vary.  The most significant variation
> will be between research and administrative enterprises.  We are already
> seeing calls for entirely separate research and administrative networks.
>   Where such a need exists, the use of distributed firewalls that can be
> tailored to an individual department's need is preferred over a
> big-brother style border firewall.  This is to attempt to balance the
> trade-offs inherent in what Terry Gray calls the "Perimeter Protection
> Paradox": see <http://staff.washington.edu/gray/papers/fff-final.htm>.
>
>> I strongly believe that a host-based firewall is not a substitute for
>> a hardware firewall, especially when the host has been compromised.
>
> It's a little late then, isn't it?  Moreover, a large-perimiter firewall
> won't help much in the case of a compromised host either.  A *hardware*
> firewall might help, but only if it's connected directly to the host.
> It _is_ therefore useful to have one or two little Linksys or similar
> broadband firewall/routers that you can hook up to a host if necessary.
>   Otherwise, having SNS block the host at the local router will also work.
>
>> Layers of security is always ideal, and a hardware firewall is a very
>> standard layer of security found in almost every enterprise
>> environment that this campus has still been very slow to adopt.
>
> Again, let me repeat that it is not just "this campus"--I know of *zero*
> campuses of our size and caliber that do a full-on campus border
> firewall, and our campus has actually been ahead of the curve in
> offering distributed firewalls.  (University of Washington has probably
> been ahead of us in this respect, but they are completely open at the
> border.)
>
>> Based on my interactions in CISPC, I think the chances of a
>> campus-wide network firewall are slim-to-none, but again I will let
>> the campus network group speak to that.  I believe we do get a pretty
>> amazing deal on Cisco equipment through the campus purchasing program
>> so you may want to consider a departmental hardware firewall (or the
>> IST FWSM option) as there is definite value in having a central point
>> of control for all network traffic.  It would be great if this cost
>> could be shared and addressed with a campus-wide firewall, but I'm
>> not hopeful that this type of setup will get implemented or is even
>> feasible.
>
> We are purchasing the very highest-end cisco firewall for use in the
> campus data center.  Those devices, redundantly connected, will cost
> over $150,000 just for hardware alone, and they cannot support the
> amount of potential traffic and the range of redundant connections at
> the campus border.  (It's unlikely that they will even be able to
> support all of the data center traffic, namely storage replication
> traffic between UCB and UCLA/UCSD.)  In my opinion, you'll get a lot
> more bang for the buck with the distributed firewall service we have.
> Hardware firewalls just can't keep up.
>
> I also don't see why it's necessary to have *a* campus-wide firewall to
> distribute costs.  The distributed FWSMs already do a good job of
> distributing costs *and* functionality.  They can't do everything, but
> they can do more than a monolithic campus-wide firewall could.
>
> Bill also asked why most campus hosts have routable IP addresses.
> Again, this would likely require one giant NAT box at the campus border.
>   NAT boxes--like stateful firewalls--must keep a connection state on
> *every* connection that goes through the campus border.  If the state
> table overflows, a large number of connections will be terminated.  NAT
> also assumes a client/server model and it basically destroys the
> end-to-end principle of TCP/IP.  This may not seem horrible from an
> administrative, but it can create big problems with certain types of
> research.  This is an unsound and unscalable model, and again, I know of
> no major research university that operates this way.
>
> To sum up the various reasons:
>
> 1. Border firewalls are not particularly effective compared to
> distributed firewalls closer to the hosts.
>
> 2. Border firewalls are not as cost-effective as more distributed
> firewalls.
>
> 3. NAT has basically been proven not to work on large scales.  NAT was
> supposed to be the "IPv6 killer" but it has ended up being the IPv4
> killer, in that the general dissatisfaction with NAT has helped speed
> depletion of IPv4 address space at a greater-than-linear rate.
>
> 4. We regard "defense-in-depth" not as "many layers of firewalls" but as
> "many ways of mitigating or removing the same vulnerabilities."
> Defense-in-depth means writing secure code (and testing it), controlling
> access through variant means, carefully-configured firewalls by people
> who understand *all* of the applications and services running
> immediately behind the firewall, patching of standard OS and software
> packages, etc.  A firewall at the border adds very little
> defense-in-depth and increases all types of costs dramatically.
>
> In addition to the URL that Erik included, there are some interesting
> presentations to look at that depict the evolving view toward firewalls
> and other security mechanisms in the research and education (R&E)
> community.
>
> This presentation from Eli Dart of LBNL and ESNet is particularly good
> on a number of levels:
>
> http://events.internet2.edu/2010/jt-slc/agenda.cfm?go=session&id=10001008&event=1111
>
> Joe St. Sauver of the the University of Oregon and Internet2 covers some
> similar topics:
>
> http://www.uoregon.edu/~joe/architectures/architecture.pdf
>
> michael
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Michael Sinatra
In reply to this post by Tom Holub
On 05/25/10 14:31, Tom Holub wrote:
> There was a Firewalls Task Force a few years back (2002) which looked at
> the question of firewall implementations on campus.  The report appears
> to no longer be online (never break URLs, people), but you can get it
> from archive.org:
>
> http://web.archive.org/web/20070626151624/http://fwtf.berkeley.edu/

Sorry about that.  It must be lying around here somewhere, and I'll see
if I can get it back online.

> The list of participants is either amusing or depressing, depending on
> your perspective: by my count, only 9 of 21 participants remain on
> campus.  Those who are still around are apparently still interested in
> talking about the issue.

Saskia Etling, the chair of the committee, is back on campus as a
short-term employee.  Just FYI.

michael

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Tom Holub
In reply to this post by Bill Clark
On 5/25/10 2:16 PM, Bill Clark wrote:
>
> Arguing that enterprise-wide firewalls are bad because they give a false
> sense of security is akin to arguing that seatbelts encourage reckless
> driving.

Seatbelts *do* encourage reckless driving.  Safety mechanisms rarely
produce the reduction in injuries/incidents that they are projected to
produce, because people/users automatically compensate for risk.
Anti-lock brakes don't produce a measurable improvement in road safety,
not because they don't work, but because people become accustomed to
braking faster, and therefore leave less stopping distance.  Similar
things can happen with a hardware firewall.  Many IT vendors who provide
systems which use clear-text authentication or other obviously poor
security practices will respond, "well isn't it behind your firewall?"
when asked if their systems could comply with our minimum standards.
The effect is real; the question is the magnitude of the benefit vs. the
magnitude of the risk compensation.

--
Tom Holub ([hidden email], 510-642-9069)
Director of Computing, College of Letters & Science
249 Campbell Hall
<http://LS.berkeley.edu/lscr/>

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
In reply to this post by Erik Klavon
(Apologies to those using screen readers for not top-posting, but I'd like
to address Erik's points inline.)

> I do very much prefer that everything be locked down at the edge
> (which is to say, as close to the host) of our network as possible.

Sorry; I meant "border" and not "edge" as I noticed in the terminology
section of the link you sent earlier :)

> Please define what you mean by "either-or mentality".

That much of the argument against border firewalls (that I've read in the
past few hours) seems to be "border firewalls aren't a silver bullet, so
therefore they are useless" or "host-based security is critical anyway, so
border firewalls are a waste of time" which seems to me to be excluding
the value of having BOTH solutions in place.  Nobody (on Micronet) has
been saying "we should close down our network instead of focusing on
securing our hosts" but rather that we should do both.

> You, and anyone else on campus is free to do so for the systems under
> your control. And, if this isn't what you want, you're free not to do
> it (to the degree that policy allows).

I'd been (mistakenly) assuming that it was both feasible and easy (from a
technology standpoint) to lock down the campus network at the border, and
that most of the obstacles were political in nature (i.e. departments
didn't want to give up the ability to run their own webservers without
having to ask for firewall exceptions) but that's not really the case.

Given that there are already very good options being offered, perhaps I
should shift my position to say that departments should be more strongly
encouraged to make use of the FWSM option for protecting their own
networks.

> I don't know you well enough to say this with any certainty, but my
> guess is that your view is less out of date than it is of a different
> environment than the one you now find yourself in.

That sounds like a fair assessment.  My more recent university experience
was at a smaller (and far more centralized) institution, and while I did
work at a much larger one that was a long time ago and the whole computing
environment was very different back then.

Thanks again to everyone who has contributed to this quite interesting
discussion! :)

-Bill Clark

>
> Erik
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Erik Klavon
On Tue, May 25, 2010 at 02:52:19PM -0700, Bill Clark wrote:

> (Apologies to those using screen readers for not top-posting, but I'd like
> to address Erik's points inline.)
>
> > I do very much prefer that everything be locked down at the edge
> > (which is to say, as close to the host) of our network as possible.
>
> Sorry; I meant "border" and not "edge" as I noticed in the terminology
> section of the link you sent earlier :)
>
> > Please define what you mean by "either-or mentality".
>
> That much of the argument against border firewalls (that I've read in the
> past few hours) seems to be "border firewalls aren't a silver bullet, so
> therefore they are useless" or "host-based security is critical anyway, so
> border firewalls are a waste of time" which seems to me to be excluding
> the value of having BOTH solutions in place.  Nobody (on Micronet) has
> been saying "we should close down our network instead of focusing on
> securing our hosts" but rather that we should do both.

Assuming one could find capable technology and infinite resources to
deal with all the problems, sure, why not do both. As long as I can
exclude my hosts from the whole thing where I have compensating
controls.

Erik

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Erik Klavon
In reply to this post by Bill Clark
On Tue, May 25, 2010 at 02:37:48PM -0700, Bill Clark wrote:
> My point regarding public addresses wasn't meant as a call for a
> campus-wide NAT but more for something similar to the FWSM option, so that
> individual units could set up their own non-routable local networks.  I
> had been under the impression that the use of private address space for
> workstations was actually discouraged by campus policy, perhaps for
> reasons relating to how network charges are set up.  Perhaps (hopefully?)
> I'm mistaken there.

Individual departments can (and have) set up their own non routed
RFC 1918 networks. If you want campus routed RFC 1918 address space
you can get that too. See the URL below for guidelines on the use of
RFC 1918 address space on campus. I can't recall any policy that
discourages use of RFC 1918 address space; if you can find an example
please provide it. If you use NAT, there are some policy requirements
that you be able to attribute network activity back to an individual
host behind the NAT device.

http://net.berkeley.edu/netinfo/ip/rfc1918.shtml

Erik

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Bill Clark
The "policy" I'm referring to (based purely on unverified heresay)
involved the way units are charged for network services, but may simply be
based on a misunderstanding about how the "node charges" work.  It looks
like all of that is going to change effective July 1st to a pay-per-person
model anyway, which makes a lot more sense.  So even if there were any
truth to the "IS&T frowns on NAT usage within departments because it
messes up their recharge model" rumors (and it seems there aren't) those
would be a thing of the past, next fiscal year.

I've already suggested to the powers that be within our unit that we might
want the FWSM option added to our network.. if there were a recharge
service to provide NAT in the same way, so that there'd be minimal setup
and nearly zero maintenance on our end, I'd push for our adopting that as
well.

I realize we don't exactly have a shortage of routable addresses on campus
(we have what.. two or three /16 networks, at least -- right?) but if
departments were charged more for routable addresses than non-routable,
that might encourage more appropriate usage patterns.  Desktops really
don't need (and probably shouldn't have) publicly routable addresses.

-Bill Clark

> On Tue, May 25, 2010 at 02:37:48PM -0700, Bill Clark wrote:
>> My point regarding public addresses wasn't meant as a call for a
>> campus-wide NAT but more for something similar to the FWSM option, so
>> that
>> individual units could set up their own non-routable local networks.  I
>> had been under the impression that the use of private address space for
>> workstations was actually discouraged by campus policy, perhaps for
>> reasons relating to how network charges are set up.  Perhaps
>> (hopefully?)
>> I'm mistaken there.
>
> Individual departments can (and have) set up their own non routed
> RFC 1918 networks. If you want campus routed RFC 1918 address space
> you can get that too. See the URL below for guidelines on the use of
> RFC 1918 address space on campus. I can't recall any policy that
> discourages use of RFC 1918 address space; if you can find an example
> please provide it. If you use NAT, there are some policy requirements
> that you be able to attribute network activity back to an individual
> host behind the NAT device.
>
> http://net.berkeley.edu/netinfo/ip/rfc1918.shtml
>
> Erik
>



 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] Campus Firewall and Public IPs

Erik Klavon
On Tue, May 25, 2010 at 06:55:56PM -0700, Bill Clark wrote:
> The "policy" I'm referring to (based purely on unverified heresay)
> involved the way units are charged for network services, but may simply be
> based on a misunderstanding about how the "node charges" work.  It looks
> like all of that is going to change effective July 1st to a pay-per-person
> model anyway, which makes a lot more sense.  So even if there were any
> truth to the "IS&T frowns on NAT usage within departments because it
> messes up their recharge model" rumors (and it seems there aren't) those
> would be a thing of the past, next fiscal year.

Node charges were never, ever based on IP addresses. Any reasoning
based on this assumption is faulty.

> I realize we don't exactly have a shortage of routable addresses on
> campus [...]

We have a finite allocation of IPv4 address space. Our allocation is
small compared to that of other R&E organizations of our size. It is
unlikely we will receive any additional IPv4 address space. We must
wisely use the limited IPv4 address space we have.
 
> Desktops really don't need (and probably shouldn't have) publicly
> routable addresses.

I don't agree with the general assertion that desktops don't need or
shouldn't have globally routable IP addresses. Not all applications
that can be run on a desktop are compatible with NAT. Within your
department, you may be able to make this statement, or be in a
position to say that any application broken by the use of NAT is an
acceptable loss. This isn't an assumption we can make campus wide.

Erik

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.