IP Whitelisting has been edited by Aidan Skinner (Feb 05, 2009).

(View changes)

Content:

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, virtualhost, hostname and network attributes. Action and one of host or network would be mandatory. Virtualhost would be optional, if specified the rule would apply only to that virtualhost. 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="" class="code-quote">"deny">
  <rule action="" class="code-quote">"allow" hostname="*.qpid.apache.org" virtualhost="dev"/>
  <include file="/path/to/file" />
  <rule action="" class="code-quote">"allow" network="192.168.1.0/24" />
  <rule action="" class="code-quote">"allow" network="10.0.0.0/8" />
</firewall >

and /path/to/file could contain:

<firewall host="broker1.qpid.apache.org">
 <rule action="" class="code-quote">"deny" newtork="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

--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org

Reply via email to