With the recent attacks on Mongo databases, I've seen many guides on how to password-protect your database. I've gone through each guide and I've set up a 'superAdmin' with root role and another basicAdmin with read/write privileges. I reboot mongo using
mongo --auth
and authenticate using my superAdmin login, however this causes problems for my site which uses this db. When I boot my Node app, I can't access any pages as it cannot connect to the database because it has auth enabled. If in my config/database.js file I have:
module.exports = {
'database': 'mongodb://myWebsite.com/myDatabase'
};
How can I allow my site to access my MongoDB and read/write as users signup but also restrict any ransomware group from just walking in and dropping every collection over and over?
There are three main methods that you can use to protect your database.
Username and password
This is the simpler one. As you have mentioned that you have already secured the server using password, you can simply connect to database using mongoose as
mongoose.connect('mongodb://username:password#host:port/database');
I might recommend here that you change the default port of mongoDb to something else. Changing port can be found in file /etc/mongodb.conf.
Bind to private ip and use firewall
Again refering to file /etc/mongodb.conf change bind_ip to local ip of your network. Most of the services do provide that. Also better to setup firewall for the same. Simple firewall that you can use is UFW. Only allow traffic from servers that you are using. This method might not be effective if you are using shared vpn service.
SSH tunnel to access database
This is far most the most reliable method and i would recommend you to use this with the last method. Here is how this works. Set bind_ip to 127.0.0.1. Let us assume that you are running port on 5000. In order to set up a tunnel use
ssh \
-L 4000:localhost:5000 \
-i ~/.ssh/key \
<username>#mongo_db_ip
Remember to add your ssh key in instance running mongodb database. The above command should be issued on server that is running nodejs. 5000 as mentioned is the remove port and 4000 is the local port that you need to connect to on mongodb. So your command in mongoose to connect to database would be
mongoose.connect('mongodb://localhost:4000/<database>');
Summary
As you can see in almost all the steps i have focused on setting up a firewall which is very important.
Also username and passwords should be avoided and it is better to use ssh keys. From practical experience they also reduce a lot of burden while you are scaling up your service.
Hope this helps you out.
Related
I'm having a trouble which I can't connect to my database using IP Address. It works fine when I access it to my local but the problem is the other PC can't connect to my server. I've been using postgre v11 and navicat v12. Is there any permission to setup in my device in order that the other devices can access to my database? It would be great if anybody could figure out where I am doing something wrong. thank you so much in advance
You have to change the host settings of the database to access it from a foreign IP
I would look at two things if connections from remote hosts are being rejected.
First what is the value of the parameter listen_addresses in the postgresql.conf file? If it is set to:
listen_addresses='localhost'
It will be allow only local loopback connections. Change this (for example to listen on all interfaces) to:
listen_addresses='*'
Next, check the pg_hba.conf file has a rule to allow connections from your remote client. By default PostgreSQL will refuse these remote connections and they must be whitelisted. The following example entry would allow any user to connect to any database from 192.168.1.2 and they must supply the password
host all all 192.168.1.2/32 md5
Check out the official PostgreSQL docs for this at:
https://www.postgresql.org/docs/11/auth-pg-hba-conf.html
I haven't created an account in fastcomet yet, but I would like to ask the following questions. The site mentions that it supports node.js applications. So that means I can upload an express application right? How about MongoDB and mongoose? I can access MongoDB by typing in the terminal
$ mongod --dbpath=data -bind_ip 127.0.0.1
And the MongoDB URL in my case is
mongodb://localhost:27017/ilovearisti
How different would it be in fastcommet? I guess I'll have to contact them for the port numbers right?
Thanks,
Theo.
FastComet Team here! Indeed, our hosting plans are fully compatible with Node.js apps and you can have your project hosted on an appropriate package.
If you plan using the MongoDB database type in particular, our experience shows it requires a server solution with more resources and a higher level of private access. This way you would be able to accommodate the operation on an environment suitable for coding with Mongoose on top of the MongoDB driver for Node.js.
As for addressing your URL query, the default IP when starting a mongo instance is set to 127.0.0.1, so it is configured as localhost and port 27017. With this in mind, you only need to make changes on the IP configuration via the mongod daemon if you are using a remote database setup with a different IP address.
Having said all of the above, we can confirm that if you have created a database called iloveiristi, the MongoDB URL will be as follows:
mongodb://localhost:27017/iloveiristi
We hope this information proves useful and we wish you good luck with your project.
Best regards!
I'm trying to set up both Confluence and PostgreSQL in Docker. I've got them both up and running on my fully up to date CentOS 6 machine, with volume-mapping to the host file system so I can back them up easily. I can connect to PostgreSQL using pgAdmin from another machine just fine, and I can get into Confluence from a browser from that same machine. So, basically, both apps seem to be running as expected inside their respective containers and are accessible to the outside world, which of course eliminates a whole bunch of possibilities for my issue.
And that issue is that Confluence can't talk to PostgreSQL during initial setup, which is necessary for it to function. I'm getting connection failed errors (to be specific: "Can't reach database server or port : SQLState - 08001 org.postgresql.util.PSQLException: The connection attempt failed").
PostgreSQL is using the default 5432 port, which of course is exposed, otherwise I wouldn't be able to connect to it via pgAdmin, and of course I know the ID/password I'm trying is correct for the same reason (and besides, if it was an auth problem I wouldn't expect to see this error message). When I try to configure the database connection during Confluence's initial setup, I specify the IP address of the host machine, just like from pgAdmin on the other machine, but that doesn't work. I also tried some things that I basically knew wouldn't work (0.0.0.0, 127.0.0.1 and localhost).
I'm not sure what I need to do to make this work. Is there maybe some special method to specify the IP to a container from the same host machine, some nomenclature I'm not aware of?
At this point, I'm "okay" with Docker in terms of basic operations, but I'm far from an expert, so I'm a bit lost. I'm also not a big-time *nix user generally, though I can usually fumble my way through most things... but any hints would be greatly appreciated because I'm at a loss right now otherwise.
Thanks,
Frank
EDIT 1: As requested by someone below, here's my pg_hba.conf file, minus comments:
local all all trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
host all all all md5
try changing the second line of the pg_hba.conf file to the following:
host all all 0.0.0.0/32 trust
this will cause PostgreSQL to start accepting calls from any source address. Since a docker container is technically not operating on localhost but on its own ip, the current configuration causes PostgreSQL to block any connections to it.
Also check if confluence is searching for the database on localhost. If that is the case change that to the ip of the hostmachine within the docker network.
Success! The solution was to create a custom network and then use the image name in the connection string to PostreSQL container from Confluence container. In other words, I ran this:
docker network create -d bridge docker-net
Then, on both of the docker run commands for the PostgreSQL and Confluence containers, I added:
--network=docker-net
That way, when I ran through the Confluence configuration wizard, when it asked for the hostname for the PostgreSQL server, I used postgres (the name I gave the container) rather than an IP address or actual hostname. Docker makes that work thanks to the custom network. This also leaves the containers available via the IP of the host machine, so for example I can still connect to PostgreSQL via 192.168.123.12:5432, and of course I can launch Confluence in the browser via 192.168.123.12:8080.
FYI, I didn't even have to alter the pg_hba.conf file, I just used the official PostgreSQL image (latest) as it was, which is ideal.
Thanks very much to RSloeserwij for the suggestions... while none of them proved to be the solution I needed, they did put me on the right track in the Docker docs, which, after some reading, led me to understand a few things I didn't before and figure out the config magic I needed.
A beginner question, but I've looked through many questions on this site and haven't found a simple, straightforward answer:
I'm setting up a Linux server running Ubuntu to store a MySQL database.
It's important this server is secure as possible, as far as I'm aware my main concerns should be incoming DoS/DDoS attacks and unauthorized access to the server itself.
The database server only receives incoming data from one specific IP (101.432.XX.XX), on port 3000. I only want this server to be able to receive incoming requests from this IP, as well as prevent the server from making any outgoing requests.
I'd like to know:
What is the best way to prevent my database server from making outgoing requests and receiving incoming requests solely from 101.432.XX.XX? Would closing all ports ex. 3000 be helpful in achieving this?
Are there any other additions to the linux environment that can boost security?
I've taken very basic steps to secure my phpmyadmin portal (linked to the MySQL database), such as restricting access to solely my personal IP address.
To access the database server requires the SSH key (which itself is password protected).
A famous man once said "security is a process, not a product."
So you have a db server that should ONLY listen to one other server for db connections and you have the specific IP for that one other server. There are several layers of restriction you can put in place to accomplish this
1) Firewall
If your MySQL server is fortunate enough to be behind a firewall, you should be able to block out all connections by default and allow only certain connections on certain ports. I'm not sure how you've set up your db server, or whether the other server that wants to access it is on the same LAN or not or whether both machines are just virtual machines. It all depends on where your server is running and what kind of firewall you have, if any.
I often set up servers on Amazon Web Services. They offer security groups that allow you to block all ports by default and then allow access on specific ports from specific IP blocks using CIDR notation. I.e., you grant access in port/IP combination pairs. To let your one server get through, you might allow access on port 3000 to IP address 101.432.xx.xx.
The details will vary depending on your architecture and service provider.
2) IPTables
Linux machines can run a local firewall (i.e., a process that runs on each of your servers itself) called iptables. This is some powerful stuff and it's easy to lock yourself out. There's a brief post here on SO but you have to be careful. It's easy to lock yourself out of your server using IPtables.Keep in mind that you need to permit access on port 22 for all of your servers so that you can login to them. If you can't connect on port 22, you'll never be able to login using ssh again. I always try to take a snapshot of a machine before tinkering with iptables lest I permanently lock myself out.
There is a bit of info here about iptables and MySQL also.
3) MySQL cnf file
MySQL has some configuration options that can limit any db connections to localhost only - i.e., you can prevent any remote machines from connecting. I don't know offhand if any of these options can limit the remote machines by IP address, but it's worth a look.
4) MySQL access control via GRANT, etc.
MySQL allows you very fine-grained control over who can access what in your system. Ideally, you would grant access to information or functions only on a need-to-know basis. In practice, this can be a hassle, but if security is what you want, you'll go the extra mile.
To answer your questions:
1) YES, you should definitely try and limit access to your DB server's MySQL port 3000 -- and also port 22 which is what you use to connect via SSH.
2) Aside from ones mentioned above, your limiting of PHPMyAdmin to only your IP address sounds really smart -- but make sure you don't lock yourself out accidentally. I would also strongly suggest that you disable password access for ssh connections, forcing the use of key-pairs instead.You can find lots of examples on google.
What is the best way to prevent my database server from making outgoing requests and receiving incoming requests solely from 101.432.XX.XX? Would closing all ports ex. 3000 be helpful in achieving this?
If you don't have access to a separate firewall, I would use ip tables. There are a number of managers available for you on this. So yes. Remember that if you are using IPtables, make sure you have a way of accessing the server via OOB (short for out of band, which means accessing it in such a way that if you make a mistake in IP tables, you can still access it via console/remote hands/IPMI, etc)
Next up, when creating users, you should only allow that subnet range plus user/pass authentication.
Are there any other additions to the linux environment that can boost security? I've taken very basic steps to secure my phpmyadmin portal (linked to the MySQL database), such as restricting access to solely my personal IP address.
Ubuntu ships with something called AppArmor. I would investigate that. That can be helpful to prevent some shenanigans. An alternative is SELinux.
Further, take more steps with phpmyadmin. That is your weakest link in the security tool chain we are building.
To access the database server requires the SSH key (which itself is password protected).
If security is a concern, I would NOT use SSH key style access. Instead, I would use MySQLs native support for SSL certificate authentication. Here is now to configure it with phpmyadmin.
Do you think they are getting a kickback from Oracle (the makers of Workbench), or is there a valid reason to consider phpmyadmin to be less secure than (the paid) workbench application?
The main issue using phpmyadmin is related to MySQL users allowed ip's.
For example; Let assume that you have installed MySQL with default configuration and you set 123456 as a password (which is not good). As you know root login are only allowed when source ip is 127.0.0.1 ( default configuration ). In this scenario, your database server will be secure even if 3306 port can be accessible from internet. Because of client have to initiate connection from 127.0.0.1 which is localhost.
If you've installed phpMyAdmin on your server, this source ip protection will be useless. Because hackers will be able to initiate MySQL connection from localhost through PHP/Apache.
In order to keep your database server secure, use SSH Tunneling feature of workbench . Documentation for ssh tunneling can be found here; https://www.namecheap.com/support/knowledgebase/article.aspx/9330/2180/how-to-connect-to-database-using-workbench-mysql-client