This page last changed on Jan 26, 2010 by robbie.

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> section or inside the equivalent <virtualhost><security> element.

Elements inside <firewall> would be <rule> or <xml fileName="[path"]/> which can be used to include further rules at that point in the rule chain.

<rule> must have action and either hostname or network attributes. The action attribute must 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:

<broker>
  <security>
    <firewall default-action="deny">
      <rule access="allow" hostname="*.qpid.apache.org"/>
      <xml fileName="/path/to/file" />
      <rule access="allow" network="192.168.1.0/24" />
      <rule access="allow" network="10.0.0.0/8" />
    </firewall >
  </security>
</broker>

[...]
<virtualhosts>
  <virtualhost>
    <name>prod</name>
    <prod>
      <security>
        <firewall>
          <rule access="deny" network="192.168.1.0/24"/>
        </firewall>
      </security>
     </prod>
  </virtualhost>
</virtualhosts>

Any machine in the 192.168.1.0/24 network would be allowed access to any virtualhost other than prod
Any machine in the qpid.apache.org domain would be allowed access to any virtualhost
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.

Examples

Denying everybody but foo.bar.com:

<firewall default-action="deny">
  <rule access="allow" hostname="foo.bar.com"/>
</firewall>

Denying everybody outside of bar.com:

<firewall default-action="deny">
  <rule access="allow" hostname=".*bar.com"/>
</firewall>

Allowing everybody except Baxcorp:

<firewall default-action="allow">
  <rule access="deny" hostname=".*baxcorp.*"/>
</firewall>

Deny everybody except one machine:

<firewall default-action="deny">
  <rule access="allow" network="192.168.1.2"/>
</firewall>

Allow everybody except one machine:

<firewall default-action="allow">
  <rule access="deny" network="192.168.1.2"/>
</firewall>

Deny everybody except machines in the range 192.168.1.0-192.168.1.255

<firewall default-action="deny">
  <rule access="allow" network="192.168.1.0/24"/>
</firewall>

Allow everybody except machines in the range 192.168.1.0-192.168.1.255

<firewall default-action="allow">
  <rule access="deny" network="192.168.1.0/24"/>
</firewall>

Allow everybody except machines in the range 192.168.0.0-192.168.255.255 unless it's 192.168.1.2, has the magic word in the hostname or is in the IP range 192.168.23.0-192.168.23.255

<firewall default-action="allow">
  <rule access="allow" network="192.168.1.2"/>
  <rule access="allow" hostname=".*please.*"/>
  <rule access="allow" network="192.168.23.0/24"/>
  <rule access="deny" network="192.168.0.0/16"/>
</firewall>

Complete example configuration files are attached to this page:


Document generated by Confluence on May 26, 2010 10:33