Raptor allows to monitor traffic and drop or reject selective packets. Basically it is similar than the official PacketFilter plugin, but has much more features. For each packet going through the server it processes a list of Actions. In principle this list is processed from the top down, but branching is also allowed. You can define functions and if-then-else like structures. Even recursion is possible. These features can improve performance and open a complete new world of features. There are Actions for logging, sending Jabber messages and emails. Another key feature are counters. They count packets per JID. This allows you for example to detect abuse or react on something at maximum only once every minute. E.g. if you intercept 100 packets per second you probably don’t want 100 log entries per second.
Such sets of actions are called profiles. Profiles can be easily imported and exported in an XML format. You will find it useful to share profiles or parts of them within the community.
You will find much more information about what is possible and how to use Raptor in the online manual included in the packet. Check out the self-explanatory XML examples below to get an idea what is possible with Raptor.
Raptor is clearly targeted to advanced users. Basic programming knowledge is required, some experience with multithreaded applications is recommend.
requirements and license
This is an BETA release, be aware of bugs! Use on production systems at your own risk!
Openfire 3.5.2 or newer
Raptor is licensed under GPLv3.
Raptor does not need direct database access, so it should support all databases Openfire supports. Instead profiles are stored by default as XML in "…/openfire/conf/raptor". You may change this directory, see README.
Currently there is no editor for profiles, you will need to write XML code by hand. However, an AJAX based editor for admin console is planned for future releases.
changelog
version 0.2.1 (March 19, 2009)
Added XML Viewer with Syntax-Highlight to Admin Console Interface.
Traffic to component.your-server.tld was blocked in some examples in manual. You components would not work correctly then.
Mentioned email sender properties in manual.
Email sender does now default to admin@your-server.tld.
**version 0.2 (****March **15, 2009)
Solved several race condition bugs in Counter. Packets are now synchronized using bare JID strings, instead of using AtomicInteger class.
new check:set_count is an atomic combination of check:count and action:set_count. This helps to deal with race conditions at user/profile level. See new examples in manual.
check:address does now support checking against a GROUP. If a domain ends with localhost this is automatically replaced with your servername.
new concept of functions. Functions are similar as the old action:branch, but they can be called multiple times using new action:call. In combination with variables even loops (as recursion) might be possible, if someone finds that useful. New entry point for your program is now a special function named MAIN. Old entry-Action are still supported, but deprecated.
Rules are now also Actions (action:rule), so you can place rules everywhere you can place actions. Old action:branch was removed, because there is no more need for them. However, action:branch is still supported when loading old profiles. An action:branch is substituted using an action:rule without Checks. However, it is recommend to rewrite your profiles, since there are many new features now.
new concept of variables. Variables allow to store information per packet during processing. Allowed Datatypes are JID and INT. Use this feature with new check:jid and action:set_jid rather new check:int and action:set_int.
new check:incoming reads incoming parameter of Openfire’s PacketInterceptor.
new Raptor icon.
updated manual.
(for developers) improved usage of M4 macro processor for conditional comments.
**
**
version 0.1 (October 10, 2008)
initial version
download
raptor-0.2.1-544.tar.gz
raptor-0.2.1-544.zip
This is an BETA release, be aware of bugs! Use on production systems at your own risk!
This download includes compiled JAR file, online manual, source code, javadoc docs, several scripts and used libraries.
XML examples
Several example XML files are attached to this document.
**Raptor **0.2.1-544 will show up in Openfire as **Raptor **0.2-544. I just forgot to update the version number also in the compile script. However, you can vary versions by their distinct build number.
Seems like a v cool plugin am wondering whether it might be useful to me in a specific scenario I’m looking at for controlling packet flow from OF to client. The Flood Control example above is similar to what I’m looking for, but I had planned graceful degradation through buffering, rather than dropping the packets. Does the plugin accommodate for such buffering possibilities in some way?
Also, does it inspect fully packets and then match criteria, or will it never look further than it needs? What I mean is, in the flood example, will it still have examined the packets in detail or will it just check size and number of packets? If it inspects them further, I am concerned whether (when this grows to large numbers) too much of an overhead would be introduced using this plug-in purely for this type of flood control… (?)
The overhead for packet flood control is minimal. This is realized using counters: Raptor stores one single integer per JID in an HashMap. Each time an packet is processed by Openfire, the counter corresponding the user is incremented. In specified time intervals all counters are decremented. Using this simple mechanism you can measure something like “packets per time”. However it’s not exact, but fast and accurate enough.
Currently there is no way to examine packets in detail. You can only check things like “from” and “to JID”, packet type and so on. (see manual for details) However, the only reason why this is not implemented is because I don’t need it for myself. With a few Java programming skills it should be simple to create new types of “Checks” and “Actions” for Raptor.
I’m not exactly sure what you understand by “buffering”. Do you want do delay a packet for a few seconds? Are you trying to simulate a slow network connection, or something like that? That’s not possible with the current Raptor version. However, you could create an “Action” which does store the packet in memory/database to be send by an background thread later.
Raptor has a very flexible framework, adjustments are relativly easy. If you make improvments to Raptor which might be useful for others, please send them to me. If I find them useful too, I will integrate them into the “offical” version of Raptor.
Wow, thank you so much, that is a much better answer than I ever hoped for !
Great news on the simple packet counter, that implementation sounds ideal, I will have to look better into the option of defining an action for buffering. Will have to give it some thought whether that is the best way for me to realise the function I need.
By the way, yep, that is exactly what I was thinking with the buffering, apologies for not giving more details. The idea is to be able to say something like “never flood the client with more than X nr of packets (or bytes) per Y time interval” and when that limit is reached, start cueing up packets (up to a certain absolute maximum of course, at which point it will either be forced to speed up or start dropping packets anyway I guess). Here it would check the counter per JID on the pre-specified time interval. The other issue perhaps would be to change the processing over to reading from the buffer, once that is being used, so that the order is still maintained.
If I do go down this route and end up adding to / adapting Raptor, I will definitely make sure I submit them to you with documentation, even just on the off chance that they might be useful for someone else.
Thanks again, your answer was very much appreciated !
Sorry, I don’t speak any word portuguese? However, Google does translate your post into this:
Great plugin … Very well done and worked, but I have some doubts … very grateful for any help.
I tested the plugin but I could not change to send an error message that the user is locked …
[code]
I saw the list of actions but found nothing …
Another question and it is possible with this plugin even block the sender for example more than 800 characters?
Any help is welcome … thanks
I have problems to understand your first question. Probably Google translated it wrong. However, a few hints into the blue:
ActionLockOut is still not implementent, so it is not possible to use the internal LockOut mechanism of Openfire
The examples provided with Raptor show a locking mechanism which simply drops all packets for a specfic user over some time. See attachments to the document.
Regarding your second question, this is currently not possible. However, with a few Java skills it would be simple to introduce a new Check which is able to compare the length of a message. Just take a look into the sourcecode.
Sorry, how to block user who does flood in a chat room …
It works, but blocks all users …
I just wanted to block a user from sending messages X time …
Possible?
You can use a modified version of the FloodDetection example. If a user does flood a chatroom he sends many messages to your conference server ‘conference.yourserver.tld’. Just count messages from a user that go to the conference server. It the counter reaches the limit then drop messages from that user to the conference server.
action:set_count does not have an attribute named “To”.
I still do not work well in the plugin, I could say or do that to guide me?
Raptor is not easy to use because it’s powerful and very flexible. However, it comes with an extensive manual which should explain everything. It does also include some examples. In your special case you just need to adapt the FloodDetection example.
<?xml version="1.0" encoding="UTF-8"?>
FloodDetection
This example is a simple flood detection. If it detects a flood all packets from the user are droped for the next 10 minutes.
2
I am working so …
Now I look in the manual option to lock only one user …
Note: I noticed that only blocks messages in groupchat, not just chat …
I consider the best meted see if I can accomplish what I want …
If can help the layman would appreciate …
Thanks to coolcat and wanted to say that did the best work for plugin!! no doubt!
Please try to write complete sentences. It’s very hard to understand what you are writing.
The count-Attribute for action:set_count can only be FROM, TO, BOTH or VAR. Same goes for check:count.
This is the FloodDetection example, just with an additional rule around so only packets to the conference server are affected. There is a better way to detect this kind of messages, but Raptor doesn’t support that. However, PacketFilter does.
<?xml version="1.0" encoding="UTF-8"?> <raptor xmlns:action="http://martin-weusten.de/raptor/action" xmlns:check="http://martin-weusten.de/raptor/check">
<name>MUC-FloodDetection</name>
<desc>This example is a simple flood detection for MUC-rooms. If it detects a flood all packets from the user are droped for the next 10 minutes.</desc>
<version>2</version>
<counter name="TIMER" interval="1000" decrement="1"/> <counter name="TRAFFIC" interval="2000" decrement="100"/>
<function name="MAIN">
<action:rule>
<if>
<check:address fromtype="ANY" from="" totype="DOMAIN" to="conference.localhost" />
</if>
<then>
<action:rule>
<if>
<check:count counter="TIMER" count="FROM" compare="GREATER" ref="0"/>
</if>
<then>
<action:drop/>
</then>
</action:rule>
<action:count counter="TRAFFIC" count="FROM"/>
<action:rule>
<if>
<check:set_count counter="TRAFFIC" count="FROM" compare="GREATER" ref="1500" newvalue="0"/>
</if>
<then>
<action:set_count counter="TIMER" count="FROM" newvalue="600"/>
<action:log>Flood from user '\F' with IP=\I. Dropping all packets from this user to conference server for 10 minutes.</action:log>
<action:drop/>
</then>
</action:rule>
</then>
</action:rule>
</function>
</raptor>
