[jira] Commented: (ZOOKEEPER-934) Add sanity check for server ID
[ https://issues.apache.org/jira/browse/ZOOKEEPER-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933719#action_12933719 ] Flavio Junqueira commented on ZOOKEEPER-934: One more comment. Looking at the logs for ZOOKEEPER-880, I remembered that in their case the RecvWorker thread was able to read a valid id from the connection with a Nagios server. I'm not exactly sure how that happened, but that essentially tells that the simple check you proposed might not do it. We don't want a Nagios box impersonating a ZooKeeper server! :-) 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.
[jira] Commented: (ZOOKEEPER-934) Add sanity check for server ID
[ https://issues.apache.org/jira/browse/ZOOKEEPER-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933838#action_12933838 ] 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 ID. 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.
[jira] Commented: (ZOOKEEPER-934) Add sanity check for server ID
[ https://issues.apache.org/jira/browse/ZOOKEEPER-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933610#action_12933610 ] Vishal K commented on ZOOKEEPER-934: How about we reject connection if (sid != OBSERVER_ID !self.viewContains(sid))? 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.
[jira] Commented: (ZOOKEEPER-934) Add sanity check for server ID
[ https://issues.apache.org/jira/browse/ZOOKEEPER-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933713#action_12933713 ] Flavio Junqueira commented on ZOOKEEPER-934: I was not thinking about OBSERVER_ID, good point, I think it should do it. 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.
[jira] Commented: (ZOOKEEPER-934) Add sanity check for server ID
[ https://issues.apache.org/jira/browse/ZOOKEEPER-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933045#action_12933045 ] Flavio Junqueira commented on ZOOKEEPER-934: It sounds like we need to do it so that we don't get affected by port scanners or monitoring systems. However, I'm not sure if this impacts the observers feature we are discussing in the other jira (ZOOKEEPER-933). It sounds like it does, but I need to verify. Any thoughts? 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.