Filter updating mechanism

2 views
Skip to first unread message

Lars Strojny

unread,
Oct 25, 2007, 7:11:17 PM10/25/07
to php...@googlegroups.com
Hi,

I have thought a lot about how to properly update filter rules
automatically without deploying new software. We have a few constraints
to met:

1. The origin of the filter rules must be verified. The content too
2. The remote update service must be high available (AEC-4)
3. The update methods should be variable
4. When implementing PHP IDS in application foobar, the update
process may run on a complete different environment
5. Every filter rule needs to have an unique ID which is never
changed
6. Filter source adapters must be capable of writing
7. Every filter set update must have a unique revision

1.)
First item can be accomplished with SSL. The second point is the hardest
one. Some sort of public key crypto would be needed.

2.)
If an client server triggers the update, the service must be available.
Maybe we should think about an naive P2P-system here.

3.)
Updates should be available via different webservice technologies (REST,
Soap, XML-RPC for the first time, PHP-RPC, similiar to flickr, is a nice
to have).

4.)
Think on a setup where my webservers do not have the possibility to
communicate to the web. I have my internal DNS for email adress host
verification, but that is all. I have a few service providers, which can
communicate to the outside, but my external calls are wrapped in an
internal webservice (this is really common in bigger server
environments). This means, I should have the possibility to update
filter rules independent from the place where filter rules are used. The
realistic scenario is to store such values in a database.


----------- uses filters ---------- update filters -------------------------
| Webserver | < ======= > | Database | < ======= > | Service provider in DMZ |
----------- ---------- -------------------------


5.)
If we want to update an ambigous filter rule, there must be a key which
identifies that rule.

6.)
XML, JSON, etc. adapters must be able to write their sources.

7.)
Reusing SVN revisions here seems to make sense to me.

I'm awaiting your comments!

cu, Lars

signature.asc

Mario Heiderich

unread,
Oct 26, 2007, 3:21:48 AM10/26/07
to php...@googlegroups.com
Hi!

Nice thoughts - what about using S3 to solve problem 2?

2007/10/26, Lars Strojny <la...@strojny.net>:



--
_______________________
php-ids.org
Reply all
Reply to author
Forward
0 new messages