welcome: please sign in

The following 360 words could not be found in the dictionary of 7 words (including 7 LocalSpellingWords) and are highlighted below:
able   above   accept   accepting   access   actions   activity   ad   additional   addresses   Administration   administrative   advantage   afs   all   Allocated   allocated   allocation   allocations   Allow   allow   allowed   allowing   already   also   an   An   analogue   and   another   any   anyone   Apache   application   appropriate   arbitrary   are   argument   as   As   at   At   attack   attacker   authorized   authorizing   automate   avoid   basis   be   behalf   block   Both   buggy   but   by   called   can   cannot   Category   Chat   Client   client   close   code   come   comma   Common   common   communicate   concern   configuration   configure   connect   connections   Contents   costing   covered   created   curious   current   default   developed   directives   directly   disallowing   do   does   doesn   doing   dollars   Dom   domtool   don   each   easy   end   enforce   entire   etc   example   exhaustive   fairly   feasible   fees   ferm   file   files   Firewall   firewall   first   following   Foot   for   freenode   from   future   fwtool   Fyodor   generally   generates   Generation   generation   git   given   good   harm   has   have   haven   hcoop   helpful   hides   highest   hoc   hope   hosting   hostnames   hosts   http   https   hundreds   if   If   Implicit   in   included   independently   information   infrastructure   input   interface   Internet   irc   is   isn   isolating   it   It   iteration   itself   keep   keeping   known   large   later   Libera   like   limit   limited   list   listen   listening   Local   local   locally   look   mail   make   manage   Manual   marsh   matters   may   media   Member   member   members   mod   modifications   moment   most   mozilla   much   must   near   need   needs   net   network   networks   next   Next   no   node   nonstandard   not   Note   numbers   obtain   Of   of   oftc   old   omitted   On   on   One   one   only   opened   optional   or   other   our   outgoing   own   particular   per   performed   permission   permitted   personal   port   portal   ported   Ports   ports   possible   prevent   prevented   primarily   primary   privileges   problem   problems   protocol   provide   provides   Proxied   proxies   proxy   public   range   Rationale   reasonable   recipes   reliable   remote   replacement   request   requested   requesting   requests   rule   Rules   rules   run   running   script   sec   second   See   see   separated   serve   Server   server   servers   services   setting   shady   shell   shelob   should   simply   Since   single   skipping   so   software   space   specific   specifically   specified   starting   stopping   subversion   successful   supports   Sure   system   System   Table   take   ten   that   The   the   them   these   they   things   this   This   those   time   to   To   too   tool   Tool   tools   traffic   transfer   try   unlawful   unrestricted   up   upper   us   used   useful   user   users   using   ve   very   view   visible   way   We   we   web   well   were   what   When   when   whenever   where   which   whitelist   Why   will   without   xmpp   You   you   your  

Clear message
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 avoid using ports too close to another member (see AllocatedFirewallPorts for allocated ports). A good rule is requesting ports skipping ten at a time (e.g. if the highest allocated ports were 50001 and 50002, you should request ports starting at 50010). If you have already requested ports, try to keep them near to your other ports if possible. 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.

Both TCP and UDP are opened for user firewall rules at this time. The next iteration of fwtool will allow setting rules for each protocol independently.

3. Common Rules

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

On marsh (the shell server), outgoing http, https, git, and subversion are permitted to all hosts. mail and xmpp are permitted to the hcoop mail and xmpp hosts.

IRC is permitted to the following networks generally (you may request access to additional networks on a personal basis, but we cannot allow access to networks known for any unlawful/shady activity):

Rules and recipes for common requests:

irc network
marsh USERNAME Client 6667 IRC_NETWORK_HOSTNAME

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 2021-06-05 12:05:21 by BjörnLindström)