Terms of Service
Usage of this computing system assumes that you have read this document. Violating the terms of this document is a violation of the Computer Fraud and Abuse Act of 1986, and can face criminal prosecution.
I’ve created a couple of new server side compute rules, to maximize security and keep performance of core applications at a reasonable level. Here are a couple of those newly implemented rules and guidelines to make the server-side experience as smooth as possible.
5 failed remote login attempts in 2 minutes leads to 10 minute IP address band. User Consequence: must remember his/her password.
Non-System users (all SRC student/faculty users) have limited compute and storage resources. In the case of resource conflict, and only in the case of conflict, non-system users receive a combined maximum 25% of the available CPU time. In all cases non-system users are limited to a combined 1GB of RAM. User Consequence: reduced computing capacity, forced sharing of capacity among students/faculty.
Limited number of available programming environments. This one needs a little explanation, of course. The security advantage: system programs share resources. If you can read the memory space where I have my private keys, there’s something seriously wrong with the security model, so the environments must be isolated. Ideally, users should not even be able to ssh and work on a production machine. This isn’t an option at the moment, so I’m forcing all non-essential libraries and programs to be loaded in sandboxed memory locations by not providing system versions for languages that aren’t absolutely necessary. (Heck, if Golang isn’t even installed globally on the server as a security provision, what makes you think your application is more important than the software that runs all of the server’s network transactions.) The technical Advantage: I can’t install and maintain hundreds of versions of software and libraries that I don’t use and don’t care for. Learn to vendor your dependencies properly and responsibly, and practice good software development. User Consequence: forces compilation from source of a large number of software and libraries, forces user to follow standards for software distribution.
Restricted Ports. This is a SERVER after all. Users shouldn’t be able to open up holes into the global internet without having it registered. User Consequence: Forces users to write WSGI, FCGI, scripts to proxy requests to a port that the user has opened up to localhost.
If the following activities are detected, your SRC-CODE access will be revoked immediately.
Snooping on unencrypted server ports. Our server does not have enough compute capacity to encrypt all applications end-to-end, so I have setup NGINX™ to act as an ssl endpoint. This leaves the following internal ports open for snooping:
:21, :14000 - :14100Unencrypted FTP Server.
:25SMTP mail server.
:80Unencrypted HTTP communications.
:389Unencrypted OpenLDAP server communications.
:3000Gogs Git Service.
:5432Unencrypted PgSQL server communications.
:6379Unencrypted Redis server communications.
:8000Drone Continuous Integration Service.
:8080Per-User Apache websites.
Accessing files that you do not have privilege to access. Do not attempt to access or modify files that are not yours. This includes other member’s publicly open ports or unencrypted data sockets. There is no expectation of privacy on this system, but that does not mean you have to be the one to violate other’s privacy.
Do not impersonate another member of the SRC Community.
Do not attempt to attack the server or its users in anyway.
Why are these rules so harsh?
Because we look to negotiate with ITS on the possibility of opening up this server to the public, and security is of utmost importance.
Because we have 50 something GB of data that we don’t have backed up and cannot afford to lose.
Because these rules aren’t harsh. They are good practice. I’ll be damned if the current generation of software engineers can’t even compile software from source.