hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Esteban Gutierrez <este...@cloudera.com>
Subject Re: hbase attack scenarios?
Date Thu, 07 Aug 2014 18:43:33 GMT
Hello Will,

Cloudera, Inc.

On Wed, Aug 6, 2014 at 9:14 PM, Wilm Schumacher <wilm.schumacher@cawoom.com>

> Am 06.08.2014 um 19:07 schrieb Andrew Purtell:
> > We have no known vulnerabilities that equate to a SQL injection attack
> > vulnerability. However, as Esteban says you'd want to treat HBase like
> any
> > other datastore underpinning a production service and out of an abundance
> > of caution deploy it into a secure enclave behind an internal service
> API,
> > so random (possibly untrusted) clients are not hitting it directly.
> this is of course a very good point. Not specific to hbase, but of
> course true for hbase, too.
> There should be of course only one type of client who hit the db
> directly: the operating service clients.
> > If you'd like to encrypt data flowing in and out of the secure enclave on
> > the wire, deploy a KDC for cluster services and enable strong
> > authentication plus SASL "auth-conf" protection level. Requires HBase
> > 0.98.3 or higher (HBASE-11149).
> thanks for the hints.
> > The administrative UIs might have some kind of cross-site vulnerability
> > because we don't worry about that; the UIs are expected to be firewalled
> > for admin access only.
> this is of course an important point, too.
> So my takeaway from your responses are:
> * make the db as encapsuled as possible => should be hit only by the
> service api which has to be as restrictive as possible
> * least priviliges of course
> * every administrative interface should be firewalled (actually I would
> also use openvpn, but the general point is clear)
> However, this are very general points (true of course, but very general
> and generic for all dbs or whatever system does the work).
> That's there is nothing else to consider makes me kind of nervous. So if
> there is something like a login, where the user can post "username" and
> "password", and I do a getRow for the username (=rowkey), and than e.g.
> make a check for the passwd (sha encrypted of course) etc. ... basically
> the user can define whatever string the user wants to the getRow rowkey.

You avoid that by exposing an internal service API to the clients as Andrew
said. There are many authentication protocols that you could use and HBase
should be only used as the store. For this trivial case a simple solution
might be better to pass the of SHA of password as part of the request to
this internal API and cache results via a LRU table.  So any attempt to try
to log in via brute force would be hitting first the internal API and not
HBase. If you cache valid users (should fit in memory) you will also avoid
going to HBase all the time.

> So the application does not need to "escape" the username for the getRow
> which is then pumped more or less directly into the db (even if it is
> just a getRow) ... just makes me nervous :D.

> However, the attack scenarios pointed out by Esteban (evil RPC => OOME)
> showed me, that I should restrict the possible strings (e.g. usernames
> in this case) to e.g. [a-Z0-9]{2,100}, even if there is no possible
> vulnerablity known.

Thats not exactly the case, in HBase the input will be serialized by the
HBase client and HBase will process that data correctly regardless the
input values (for HBase keys and values are plain bytes). The OOME
escenario implies that the user could connect directly to the HBase cluster
and generate corrupt messages that could trigger an OOME in the Region

> Perhaps I did SQL too long to be a little more trustful. I guess this is
> the adaption process for me and "real" NoSQL. God, I love hbase ;).

> Thanks for the replies and keep up the good work
> Wilm

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message