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

Laurent Alebarde l.alebarde at free.fr
Fri Oct 4 13:26:16 CEST 2013


ok, thanks for the insights Pieter. It is helpful to have some 
philosophycal stuff.


Le 04/10/2013 12:21, Pieter Hintjens a écrit :
> 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
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131004/73cd493b/attachment.htm>


More information about the zeromq-dev mailing list