How to disable TCP port?
Configure only unix socket.
For isolation of local users.
This is a 5 year old bug at least. The only issue I found was closed as WONTFIX and RTFM, but this issue logged against 2.4 here somewhat relates to the issue: https://jira.mongodb.org/browse/SERVER-9383.
MongoDB will refuse to create the unix domain socket unless the IPV4 IP Address is either 127.0.0.1 or 0.0.0.0. You don't get to run it on one interface or disable it (for reasons unstated). To me it's a reflection of the quality of the MongoDB code.
I traced the code back to 2011 and my belief is that it was a crude hack to prevent you from accidentally have 2 mongodb processes trying to create the same socket file. If you ran one instance on 192.168.1.1:27017 and 192.168.1.2:27017, they would both try to create the same socket file at: /tmp/mongod-27017.sock. Since no one at 10gen has a clue as to why that check is in there, no one has fixed it since 2011. It's easy to check that 127.0.0.1:27017 is already in use, because of EADDRINUSE, but it's hard to check that your socket file is stale or if another process created it. I'm not sure why they didn't just name the socket file differently.
See the code here: https://github.com/mongodb/mongo/blob/r2.2.4/src/mongo/util/net/listen.cpp#L91
if (useUnixSockets && (sa.getAddr() == "127.0.0.1" || sa.getAddr() == "0.0.0.0")) // only IPv4
out.push_back(SockAddr(makeUnixSockPath(port).c_str(), port));
I can understand that your concern here is with security in your setup but it is worth considering that MongoDB is built by design to interact in clustered systems and hence TCP networking is part of that design. That said, and as you are aware, there is by default a unix domain socket connection you can use for local access.
You can use the '--bind_ip' configuration option to bind to the loopback only ('127.0.0.1') or only the interface you wish to use, as mongod will by default bind to all available interfaces. For a full list of startup options you might want to look at the manual page to determine what you need.
For other security you can refer to your firewall rules.
Late to the game but for future viewers you can disable tcp by using a bindIP to a socket file.
For example:
net:
port: 8080
# socket filename has port in it
bindIp: /var/tmp/mongodb/mongodb-8080.sock
unixDomainSocket:
pathPrefix: /var/tmp/mongodb
If I start mongo and run lsof -i :8080 I don't see mongo listening on that port.
Related
(I've searched SO, AWS support and more widely without success.)
I've just successfully deployed a MEANjs application to a Bitnami MEAN instance on EC2, following Ahmed Haque's excellent tutorial on scotch.io. As part of the tutorial/deployment I altered the AWS Security Group to include port 27017 for MongoDB traffic. The CIDR notation for the port 27017 was 0.0.0.0/0 - which AFAIK means 'allow access from any IP address'.
Question: Why does MongoDB port 27017 need to be opened in AWS EC2
Security Group for a 'production' type environment? Surely this is directly exposing the DB to the
Internet. The only thing that should be talking to Mongo is the
"/server/api" code, which is running on the same instance -
and so shouldn't need the port opening.
If I change the Security Group rule for port 27017 by closing off 27017, changing the source to: localhost, the internal IP address, the public IP address, or hack a CIDR to be equivalent to any of those - then the web app hangs (static content returns but no responses to db backed api calls). Changing the SG rule back to 0.0.0.0/0 almost immediately 'fixes' the hang.
All is otherwise sweet with my install. I've closed port 3000 (the node app) in the Security Group and am using Apache to proxy port 80 traffic to port 3000. Set up like this, port 3000 does not need to be open in the Security Group; to me this implies that on-instance traffic doesn't need ports to be externally exposed - so how come that's not true of the Mongo port?
I cant see anything in the '/client' code which is talking direct to Mongo.
What am I missing?
Thanks in advance - John
OK, after further investigation and overnight/red wine reflection I think I have an answer for those learners like me following the above tutorial (or similar). Following the Agile principle that 'done' means 'working code in a production environment' I was trying to understand the last 5 meters as a developer trying to get code working in a representative production environment (which wouldn't have unnecessary ports open) - this answer is written from that perspective. (Builds welcome from wiser readers.)
What's Happening
The step in the tutorial which (a) changed the Mongo bind IP address from 127.0.0.1 to 0.0.0.0, and (b) specifies a connection URL which uses the external IP address of the same instance, appears to have two effects:
It makes the MongoDB on the instance you're configuring potentially available to other instances (0.0.0.0 tells Mongo to "listen on all available network interfaces".)
It means that the IP traffic from your MEAN app /server component on the same instance will talk to Mongo as though it was coming from off-instance (even though it's on the same instance). Hence the Security Group needs to make port 27017 open to allow this traffic to flow. (This is the nub of the issue in terms of MEANjs stack component interaction.)
Fix
On a single instance MEANjs server, if you change the Mongo bind IP address back to 127.0.0.1 and the Mongo connection url to be 127.0.0.1:27017 then you can close off port 27017 in the EC2 Security Group and the app still works.
To share one MongoDB across more than one MEANjs app server (without wanting to stray into serverfault territory):
Change the Mongo bind IP address to 0.0.0.0,
Use the private IP address of the Mongo server in other app/instance connection strings
Add a EC2 Security Group CIDR rule of private IP address/24, or private IP address/16 to allow access across instances in the specified internal IP address range.
The above is developer 'hack', not a recommendation for good practice.
Here is the mongodb documentation https://docs.mongodb.com/manual/reference/configuration-options/ it specifies that
The IP address that mongos or mongod binds to in order to listen for
connections from applications. You may attach mongos or mongod to any
interface. When attaching mongos or mongod to a publicly accessible
interface, ensure that you have implemented proper authentication and
firewall restrictions to protect the integrity of your database.
To bind to multiple IP addresses, enter a list of comma separated
values.
and that
127.0.0.1. is the default configuration
I'm clueless when it comes to networking so I wanted to know if someone could explain to me what this means in a more comprehensive way. Also, what would it mean if I were to change this? Why would I want to bind multiple IPs? and finally if anyone has a clue, why is 127.0.0.1 the default option?
Edit:
(You can skip this edit part)
Some of the motivation behind this question lies in getting these warnings while trying to run mongodb on docker:
2016-05-22T05:36:12.478+0000 I CONTROL [initandlisten] ** WARNING: Insecure configuration, access control is not enabled and no --bind_ip has been specified.
2016-05-22T05:36:12.478+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted,
2016-05-22T05:36:12.478+0000 I CONTROL [initandlisten] ** and the server listens on all available network interfaces.
and also some issues where I'd get this error
2016-05-20T01:04:18.012+0000 I NETWORK [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2016-05-20T01:04:18.018+0000 I NETWORK [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) ok
(more on that here if you are curious https://dba.stackexchange.com/questions/139075/replica-set-in-mongodb-using-docker-primary-has-error-and-stops-being-primary-w/139145#139145 but this issue is not the topic of this post!)
On bindIp
127.0.0.1 by convention is the IP address of localhost and is bound to the loopback interface, which is only accessible from the same machine.
Using this address as default is best practice, since doing so makes it impossible to accidentally expose a service to the public. You have to make the conscious choice to change the bind IP to make your service publicly available. Which you should only do after you made sure that you took proper security measures.
Note This is very simplified, skipping advanced topics
Typically, a machine has the loopback interface and one or more "real" network interfaces.
Say you have one network interface which is "internal" (only accessible by your application servers, since you put them into the same network) and you have one network interface which is "external" (reachable via the public internet for maintenance purposes). Now, if you would bind your MongoDB instance to all interfaces (you would use the IP address 0.0.0.0 to do that), your MongoDB instance would be accessible from the public internet – hardly a desired situation. Attackers could try to brute force your passwords and may eventually get access to your MongoDB instance. Better to prevent any access from the public internet at all.
What you would rather want to have that your MongoDB instance is accessible for your application servers and from the machine it runs on. So you would bind MongoDB to both the loopback interface's IP (127.0.0.1) and the IP of the private network, which in general would be one of
the range from 10.0.0.0 to 10.255.255.255
the range from 172.16.0.0 to 172.31.255.255
the range from 192.168.0.0 to 192.168.255.255
Let us take our example and say both the application servers and the MongoDB instance are in a private network in the range 192.168.X.X and you have given the MongoDB instance the IP address 192.168.0.1. So you would want to have your MongoDB instance be accessible via 192.168.0.1 so that the application servers can talk to it and via 127.0.0.1 to use the administration tools from the machine MongoDB runs on effortlessly.
So with the YAML configuration syntax, you would pass multiple IPs
NOTE do not add space between commas on multiple IPs
# WARNING!!! WARNING!!! WARNING!!!
# DO NOT DO THIS UNLESS YOU HAVE CLIENT AUTHENTICATION ENABLED
# (or you really, really, really know what you are doing)
net:
bindIp: 127.0.0.1,192.168.0.1
On the warnings
In short, this is MongoDBs way of saying:
Mate, you have two problems: you have not configured security yet and your MongoDB instance is only accessible from the local machine. The former is not as severe because of the latter. But you really should configure security before you bind the MongoDB instance to other IPs than "localhost"!
There is sort of an implied "Unless you really know what you are doing!", because iirc, the warning vanishes if you either activate client authentication or change the bindIp.
In my case i change bindIp to 0.0.0.0 in /etc/mongod.conf
sudo nano /etc/mongod.conf
# network interfaces
net:
port: 27017
bindIp: 0.0.0.0
I need to write my first socket program involving TCP connections. In the program I have created there is a client and server, both of which are the machine I am coding on.However,it requires that I pass the port number as a command line argument. How do I accomplish this?
The answer is simple : Make sure your server and your client agree on the port to use. As long as the port is available and can be used, set up the connected so that the client and server use that same port.
Here's a link that explain the different ranges available for TCP and UDP ports.
As an exemple, the port 3074 is used by microsoft for its Xbox live service. Making an application using this port might interfere with the service.
The port used will be defined either in a configuration file or hard-coded in the source code of both the server and the client. You should easily be able to find it with a quick look at the code or the directory which contains the application.
All connection attempts on RhodeCode on CentOS 6.3 are refused except from localhost.
Note that iptables is not running, and I am only trying to visit the web interface.
I have googled the exact error message below and looked around SO. I have yet to find a solution.
abort: error: No connection could be made because the target machine actively refused it
If the firewall is down, and I am not trying to modify any repository, what else is preventing me from connecting? EDIT: See #5 below. Not sure how to address it yet.
Things tried and other info
Using localhost, 127.0.0.1 and hostname in production.ini
service iptables stop
Connected over HTTP successfully. In other words, connections are accepted outside RhodeCode.
Made sure no authentication methods were enabled or configured in production.ini
Although the server accepts connections on localhost, netstat -l does not show that port 5000 is listening. Port 5000 is set in production.ini and ps uax | grep paster confirms the server is running. No other software tries to grab port 5000.
Ok, apparently I have been misunderstanding the host configuration. I was running on the assumption that host should be set to 127.0.0.1 or localhost in production.ini for RhodeCode to know what host to look for for another service. This was a faulty presumption on my part, since I am used to pointing web applications to local systems to look for databases.
It turns out that host binds the application to a specific address for access, meaning that it RhodeCode was supposed to only respond to local requests, regardless of what other system policies say. The setup docs did not make this clear because it did not specify that external connections would be refused. All it said was:
This command [paster serve] runs the RhodeCode server. The web app should be available at the 127.0.0.1:5000. This ip and port is configurable via the production.ini file created in previous step
The problem was fixed by binding RhodeCode to 0.0.0.0, which opened it to outside connections. Kudos to Łukasz Balcerzak for pointing this out in the RC support google group.
I am trying an example at Spring 3 with MongoDB. I can reach MongoDB's interface on port 28017. However examples use 27017 in configuration files. Which one to use?
28017 is admin interface and admin operations can be checked from there via web. However when using MongoDb at applications 27017 should be defined as port. When trying to reach that port given information is that:
You are trying to access MongoDB on the native driver port. For http diagnostic access, add 1000 to the port number
I find it very interesting by doing a very stupid thing. Added 1000 to 27017 and it become 28017, I access localhost:28017 and the admin panel appeared.
best of luck
I suggest you do not use default port in your application.
that is the first hackers are looking for.