In the case of using Jelastic cloud, I want to play Minecraft. The environment is Ok, everything works fine, but I can't connect to my server.
I did everything like in this guide http://blog.jelastic.com/2012/11/08/play-minecraft-in-the-cloud/
Maybe I have to do something else?
According to this guide you've created VDS with CentOS. Jelastic provides full root access that allow managing your virtual machine in any preferred way.
Now we recommend you to check out opened ports with
netstat -nltp
and firewall configuration with
iptables -nvL. Seems like you forget to open necessary port.
In VDS environments in Jelastic ports are closed by default except 22, 80, 443, 8080, 8022. As we know Minecraft server uses 25565 port for external connections.
For opening necessary port for the Minecraft (25565) you should add following firewall rule:
iptables -A INPUT -p tcp -m tcp --dport 25565 -m state --state NEW -j ACCEPT && service iptables save && service iptables restart.
More information about Jelastic can be found in our latest release notes as well as on our documentation pages.
Have a nice day,
Jelastic Support
Related
I'm looking for a way to either redirect ports within a container (Not using Docker with '-p') or use multiple containers with same port with network_mode.
Background:
I have a service (VPN) inside a container that provides a central gateway to another network. Now I want to use "network_mode: 'container:vpn'" to attach additional 'sub'-containers to the VPN container so that they also use the corresponding VPN. This also works. To be able to access services I have to pass ports of the sub-containers to the host, which has to be done via the VPN container (works also). But here I have a problem, if several sub-containers publish the same port, I do not know how to map them, because for example the port 8000 is used multiple times.
The port in the original images I can't adjust because the applications need this internally or can not allocate it differently. Now I had the idea to use the containers as base image and to create a shadow image in which the ports are redirected by iptables (iptables -t nat -A PREROUTING -p tcp --dport 8000 -j REDIRECT --to-port 8020). However, this doesn't seem to work because iptables can't be used in a container (only in privileged mode which I don't want).
I wonder how to solve this problem?
Maybe someone has an idea what methods/options there are to solve the problem.
Ideally, I would like to continue using different docker-compose files for every service.
thx
Install socat in the docker image you want to do the port forwarding
for example add this to your Dockerfile
RUN apt-get install -y socat
The command to install socat could be different for other os variants.
Once socat is installed, just call it.
In this example it redirects from 7545 to 8545 in the same container
socat TCP4-LISTEN:7545 TCP4:127.0.0.1:8545
I've been wondering why docker installation does not enable by default port forwarding to containers.
To save you a click, what I mean is:
$ sysctl net.ipv4.conf.all.forwarding=1
$ sudo iptables -P FORWARD ACCEPT
I assume it is some sort of security risk, but I just wonder what the risk it is.
Basically I want to create some piece of code that enables this by default, but I want to know what is the bad that can happen.
I googled this and couldn't find anything.
Generally FORWARD ACCEPT seems to be considered too permissive (?)
If so, what can I change to make this more secure?
My network is rather simple, it is a bunch of pcs in a local lan (10.0.0.0/24) with an openvpn server and those pcs may deploy docker hosts (I'm doing this by hand, not using docker compose or swarm or anything because nodes change) that need to see each other. So no real outside access. Another detail is that I am not using network overlay which I could do without swarm, but the writer of the post warns it could be deprecated soon, so also wonder if I should just start using docker-swarm straight away.
EDIT: My question here is maybe more theoretical I guess than what it may seem at first. I want to know why they decided not to do this. I pretty much need/want full communication between docker instances, they need to be ssh'd into and open up a bunch of different ports to talk to each other (and this is the limitation of my networking knowledge, I don't know how this really works, I suppose they are all high ports, but are those also blocked by docker?). I am not sure docker-swarm would help me much here either. They aimed at micro-services I maybe need interactive sessions from time to time, but this is probably asking too much in a single question.
Maybe the simplest version of this question is: "if I put that code up there as a script to load each time my computer boots up, how can someone abuse it".
Each docker container runs on a local bridge network with IPs generally in the range of 172.1x.xx.xx. You can get the ip address running:
docker inspect <container name> | jq -r ".[].NetworkSettings.Networks[].IPAddress"
You should either run your container exposing and publishing the specific container ports on the host running the containers.
Alternatively, you can use iptables to redirect traffic to a specific port from outside:
iptables -t nat -I PREROUTING -i <incoming interface> -p tcp -m tcp --dport <host listening port> --j DNAT --to-destination <container ip address>:<container port>
Change tcp for udp if the port is listening on a udp socket.
If you want to redirect all traffic you can still use the same approach, but may need to specify a secondary ip address on your host (e.g., 192.168.1.x) and redirect any traffic coming to that address to your container.
I have a mongodb docker container I only want to have access to it from inside of my server, not out side. even I blocked the port 27017/tcp with firewall-cmd but it seems that docker is still available to public.
I am using linux centos 7
and docker-compose for setting up docker
I resolved the same problem adding an iptables rule that blocks 27017 port on public interface (eth0) at the top of chain DOCKER:
iptables -I DOCKER 1 -i eth0 -p tcp --dport 27017 -j DROP
Set the rule after docker startup
Another thing to do is to use non-default port for mongod, modify docker-compose.yml (remember to add --port=XXX in command directive)
For better security I suggest to put your server behind an external firewall
If you have your application in one container and MongoDb in other container what you need to do is to connect them together by using a network that is set to be internal.
See Documentation:
Internal
By default, Docker also connects a bridge network to it to provide
external connectivity. If you want to create an externally isolated
overlay network, you can set this option to true.
See also this question
Here's the tutorial on networking (not including internal but good for understanding)
You may also limit traffic on MongoDb by Configuring Linux iptables Firewall for MongoDB
for creating private networks use some IPs from these ranges:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
more read on Wikipedia
You may connect a container to more than one network so typically an application container is connected to the outside world network (external) and internal network. The application communicates with database on internal network and returns some data to the client via external network. Database is connected only to the internal network so it is not seen from the outside (internet)
I found a post here may help enter link description here. Just post it here for people who needed it in future.
For security concern we need both hardware firewall and OS firewall enabled and configured properly. I found that firewall protection is ineffective for ports opened in docker container listened on 0.0.0.0 though firewalld service was enabled at that time.
My situation is :
A server with Centos 7.9 and Docker version 20.10.17 installed
A docker container was running with port 3000 opened on 0.0.0.0
The firewalld service had started with the command systemctl start firewalld
Only ports 22 should be allow access outside the server as the firewall configured.
It was expected that no one others could access port 3000 on that server, but the testing result was opposite. Port 3000 on that server was accessed successfully from any other servers. Thanks to the blog post, I have had my server under firewall protected.
I recently diagnosed a very complex issue involving Docker and iptables.
I have an Ubuntu host with the following iptables settings:
$ sudo iptables -L -t nat
[...]
Chain xyz (1 references)
target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:https /* xyz */ redir ports 8443
The rule is in place to redirect all inbound traffic from port 443 to 8443. It is meant to redirect traffic to a Java-based application that has nothing to do with my Docker containers, but runs on the same machine, and has a self-signed SSL certificate.
When I run a Docker container on the same machine with Docker's default network settings, and I issue a wget HTTPS request from within the container, Docker (or the OS) seems to redirect the outbound connection to port 8443 on the Ubuntu host, and, therefore, to the local Java-based application which, in turn, accepts the connection (most of the times) and returns invalid (self-signed) certificate details. As a result, applications inside the container end up talking to this local Java application on the host, instead of the real servers on the Internet they should be talking to.
I also verified that any wget HTTPS request issued directly from the Ubuntu host hits the target server on the Internet. The problem occurs only with requests that are initiated by Docker containers running on the same host.
Can anyone explain why this happens?
The example is not complete. You have not shown where this chain is linked from. I'll try to answer anyways, but you might want to reduce your IPtables rules to a set that does nothing but reproduce your problem.
The way iptables works is that the incoming packet has matching rules applied to it. Any rule that matches it, has its target applied.
In your case, what probably happens is that your outbound packets are matched on this rule, and therefor get redirected as well.
Since REDIRECT targets are on the pre-routing table, and that one is not limited to incoming traffic, you will need to limit the matching in some way. Easiest, probably, is to add ! -i lo to the rule. This should prevent matching of packets arriving through the loopback interface.
I have a rails server setup on a CentOS with a static ip that's accessible to the outside network.
If I go to http://my.ip.address on that machine, it works fine and I can see my rails server and the access is logged in /var/log/httpd/access_log
However, if I do the same thing on another computer, the connection times out and I don't see the access in the access_log.
netstat shows that httpd is listening on port 80, so as far as I can tell, everything seems to be working fine.
What else could be blocking this connection if it's not the network blocking the access?
You probably need to start the rails server with -b 0.0.0.0 (older versions do not require this).
Aetherus was correct. CentOS was blocking port 80 by default. I followed the guide in his link and was able to solve the problem.
For future users, these are the commands that fixed the problem:
iptables -I INPUT 5 -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
service iptables save
The first line adds a line (at line position 5) to your iptables configuration that accepts traffic on port 80. The second line saves the configuration so it's persistent through reboots.
Note that if you have any iptables configuration other than default, you may need to adjust the command so it inserts at a line other than position 5. In this case, position 5 is used because it is above the last REJECT filter that is at line number 5 by default.