welcome: please sign in

Diff for "FirewallTool"

Differences between revisions 1 and 2
Revision 1 as of 2013-01-21 08:34:07
Size: 2170
Editor: ClintonEbadi
Comment: it turns out that I am actually going to write new domtool container types god help me
Revision 2 as of 2013-01-21 08:45:46
Size: 2926
Editor: ClintonEbadi
Comment: perhaps what some firewall rules would look like
Deletions are marked like this. Additions are marked like this.
Line 32: Line 32:
== Idea ==
Line 33: Line 34:
My current thinking, expressed in pseudo-domtool @sig@

{{{
(* -*- domtool -*- *)

firewall "node" with
  userRules "user" with
    proxiedServer [port, ...] [host, ...];
    client [port, ...] [all_hosts];
    server ...;
  end;
end;
(* userRules could implicitly create group? *)


firewallGroup "name" with
  client ...;
end;
(* Groups would be independent of nodes? *)
(* How to differentiate between groups users can request and not? *)

firewallRules with
  addRules "group_name"; (* On DefaultFirewallHost? Or not support? *)
  addRulesAt "node" "group_name";
end;

(* In some user config file, let them grant themselves common ports on
   user nodes. Definitely provide bindings for web/shell nodes. *)
}}}

The system described below does not yet exist and is only in the earliest planning stages. See FirewallRules for how we manage firewalls today.

1. Rationale

The current FirewallRules system is a pretty thin abstraction over ferm, and has an ad-hoc parser with a number of built in limitations. Even after only having a dozen or so rules, it is becoming clear that managing firewall rules will quickly become burdensome both for members and admins.

Based on current patterns of requests, there a few things to consider:

  • We need a way to define groups of rules that members can trivially request
    • default ports for shell user (http, vcs software, mail, ssh, ...)
    • common rules for certain cgi applications or special uses (e.g. wordpress always needs to contact wordpress.org for full functionality)
  • Don't want to tie configuration to physical nodes (e.g. moving to a new shell server)
  • Restrict users to having rules on certain nodes (statically enforced)
  • Members should be able to grant themselves "safe" rules without any admin intervention
    • allowing members to grant themselves safely marked rule groups seems like a good start

A few wish list considerations:

  • Want to store per-node firewall config for system services (apache, exim, imap, etc.)
    • Ideally, also store common port config (afs, kerberos, domtool, etc.)

Conclusion: the current fwtool implementation would require duplicating a lot of functionality already present in the support machinery for the domtool domain type. A new syntax for user rule files would need to be created (or tons of hackish supporting code) so ...

The only (in)sane way forward is to create a domtool container for firewalls to manage rules. This has distinct advantages:

  • Takes advantage of current domtool infrastructure for pushing configs
  • The domtool language is quite nice and has the needed functionality for abstracting groups of users, common config, etc.
  • Lays the groundwork for using domtool to perform node management in addition to domain management

2. Idea

My current thinking, expressed in pseudo-domtool @sig@

(* -*- domtool -*- *)

firewall "node" with
  userRules "user" with
    proxiedServer [port, ...] [host, ...];
    client [port, ...] [all_hosts];
    server ...;
  end;
end;
(* userRules could implicitly create group? *)


firewallGroup "name" with
  client ...;
end;
(* Groups would be independent of nodes? *)
(* How to differentiate between groups users can request and not? *)

firewallRules with
  addRules "group_name"; (* On DefaultFirewallHost? Or not support? *)
  addRulesAt "node" "group_name";
end;

(* In some user config file, let them grant themselves common ports on
   user nodes. Definitely provide bindings for web/shell nodes. *)


CategorySystemAdministration CategoryWorkInProgress

FirewallTool (last edited 2013-01-21 08:45:46 by ClintonEbadi)