Vishal K commented on ZOOKEEPER-934:

Nagios might be just sending some 8 byte information to QCM and QCM will accept 
that as a ID and start thread that connection. If we have the above check, we 
will run into this scenario only if nagios sends OBSERVER_ID or a valid server 

As a first step it might be a good solution to :
1. reject if (sid != OBSERVER_ID && !self.viewContains(sid)
2. interrupt SendWorker When RecvWorker exits
3. Incorporate a sloution for ZOOKEEPER-933. Note with this solution in place, 
Nagios will also have to generate the correct role/peertype string in addition 
to ID.
4. Kill SendWorker and RecvWorker iff leader election has been completed and  
we have no notifications to send. 

In general, this cannot be solved without some form of authentication. 
Essentially, these are forms of DoS attacks.

Another quick solution could be to introduce a "cluster password" (or a cluster 
identifier string)- We can store this password in zoo.cfg file. A peer can 
include hash of this password in outgoing messages or use the 
f(password,serverid) as a key to hmac outgoing packets. This of course is not 
secure. However, it is good enough to prevent QCM from considering port 
scanners as ZK servers.

> Add sanity check for server ID
> ------------------------------
>                 Key: ZOOKEEPER-934
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-934
>             Project: Zookeeper
>          Issue Type: Sub-task
>            Reporter: Vishal K
>             Fix For: 3.4.0
> 2. Should I add a check to reject connections from peers that are not
> listed in the configuration file? Currently, we are not doing any
> sanity check for server IDs. I think this might fix ZOOKEEPER-851.
> The fix is simple. However, I am not sure if anyone in community
> is relying on this ability.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to