[
https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144744#comment-13144744
]
Richard Lowe commented on CASSANDRA-2274:
-----------------------------------------
I took a look at this too and also identified {{o.a.c.net.MessagingService}} as
the best place to start adding receiver-side security. At the moment the
authentication provided by {{o.a.c.auth.IAuthority}} and
{{o.a.c.auth.IAuthenticator}} is client-side only, so no help in preventing
nodes from processing requests from rogue or malicious nodes that have their
authentication turned off (the default).
There are two approaches I identified for preventing unauthorised nodes from
interacting with the cluster.
# The {{MessagingService}} defines a {{PROTOCOL_MAGIC}} value that it uses to
determine if the node sending an incoming message is "sane". By changing this
value from the default value it would effectively mean that only nodes running
your own modified version of Cassandra would be able to communicate with each
other, as all other nodes (including those using an official release) would
treat your nodes as "insane" and refuse to communicate. This is a brutal way to
achieve the goal, but it may be sufficient for some.
# Add some checking of messages that are received before the action they
request is carried out. At the moment the {{receive()}} method in
{{MessagingService}} does nothing to verify the authenticity or authority of an
incoming message before queuing it for processing. However, the
{{o.a.c.net.Message}} that is passed to the {{receive()}} method has a {{from}}
field, which as David Allsopp points out contains the IP address of the
receiving node. If the IP address is sufficient to ascertain the identity of
the sender (for your use case) then this could form the basis of some
validation, e.g. checking that the IP is in a list of allowed IPs (or range of
IPs), either stored in a configuration file or, as has been suggested, in a
cluster-wide shared column family (although I'm not quite sure how that would
work in practice).
If IP address alone is not enough to identify a node (which is highly likely),
then I think there is no choice but to extend the {{Message}} class to include
extra identity and credentials information.
I'm not sure how feasible this is as I'm not familiar enough with Cassandra and
its underlying protocols: if secured nodes were to use an extension of
{{Message}} instead of {{Message}} itself then it's likely that unsecure nodes
would not be able to process messages sent by secure nodes -- but then perhaps
that's the point.
When it comes to validating identity and credentials, it seems sensible to
re-use existing PKI or similar mechanisms, through PAM integration to take
advantage of system policies and AD or LDAP. The strategy used should be
configurable and pluggable, just as the existing client-side security strategy
is, and include the ability to turn off sender verification to allow the
current status quo to continue in environments where that makes sense.
Unfortunately I don't have time to implement any of this right now, but really
wish I did. This is an important aspect for us though so I may be able to have
a go soon, if someone else doesn't beat me to it.
> Restrict Cassandra cluster node joins to a list of named hosts
> --------------------------------------------------------------
>
> Key: CASSANDRA-2274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2274
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.2
> Environment: All
> Reporter: Andrew Schiefelbein
>
> Because firewalls and employees are not infallible it would be nice to
> restrict the ability of any node to join a cluster to a list of named hosts
> in the configuration so that someone would be unable to start a node and
> replicate all the data locally. I understand that in order to do this the
> person must know the seed servers and the cluster name and to extract the
> data they will need a userid and password but another level of security would
> be to force them to execute any brute force attack from a locked down server
> instead of replicating all the data locally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
