[mod-security-users] Using ModSecurity and RBLs

[Christian Bockermann]

Hi list,

I wonder if anyone was using ModSecurity's @rbl operator to block
requests based upon a realtime-blocklist.
I wasn't - due to lack of a convenient way to handle RBLs.
However, I recently started the implementation of a small and
dynamic RBL-server, which can be used as a central database of
black-listed IPs among ModSecurity several instances.


# Deny clients on the central block-list
#
SecRule REMOTE_ADDR "@rbl rbl.localnet" "phase:1,deny"


The big feature here is, that ModSecurity can add IPs to the
RBL as well, for example:

# this adds a client IP to the block list for 60 seconds
#
SecRule REMOTE_ADDR "@rbl block-600.rbl.localnet" "phase:1,deny"


To remove an IP from the RBL from within ModSecurity, you can
use a rule like:

# remove/unblock the IP of the current request:
#
SecRule REMOTE_ADDR "@rbl unblock.rbl.localnet" "phase:1,pass"


My 'jwall-rbld' is an tiny open-source Java implementation of a
DNS server which does provide this, though it is in an experimental
state, right now.

If anyone is interested, you can find a blog-post about it and
some documentation at

https://secure.jwall.org/blog/2010/11/14/1289761589498.html


@users of the AuditConsole:
The next release of the AuditConsole will include the RBL server
as built-in feature (optional, of course) as well as a web-interface
for manually inspecting/modifying the RBLs...


Best regards,
Chris

[Ryan Barnett]

I think this is fantastic idea/tool. While this type of IP-based blacklisting is certianly possible to achieve by using ModSecurity’s persistent collections, it falls short when youa are in a distributed environment as the persistent storage is local. I have been asked a number of times by commercial customers how they implement some form of shared-state data and this would certainly help if you want to share IP variable data for blocking.

Chris – while IP-based blocking is the obvious use-case here, It might be interesting to try and allow for other types of shared data such as suspicious IP addresses. Perhaps to add/query some other subdomains such as suspicious.rbl.localnet or something. These would be sources that you might not want to block but perhaps raise a base anomaly score or create an audit log regardless of matched rules, etc... You might also want to consider this ModSec Jira ticket for @rbl enhancements which might be applicable here as well - https://www.modsecurity.org/tracker/browse/MODSEC-151

Good stuff though. I will check it out some more.

-Ryan


On 11/14/10 5:23 PM, "Christian Bockermann" <***@jwall.org> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

I wonder if anyone was using ModSecurity's @rbl operator to block
requests based upon a realtime-blocklist.
I wasn't - due to lack of a convenient way to handle RBLs.
However, I recently started the implementation of a small and
dynamic RBL-server, which can be used as a central database of
black-listed IPs among ModSecurity several instances.


# Deny clients on the central block-list
#
SecRule REMOTE_ADDR "@rbl rbl.localnet" "phase:1,deny"


The big feature here is, that ModSecurity can add IPs to the
RBL as well, for example:

# this adds a client IP to the block list for 60 seconds
#
SecRule REMOTE_ADDR "@rbl block-600.rbl.localnet" "phase:1,deny"


To remove an IP from the RBL from within ModSecurity, you can
use a rule like:

# remove/unblock the IP of the current request:
#
SecRule REMOTE_ADDR "@rbl unblock.rbl.localnet" "phase:1,pass"


My 'jwall-rbld' is an tiny open-source Java implementation of a
DNS server which does provide this, though it is in an experimental
state, right now.

If anyone is interested, you can find a blog-post about it and
some documentation at

https://secure.jwall.org/blog/2010/11/14/1289761589498.html


@users of the AuditConsole:
The next release of the AuditConsole will include the RBL server
as built-in feature (optional, of course) as well as a web-interface
for manually inspecting/modifying the RBLs...


Best regards,
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFM4GFMpc5/RcXDlTwRAvZjAKCE2sKfA0u20Pj1Y8WQF4x5WR/g8gCcCj91
nkqUj3rsye9wQX6f/6lOc6Q=
=U6HO
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
mod-security-users mailing list
mod-security-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html

[Christian Bockermann]

Post by Ryan Barnett
I think this is fantastic idea/tool. While this type of IP-based blacklisting is certianly possible to achieve by using ModSecurity’s persistent collections, it falls short when youa are in a distributed environment as the persistent storage is local. I have been asked a number of times by commercial customers how they implement some form of shared-state data and this would certainly help if you want to share IP variable data for blocking.

Yes, I can imagine :-)
I will have a look. Thanks for pointing that out.

In theory, my last version of the jwall-rbld should already allow for other
kinds of data -- if ModSecurity's @rbl operator can do that.
For example, it *should* be possible to block an entire session-ID with

SecRule REQUEST_COOKIES:JSESSIONID "@rbl block-60.rbl.localnet" "phase:1"

I haven't tried how the @rbl will handle data other than IP addresses, but
the jwall-rbld *should* in this case treat that normally and create the key
value queried by ModSecurity.

An interesting feature for jwall-rbld might be white-listing of addresses
or address-ranges, though. Should be easy to add.

Regards,
Chris

[c***@post.ch]

Hi Christian,

That looks like a welcome feature. I have not worked with RBL so far, but I imagine I might
in the future. What is not so nice is the syntax for blocking/unblocking. I take it you want
communicate additional information to the RBL Server without changing ModSec.
Is not there an alternative - possibly one with patching ModSec?

Regs,

Christian

-----Ursprüngliche Nachricht-----
Von: Christian Bockermann [mailto:***@jwall.org]
Gesendet: Sonntag, 14. November 2010 23:23
An: Mod Security
Cc: AuditConsole List
Betreff: [mod-security-users] Using ModSecurity and RBLs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

I wonder if anyone was using ModSecurity's @rbl operator to block
requests based upon a realtime-blocklist.
I wasn't - due to lack of a convenient way to handle RBLs.
However, I recently started the implementation of a small and
dynamic RBL-server, which can be used as a central database of
black-listed IPs among ModSecurity several instances.


# Deny clients on the central block-list
#
SecRule REMOTE_ADDR "@rbl rbl.localnet" "phase:1,deny"


The big feature here is, that ModSecurity can add IPs to the
RBL as well, for example:

# this adds a client IP to the block list for 60 seconds
#
SecRule REMOTE_ADDR "@rbl block-600.rbl.localnet" "phase:1,deny"


To remove an IP from the RBL from within ModSecurity, you can
use a rule like:

# remove/unblock the IP of the current request:
#
SecRule REMOTE_ADDR "@rbl unblock.rbl.localnet" "phase:1,pass"


My 'jwall-rbld' is an tiny open-source Java implementation of a
DNS server which does provide this, though it is in an experimental
state, right now.

If anyone is interested, you can find a blog-post about it and
some documentation at

https://secure.jwall.org/blog/2010/11/14/1289761589498.html


@users of the AuditConsole:
The next release of the AuditConsole will include the RBL server
as built-in feature (optional, of course) as well as a web-interface
for manually inspecting/modifying the RBLs...


Best regards,
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFM4GFMpc5/RcXDlTwRAvZjAKCE2sKfA0u20Pj1Y8WQF4x5WR/g8gCcCj91
nkqUj3rsye9wQX6f/6lOc6Q=
=U6HO
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
mod-security-users mailing list
mod-security-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html

[Christian Bockermann]

Hi Christian!

Post by c***@post.ch
That looks like a welcome feature. I have not worked with RBL so far, but I imagine I might
in the future. What is not so nice is the syntax for blocking/unblocking. I take it you want
communicate additional information to the RBL Server without changing ModSec.
Is not there an alternative - possibly one with patching ModSec?

You're referring to using 'block-60.rbl.localnet' and 'unlock.rbl.localnet', right?
I do agree, that this is a bit ugly.

The problem here is, that all of this is carried out using simple DNS lookup queries.
That's simply the way RBL works. It might be an option to implement the same functionality
by patching ModSecurity and using a more sophisticated database than a DNS server, e.g.
integrating memcache into ModSec would be a great idea, in my view.

I can also extend the jwall-rbld to receive more commands with special communication, such
ModSecurity can communicate with it in a better way. However, this will greatly move beyond
pure RBL communication.

With the current state, the jwall-rbld can be used with standard techniques, e.g. by creating
a local DNS-cache on your ModSecurity machine and no other alteration of the software. That
was my primary goal behind.
But I am willing to extend this if anyone requests that feature :-)

Regards,
Chris

[c***@post.ch]

Hi Christian,

Yes, that was exactly what I was referring to.

I am aware of the limitations of the DNS communication channel - and
the elegance of RBL that comes with it. I would not change that.
But if possible, I would try and change the syntax - even if it means
to patch ModSecurity.

A proposal for a clearer syntax:

SecRule REMOTE_ADDR "@rbl rbl.localnet" "phase:1,deny,action:rbl-block=600"

This could send the same DNS query to rbl.localnet. But it is hidden from the user.

Your proposal has the advantage to work without patching ModSecurity but
it looks like a cludge to me.
My proposal is cleaner, but it patches ModSecurity to work with a custom
RBL server. This does not look like a mainstream feature to add to ModSec.

Ahoj,

Christian




-----Ursprüngliche Nachricht-----
Von: Christian Bockermann [mailto:***@jwall.org]
Gesendet: Dienstag, 16. November 2010 10:16
An: Folini Christian, IT222 extern
Cc: Mod Security
Betreff: Re: AW: [mod-security-users] Using ModSecurity and RBLs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Christian!

Post by c***@post.ch
That looks like a welcome feature. I have not worked with RBL so far, but I imagine I might
in the future. What is not so nice is the syntax for blocking/unblocking. I take it you want
communicate additional information to the RBL Server without changing ModSec.
Is not there an alternative - possibly one with patching ModSec?

You're referring to using 'block-60.rbl.localnet' and 'unlock.rbl.localnet', right?
I do agree, that this is a bit ugly.

The problem here is, that all of this is carried out using simple DNS lookup queries.
That's simply the way RBL works. It might be an option to implement the same functionality
by patching ModSecurity and using a more sophisticated database than a DNS server, e.g.
integrating memcache into ModSec would be a great idea, in my view.

I can also extend the jwall-rbld to receive more commands with special communication, such
ModSecurity can communicate with it in a better way. However, this will greatly move beyond
pure RBL communication.

With the current state, the jwall-rbld can be used with standard techniques, e.g. by creating
a local DNS-cache on your ModSecurity machine and no other alteration of the software. That
was my primary goal behind.
But I am willing to extend this if anyone requests that feature :-)

Regards,
Chris

[Christian Bockermann]

Hi Christian!

Post by c***@post.ch
I am aware of the limitations of the DNS communication channel - and
the elegance of RBL that comes with it. I would not change that.
But if possible, I would try and change the syntax - even if it means
to patch ModSecurity.

I'd need to leave that to Breno, then :-)
I can only provide the jwall-rbld daemon.

Post by c***@post.ch
This could send the same DNS query to rbl.localnet. But it is hidden from the user.
Your proposal has the advantage to work without patching ModSecurity but
it looks like a cludge to me.
My proposal is cleaner, but it patches ModSecurity to work with a custom
RBL server. This does not look like a mainstream feature to add to ModSec.

I absolutely agree.
Problem here is, that the user also would need to define the TARGET rbl
in some way. So there would be some global config required to do that,
e.g.

SecDefaultRBL "rbl.localnet"

# Now, send a block-command to the rbl identified by DefaultRBL
#
SecRule REMOTE_ADDR "@rbl rbl.localnet" "phase:1,deny,action:rbl-block=600"


But again, you're absolutely right.
Would be a cleaner approach.

Regards,
Chris