I have inherited an aws project with the following cloudformation settings for a vpc security group.
SecurityGroupEgress:
- IpProtocol: -1
FromPort: -1
ToPort: -1
CidrIp: 0.0.0.0/0
I am not an expert in networking or VPC, could someone explain to me what the following means, specifically the -1.
It means:
On whatever security group this configuration is attached
Allow all traffic
On any port
From anywhere in the Internet (0.0.0.0/0)
From AWS::EC2::SecurityGroupEgress - AWS CloudFormation:
You can use -1 for the type or code to mean all types or all codes.
Related
I am doing a mongoexport and then a BigQuery load of a 50 million record collection
All of my cloud functions and app engine instances connect fine to Mongo Atlas via the VPC peering connection setup via Serverless VPC Access to our Atlas hosted in GCP
However, I have not been able to get Compute Engine instances to connect via our VPC. When I add the Compute Engine instance external IP, it connects fine. When I remove that and add in the internal IP for the Compute Engine instance I get timeouts, but it does show:
2021-01-10T18:09:44.531+0000 could not connect to server: server selection error: server selection timeout, curr
ent topology: { Type: ReplicaSetNoPrimary, Servers: [{ Addr: ***.mongodb.net:27017, Type: Unkn
own, State: Connected, Average RTT: 0, Last error: connection() : dial tcp *.*.*.*:27017: i/o timeout }, { Ad
dr: ***.mongodb.net:27017, Type: Unknown, State: Connected, Average RTT: 0, Last error: connec
tion() : dial tcp *.*.*.*:27017: i/o timeout }, { Addr: ***.mongodb.net:27017, Type: Unkn
own, State: Connected, Average RTT: 0, Last error: connection() : dial tcp *.*.*.*:27017: i/o timeout }, ] }
So my best guess is I'm not putting in the right IP range, or the right specific IP to allow compute engine instances to connect internally, it seems like it's Mongo Atlas firewall blocking.
What are the proper steps to setup connection between compute engine and mongo atlas over VPC so that there is no ingress/egress and connections are direct.
I recommend you to use the Intelligence tool on GCP to discard any firewall issue, keep in mind that the tool simulate the packet not a real packet. Once you have discard the firewall rules at GCP level, ensure that the internal firewall is allowing traffic.
I guess cause of this problem is firewall settings too.
Follow 2 steps below.
Step 1. Check VPC peering status
You can use VPC peering's internal access when 'status' is in active.
Check whether it is active or not.
Step 2. Check Firewall rules
If you don't have touch anything on firewall rules, Add a rule that allows each other's CIDR range at both sides.
Your issue is the following: you are trying to access to this DNS to connect your MongoDB atlas cluster ***.mongodb.net. This DNS is public, and your VM need to go on the internet to resolve this DNS. And because, you haven't public IP, you can't go to the internet.
The solution is to use a Cloud NAT to allow your VM to reach the Internet.
So I have an EC2 instance on AWS and it runs Mongodb. I have been having issues with hackers for a few months now and I can't seem to figure out how to keep them out. Luckily, I don't have anything important on there.
I did notice that my security group on AWS is basically open to all. For example, my inbound rules:
Port 80, tcp, 0.0.0.0/0
Port 8080, tcp, 0.0.0.0/0
Port all, tcp, 0.0.0.0/0
Port 22, tcp, 0.0.0.0/0
Port 27017, tcp, 0.0.0.0/0
Port 443, tcp, 0.0.0.0/0
If i change the source is there a convention I should follow? How should I set the source? I am new to this as I did not set up my security groups. Just trying to figure out how I can keep out the hackers. They have been going at it for a while now.
The0.0.0.0/0 means that the port allows connection from anywhere on the internet.
If you set the source, only the source (whether it's an IP or a range of ups) will be able to access the port.
How are you going to set the source really depends on your needs.
your data source should ideally allow access only from trusted internal IPs. remove full access of all tcp ports. only keep 27017 and map it to the IP address which is accessing your system. For web access, it's best to configure a reverse proxy and access it via that proxy.
If you are the only one accessing the EC2 instance, you can edit your security group and choose "My IP" as the Source, and then only you would be able to access it and the hackers will not.
It is best practice to limit command and control ports (22, 3389, etc) to only be accessible from known networks, such as your home, VPN IP pool, or corporate network.
(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.
I have my free-tier EC2 containing my Scala application. The app is running on port 8080 but I have declared redirection from port 80 to port 8080. Security group of EC2 includes inbound rules of port 8080 and 80 to all IPs. Nonetheless, I couldn't access the service with browser.
Outputs from netstat and iptables
Security group
Browser returns ec2-35-157-211-142.eu-central-1.compute.amazonaws.com refused to connect.
I'd really appreciate if someone could help me.
Thanks.
Ensure that your EC2 instances are located in public subnets. If that's fine, then ensure that they have public IPs assigned, otherwise they won't be accesible from the internet.
If they have public IP, then you should check that the security group has outbound rule allowing those ports for all IPs (or at least the ones you want to allow to connect). If you have inbound rule but no outbound rule your instance won't be able to serve traffic, so please define the outbound rule the same way that the inbound rule.
If that's properly set, then ensure that the network ACL allows inbound/outbound rules for the same ports (and of course: it does not deny them).
I hope this helps :).
If you're able to connect locally but not remotely, chances are that you aren't binding your server to the external interface. To bind to all interfaces, just make host = "0.0.0.0" similar to the following:
For Spray:
IO(Http) ! Http.Bind(service, "0.0.0.0", port = 8080)
For Akka HTTP:
Http().bindAndHandle(route, "0.0.0.0", 8080)
I have to run a program on an EC2 that reads the host's public IP address from config (which I don't appear to be able to easily change), and then connects to it, i.e. it's looping back to the instance via the public IP address.
I can't find out how to create a security group that can loopback to the the EC2 instance. My rules are:
outbound: 0.0.0.0/0 all tcp
inbound: [private IP/32, 127.0.0.1/32, public IP/32] all tcp 4440 (the port I need)
None of the inbound IPs work. I'm testing this by telnetting on the host to the public IP: telnet x.x.x.x 4440, and I'm never able to (where x.x.x.x is my public IP). I can do it by specifying 127.0.0.1 though, so the server I'm connecting to is online and bound correctly. I can also access the server through my browser. I just can't loopback. The connection hangs, which is why I think it's a security group issue.
How can I allow this program - which tries to connect to the public IP from the instance - to connect to the same instance by its public IP address?
I just did a test (using ICMP rule) , you have to add a rule in the security group as you said. you should add it normally, and set the source to 1.2.3.4/32 (following your example). please note that I am using Elastic IP in my tests.
According to the docs, it should also be possible to list that security group as its own source. This would permit the loopback even if the IP address changes due to a stop/start.
Another security group. This allows instances associated with the specified security group to access instances associated with this security group. This does not add rules from the source security group to this security group. You can specify one of the following security groups:
The current security group
A different security group for the same VPC
A different security group for a peer VPC in a VPC peering connection