The Humble University.
The humble tech department at the humble university.
Basically I have a story. Tufts University, as a university in the Boston, MA area, was a early adopter of the “Internet,” the thing that we use to do stuff with. This means that Tufts has a direct hardwired fiber connection into the internet backbone. See:
[nandre@t ~]$ traceroute sm.axfp.org traceroute to sm.axfp.org (198.23.162.221), 30 hops max, 60 byte packets 1 anderson-rtr-pri-t-vlan87.net.tufts.edu (130.64.87.1) 0.319 ms 0.389 ms 0.457 ms 2 medford-dist-pri-x-pearson-rtr-pri.net.tufts.edu (130.64.4.30) 0.310 ms 0.385 ms 0.438 ms 3 border-pri-x-tab-core-sec.net.tufts.edu (130.64.254.210) 0.163 ms 0.162 ms 0.170 ms 4 vl1079.mag01.bos01.atlas.cogentco.com (66.28.20.249) 1.266 ms 1.265 ms 1.258 ms 5 te0-4-0-0.ccr22.bos01.atlas.cogentco.com (154.54.43.53) 1.110 ms 1.139 ms 1.167 ms 6 te8-8.ccr01.alb02.atlas.cogentco.com (154.54.30.17) 4.742 ms te7-8.ccr01.alb02.atlas.cogentco.com (154.54.43.10) 4.486 ms te7-8.ccr02.alb02.atlas.cogentco.com (154.54.43.14) 4.564 ms 7 te3-8.ccr01.buf02.atlas.cogentco.com (154.54.42.241) 11.222 ms te7-8.ccr01.buf02.atlas.cogentco.com (154.54.42.245) 11.000 ms te3-8.ccr01.buf02.atlas.cogentco.com (154.54.42.241) 11.095 ms 8 38.122.36.46 (38.122.36.46) 13.905 ms 14.249 ms te3-8.ccr01.buf02.atlas.cogentco.com (154.54.42.241) 11.101 ms 9 host.colocrossing.com (192.210.233.194) 24.337 ms 24.584 ms 24.920 ms 10 198.23.162.194 (198.23.162.194) 14.042 ms 14.041 ms host.colocrossing.com (192.210.233.194) 25.494 ms 11 198.23.162.194 (198.23.162.194) 14.315 ms sm2.axfp.org (198.23.162.221) 13.824 ms 13.827 ms
Notice the ever-prevalent cogentco.com on the way to my ServerMania VPS in Buffalo, NY. This is a huge advantage, because during peak hours I can get up to 150 mbps up/down. That’s awesome.
Tufts policy allows me to get a DHCP lease with a handy portal (which is really a mediocrely crafted front end to a DHCP/access control system). That address, though “dynamic,” gives me a fully functional server with all ports open*.
Now I wanted to get a Static DHCP Lease. They offer then for Tufts Servers, like linux.cs.tufts.edu, and it’s only the click of a few buttons and 10 hours of bureaucratic absurdity. However, when I asked for a static DHCP lease, I received:
We do indeed support linux servers, workstations, services in ASE (and concomitant static IP's) on the Medford campus however there are a couple of questions and requirements which need to be answered. 0) Is this a commercial service? A non-profit org? I am honestly not sure the Tufts policy on this but we can find out in order to give you the best recommendation. 1) Is this currently just an experiment or do you plan on going into production? 2) Is this your own personal endeavor or do you have a faculty advisor or ? Either way we have a requirement that all linux systems (workstations or otherwise) on the Tufts network meet the following requirements 0) The system uses a firewall, specially, shorewall. We can provide samples to get you up to speed and it is very easy to understand. 1) The system uses tcp_wrappers for access control in addition to the firewall. Again we have samples and it will only take you a few minutes to understand. 2) The system is kept up to date with the latest operating system and package patches. 3) The system has known users of ownership, sys admin, and contact information so network operations, etc. know who to get in touch with in case of an issue. 4) The system sends logs to a central log server for automated analysis and alerting. You can of course continue to send logs to the systems local harddrive since that is easiest for you to access. The central log server simply looks for patterns such as an ssh login from Tufts and then 10 minutes later if the same account logs in from 5000 miles away it will send an alert. Because the network is under constant scrutiny millions of times per day it is important that we utilize all options available for secure management. 5) ASE system administration staff have ssh and sudo access to the system. We will not change anything on the system without talking to you first but this is important to ascertain what the system is doing at any given moment with a maximum amount of efficiency and expediency. Vice versa you are free to run the box on your own but please let us know of any changes you make just in case it sets of any mental alarms. You could be amazed at how many times we have heard "oh our web software wasn't working correctly so we turned off the system firewall"... 6) ASE provides no means to backup, recover or failover the system, home directories, data or configuration in case the server dies. If the system is research oriented we can arrange for enterprise level storage which is backed up but otherwise you are on your own. 7) A ups is highly recommended and we can help you configure that but again related to #6 any hardware issues you are generally on your own unless it is a Tufts owned piece of equipment. 8) Our general security policy is "deny everything except that which is explicitly allowed and only from explicitly known systems" In the case of a web server this means of course that portion needs to be open up to the internet but ssh could potentially only be allowed from Tufts or the Tufts vpn. Everything else should be blocked. Given this there are a # of other options available such as using a variety of on campus hosting options running on our virtualization servers (kvm, vmware, etc) where a front-end answers for the requests and you then simply run the back-end which is used to fulfill the http requests. Either way it revolves around Tufts willingness to allow a .com or .org and your specific usage case. We look forward to hearing back from you and determining what can be worked out.
Then later:
NOTE: It isn't "regulation" so much as standard enterprise level architecture, system administration.
Which I was surprised to see. During normal DHCP operation, Tufts has a standard ISP policy: If you have an issue with your server, we will disconnect you from the internet until it gets resolved.
When I get a different type of DHCP lease, Tufts adopts a “full enterprise level security architecture.” Naturally, I responded:
Here is what I see as the difference between an Enterprise and Consumer level system. Please let me know if any of my assumptions are incorrect: 1) In an enterprise level situation, you would: - have paid for my server. - have set up my server. - be using my server, yourself. - maintain my server to your required standards for your use. As none of this has happened, I don't see how you equate the two. 2) In this situation you function as an Internet Service Provider to me (your consumer), similar to Verizon FiOS. The only difference is I pay for Verizon directly as opposed to through my tuition (this lack of direct financial accountability is arguably the problem with any service offered through this system, but I digress...). Understand: - Verizon will provide a static DHCP lease from their address pool for a fee. - Verizon has the authority to cut off my internet access in the event they detect unreasonable activity - Verizon does not require root access and a phone call every time I make a change to what is on my local network (obviously my network is a subset of theirs). I understand that in an enterprise level situation, you require more direct control of your servers. I do not see how this fits even remotely into that category. If you had agreed to purchase and set up a server on your own dollar for my use, then I would be fully willing to have you manage it. This is not that case. Do you have a reasonable argument as to why your static IP addresses come with such a high burden, or is what you are handing me simply policy that has been enacted which you are unable to change? Furthermore, you appear to misunderstand the definition of "server" as it is somewhat unclear these days: 1) By pressing about 4 buttons on my macbook air, it starts a web and SSH server. Everyone can do this. By mapping a domain name to my computer using DNS, it is now easily globally accessible. 2) When I ask that I get a different type of DHCP lease, your requirements go from a standard ISP policy to a slew of enterprise level remote management and logging requirements. Why is the difference so huge?
Granted, I’m just poking things (I have a nasty tendency to do that…I try not to burn bridges too often). But I did not feel it was reasonable. This all boils down to the university conundrum:
The University Conundrum
Tufts Technology Services (TTS) is not a business. The reason capitalism works is because Verizon, my home ISP, has competition from Comcast, a terrible ISP with the uptime of tired cat and bottom heavy connection speed tiers that practically turn the world upside down (300 mbps down, 5 up). Since I pay Verizon directly (as opposed to through my tuition), they have a direct financial incentive to serve me well. TTS (and the rest of Tufts organizations) hide behind a bureaucracy of ridiculous scale and get paid through a budget, not a bill.
This is combined with the fact that all private academic institutions have adopted the tragic philosophy that hiring under qualified but cheaper people will save them money in the long run. I’m sure it does help the bottom line, but it ruins efficiency when the director (and all workers) of your technology service (not Tufts, this is my high school now) doesn’t know what bash is but yet is managing a gigantic system of Unix-based OSX computers. How? Why? The “university conundrum” strikes again.
TTS did redeem itself. I saw independent thinking and was proud:
Nicholas, You've made your point very cogently. As previously mentioned we are working to provide a solution to meet your needs, there are many people who need to be contacted and we need to be given the time to do so.
After looking up the word “cogent,” I appreciated the comment.
Thanks for your help and understanding. I do not mean to be incendiary with my comments. I understand that offering such a support and monitoring service as you mention has a significant place in ensuring the security and proper operation of a network as wide as that of Tufts'. It would be beneficial for many (but not necessarily all) people wishing to run servers at Tufts to utilize it. Obviously finding a policy which fits every usage scenario is difficult if not impossible, and so I especially appreciate your help with this. This is not very urgent, so no need to go out of your way. Thanks, --Nick
That’s it!
*So I will admit that for no apparent reason, port 25 stopped working on my server. After establishing that it was a network issue of some type (and a very strange one at that, as other computers on the LAN did not have that issue), I moved buildings and the port mysteriously reopened. The logical conclusion? Tufts is stupid.