Background
"Open Web Servers" are web servers that are visible from the Internet. Unless you take action to put the web server behind Cloudflare, it will only be visible from inside the Lab network. Web servers open to the Internet are challenging to secure due to ever increasing and sophisticated attacks. Even with careful configuration and updated software, new vulnerabilities emerge quickly. In order to protect web servers open to the Internet, they must be behind Cloudflare, which provides a wide range of protections.
Requirements
Requirement 1: Distinct server DNS record
You must have a DNS record for the server that is separate from the web site name.
Pick the server name and use iprequest.lbl.gov to acquire an A+PTR record.
The server cannot have the same name as the web site, since the web site name will point to Cloudflare. You are free to use whatever server name you like but our recommended standard is to add a -local suffix, for example coolscience-local.lbl.gov. If other services need to be accessed, such as SSH, you will use the server name.
Requirement 2: Distinct web site DNS record
Pick the web site name and use iprequest.lbl.gov to acquire a CNAME for the web site.
Make the target for the CNAME the server name you created above. For example, the web site coolscience.lbl.gov will have a CNAME to coolscience-local.lbl.gov. This setup allows you to test you web server configuration, such as making sure the web server properly serves requests for the web site, but keeps the web server protected during this stage, only accessible from inside the Lab network or VPN.
Lastly, adjust the TTL on the web site CNAME to 600 seconds with iprequest.lbl.gov. This is an important change to insure your web site will be available through Cloudflare in a timely manner. The default of 43200 seconds (12 hours) will create a delay.
Requirement 3: Serving content
Your web site and home page must be serving content that represents Berkeley Lab. A web server cannot be open to the Internet with an "Under Construction page" or a default Apache page. Web sites must not be open to the Internet until development is complete. Content must reflect the RPM Policy on Acceptable Use of Information Technology and include contact information for the web site.
Requirement 4: SSL configured on 443/tcp
Your web server must only service HTTPS (SSL) on standard port 443/tcp. Cloudflare only uses HTTPS to connect to your site.
You do not need an acquire an SSL certificate because Cloudflare accepts self-signed certificates and generates valid certificate the clients see for the web server hostname. Note that Cloudflare will automatically redirect any HTTP traffic to HTTPS, so there are no concerns about references to HTTP (bookmarks, links, etc). HTTP 80/tcp should be disabled on the web server.
Post-Cloudflare Requirements
Requirement 5: Web site access restricted to Cloudflare
Once your web site is behind Cloudflare, you must restrict access to Cloudflare IP ranges. This restriction must be done at Layer 3 (IP), for example using a hardware firewall or host based firewall, such as iptables. Methods that are higher in the network stack, such Apache rules, provide inadequate protection and do not meet this requirement. This will protect your web server from an attacker inside the Lab bypassing Cloudflare protection.
Requirement 6: Content Moderation (if applicable)
If your website contains a wiki, bulletin boards, blog or similar functionality that allow users to post content, you must disable anonymous content posting. Commenting on blogs and modifying wikis is a popular target of spammers and attackers looking to deface websites for the lulz.
Requirement 7: Account Vetting (if applicable)
Accounts on most content management systems and many custom developed applications provide access to additional functionality. Attackers are aware of this and will acquire an account as a means to leverage their attack. For this reason, you must not allow anyone on the Internet to acquire an account without some form of account vetting. There is no single solution to vetting accounts. In low volume cases, having a human review each account request may be possible. In higher volume situation, a solution that requires the user to provide a cell phone number and confirm via SMS are sufficient. Please consult with [email protected] if you'd like other vetting ideas.
Recommendations
Recommendation 1: Modify Logging
Your web server configuration should be modified to record the actual client IP address of the request. Unless you take action, your web server will only log the Cloudflare IP address, not the actually client IP address. There are many solutions to his issue and describing them all for all web servers is beyond the scope of this web page. The short version of our recommendation for Apache is to use mod_remoteip. Cloudflare has some additional details here.
Recommendation 2: Separate Other Resources From Web Servers
If the web server is successfully attacked, other resources on the server are also put at risk. For example, if you host your web server on the same box where your personal files are stored, you personal files are at a greater risk. In extreme cases we have seen web servers acting as NFS and NIS servers. We advise you dedicate a web server to the single function of being a web server. Do not run other services, especially those that offer authentication or other security resources, on a web server.
Recommendation 3: Vigilance with popular packages
Applications like open source wikis, photo galleries, content management systems, and blogs are a growing vector of attack. These are increasingly popular applications because they are easy to setup and feature rich. However, these applications are targeted and attacked within hours of announced vulnerabilities. Some recent examples include Joomla, Drupal, Mediawiki, and struts2 based applications. If you run popular web applications or frameworks, you must subscribe to the security lists of these products and immediately patch them when vulnerabilities are announced.
Recommendation 4: Recognize custom code increases risk
Custom code, such as CGIs, commonly runs as the web server user. These scripts are routinely scanned and attacked by both humans and automated tools. An attacker who finds exploitable scripts or code will use them to attack your underlying data and system. Writing secure code and attending to all the various attack scenarios (like XSS and SQL injection) is a big topic - much too big for this web page. CPP may be able to refer you to additional resources, but at a minimum, limit your use of custom code and get help from experienced people. You can also request a web vulnerability scan of your custom code by contacting [email protected]. This can identify some of the most common vulnerabilities.
