As a follow up, I have a design question
http://docs.couchdb.org/en/2.0.0/intro/security.html#authentication-database
says:
* There is a special design document|_auth|that cannot be modified
However it looks like the admin user can delete the authentication
database (thereby deleting _auth document as well).
Is there a convenience benefit of allowing this (eg: admin party is
useful when you start off locally and dont care about security) ?
Thanks
Vivek
On 01/23/2017 05:27 AM, Vivek Pathak wrote:
Sorry for delayed response (I had to restore the backups and harden
the server a bit in order to deal with the ongoing attempts to grab my
data). And thank you all to those who helped.
Looks like this was a plain password sniffing of admin password. No
evidence of guessing or repeated attempts - and it was not a simple
password to guess or crack.
I believe the admin password could only be sniffed because it was on
open port 5984. I was careless because the site was in development.
So now I have couchdb listening on 127.0.0.1, and the admin password
is now randomly generated 18 characters (dont know good if the centos
7 rng has trapdoor though). The need for replication and UI access
via _utils can be satisfied by setting up a ssh tunnel via a random
port, eg:
ssh -N -L 57237:localhost:5984 [email protected]
Next is to move to https - and that should complete the securing
aspect. Also ended up creating offline backup on a stopped ec2
instance - this should come handy if the attack become really serious.
Thank you
On 01/20/2017 09:09 AM, Thomas Guillet wrote:
@Paul: I agree, it is pretty straightforward to have some basic
settings on.
Could we rely on the cluster_setup endpoint to secure the instance?
If that is considered to be the first 'mandatory step' of a live
instance, it would be nice as an almost out-of-the-box secure set up.
(Plus, you can always "curl" the endpoint instead of "perl" the
local.ini)
SSL-only is tricky as the http server can't be deactivated in
local.ini but in default.ini (from memory).
@All: What do you consider a same/secure set up? What are the known
unsecured features/weaknesses of CouchDB.
@Vivek: You issue worries me quite a lot. Do you have a better idea of
what happened?
I saw you are using HTTP instead of HTTPS, were you using in encrypted
connection to exchange your credentials and session?
Is your instance behind a proxy? (nginx or alike) They may have other
logs to help us investigate.
2017-01-20 12:49 GMT+01:00 Paul Hammant <[email protected]>:
tee-hee, that was my wishful thinking, less actual planning :)
As usual, there is no estimate for now.
Don't worry - my open source commitments slip by five years at a
time, but
I thought I'd ask just in case.
It might be better to focus on a series of post-install scripts for 2.x
that lock down a couch.
I was *very* excited by my first (and more or less only) exposure to
CouchDB for -
http://paulhammant.com/2015/12/21/angular-and-svg-and-couchdb.
As part of that I wanted to make it easy for the reader to turn on
CORS:
perl -p -i -e 's/;enable_cors/enable_cors/'
/usr/local/etc/couchdb/default.ini
perl -p -i -e 's/enable_cors = false/enable_cors = true/'
/usr/local/etc/couchdb/default.ini
perl -p -i -e 's/;origins/origins/' /usr/local/etc/couchdb/default.ini
perl -p -i -e 's/origins = /origins = */'
/usr/local/etc/couchdb/default.ini
perl -p -i -e 's/origins = \*\*/origins = */'
/usr/local/etc/couchdb/default.ini
That's to turn on CORS (CouchDB v1.6.x), for the blog entry.
I'll bet that it's only another eight "one-liners" (Perl or not) to go
SSL-only, cancel the AdminParty, and generate a unique admin password.
- Paul
