I run my node.js app on Amazon EC2 (Ubuntu 14.04)
On localhost, it works, but application not available on the internet by this address http://ec2-35-160-4-84.us-west-2.compute.amazonaws.com:3443/ where 3443 is my port.
How can I fix it?
Sounds like you need to go to your Security groups on the server, and update the inbound rules to allow port 3443. I assume this would be a TCP connection so you need to update the Custom TCP put in the port and then choose which IP or if all you want to allow into the system.
To get to Security Groups .. go to your EC2 instance, then look on the left side where the menu is and you will see Security Groups listed. Click there, and make sure you are updating the Security Groups INBOUND rules for the right server.
Hope that works.
Related
does anyone know what i'm doing wrong here? i'm trying to access my windows-server 2019 ec2 node locally so i can successful collect metrics via WMI Exporter and point this at my prometheus instance.I'm trying to access port 9182 for WMI Exporter, and can connect fine via localhost on my remote widows instance, also the IPv4 Address on the same instance.I've also tried to configure the firewall port on the windows host 9182. When I try to access via localhost this returns This site can’t be reached, if i try via public address on both i get Can’t reach this page. Ive opened port 3389 inbound and all traffic ipv4 outbound. Any help would be great. I have also tried adding RDP Ip directly to the inbound security rules, yet still have the same issue. Many Thanks
After installing windows_exporter, the installer will create an inbound rule for windows_exporter itself. However it may be not enough and cause your issue for some reasons. See this similar issue.
Try to add a new inbound rule for the Windows firewall and let any programs can access the listening port (default 9182). That works for me.
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
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 currently have an EC2 instance up and running with Amazon Linux running and transferred my project (which contains both React/NodeJS/Express) onto the EC2 instance via SFTP using FileZilla.
For the EC2's Security Groups, I opened a port for 3000 (protocol: tcp, source: 0.0.0.0/0), which is how my Express is defined as well.
So I sshed into EC2 instance and ran the project's Express, and sees it listening to port 3000 within the terminal. But once I hit the Public DNS with ec2...us-west-1.compute.amazonaws.com:3000, it says The site can't be reached - ec2...us-west-1.compute.amazonaws.com took too late to respond.
What could be the issue and how can I go about from here to connect to it?
Thank you in advance and will upvote/accept answer.
Just check if your Node.js server is running on the EC2 instance.
Debugging:
Check first if It working locally properly.
Check for the node.js server in EC2.
sudo netstat -tulpn | grep :3000
try to run server with --verbose flag i.e npm run server --verbose
it will show logs of the server while starting.
Check for the security group Setting for the EC2 instance.
try to connect with the ip:port i.e 35.2..:3000
If still it not working and response taking long time.
that means some other service is running on the same port.
try this in ec2:
sudo killall -9 node
npm run server
And connect with using IP(54.4.5.*:3000) or public DNS (http://ec2...us-west-1.compute.amazonaws.com:3000).
Hope It will help :)
You may be encountering an issue with outbound traffic. You may be inside a company's network, either physically connected or VPN'd in. In some instances, your VPN isnt set up to handle split traffic, so you must abide by your company's outbound restrictions.
In a situation like this, you would want to use a proxy to access your site. when locking down your security group, make sure you use your proxy's public IP (not your company's).
Usually, when we have connectivity issues, it is something basic or a firewall. I assume you have checked whether a firewall is running on either end, eg. iptables -L -n. Also, any protocol analyzer like wireshark or tcpdump would tell you where packets to port 3000 are visible.
I understand the need for putting a web server in a DMZ and blocking inbound traffic to all ports except 80 and 443. I can also see why you should probably also block most outbound traffic in case the server is compromised.
But is it necessary to block outbound HTTP traffic over port 80? If so, why? A lot of web applications these days rely on sending/retrieving data from external web services and APIs, so blocking outbound traffic over port 80 would prevent this capability. Is there a security concern that's valid enough to justify this?
The only reason I can think of is if your machine is somehow compromomised remotely then it won't be able to DDoS another website on port 80. It's not something I normally do though.
Rather then blocking it, throttle it. Use iptables -m limit.
I have several web apps that invoke external web services, so I would say it's a bad idea to block output HTTP traffic. If you're concerned with security, you could block it and allow for only certain destinations.
Depending on your SQL version, you could have certificate authentication time out issues with SQL server 2005.
First - I agree with #vartec on throttling "Rather then blocking it, throttle it. Use iptables -m limit" as at least part of the solution.
However I can offer another reason to not block port 80 outbound at all times. If you have automatic security updates turned on the server can't reach out to PPAs over port 80 to initiate a security update. Thus if you have automatic security updates set up they won't run. On ubuntu auto-security updates are turned on in 14.04 LTS with:
sudo apt-get install unattended-upgrades update-notifier-common && \
sudo dpkg-reconfigure -plow unattended-upgrades
(then select "YES")
More graceful solutions would be ansible scripts opening the port automatically, possibly also modifying an AWS security group rule via the CLI in addition to iptables if you are at AWS. I prefer modifying my outbound rules temporarily via AWS CLI initiated by a stealth box. This forces logging the update up in my AWS S3 log buckets but never shows up in the logs on the server itself. Further the server that initiates the update doesn't even have to be in the private subnet ACL.
Maybe do both? You have to figure at times an attack is going to relay off an internal IP in your subnet so there is merit to doubling down while preserving the ability to automate backups and security updates.
I hope this helps. If not reply and provide more code examples to be more specific and exact. #staysafe !
If the machine is compromised and outbound traffic on port 80 is allowed, it would make it easier for intruders to send back harvested data to themselves. Allowing outbound traffic means you can initiate a connection from your machine to the outside world. A better approach would be allowing outbound traffic only to certain web sites/addresses that you trust (i.e. Microsoft Windows Update, Google reCAPTCHA) rather than any destination in the world.
what do you mean with blocking outbound traffic over port 80.
You have two possibilities. Gernerate Dynamic Rules which allow communication from client to your webserver for this session. Search for Stateful firewall rules.
Or you generally allow established Connections to communicate in and outgoing with each other.
If you generally block all outbound traffic over Port 80 your Webserver could not reply to any client.
The other way around, if your Webserver needs to get some API, e.g. a jquery library he wont use port 80 as his Port to communicate with the Webserver who holds the API.
Your Webserver would normally choose a port > 1024 and use it for his request to get the API from the remote Server.
So blocking all traffic over port 80 (as your port you connecting from) would not prevent your Server from sending any requests for apis and such things. because he doesnt use port 80 when he acts as a client.