[hcoop/zz_old/ikiwiki] / FirewallRules.mdwn

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.\r
\r
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, rooted at {{{/etc/firewall/closed.conf}}}.  The file {{{/etc/firewall/users.conf}}} defines user-specific rules, granting users permission to listen on particular ports or connect to particular ports on other servers.  We try to limit connections to particular IP addresses, as well, whenever feasible.\r
\r
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.\r
\r
= fwtool =\r
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 {{{/etc/firewall/users.rules}}}.  The portal has [https://members.hcoop.net/portal/sec an interface for requesting modifications to this file] on your behalf.  You should also be able to view this file directly, if curious.\r
\r
At the moment, {{{fwtool}}} supports these directives:\r
\r
 * {{{user Client ports [hosts]}}}: Allow {{{user}}} to connect to remote hosts on any of the given {{{ports}}}, which are specified as a comma-separated list of single port numbers and/or ranges of the form {{{low:high}}}.  The space-separated list {{{hosts}}} is optional.  If omitted, connections are allowed to any remote IP addresses.  If included, {{{hosts}}} provides an exhaustive list of the IP addresses and/or hostnames to which to allow connections.\r
 * {{{user Server ports [hosts]}}}: The analogue of the above, for the privileges of listening and accepting connections.\r
 * {{{user LocalServer ports}}}: Allow {{{user}}} to listen and accept connections on the {{{ports}}}, but only for connections from the local server to itself.  This is useful for things like running your own web server that Apache proxies, which you can configure using the {{{LocalProxy}}} VirtualHostConfiguration directive.\r
Commit	Line	Data
ee25310d	1	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.\r
	2	\r
	3	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, rooted at {{{/etc/firewall/closed.conf}}}. The file {{{/etc/firewall/users.conf}}} defines user-specific rules, granting users permission to listen on particular ports or connect to particular ports on other servers. We try to limit connections to particular IP addresses, as well, whenever feasible.\r
	4	\r
	5	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.\r
	6	\r
	7	= fwtool =\r
	8	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 {{{/etc/firewall/users.rules}}}. The portal has [https://members.hcoop.net/portal/sec an interface for requesting modifications to this file] on your behalf. You should also be able to view this file directly, if curious.\r
	9	\r
	10	At the moment, {{{fwtool}}} supports these directives:\r
	11	\r
	12	* {{{user Client ports [hosts]}}}: Allow {{{user}}} to connect to remote hosts on any of the given {{{ports}}}, which are specified as a comma-separated list of single port numbers and/or ranges of the form {{{low:high}}}. The space-separated list {{{hosts}}} is optional. If omitted, connections are allowed to any remote IP addresses. If included, {{{hosts}}} provides an exhaustive list of the IP addresses and/or hostnames to which to allow connections.\r
	13	* {{{user Server ports [hosts]}}}: The analogue of the above, for the privileges of listening and accepting connections.\r
	14	* {{{user LocalServer ports}}}: Allow {{{user}}} to listen and accept connections on the {{{ports}}}, but only for connections from the local server to itself. This is useful for things like running your own web server that Apache proxies, which you can configure using the {{{LocalProxy}}} VirtualHostConfiguration directive.\r