[unisog] registering servers
flynngn at jmu.edu
Tue Jul 25 13:08:39 GMT 2006
Jordan Wiens wrote:
> We've got a policy of blocking outbound port 25 and requiring mail
> servers to be registered. This has saved us a lot of headaches over the
> past few years and we're looking at what other Universities have done in
> regards to registering other services besides just outbound mail.
> Can those who have experience with registering some or all of the
> services on their campus before allowing access comment to me (either
> off or on list) and I'll report with a summary of the results?
> I'm specifically interested in how much work it was to implement,
> whether you have stuck with the initial design, unforeseen problems,
> whether the benefits outweigh the cost, etc.
We went to a default deny inbound TCP access policy for the
general population last November with almost no problems.
People desiring to expose a server to the Internet use a web
based form to request it. Inbound connections to student
addresses have been blocked since 2003 and to IT staff
and other sensitive addresses since 2004.
Three keys to success:
1) We monitored traffic for the prior two months locating existing
servers ( outbound SYN-ACK ) and grandfathered them in with some
minimal sanity checking ( e.g. not TCP 6346 ). We're slowly
working through the list to unexpose those not intentionally
exposed. We could have been more aggressive but our number one
priority was to avoid disrupting operations. By doing so, we
heard zero complaints about the new policy and protected 85%+
of the computer population. 85% isn't as good as 100% but its
a lot better than 0% :)
2) Communication. There was a fair amount of confusion about what
the policy meant. We met with the departmental technology
coordinators and some individual departments to head off
concerns. Primary among the concerns:
a) We're not prohibiting exposure. We're just not making it
the default for the vast majority who don't need it ( 85% + )
and are exposed to unnecessary risk through the old policy.
We do try and discourage VNC, RDP, and other remote access
applications and steer the requester to our VPN client.
b) It does not affect connections initiated from inside campus.
3) Responsiveness to requests. Particularly at cutover. We had
initially planned to automate the process but the lack of
demand combined with the butterflies in my stomach caused by
the thought of automated router network ACL changes have led
us to continue with the manual process for now.
This will be our first Fall start of school under the new policy
but its been almost painless the last 9 months. We did have a few
glitches when we implemented the Cisco IOS firewall software to
handle FTP traffic a few months ago due to some asymmetric
routing across our Internet interfaces but we've straightened
that out. If you don't have a firewall that will handle FTP
sessions, you'll need to allow incoming connections with TCP
source port 20 or active FTP sessions won't work. We weren't
prepared to educate everyone about the difference between
active and passive FTP :) People with ulterior motives do
purposely source their activities on port 20 so we wanted to
close that major hole that would allow connections to any
We have continued to allow incoming connections to 113 due to
a few remaining applications that use it but monitor its
use and have our IDP configured to drop unusual connections to
that port. We'll continue to look for ways to minimize that
As for mail servers, we only have a handful exposed to the
Internet. Generally, we try to get people to relay through
the main campus mail system.
There have been a number of occasions when vulnerable
services have been protected by the access policy. It
allows us to focus more attention to vulnerabilities
on exposed servers. Thus far, there have been so few
costs and problems that I wish we had done it long ago.
Now, if only our new initiative of voluntary default deny/least
privilege non-administrator Windows accounts could be
as painless... :)
James Madison University
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2836 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dshield.org/pipermail/unisog/attachments/20060725/b36856a1/attachment.bin
More information about the unisog