[zeromq-dev] What about using ZAP's EACCESS to feed fail2ban ?

Pieter Hintjens ph at imatix.com
Fri Oct 4 12:21:00 CEST 2013


You are mixing IMO a few different things that should not be mixed.

1. ZAP is not expensive; it's an inproc req/rep once per connection.

2. All mechanisms except default NULL use ZAP at least for IP address
checking. If you make a mechanism that breaks this model, you're
making life harder for everyone. It's already hard enough to
understand the abstractions. If each mechanism goes a different way,
it's painful.

3. Adding IP address checking and blacklisting to libzmq when you can
absolutely use ZAP for would be unfortunate.

4. You can of course authenticate client keys in the parano_server
without using ZAP. That's consistent with how the NULL mechanism
works.

tl;dr please don't make false optimizations that break the model and
create inconsistency that confuses everyone.

Thanks
Pieter

On Fri, Oct 4, 2013 at 11:58 AM, Laurent Alebarde <l.alebarde at free.fr> wrote:
> If only ZAP is considered, you are right. But in use cases where the server
> knows in advance all its client long term public key, authentication may be
> performed without ZAP, in a lightweight mechanism.
>
> In the PARANO mechanism I am designing, the HELLO command use (c->S) instead
> of (c'->S), what enables to put C' in the box instead of sending it in plain
> text. So here, I can forget the use of ZAP.
>
> Le 04/10/2013 11:48, Pieter Hintjens a écrit :
>
> You don't need to do this in libzmq; it can be completely hidden in
> the ZAP handler.
>
> On Fri, Oct 4, 2013 at 10:16 AM, Laurent Alebarde <l.alebarde at free.fr>
> wrote:
>
> When ZAP is used, libzmq gain information on possible ennemies. It may be
> interesting to manage a EACCESS trigger counter per IP, in order to be able
> to feed a fail2ban like list.
>
> Rationals : Efforts are made in the code and has been argumented to delay
> the costly operations in the curve protocol, to avoid some types of attacks.
> So, it makes sense to delegate to the firewall via fail2ban the rejection of
> ennemies.
>
> Use case : For example, if an IP raises 3 EACCESS in less than 2 minutes, it
> is banned for one hour directly by the firewall.
>
> This could be implemented via a STL map with the IP has a key, with a value
> being a structure containing the counter, the state, a timestamp of the last
> trigger, and alongside, a timestamp-ordered STL set of the IP-keys. The
> state is true if the counter reaches a parametrisable level (say 3 times).
> The number of IP memorized or the duration of the memory SHALL be
> parametrisable.
>
> It should be open to enable other conditions than ZAP EACCESS, for future
> mechanisms, so, the API SHOULD be something like :
>
> if (errno == EACCESS) record_ennemy();
>
> in say the curve_server.cpp file.
>
> In the background, a text file compatible with fail2ban is maintained.
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list