By default, the S&T border firewall blocks all inbound connections. Only approved services are granted an exception to this default deny. All exceptions are subject to auditing, verification and revocation.
If the request is for outbound network connections then no exception is needed as those are automatically allowed.
Auditing
The most basic audit performed is with a vulnerability scanner. Any critical vulnerabilities will preclude an exception and all important vulnerabilities must be remediated to avoid loss of exception. The University receives vulnerability reports from third parties; on receipt of a verified report the exception will be suspended pending remediation and the exception requestor notified. Other security audits may be performed depending on the nature of the service and exception.
All services are expected to be fully patched. Any missing security patches may be result in suspension or revocation of the exception. Other measures may be required as well. For example, the use of fail2ban to protect a service or requiring key-only authentication for SSH.
Verification
Firewall exceptions are for an identified service. If a different service is used than the one identified the exception will be suspended and may be revoked. Some services can have additional capabilities added on. For example, a web server may use modules to provide additional services such as PHP. Only identified services that have been specifically approved are allowed.
Revocation
Information Security may at any time suspend or revoke an exception in order to best protect the stability and security of the University’s network and associated systems and data. Revocation of the firewall exception in docflow automatically generates a notice to the submitter.
Form Submission
The Exception to Firewall Policy form is hosted in docflow. It must be submitted by the full-time faculty or staff member responsible for the service the exception is being requested for. A separate form must be filed for each system for which an exception is desired, but the form can include multiple services.
An exception reason must be provided in order to have context to enable a decision to approve the request. The more specific the reason the easier it is to approve.
The service, or services, for which an exception is being requested must be identified. Note that the exception is for the service not a port. Only network traffic that matches the requested service will be allowed, regardless of what port the service is operating on. It is perfectly acceptable (and can be desirable) to run a service on non-standard ports.
If the exception is for a common service that is listed in the multi-select box then the service can be selected there. For other services the application, protocol and port should be specified. Note: the protocol and port are there to help clarify the request. Exceptions are granted to services, not ports.
Finally, if the service should only be available to particular IP addresses or networks then those can be specified. This can be an important way to protect a service from attackers when the user’s network locations are known.