welcome: please sign in
Edit

FirewallRules

1. Rationale

Since we primarily provide "Internet hosting" and not "shell servers," our primary concern is keeping our services up and reliable. To this end, we try to limit user actions as much as possible without stopping those users from doing reasonable things.

One way we enforce this is by disallowing all network traffic that isn't covered by a specific "whitelist" rule in our ferm firewall configuration. We try to limit connections to particular IP addresses, as well, whenever feasible.1

2. fwtool

To make it easy for us to manage these per-user tools, we've developed an administrative tool called fwtool. It generates the appropriate ferm configuration using input from the file /afs/hcoop.net/common/etc/domtool/firewall/user.rules. The portal has an interface for requesting modifications to this file on your behalf. You should also be able to view this file directly, if curious.

At the moment, fwtool supports these directives2:

When requesting *Server rules, ports must be above 50000, and you should try avoiding using ports too close to another member (see AllocatedFirewallPorts for allocated ports). We hope to automate port allocation in the future, and are isolating ad-hoc allocations to the upper range of ports to prevent problems later on.

3. Common Rules

On navajos (the web server), outgoing http and https are permitted to all hosts by default.

On bog (the shell server), outgoing http, https, git, and subversion are permitted to all hosts; and irc is permitted to freenode by default.

Rules and recipes for common requests:

4. The Next Generation

The current firewall system is fairly limited and directly ported from what we were using on Fyodor, so it doesn't take advantage of the entire DomTool infrastructure. See FirewallTool for information on the next generation replacement.


CategorySystemAdministration CategoryMemberManual

  1. Why do this? As an example, we can look at a successful attack performed on our old server. A member's buggy PHP script allowed anyone to run arbitrary code as the PHP user. An attacker used this to obtain shell access, by running a shell server on a nonstandard port; and to connect to an IRC network and serve large media files, costing us hundreds of dollars in transfer fees. The first problem can be prevented by simply not allowing users to listen on ports that they don't have specific permission for. The second one can be prevented by authorizing IRC client connections to particular server IP addresses only. Sure, most of the time no harm will come from allowing unrestricted IRC client connections, but, when it matters, it can be very helpful to block actions that we haven't specifically authorized. (1)

  2. Implicit in each is a node argument where the firewall rules are created, but the portal hides this (2)

FirewallRules (last edited 2014-02-03 04:08:05 by hosted-by)