This page last changed on Feb 05, 2009 by aidan.
While using a properly configured firewall is the obvious way to restrict access to a broker, it's occasionally desireable to do this on the broker itself.
Configuration
The access restrictions apply either to the server as a whole or too a particular virtualhost. Rules are evaluated in the virtualhost first, then the server as a whole (most-specific to least-specific). This allows whole netblocks to be restricted from all but one virtualhost. A <firewall> element would appear in either the <broker><security><access> section or inside the equivalent <virtualhost> element.
Elements inside <firewall> would be <rule> or <include file="[path"]/>. <include> would read the file specified at path, which would contain an <firewall host="hostname"/>.
<firewall> would contain further <rule> entries, but not <include>. If the host attribute was specified the broker would check it's hostname against the attribute and cause a fatal error on startup if it did not match.
<rule> would have action, hostname and network attributes. Action and one of host or network would be mandatory. The action attribute would be either allow or deny. Host contains a comma seperated list of regexps against which it would match the reverse dns lookup of the connecting IP. Network contains a comma seperated list of of CIDR networks against which the IP would be matched.
The first <rule> which matched the connection would apply. If no rules applied, the default-action would apply.
For example, the following could appear in config.xml:
<firewall default-action="deny">
<rule permission="allow" hostname="*.qpid.apache.org"/>
<include file="/path/to/file" />
<rule permission="allow" network="192.168.1.0/24" />
<rule permission="allow" network="10.0.0.0/8" />
</firewall >
and /path/to/file could contain:
<firewall host="broker1.qpid.apache.org">
<rule permission="deny" network="192.168.1.0/24" virtualhost="prod"/>
</firewall>
any machine in the qpid.apache.org domain could access dev.
Any machine in the 192.168.1.0/24 network would be allowed access to any virtualhost other than prod
Any machine in the 10.0.0.0/8 network would be allowed access to any virtual host
Any other machine would be denied access.
Changes would be possible while broker was running via commons-configuration magic when the file is editted. Existing connections would be unaffected by a new rule.
Implementation
An IPRestriction class would extend ACLPlugin which listens for ConnectionOpen and checks against the list of rules. It will use the mechanism described at http://qpid.apache.org/java-authorization-plugins.html.
IPRestriction would parse the config file, compiling into an ordered list of Rule classes, which would have two methods: boolean match(InetAddress IPAddress) and boolean allow(). During the authorization phase it would iterate through these Rules until match() returns true when it will authorize or not according to the value returned by allow().
Because of the way that Java pre-6 caches dns forever, a small value for networkaddress.cache.ttl is necessary.
QPID-1583
|
[3:42 pm] |
partychat4 |
["rhs"] aidan: so a <whitelist default-action="allow">...<rule action="deny"/>...</whitelist> sort of thing would actually be a blacklist, would it not? |
|
[3:45 pm] |
aidan.x.skinner |
rhs: yes |
|
[3:48 pm] |
aidan.x.skinner |
rhs: I've been pondering dropping default-action and just letting having a rule with no match attribute at the end serve that purpouse |
|
[3:48 pm] |
aidan.x.skinner |
(and default to deny if not specified) |
|
[3:48 pm] |
partychat4 |
["rob"] but if you have no whitelist at all the default action is allow? |
|
[3:49 pm] |
aidan.x.skinner |
yeah |
|
[3:49 pm] |
aidan.x.skinner |
i guess that probably makes allow a more sensible default? |
|
[3:49 pm] |
aidan.x.skinner |
also, ideas for calling <whitelist> something else would be gratefully recieved |
|
[3:49 pm] |
partychat4 |
["rob"] I'm not sure there is a sensible default which is why I think you should force the user to set one |
|
[3:49 pm] |
partychat4 |
["rhs"] accesslist? |
|
[3:50 pm] |
aidan.x.skinner |
rob: we could demand one empty rule at the end? |
|
[3:50 pm] |
aidan.x.skinner |
rhs: i thought about that but considered it a little too close to ACL |
|
[3:51 pm] |
partychat4 |
["rhs"] <firewall>? |
|
[3:51 pm] |
partychat4 |
["rob"] aidan: I'm pretty relaxed really |
|
[3:51 pm] |
partychat4 |
["rhs"] <firewall default="deny">...</firewall> might make some sense |
|
[3:51 pm] |
partychat4 |
["rhs"] er, default-action rather |
|
[3:52 pm] |
aidan.x.skinner |
firewall sounds reasonable |
|
[3:52 pm] |
partychat4 |
["rhs"] I'm also fairly relaxed, I just had the urge to mock your usage of the term whitelist. |
|
[3:52 pm] |
aidan.x.skinner |
it's not a great term really. but greylists are something else again |
|
[3:53 pm] |
aidan.x.skinner |
whiteandblacklist seemed a little unwieldy |
|
|
[3:54 pm] |
partychat4 |
["rhs"] but I'm not particularly fussy either way |
|
[3:54 pm] |
aidan.x.skinner |
firewall is more accurate, i'm going to go with that |
|
[4:06 pm] |
partychat4 |
["marnie"] honest answers, does anyone here really care about what we call it ? |
|
[4:07 pm] |
partychat4 |
["marnie"] cos I know some people who do |
|
[6:13 pm] |
partychat4 |
[jonathan.robie@gmail.com] i care that what we call it is easy to explain |
|
[6:13 pm] |
partychat4 |
[jonathan.robie@gmail.com] i think the sub elements might be <include/> and <exclude/>, i don't know what to call the containing element |
|

Posted by aidan at Feb 04, 2009 01:30
|
I prefer to call this an "access list for a server". It's not a firewall - you clearly say that in your description. And I think we're moving into calling these things servers rather than brokers, for consistency with AMQP. An access list contains access elements. Each access element specifies the permissions for a network or a hostname:
<accesslist server="server1.qpid.apache.org">
<include file="/path/to/file" />
<access permission="allow" network="192.168.1.0/24" />
<access permisson="block" network="10.0.0.0/8"/>
<access permission="allow" hostname="*.qpid.apache.org"/>
</accesslist>
As for the virtualhost idea, I think I would do that by nesting accesslist:
<accesslist server="server1.qpid.apache.org">
<accesslist virtualhost="prod">
<access permission="deny" network="192.168.1.0/24" />
</accesslist>
</accesslist>

Posted by jonathan.robie@redhat.com at Feb 04, 2009 07:34
|
Here's a variant for those who prefer "firewall" and "rule":
<firewall server="server1.qpid.apache.org">
<include file="/path/to/file" />
<rule access="allow" network="192.168.1.0/24" />
<rule access="block" network="10.0.0.0/8"/>
<rule access="allow" hostname="*.qpid.apache.org"/>
</firewall>
As for the virtualhost idea, I think I would do that by nesting firewall:
<firewall server="server1.qpid.apache.org">
<firewall virtualhost="prod">
<rule access="deny" network="192.168.1.0/24" />
</firewall>
</firewall>

Posted by jonathan.robie@redhat.com at Feb 04, 2009 09:09
|
I'm going to put firewall into the virtualhosts <security><access> section and one in the main <security><access> section>. Virtualhosts will get evaluated first, then the global one.

Posted by aidan at Feb 05, 2009 03:02
|
|