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
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.