I created a Linux t3a.nano EC2 on AWS, I haven't done anything on the instance other than starting it and connect to it through SSH.
I would like to open 2 ports, port 80, and 3000, for that, I created a Security Group and added both ports to the inbound rules.
Based on AWS documentation that is all you need to do in other to open the ports, but if I connect to the instance and list the ports open none of the ports on my Security Group are listening, only 22, but that is open by default.
I am running this command to list the ports:
sudo netstat -antp | fgrep LISTEN
Other Steps I tried:
Check my ACL, will attach a picture of the configuration below, didn't change anything it looks to be fine.
Checked that the instance is using the correct security group.
Stoped and started the instance.
Created an Elastic IP and associated it to the instance to have a permanent public IP address.
Any suggestions about which steps could I am missing?
You are checking the ports from inside the instance. Security Groups (SGs) work outside of your instance.
You can imagine them as a bubble around your instance. Subsequently, the instance is not aware of their existence. This can be visualized like on the below image, where the SG is a barrier outside of the instance. Only if SG allow traffic in, then your instance can further limit it by using regular software level firewalls.
To open/block ports on the instance itself you have to use a regular a firewall such as ufw. By default all ports on the instance will be opened, at least when using Amazon Linux 2 or Ubuntu.
Therefore, with your setup, inbound traffic for pots 22, 3000 and 80 will be allowed to the instance.
Update - Response
I got to this point thanks to the comments above!
I wanted to open port 3000 to host a web service, so I did all the steps on my original question, the step that I was missing was to run a server to do something on port 3000. After I ran node I was able to see the port open internally and was able to make requests to that port.
The Security Group remains the same, but now if I list the ports this is what I get: sudo netstat -antp | fgrep LISTEN
Related
I have tried everything, this is my last hope before I give up on ever working with AWS again. My security group setting allow port 3000 which is being forwarded to port 80 already. I have rebooted, done a stop start, created a new AWS account, and allowed traffic on port 80. Does anyone know of what else this could be?
My local OS is Ubuntu 20.04.
To make port 80 accessible to a computer on the Internet (assuming that it is working on localhost):
The Amazon EC2 instance should be in a public subnet (if you can SSH to it, then this is true)
A public IP address should be assigned to the instance (again, if you can SSH to it, then this is true)
A Security Group associated with the instance should permit inbound access on port 80 from 0.0.0.0/0 (meaning the whole Internet)
There is no need for the Inbound Rule that references port 3000 since you are wanting incoming traffic on port 80 only (I presume).
If your app is still timing-out with the above configuration, then you'll need to debug what it is attempting to do. You could, for example, temporarily open the Security Group for all ports just to confirm that it is not the cause of the problem.
I am able to access my app inside the ec2 instance using elinks but when I try to do from the browser it says "This site can’t be reached".
I am trying to run a node app on port 3000
my netstat
netstat
my ec2 security group inbound rules
after going through other stackoverflow tickets I figured that there are two levels of checks
EC2 security groups
EC2 instance firewall
so although I added the port 3000 on security group inbound rules still I had to puncture the instance firewall as well. Port 80 is open by default
I'm actually doing the same thing, and in order to do so, you need to give it a public IPv4 address and also run a web server from it. At least that is the conclusion I reached this morning.
I created compute engine instance in GCP to deploy my web app.It works fine inside the instance (localhost:8080).
However, using the external Ip address, I'm unable to access it even though I have allowed for 0.0.0.0/0 for all instances by the firewall rule.I added both port tcp:8080 and tcp :8444 but It does not allow to connect even 'Telnet'.
Connecting To 35.185.98.244...Could not open connection to the host, on port 8444: Connect failed
Connecting To 35.185.98.244...Could not open connection to the host, on port 8080: Connect failed
Anybody can help me to solve this issue?
my git url: https://github.com/ChkBuk/myexamples/tree/master/SyneBiz
Take a look at the Firewall Rule in the GCP. Make sure that you allow ingress traffic for the port 80 (since you are accessing it from the browser). The ports 8080 and 8444 are local ports accessed internally. These ports are not exposed to the public. You have to make sure that there is a forwarding rule that redirects the traffic from port 8080/8444 to port 80.
Eventually, try to test the URL connection and the ports within the compute engine instance, or outside the GCP. Below are some examples:
$ curl http://[external-IP-vm-address]:80
$ telnet localhost 80
$ nmap <external-ip-vm-address>
$ netstat -plant
There are other network tests that you could perform. You may consult this discussion thread from Stackexchange.
Lastly, it could be that the ports 8080 and 8444 are already being used by other processes. For this reason, you are unable to connect to them.
Try the following troubleshooting steps.Type:
$ netstat -tulpn
This command above will display a list of all processes running on their respective ports. If the port 8080/8444 are there, take a look at the existing process running on it. You may then kill that process. For more information on troubleshooting the processes running on port 8444 and 8080, you may consult this article.
Question: How can I allow inbound SSH traffic on a non-standard port when using Amazon Security Groups and also provisioning with Chef?
Amazon EC2: Allow inbound ssh traffic on port 999 instead of 22 by adding this rule to a Security Group.
Custom TCP Rule Port Range: 999
Chef: Create a new server with access to ssh on a non-standard port via:
knife ec2 server create .... -p 999 ....
Ubuntu: Allow ssh access on a non-standard port by editing /etc/ssh/sshd_config
Port 999
Easy enough? Why doesn't it work?
When using knife ec2 server create ... -p 999 ... the instance creates. However it hangs on "Waiting for sshd...". Eventually that errors out. The instance is not available using ssh -p 999 username#ip-address nor ssh -p 22 username#ip-address.
As some of the commenters have said, you are being locked out because the instance is listening on port 22, but your security groups are only allowing TCP connections on port 999.
There is no way to connect to the instance in this state.
There are three solutions to this problem that I can see.
Solution 1: Make a new AMI
Create a new AMI which has sshd configured to listen on 999.
Once you have done so, create your EC2 servers using your custom AMI and everything should work.
There are fancy-pants ways of doing this using cloudinit to let you customize the port later, but it hardly seems worth the effort.
Just hardcode "999" instead of "22" into /etc/ssh/sshd_config
The obvious downside is that for any new AMI that you want to use, you'll have to bake a new base AMI that uses the desired port instead of 22.
Furthermore, this diverges away from the Cheffy philosophy of layering configuration on a base image.
Solution 2: Icky Icky Security Groups
You can hack your way around this by modifying your security groups every time you bring up a new server.
Simply add an exception that allows your machine to SSH into the box for the duration of your bootstrapping process, then remove this from the security group(s) that you are using once you are done.
The downside here is that security groups in EC2 are not dynamic, so you either have to create a new security group for each machine (ick!), or let this open port 22 for your workstation on all of your servers during the bootstrapping window (also ick!).
Solution 3: Tunneling
The last option that I can think of is to allow connections on port 22 amongst your live servers.
You can then tunnel your connection through another server by connecting to it, opening an SSH tunnel (i.e. ssh -L ...), and doing the knife ec2 actions through the tunnel.
Alternatively, you can pass through one of the other servers manually on your way to the target, and not use knife to bootstrap the new node.
The downside here is that you need to trust your servers' security, since you'll have to do some agent forwarding or other shenanigans to successfully connect to the new node.
This is probably the solution that I would choose because it does not require new AMIs, doesn't open port 22 to the outside world, and requires a minimal amount of effort for a new team member to learn how to do.
I am trying to use nodejs and socket.io to deliver a webapp, which use websocket on port 3000.
I have opened port 3000 on my EC2 instance in my management console by adding the inbound TCP rule to the relevant security group, however I still can't access it via public dns on my browser.
sudo netstat -tulpn doesn't show it as an open port.
What am I missing? Is there some service I need to restart or a command line I need to push to get it running?
Thanks
sudo netstat -tulpn doesn't show it as an open port.
netstat command will show what all ports that are being listened by "some" process. So in this case as you have mentioned, It seems like you application is not listening on port 3000.
First, fix your application and ensure that it is listening on port 3000.
Also, netstat has nothing to do with whether a port is opend/closed from firewall perspective. It will tell you whether a given port is in LISTENING mode by some process.
Follow these steps:
Make sure your application is listening on port 3000:
netstat -anp | grep 3000
also telnet 127.0.0.1 3000
Then make sure that local firewall is configured to allow incoming access to port 3000
OR disable local firewall to do a quick test (service iptables stop). for linux, its usually iptables
Allow incoming access to port 3000 in your AWS security group.
Please follow above 3 points and let us know if you still face the same issue.
in addition to all the steps above, check if you have ufw (uncomplicated firewall) set up.
to check if you have ufw running do:
sudo ufw status
if it is running,
to allow port 3000 simply do the command
sudo ufw allow 3000
this solved the problem for me. i forgot that i had setup ufw a while back, and recently starting using my aws instance again.
I guess you made your changes using the AWS Management console.
But this just means that Amazon's system will allow message on port 3000 through their own security systems to your server.
Your EC2 server (you don't say whether it's Windows or Linux) may have its own firewall system that you have to open port 3000 on. You will have to look at the documentation for your server to what settings you need to change.
I assume you've tried opening a browser on your EC2 instance and you can access the webapp from there.
Also, thinking laterally, if there are no other web servers running on your EC2 server why not change your node.js webapp to use port 80?
Had similar problem, but I was using socketio with SSL
var https = require('https').Server({
key: fs.readFileSync(path.join(__dirname + '../) + 'ssl.key', 'utf8'),
cert: fs.readFileSync(path.join(__dirname + '../') + 'ssl.crt', 'utf8')
}, app);
But the keys were wrong, so even though my AWS security was done, iptables clear and nginx providing with client js file, the request kept closing. So in Firefox I got net::ERR_CONNECTION_CLOSED and finally figured out that it might be the SSL failure.
I hope this helps somebody. I had followed an online tutorial that said I should add a security rule for 3000 TCP and link back to the security group identifier in the source.
That's wrong. Remove that line and just set up two custom TCP for port 3000 for IPv4 and IPv6. That fixed it for me.
Let me put my couple cents here.
Resolved issue by adding 3000 port to Secure groups with IPv4 and IPv6 and setting host in nuxt.config.js to '0.0.0.0'. This value makes Nuxt automatically find "real" ip listen to.
Here is how I was able to fix the problem:
Go to the EC2 instance page
In the "Security" tab, click on the link of the security group associated with the instance
In the Actions menu click "Edit inbound rules"
Add rule with custom tcp
And click "Save rules"