0

I searched for the best way to establish a replication between two servers with CouchDB but I do not find any infomation on it. The manual in https://docs.couchdb.org/en/stable/setup/cluster.html does not talk about this.

Currently, I am using a SSH permanent connection between the two servers using a certificate without passthrough:

ssh -f -L 127.0.0.1:5985:127.0.0.1:5984 sinccouchdb@100.100.100.100 -N -i id_rsa_sinccouchdb -l sinccouchdb -o ServerAliveInterval=60

But I am not sure if this is the best way. Anyone can point me to a better and secure solution? Thank you.

Flimzy
  • 2,454
  • 18
  • 26

2 Answers2

0

Well, after some study and tests i thing i manage to work. For reference for future users, i post my solution here.

1) The SSL tunnel is valid and works quite well BUT I believe that it consumes more resources from the server. The tunnel must keep open al ltime. The HTTPS solution is a "on-demand" solution.

2) To enable the HTTPS in couchdb, follow these instructions.

2.1. If your server is already using a Let's Encrypt free TLS certificate for the Apache HTTPD, it want work for using in couchdb because the certificate and key files must be owner by the couchdb user! Maybe some one can discovered a work around for this.

3) Narrow the Erlang random ports; if you only have 1 node of couchdb, set it in /opt/couchdb/etc/vm.args:

-kernel inet_dist_listen_min 9100
-kernel inet_dist_listen_max 9100

I also suggest to change this

 -setcookie anything //default is always monster

4) Now you have these ports open: 5984, 6984, 4369 and 9100. So, the worl sees theses ports and this is a security problem.

5) Use fail2ban and others to prevent attacks but in my case i block then except to the IP of the 2 servers (the host and the slave which receives the replication). Remeber to stop first the fail2ban:

service fail2ban stop

6) On the host server add this rules:

iptables -I INPUT 1 -p tcp -s 127.0.0.1 --dport 4369 -j ACCEPT
iptables -I INPUT 2 -p tcp -s 127.0.0.1 --dport 5984 -j ACCEPT
iptables -I INPUT 3 -p tcp -s 127.0.0.1 --dport 6984 -j ACCEPT
iptables -I INPUT 4 -p tcp -s 127.0.0.1 --dport 9100 -j ACCEPT
iptables -I INPUT 5 -p tcp -s slaveserver.eu --dport 4369 -j ACCEPT  
iptables -I INPUT 6 -p tcp -s slaveserver.eu --dport 6984 -j ACCEPT 
iptables -I INPUT 7 -p tcp -s slaveserver.eu --dport 9100 -j ACCEPT 
iptables -I INPUT 8 -p tcp  --dport 4369 -j REJECT
iptables -I INPUT 9 -p tcp  --dport 5984 -j REJECT
iptables -I INPUT 10 -p tcp  --dport 6984 -j REJECT
iptables -I INPUT 11 -p tcp  --dport 9100 -j REJECT
iptables-save > /etc/iptables/rules.v4

7) On the slave server:

iptables -I INPUT 1 -p tcp -s 127.0.0.1 --dport 4369 -j ACCEPT
iptables -I INPUT 2 -p tcp -s 127.0.0.1 --dport 5984 -j ACCEPT
iptables -I INPUT 3 -p tcp -s 127.0.0.1 --dport 6984 -j ACCEPT
iptables -I INPUT 4 -p tcp -s 127.0.0.1 --dport 9100 -j ACCEPT
iptables -I INPUT 5 -p tcp -s hostserver.eu --dport 4369 -j ACCEPT  
iptables -I INPUT 6 -p tcp -s hostserver.eu --dport 6984 -j ACCEPT 
iptables -I INPUT 7 -p tcp -s hostserver.eu --dport 9100 -j ACCEPT 
iptables -I INPUT 8 -p tcp  --dport 4369 -j REJECT
iptables -I INPUT 9 -p tcp  --dport 6984 -j REJECT
iptables -I INPUT 10 -p tcp  --dport 5984 -j REJECT
iptables -I INPUT 11 -p tcp  --dport 9100 -j REJECT
iptables-save > /etc/iptables/rules.v4

8) Add the ip of the host server in the slaver server configuration file of fail2ban and vice versa and start again the fail2ban in both servers:

nano /etc/fail2ban/jail.d/custom.local
[DEFAULT]
    ignoreip = 127.0.0.1/8 62.75.143.242 62.75.186.11 62.138.1.143

service fail2ban start

9) The access to both servers is done using SSH with keys. Follow these instructions to enable it.

10) Access the Fauxton in the host server using a SSH tunnel:

ssh -p999 -f -L 127.0.0.1:5985:127.0.0.1:5984 root@hostserver.eu -i/root/.ssh/id_rsa -N

Then open: http://127.0.0.1:5985 and in the _replicator database you can add something like this:

{"_id": "1", "source": 
  {"url": "http://127.0.0.1:5984/mydb"},
   "target":{"url": "https://salveserver.eu:6984/mydb_copy"},
   "create_target": false,"continuous": true,  "owner": "sysdba"}

In this case, the mydb_copy must exist already in the slave server. If it does not, you must include the authentication to allow the host couchdb to create the database in the slave.

-1

If couchdb doesn't support TLS (which I find unlikely, though I haven't digged into its documentation), you could try running cluster traffic through stunnel.

Mikael H
  • 5,031
  • 2
  • 9
  • 18