Ephemeral ports on AWS Web server NACL Rule - amazon-web-services

I am new to AWS and have been experimenting with NACL rules. I went through Amazon VPC NACL default rules evaluation order to understand how NACL rules work.
I've created a test EC2 instance (with NGINX) in a public subnet with some Elastic IP. I have added EC2 to the default security group, which allows all traffic on all ports. I initially configured NACL to block all traffic. This worked fine because I was not able to SSH into or HTTPS my instance. My goal is to let 0.0.0.0/0 HTTP port 80 into my instance.
Understanding that NACLs are stateless, I added communication to/from 0.0.0.0/0 on all TCP ports. This worked fine.
Now, I thought of restricting inbound and outbound to Port 80. However, using this, I wasn't able to access test NGINX page.
I noticed that if I change the outbound rule to allow all ports, I am able to access the NGINX page. I am not sure why this is happening.
Here's the new config:
Do I need to add ephemeral ports as well? https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports

Yes. You need to open ephemeral ports 1024-65535 (assuming a Linux server is being used)
Your server will receive requests on 80 (or 443) but send the response over one of those ephemeral. Blocking outbound for the ephemeral ports is blocking that response.
You do not need to open 80 (or 443) on the outbound for your web server to work. Your web server would only need port 80 (or 443) outbound open if it needs to make an HTTP request to another web server - which it may well need to do; to call a third party API.

Related

security group aws specific ip http/https blocks everything

I've follow the documentation of I've read https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
and I want to create a security group in AWS which allows only one IP access to ports 80 or 443, but AWS is blocking everything even the IP which should have access when I apply this group.
We are using nginx in the ec2 server and the certificate was created with certbot
What do you mean by "blocking everything"?
From these 2 rules, port 80 and port 443 are only open to the one IP that you had given. If this is a webapp, it is likely that you'll have a loadbalancer setup to receive the traffic.
Check the ELB security group and block traffic there (If there is an ELB setup)
Check the VPC NACL if there are any block for port 80/443 traffic. If that is the case, NACL rule will take precedence here
Make sure you check your outbound rules also. If by "Blocking everything", you meant the outbound traffic
Edit the inbound rule to be only lock out any other port to the instance ip address only, while you open 443 and 80 to everyone.
eg. if ur ec2 instance public ip is 13.255.77.8 and you don't want port 5000 to be accessible to the public, create a custom tcp with your that is only acessible to that port ie mapping port 5000 to this ip - 13.255.77.8/32

Route only api traffic to other AWS EC2 instance

I am new to networking. And I am trying to route only traffic from one VM traffic to another VM. Therefore, I have done this.
I have two AWS EC2 instances as:
Application Server
Database Server
And they have their own security groups and I have allowed all traffic is permissible. Now I want to Database_server accepts only Application_server traffic not all public traffic. Database_server is MySQL which is running on 3306 port.
Suppose:
Application_server Public IP: 14.233.245.51
Database_server Public IP: 15.233.245.51
So I have allowed on port 3306 like this 14.233.245.51/32 for only Database_server but it did not work. It was before this 0.0.0.0/0 and ::/0.
How can I solve this?
First, the application server should communicate with the database server via private IP address. This will keep all traffic within the VPC and will enable security groups to work correctly.
Second, configure the security groups:
App-SG should be associated with the application server and permit incoming traffic on the appropriate ports for the application (eg 80, 443)
DB-SG should be associated with the database server and permit incoming traffic on port 3306 from App-SG
That is, DG-SG permits inbound traffic from App-SG by referring to the ID of App-SG. There is no need to specify an IP address. The security groups will automatically recognize the traffic and permit the App server to send traffic to the DB server. Return traffic will also be permitted because security groups are stateful.
You MUST communicate with the database server via private IP address for this to work.

EC2 - Make Windows instance accessible from anywhere (XAMPP)

I've launched an EC2 instance on AWS, no after setting up XAMPP and uploading all my archives it's now time to make the site public.
Thing is that I've already tried to put all the firewall on windows allowing inbound and outbound connections to "allow" and then also on my AWS Security groups this:
Inbound:
HTTP TCP 80 0.0.0.0/0
HTTP TCP 80 ::/0
Custom TCP Rule TCP 0 - 8080 0.0.0.0/0
Custom TCP Rule TCP 0 - 8080 ::/0
Outbound:
All traffic All All 0.0.0.0/0
As i mentioned before, i allowed all inbound and outbound connections on the windows firewall of the instance.
What am i doing wrong and how can i fix this issue to make the server accessible from the IP that amazon assigned my instance?
Thanks.
Couple of things to check:
(Obvious One) Make sure the application is listening on port 80 / 8080 (You mentioned both ports in SGs. Not sure on which port your application is running)
If you are planning to access your application over the internet, make sure you have public IP assigned to your instance.
Check your NACLs if both inbound and outbound rules are added. If you are accessing the app from a specific VPC / OnPrem network, add it to NACLs. If you dont want to restrict your app and want to access over internet, make sure you have 0.0.0.0/0 is added in NACL inbound and outbound
If accessing the app over internet, you need to have Internet gateway assigned to your VPC.
Hope this helps troubleshooting your issue. Provide more details like, you instance is in public subnet or private subnet. Weather you are accessing app from within the VPC or over internet etc.

Why can't I access a port on my AWS instance, even though I have security group inbound rules that allow it?

I'm new to AWS so this is probably a "doh!" question.
I set up a CentOS 7 instance and assigned a elastic IP. I created a security group and created a custom TCP inbound rule that allows TCP traffic on port 8000 anywhere (0.0.0.0/0), an HTTP rule for port 80 also from 0.0.0.0/0, and SSH/port 22 rule from my laptop IP, and assigned the security group to my instance. iptables/6, firewalld, nor SELinux services are NOT running on the box.
I CAN SSH to the box with the elastic IP. I CAN access http://my_elastic_ip, but I can NOT access http://my_elastic_ip:8000/some.html
netstat shows the 8000 port in listening state, on all addresses.
What am I missing?
It turns out, these ports were blocked by my company's firewall. Enabling them resolved this issue.

AWS Security group - Do I need to open outbound port for accessing internet or using yum

As I read about AWS security groups, we must open outbound ports to initiate traffic from within instance. What if I have to access a website or download some packages (using yum) over HTTP? Do I need to open any specific ports for this?
As I understand for HTTP/HTTPS client uses random ports to make a socket connection so in that case should I open all ports?
In order to make connections from your EC2 instance to the internet, you must open outbound ports in your security group.
The port number you need to open is the destination port, not the source port(s).
Some examples:
to allow HTTP connections from your EC2 instance to the internet, you need to create a rule for 0.0.0.0/0 on port 80.
to allow HTTPS connections from your EC2 instance to the internet, you need to create a rule for 0.0.0.0/0 on port 443.
If the web servers you're connecting to are listening on different ports (aside from 80 or 443), then you need to change or add more rules accordingly.