SMTP open relays; wikis; and comment/bulletin board systems have taught us that if there's any hope of monetizing something an ip scanner can attack, they will.
This includes a default admin password. The problem isn't really admin party mode; it's a trivially automated type of default attack profile. I agree with Nolan that people (myself included) succeed in getting started/familiar with Couch largely because of a text editor, admin party mode, curl, and futon. Following the breadcrumb tutorials and immediately creating/destroying databases; Editing data docs and design docs quickly, directly "on the server"; and practicing replication; without having to first understand the security model/settings to grant oneself permission (or write curl command lines embedding the passwords straight into bash_history). 1) What about only allowing admin party from a machine with the same ip addresses Couch is listening on. So listen to 0.0.0.0 but make source ip a factor in the privileges assignment. So in a sense, it's multifactor authorization defaulted to only allow certain source ips admin party access (role="admin", connection="source ip/port"). 2) Make modes enumerable: "Admin Party", "Production", "Development", "Client" (for clients connecting to server hosts and the default when not supplied), "<User Defined/Added>" (like "Internal Production" which would mean the "Client" request mode isn't allowed) And then by default prevent servers in different modes from replicating/querying each other (add "req_mode" field (the mode of the thing requesting); and "rep_mode" field (the mode the database replying should be in) to the request parameters). Make database operational settings for which request modes are enabled for which reply modes. By default: "Admin Party" only allows requests from "Admin Party" and "Client" "Production" allows "Production" and "Client" "Development" allows "Development" and "Client" 3) Reuse Erlang's magic cookie concept for any access sourced remotely. If I can, by default, access an admin party database remotely by adding a "magic cookie" (that the server generated) to the URL header in place of a login; and I can only get that cookie by querying the database from the same local machine the server is running, and the server/database must be in admin party mode. That's A) pretty easy to look up and get the copy/paste instructions to do for a default; B) a clearly placed magic cookie can be retrieved (because it got added to the default server/database json response) by any appropriately authorized user; and C) is not easy for an automated scanner to exploit unless it's already on the same host. A different token would be generated for each server mode; or these magic cookies would be purely an "Admin Party" mode thing. Thoughts? Mike A hosted service would need to have a way to communicate the magic cookies of new databases to their users, or require authentication; but Embedding my server's "Admin Party" <magic cookie> on a client command line On Apr 18, 2016 8:01 AM, "Nolan Lawson" <[email protected]> wrote: > I do think that there's a tension between the needs of first-timers and > production users. First-timers are already stymied by the lack of CORS by > default, and if we remove the Admin party from the default installation, > it's going to be even more impenetrable for them. > > This is why for PouchDB Server we not only made Admin Party the default, > but also completely-open CORS. If I were to go one step further, I might > even make it bind to 0.0.0.0. That has bitten me many many times before on > a fresh install. > > Is this something that can be done with Docker? Or maybe by adding presets > to the config UI? (Think Babel presets - e.g. "playground mode" or > "production-ready".) > > Cheers, > Nolan > > > > On Sun, Apr 17, 2016 at 12:16 PM, Jan Lehnardt <[email protected]> wrote: > > > > > > On 17 Apr 2016, at 16:43, Paul Hammant <[email protected]> wrote: > > > > > > I wasn't being snide, or insulting > > > > I’m glad to hear that you didn’t mean to be snide. > > > > > If I > > > wanted to write "I find the security system poorly documented, > > > can someone explain this to me" (your suggestion), I would have written > > it > > > as "I find the documentation of the security could be expanded for > > newbies, can > > > someone explain this to me" and avoid a reference to "poorly". > > > > > > I'm an Apache member - 'hammant' - and wouldn't do what you're claiming > > I'm > > > doing. > > > > I’m not claiming anything, I’m just telling you how this reads to me. > > > > Best > > Jan > > -- > > > > > > > > > > - Paul > > > > > > On Sun, Apr 17, 2016 at 8:24 AM, Jan Lehnardt <[email protected]> wrote: > > > > > >> > > >>> On 17 Apr 2016, at 05:09, Paul Hammant <[email protected]> wrote: > > >>> > > >>> (Cultural ref: https://en.wikipedia.org/wiki/Considered_harmful) > > >>> > > >>> So AdminParty is fun for there 2 minute "hey this stuff is great" > tour > > of > > >>> CouchDB, but it leaves me (and others) worried that we don't know the > > 52 > > >>> specialist knowledge things to do to lock down a couch install > > >> completely. > > >>> You know: 443-only, a top-level administrator, sub administrators, > > >> regular > > >>> accounts, different read vs write permissions, etc etc. We can't > > imagine > > >>> going live with a CouchDB solution without that, and it makes us > think > > we > > >>> should look for other technologies when there is no cohesive 100% > > >> dev-team > > >>> endorsed page on how to close down the party once and for all. > Sooooo - > > >> *if > > >>> that page exists, I can't find it*. > > >> > > >> > > >>> Is the comummunity even in agreement - is it changes to default.ini, > > >> local.ini > > >>> (server side), or is it a series of curl statements over the wire > (and > > >> why)? > > >> > > >> No need to be snide about this. A “Why are there two ways to configure > > >> CouchDB?” would have sufficed. > > >> > > >> CouchDB has a config system. It is persisted in two .ini files. You > can > > >> change settings by editing local.ini and [re]starting CouchDB or > without > > >> restarting CouchDB using curl. The latter is rather beneficial in > > >> production > > >> systems that don’t want to incur downtimes. > > >> > > >> Changes done at runtime are stored in local.ini. When you install a > > newer > > >> version of CouchDB new config variables can appear in default.ini. If > > the > > >> install procedure finds an existing local.ini it will not replace it, > so > > >> local changes (hence the name) survive software upgrades. > > >> > > >> As Bob pointed out, there is a security consideration with ini vs. > curl: > > >> > > >> If you were to start a CouchDB instance and then add an administrator > > via > > >> curl, there is an ever so slight chance that someone else gets there > > before > > >> you. The exact scenario is somewhat convoluted, so I won’t bore you > with > > >> it. > > >> Suffice it to say, creating an admin in local.ini before the first > > launch > > >> of CouchDB completely avoids said issue. > > >> > > >> * * * > > >> > > >> If you don’t feel confident using CouchDB then I suggest you look for > > >> alternative technology, or ask someone nicely to explain this to you, > > >> but pressuring the dev team with an somewhat insulting email is not > > >> appreciated here. Again, a “I find the security system poorly > > documented, > > >> can someone explain this to me?” would have been much more productive. > > >> > > >> > > >> Best > > >> Jan > > >> -- > > >> Apache CouchDB PMC Chair > > >> http://couchdb.apache.org/conduct.html > > >> > > >> > > >> > > > > -- > > Professional Support for Apache CouchDB: > > https://neighbourhood.ie/couchdb-support/ > > > > > > > -- > Nolan Lawson > nolanlawson.com > github.com/nolanlawson >
