Fermilab is moving to a "default deny" network posture for services operating on ports 80 and 443 (the default http and https service ports respectively).
This means that by default, no traffic will be allowed into Fermlab network on those ports. Only servers which are explicitly listed in the border router's access control lists will be allowed to serve offsite requests on these ports. The reason for doing this is to protect the increasingly large number of machines running embedded or unintended webservers from an ever more hostile Internet. Web servers have become more important targets as attack points due to their ease of misconfiguration, relatively immature software (i.e., many bugs resulting in vulnerabilities), and visibility.
An initial list of "permitted" machines has been created from those with significant offsite traffic over the past month. You should check whether you have machines that need offsite connectivity. The exception list is available sorted by IP number and by DNS name.
To get a "permit" in the access list, you the system administrator need to arrange for the following:
- The web service must be offered from a static IP address for the server.
(See MISNET for network address changes)
- At least one sysadmin must be registered for the machine.
(See SYSADMINDB on how to register as an admin)
- The machine must have passed a recent "external" Nessus scan.
(See Fermilab Security Scanning using Nessus for information on how to run a scan)
- The request must be made via the Web server permit request form.
(You will need to be able to authenticate to this webpage with a KCA certificate. Instructions on how to do this for common browsers are being accumulated at http://security.fnal.gov/WebBrowsers/. )
"Passing" a scan at the moment is enforced only by checking that a scan has been performed by a responsible admin. The expectation is that the admin will review the information and address as many vulnerabilities as possible given the operational requirements of the webserver. One should note that machines granted exceptions are expected to stay current with operating system patches, application patches, and have configurations reviewed periodically for errors. These machines will be targets for attack probes and one can expect those attacks to be persistent and improving.
Note: it is possible to run webservers on ports other than these default ones. People may have good reasons for doing so and these will not be affected by the above blocks. HOWEVER, one should assume that all webservers are known to attackers (regardless of ports on which they run). Anyone running a webserver on ports other than the default is assumed to be doing so knowingly and will be expected to maintain the same standards of administration as those outlined above for getting an exception.
Requests will be handled as quickly as possible (we are hoping to automate this) but will require 1-5 business days to become operational if they are in order. One can escalate urgent cases through the appropriate GCSC for your division/section/experiment.
If none seem appropriate write to nightwatch@fnal.gov.
What's New
7/17/03 The webserver port block is announced.
7/29/03 The webserver port block is implemented.
FAQ
Q: Why can't I see the seed list offsite ?
A: As a protection against widespread distribution of this list, the list is restricted to access from FNAL addresses or via sessions authenticated with a Fermilab KCA credential.
Q: WHY ?!!
A: Basicly because the risk levels have changed. There is significant scrutiny on webservers (both from malefactors
and monitors) and the number of these without proper support continues to grow. Peer institutions and technical experts have been recommending for some time that we move to default deny on webservers and this has been discussed for quite some time. Recently, two professionally managed websites were hacked (one hacked again after the initial modifications) and the point brought home about how difficult and important it is to properly manage a webserver. Consulting with Division/Section/Experiment representatives, the CSExec has decided it's time to make this transition.
Q: Why so fast a change ?
A: We have been discussing this transition for quite a long time and have alerted sysadmins and webmasters many months ago that this transition was pending a small change of conditions and would likely happen quickly. That time has come.
Q: Why do I need a KCA certificate to request an exception.
A: We need to authenticate that it's a valid request. Since one needs a KCA certificate to run a Nessus scan,
requiring one allows us to automate the process. If you cannot get that to work then email to nightwatch@fnal.gov
is a fallback (but you will have to deal with the human delays).
Q: Do I have to remove every Nessus vulnerability ?
A: Vulnerability scanners are notorious for false positives. Some listed vulnerabilities are of the type "Check service X. Versions below Y may be vulnerable to exploit Z" which indicates that the scanner couldn't tell. Others may turn out to be wrong due to local modifications, etc. Therefore, no, you will not have to have zero vulnerabilities, but you should know why you are accepting the ones that remain.
|
