The packet filter plugin allows you to create rules that will block or reject certain packets to the server.
Copy packetFilter.jar into the plugins directory of your Openfire installation. The plugin will then be automatically deployed. To upgrade to a new version, copy the new packetFilter.jar file over the existing file.
Currently only the following databases are supported :
The Packet Filter plugin can be configured under “Server”-“Server Settings”-“Packet Filter Rules”.
Using the Plugin - Creating Rules
Actions come in 3 types Pass, Drop and Reject.
Pass - This will allow the packet to be delivered normally.
Drop - This will silently drop the packet without notifying the sender.
Reject - This rule tries to notify the person who sent it that their message was rejected.
There are a couple issues with this. First, not all clients handle forbidden packet
condition. The notification of users that their packet was rejected is therefore pretty
spotty, your mileage may vary. This rule has 2 configurable options that can be set in
the system properties screen :
- pf.rejectMessage : Defaults to “Your message was rejected by the packet filter”.
- pf.rejectSubject : Defaults to “Rejected”
This allows you to quickly disable a rule without deleting it. Disabled rules will still appear on the main rule page but will have a strike through like so :
This specifies what type of packets you want to disable your choices are :
Any - All of the above
This specifies the source base JID. Currently resource specific rules aren’t supported. The options for specifying a source are :
Any - Just like it sounds, if the source is anything.
User - These are all the local users defined on your Openfire server, all user accounts.
Group - All groups defined on your server. The source will match if the sender is a member of the specified group.
Other - This will let you specify a free form JID. (firstname.lastname@example.org)
This specifies the destination base JID. The options for selecting the destination JID are the same as above.
This prints a message to the info.log when the rule is executed. This is recommend only for trouble shooting as it can fill up the logs pretty quickly in production environments. Some example output :
Rejecting packet from email@example.com/Adium to firstname.lastname@example.org/Psi
Leave yourself a note so you can remember why you wrote the rule in the first place.
Changing Rule Order
The first rule that matches an incoming packet will be executed. For example consider the following rules:
Here we don’t want any of the Simpson’s talking to each other so every message from members of the Simpson group to each other are dropped. However, Marge and Homer should be able to talk to each other. To accomplish this rules allowing Homer to send message packets to Marge and vice versa are placed before the drop rule. New rules are automatically appended to the rule list. Rules can be moved at anytime using the arrows in the UI. When a rule is moved the changes take effect immediately.