Re: Inbound Default Deny Policy at Internet Border

[Gary Flynn <flynngn () JMU EDU>]

stanislav shalunov wrote:

> Gary Flynn <flynngn () JMU EDU> writes:
>
>
> > We're looking at implementing a default deny inbound policy at our
> > Internet border this summer.
>
>
> As long as it isn't called ``Internet'' border, but rather ``Web and
> Email'' border, that's a fine policy.  If the campus is to run
> advanced applications, it needs Internet connectivity.

I'm not suggesting blocking connectivity for people that
need it. I'm suggesting protecting people from connectivity
that don't need it.

  Why stop with
> the policy at the border?  Scans could come from within, especially in
> a university environment.  What about a default ``deny'' policy in
> every Ethernet switch?

Diminishing returns. At the border, I cut direct access from
from 600 million people to 15 thousand.

Speaking of interior access controls, isn't that what netreg,
perfigo, 802.1x, and similar products provide?

> The day before yesterday, I got this little hardware VoIP/POTS
> combination thingie, which I'm going to try at home.
> I'm not sure how
> it works.  I'm not sure how to read the serial number, but it's
> possible that fewer than 100 units [sic!] of these were sold so far.
> It's a very early stage device.  Development is ongoing.  The manual
> that came with it tells me how to plug it in, but it's really zero
> configuration.  It claims it will even somehow determine my phone
> number (I guess it might call some 800 number, have ANI determine the
> number,
 and transmit it back on the line, but I'm just guessing).  I
> have no faintest clue which protocols it supports, let alone which
> port numbers it is going to use.  I assume these aren't static, as the
> thingie can reprogram itself with a new flash (one of the few things
> the manual does tell you is how to tell it's writing flash -- and how
> it's important to avoid unplugging it at that time).  Anyone with the
> same kind of thingie can dial my (normal) number and, by magic, they
> would connect to me over IP.  It also interconnects with a few
> established VoIP networks.  By default, calls go over POTS.  (You can
> also order service for it, but that requires paying something extra
> regularly, of course; in its default config, it uses no resources of
> the company that sells it -- other than directory services -- and is
> ``free'' to use.)  At home, I'm going to just plug it into Ethernet,
> power outlet, phone line, and attach a handset.  Suppose I were at
> your campus.  What request would I need to make to get this thing to
> work to its full potential?  (Keep in mind that I don't even know its
> IP address, which, I gather, it gets from DHCP.)

Well, first, if its at your home, it wouldn't much matter.

If its on campus, I'd hope that expecting someone to do a
little more research or ask for support assistance before
tying an unknown, development level device to both their
university computer and university phone system on what
may possibly be an administrative subnet would not be
too much to ask with or without network access controls.
The network access controls just protect the campus and
university resources from just such an occurrence if
someone decides they want to install a
web/database/beta/anything server with insufficient
knowledge and preparation.

The way I envision the system working is to have a web request
system where a person can request opening inbound access for
IP addresses they are registered as owning (we have a campus
wide Perfigo system). Initially, changes would be manual but
the process could be automated after we gain more experience.
I don't envision an approval process although there may be
some sanity checking and auditing to check for abuse. The
process may also kick off an automated vulnerability scan
before access is granted. The person responsible for an IP
address may also have access to network log entries associated
with that address to help them determine if their problems are
being caused by network access controls and what specific
access is being attempted by the application in question.
Some intelligent parsing of the data may make it more useful
for unsophisticated users. It may be difficult because of the
number of infection/probe attempts that show up in the logs
but that may prove to be beneficial for security awareness. :)

--
Gary Flynn
Security Engineer
James Madison University

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/groups/.