While configuring security groups in AWS, few parameters are to be selected, like
Type, Protocol, Port range, Source
What exactly Port range mean? Does it represent port where client process runs or port of the AWS resource?
Does it represent port where client process runs or port of the AWS resource?
It represents ingress or egress ports (e.g. 22-80) that are allowed through or out of your SG. Your application nor instance may not use these ports at all.
The example range 22-80 for ingress would mean that incoming traffic on ports from 22 to 80 is allowed to pass through the SG. Your instance may not not listen to these ports at all. From SG perspective it does not matter.
Obviously its a bad security practice to open more ingress ports that your instance actually uses. So if you only want to access your instance through port 22 (ssh) and 80 (http), then only allow these to particular ports, not entire range.
Related
I have a Custom TCP rule in Outbound Security Configuration with Port Range as 0. Does this 0 means it is open to all ports to the ip range provided in the rule?. I have faced issues with this 0 as port when I changed this to correct port(5432) number after which it works fine.
I assume you are talking about the inbound rules (ingress) and outbound rules (egress) of a security group. A security group being a firewall around an AWS component - in your case, as your using port 5432, a PostgreSQL RDS database.
I just tested it on my side. I had a working inbound rule for accessing an EC2 server. When I changed the port to 0 - I could no longer access it. If you were to allow inbound\outbound traffic to all the ports you would specify: 0-65535
So as far as I can tell port 0 specified on its own doesn't seem to give any access.
Besides the 0-65535 port range, there is another valid port value when working with Cloudformation: -1.
This is used for the ICMP and ICMPv6 protocols. Some mention of it here.
You can not specify -1 as a port number when working with the AWS GUI.
If you are worried about security and just want to create an inbound rule for yourself - make sure to specify your /32 CIDR as a suffix to the IP address as per the previous image where TCP access is given across all ports to someone at the 1.2.3.4 IP address. Using a CIDR other than /32 will allow access to other IP addresses O_O
If you are new to working with security groups also please note the following:
Security groups are stateful - if you send a request from your
instance, the response traffic for that request is allowed to flow in
regardless of inbound security group rules. Responses to allowed
inbound traffic are allowed to flow out, regardless of outbound rules.
In other words, don't create a possible security risk by unnecessarily duplicating inbound rules to outbound rules (or vica verca) if you mistakenly thought that you had to create a inbound\outbound rule to handle the responses to the allowed inbound\outbound traffic.
Recently started using Network Load Balancer which listens on port 80 and forwards traffic to my target group. My autoscaling group is configured to add any new targets to this target group.
However, my application on the target EC2 instances runs on port 8001, not 80. So my targets should register under port 8001 in the target group. The auto-scaling configuration doesn't seem to support that. All new instances created by auto scaling are added as targets with port 80 and there is no way to auto specify which port that should be used instead (8001 for me).
Any ideas how to implement this?
The port definition in the target group is the port definition you're looking for. The port in the target group is the port on which the targets receive traffic. The port on the listener is the port on which the load balancer listens for requests.
So you should set port 80 on the listener and port 8001 on the target group.
What kind of application are you using (web server, application server, ...)? Maybe ALB would be more suitable for you as it works on layer 7 of OSI model, therefore it is able to proccess HTTP headers, for example.
Back to your question; To be able to forward traffic to your EC2 instances, that runs application on port 8001, you have to set port on your target group to 8001. Auto-scaling group knows nothing about what application is running on EC2 it provisions, nor about ports that are used by that application.
So the final flow is like:
LB listens on port 80 and forwards traffic to target group on port 8001. This target group then sends traffic to its targets (your EC2 instances) on port 8001.
I was crying over this for hours and the answers here gave me a clue and finally, I found out what the heck is going on!
The story of ports can get complicated, but let's clarify them.
Four Ports in the story!
It's crucial to know that you are dealing with 4 ports here! So let's name them one by one.
(I am using ECS, but the same applies to anything else that manages your code to ELB.)
P1: LB's "Listening" Port
The port where the Load Balancer receives traffic. Usually 80 or 443.
P2: TG's Port
The port where the Target Group is set to work on. It's baked into the Target Group at the time of creation of TG (as jpact mentioned) and shows in the description. You cannot change it later.
You, however, can set the health-check of the Target Group on a different port, but it doesn't help you have a working set-up.
P3: Container's "exposed" port
This is the port that the container is giving out and expects to receive traffic.
P4: The application's/host's port
This is the port your code (say a Node.js app) is actually listening to.
Want no pain? set P2 = P3
The thing is P2 (TG's) and P3 (container's) can differ. In fact, you will not even face a challenge if they are set to arbitrarily different numbers, initially.
Application <> LB (e.g. in ECS)
When you register a Service's container to a TG, no one asks about ports and it can work well. You just say attach this container to that TG and it automatically pick's the "container's" port (P3) here.
And then if you go to your TG's page you will see it is on the container's port (P3) which is a different port that the TG's (P2), but it works well and who cares!
Here comes Auto Scaling!
The headache begins when you add Auto Scaling with healthcheck!
ASG knows it should create instances on TG. However, it needs to assign a port between EC2 instance and TG. And clearly, ASG doesn't know what container (P3) is going to be in it, so by default it picks TG's port (P2). And this is where the craziness happens!
TL;DR
Set TG's port == Container's port. They can be anything you want, but make them match.
Below the container and to to your app (P4) you can have a mapping. Above TG (on LB) you have another port mapping (P1). But these P2 and P3 MUST match!
Go ahead, create new TG's with the container's port (P3), wire them to above (ELB) and below (Services) and hopefully it will work well!
PS. Apparently, you cannot change a Service's TG! So new Service as well... :)
i got to see something and did not able to understand and so asking relating AWS NACL. I created one public subnet and associated with an NACL. I created rules in NACL where 80 and 443 allowed for both inbound and outbound. Now created an EC2 instance in the subnet. When i tried yum update it did not work. I reattached the subnet to a default NACL where it allows all and yum update worked. If i am not wrong yum does download packages by http or https. my NACL had these rules and still yum update did not work. I also tried to curl the http://packages.ap-southeast-1.amazonaws.com and did not work. Is there something i am missing in NACL rules.
your answers will clear my fundamentals. please suggest.
Thanks,
You can use a NACL to restrict Inbound ports, but you'll probably have a problem restricting Outbound ports.
The way it works is:
The remote site connects to your Amazon EC2 instance on port 80. It also includes a 'return port' identifier saying which port to send the response to.
The EC2 instance receives the request on port 80, generates a response and sends it back to the originating IP address, to the port requested (which will not be port 80).
The originating system receives the response.
Ports are one-way. You only receive content on a port. You don't send from the same port. This way, if you have made multiple requests, each request is received on a different port and can be matched back to which to the original request.
So, the problem with your NACL is that it is only allowing outbound traffic to 80 and 443, which is not the port that the originating system is requesting to receive the traffic. You would need to open up the range of outbound ports.
It's worth mentioning the the use-case for using NACLs is normally to block specific protocols. If you simply wish to limit access to ports 80 and 443 on your EC2 instance, you should use Security Groups. Security Groups are stateful, so you really only need to open the Inbound connection and outbound responses will be permitted.
Oh, and presumably you also opened Port 22, otherwise you wouldn't be able to login to the instance.
I'm not sure why my browser is timing out when I try to connect to my AWS Ubuntu Instance squid proxy
I want to have my AWS Ubuntu instance act as a proxy for my python requests. The requests I make in my program will hit my AWS proxy and my proxy will return to me the webpage. The proxy is acting as a middleman. I am running squid in this Ubuntu instance. This instance is also within a VPC.
The VPC security group inbound traffic is currently set to
HTTP, TCP, 80, 0.0.0.0/0
SSH, TCP, 22, 0.0.0.0/0
RDP, TCP, 3389, 0.0.0.0/0
HTTPS, TCP, 443, 0.0.0.0/0
and outbound traffic is open to all traffic
This is my current squid configuration is the default squid.conf except that I changed one line to
http_access allow all meaning traffic is open to all.
However when I changed my mozilla browser to use the Ubuntu instance's Public IP and squid.conf default port of 3128, I cannot see any traffic going through my proxy using this command on the ubuntu instance
tail -f /var/log/squid/access.log
My browser actually times out when I try to connect to a website such as google.com. I am following this tutorial but I cannot get the traffic logs that his person is getting.
HTTP/S as shown in security group settings actually has nothing whatsoever to do with HTTP/S.
Many port numbers have assigned names. When you see "HTTP," here, it's only an alias that means "whatever stuff happens on TCP port 80." The list of values only inludes common services and the names aren't always precise compared the official port names, but the whole point is to give neophytes a word that nakes sense.
What should I change? I always thought I should be leaving HTTP/S ports to their default values.
That is not at all what this does. As already inferable from above, changing an "HTTP" rule from port 80 to something else does not change the value for the HTTP port on instances behind it. Changing the port value makes the rule no longer be an "HTTP" rule, since HTTP is just a friendly label which means "this rule is for TCP port 80."
You need a custom TCP rule allowing port 3128 from your IP, and that's it.
You need to add 3128 as custom TCP in your SG. This will allow Squid to send/ receive traffic.
Also as a best practice, make SSH accessible from your own IP rather than public.
I'm trying to setup an ALB which listens on port 443, load balancing to ECS Docker containers on random ports, lets say I have 2 container instances of the same task definition, listening on port 30000 and 30001.
When I try to create a target group in the AWS EC2 Management console, there's a "port" input field with 1-65535 range.
What number should I put there?
And when I try to create a new service in the AWS EC2 Container Service console, together with a new target group to connect to a existing ALB, there's no input field for a target group "port".
After it's created, navigating to the EC2 console, the new target group has port "80".
Do I have to listen on port 80?
But the health check happens against the "traffic port", which is the container port, 30000 and 30001, so what's the point?
Turns out, when combined with ECS, the target group's port doesn't mean anything. You don't need to listen on that port.
I ran into this situation myself at work. I noticed the target group port and the port of the registered instance were different. I've typically set them up to be the same thing so wondered what this was all about which led me to this thread. I couldn't find a good answer on AWS docs, but found this in the Terraform docs for aws_lb_target_group resource:
port - (Optional, Forces new resource) The port on which targets receive traffic, unless overridden when registering a specific target.
So, I guess it's just the default port used unless you override it. Makes sense.
I think what he's referring to is the health checks. If your ELB is listening on port 443 but your target group is set for port 80, then every health check for the target group will attempt a request on port 80 and get redirected to port 443 by the load balancer. This results in a 301 code, which is considered unhealthy. Only 200 codes are supposed to be considered healthy. At that point you either have all unhealthy targets all the time or you add 301 to the list of healthy codes which defeats the whole point in health checks because it will always return a 301 for port 80. You might as well just match the ports.
By default, a load balancer routes requests to its targets using the protocol and port number that you specified when you created the target group. Alternatively, you can override the port used for routing traffic to a target when you register it with the target group.
The port in the target group is used in conjunction with auto-scaling groups and if you ever plan to use those you want to use the right port from the start. Why? Because you can not change it after the target group has been created and auto-scaling will simply not work if you set the port wrong.