EC2 --> RDS:
RDS (DB Engine): I have inbound and outbound open on port 3306 for the web server's security group.
EC2 (Web Server): I have inbound open for 80, 443 and 22(myIP). Outbound is open for 80,443 and 3306, and it needs all traffic as well to function properly.
My question is about the outbound rules of my web server. Why do I need all traffic to be open? Does this have any security concern?
Some people lock down outbound to prevent against data loss. It works better for immutable architecture since you've removed the ability to update packages from public sources.
Obviously you can choose your own security profile; generally speaking I consider this the levels of security:
Port 22 open to the world
Port 22 access by white listed IPs
Bastion host with white listed IPs
VPN (from here down, all using VPN)
Private IPs + NAT
Proxies server outbound access
That's my ec2 security maturity model. I'm sure I missed some- feel free to comment below.
The security group outbound rules let you to specify "destination", not source. Basically you don't need to worry being attack by Denial of Server through the outbound rules.
On the other hand, unless your Web server need to connect out to Internet without restriction, then you set 80+443 destination to 0.0.0.0/0.
Otherwise , if your web server only need to connect to OS repositories for security update (e.g. ubuntu, apache,etc), then you can explicitly specify the repositories IP address instead of using 0.0.0.0/0.
Other than that, there is little risk. Unless you load something that render webpage, e.g. load web browser in the web server that read random webpage, then it make you susceptible to browser/java engine/rendering engine exploit : if exploit can execute something like ssh reverse tunnel, then there is possibilities that attacker may gain access to your web server.
Related
I am confused about configuring the EC2 security group settings.
There are three options (TCP, SSH, HTTPS) and each of them requires you to add an IP/port number.
For context, in my work I'm usually running Flask apps over EC2 and I only want particular people to view them. My question is understanding the difference between TCP, SSH, and HTTPs but more importantly which of these are important for me to configure.
Within the EC2 Console, under Security Groups:
SSH and HTTPS in the Type dropdown, are presets which set the port to 22 and 443 respectively.
TCP is the protocol. Both SSH and HTTPS are TCP.
If you're running a server which you want to expose on a non standard port, you can select Custom TCP Rule, then set the port acordingly.
You should probably have one security group that allows SSH traffic, then assign this security group to the EC2 instances you wish to shell into:
Then have a separate security group that allows the webserver traffic, in this case I also have one for port 80, aswell as 443:
Of course you will then need a server running on that EC2 instance to receive the traffic. This might be a reverse proxy like nginx, which then proxies traffic to the correct port for your app server (run your flask app with something like gunicorn in production).
If nginx and gunicorn are running on the same box, and say gunicorn serves on port 8000, then you wouldn't need a security group for this as it's loopback traffic. Your nginx configuration points to port 8000.
However if you have a separate EC2 instance running gunicorn, you might wish to set up a secuirty group for this to allow internal traffic from your VPC CIDR range:
I only want particular people to view them
This is probably a job for authentication on the app, as oppose to security groups, unless your certain of the public IPs from which you wish people to connect.
In the above examples above a Source of 0.0.0.0/0 is allowing traffic from anywhere to reach that port. The console has a convenient dropdown which lets you set My IP if you only want to allow traffic from the IP you're using to connect to the console. Otherwise you'd need to manually calculate the CIDR blocks.
Hope this helps. It probably raises more questions.
Https/Http are important for you. Both are used with websites. Https is http over SSL, meaning more secure than http. You just need these.
Http/https uses TCP port 80 and 443 by default.
SSH is used to securely access a Unix based server.
I've got an AWS VPC set up with 3 subnets - 1 public subnet and 2 private. I have an EC2 instance with an associated Elastic Block Store (the EBS contains my website) running in the public subnet, and a MySQL database in the private subnets. The security group attached to the EC2 instance allows inbound HTTP access from any source, and SSH access from my IP address only. The outbound security rule allows all traffic to all destinations. The security group associated with the database allows MySQL/Aurora access only for both inbound and outbound traffic, with the source and destination being the public access security group.
This has all been working perfectly well, but when I came to setting up the NACLs for the subnets I ran into a snag that I can't figure out. If I change the inbound rule on the public subnet's NACL to anything other than 'All Traffic' or 'All TCP', I get an error response from my website: Unable to connect to the database: Connection timed out. 2002. I've tried using every option available and always get this result. I'm also getting an unexpected result from the NACL attached to the private subnets: If I deny all access (i.e. delete all rules other than the default 'deny all' rule) for both inbound and outbound traffic, the website continues to function correctly (provided the inbound rule on the public subnet's NACL is set to 'All Traffic' or 'All TCP').
A similar question has been asked here but the answer was essentially to not bother using NACLs, rather than an explanation of how to use them correctly. I'm studying for an AWS Solutions Architect certification so obviously need to understand their usage and in my real-world example, none of AWS' recommended NACL settings work.
I know this is super late but I found the answer to this because I keep running into the same issue and always try to solve it with the ALL TRAFFIC rule. However, no need to do that anymore; it's answered here. The Stack Overflow answer provides the link to an AWS primary source that actually answers your question.
Briefly, you need to add a Custom TCP Rule to your outbound NACL and add the port range 1024 - 65535. This will allow the clients requesting access through the various ports to receive the data requested. If you do not add this rule, the outbound traffic will not reach the requesting clients. I tested this through ICMP (ping), ssh (22) http (80) and https (443).
Why do the ports need to be added? Apparently, AWS sends out traffic through one of the ports between 1024 and 63535. Specifically, "When a client connects to a server, a random port from the ephemeral port range (1024-63535) becomes the client's source port." (See second link.)
The general convention around ACLs is that because they are stateless, incoming traffic is sent back out through the mandatory corresponding port, which is why most newbies (or non hands on practitioners like me) may miss the "ephemeral ports" part of building custom VPCs.
For what it's worth, I went on to remove all the outgoing ports and left just the ephemeral port range. No outgoing traffic was allowed. It seems like either the ACL still needs those ports listed so it can send traffic requested through those ports. Perhaps the outgoing data, first goes through the appropriate outgoing port and then is routed to the specific ephemeral port to which the client is connected. To verify that the incoming rules still worked, I was able to ssh into an EC2 within a public subnet in the VPC, but was not able ping google.com from same.
The alternative working theory for why outgoing traffic was not allowed is because the incoming and matching outgoing ports are all below 1024-63535. Perhaps that's why the outgoing data is not picked up by that range. I will get around to configuring the various protocol (ssh, http/s, imcp) to higher port numbers,, within the range of the ephemeral ports, to continue to verify this second point.
====== [Edited to add findings ======
As a follow up, I worked on the alternate theory and it is likely that the outgoing traffic was not sent through the ephemeral ports because the enabled ports (22, 80 and 443) do not overlap with the ephemeral port range (1024-63535).
I verified this by reconfiguring my ssh protocol to login through port 2222 by editing my sshd_config file on the EC2 (instructions here. I also reconfigured my http protocol to provide access through port 1888. You also need to edit the config file of your chosen webserver, which in my case was apache thus httpd. (You can extrapolate from this link). For newbies, the config files will be generally found in the etc folder. Be sure to restart each service on the EC2 ([link][8] <-- use convention to restart ssh)
Both of these reconfigured port choices was to ensure overlap with the ephemeral ports. Once I made the changes on the EC2, I then changed the security group inbound rule, removed 22, 80 and 443 and added 1888 and 2222. I then went to the NACL and removed the inbound rules 22, 80 and 443 and added 1888 and 2222. [![inbound][9]][9]For the NACL, I removed the outbound rules 22, 80 and 443 and just left the custom TCP rule and add the ephemeral ports 1024-63535.[![ephemeral onnly][10]][10]
I can ssh using - p 2222 and access the web server through 1888, both of which overlap with ephemeral ports.[![p 1888][11]][11][![p2222][12]][12]
[8]: https://(https://hoststud.com/resources/how-to-start-stop-or-restart-apache-server-on-centos-linux-server.191/
[9]: https://i.stack.imgur.com/65tHH.png
[10]: https://i.stack.imgur.com/GrNHI.png
[11]: https://i.stack.imgur.com/CWIkk.png
[12]: https://i.stack.imgur.com/WnK6f.png
I'm setting up Qualys scanner in Amazon Web Services in an environment that restricts outbound access to the internet from the VPC. It does so completely.
So I'll need to open a ticket to get the outbound access it needs, and I have to specify each IP that the Qualys server will need to connect to.
I'm seeing this message in the logs:
Starting crond:
Preparing scanner personalization
About to test connectivity to qualysguard.qualys.com
Error: No connectivity to qualysguard.qualys.com - please fix.
About to test connectivity to qualysguard.qualys.com
My question is, do I need to open up access to just that one domain? Or do I have to open up access to more than that one domain. I have to be specific and cannot use wildcards in the request. This environment is extremely locked down for security reasons.
There are several ways you can restrict the access of your environment but also to allow certain ports.
AWS does not resolve on DNS names, so make sure you get the set of IP addresses that are to be allowed for access
Use ELB - allow certain ports and permit access for those ports/ip addresses
Port address translation - look in for applications that will allow particular ports from a set of ip addresses
move your application to public subnet and allow the specific port/ip addresses
I've been using AWS for a few months without any problem. But from yesterday, I can't access the website. When I ping the IP (52.24.23.108) it displays request time out. Server's status is okay - that I checked from AWS console. Isn't it a network problem of Amazon Webservices?
You need to enable the specified network traffic type (ICMP) through your security groups for your instance. You can do this by choosing Security Groups > select your security group and choose Edit Inbound Rules
Choose "ICMP" from the dropdown and source (* if you want it from everywhere) then Add Rule
PINGs should work!
A couple things could cause this, most likely you provisioned the instance with a public IP, by NOT a n elastic IP. If you had a server restart, either by your doing or by AWS, then your public IP would be dropped. If you did use a elastic IP, then look at your security group to see if you allow icmp still or if the security group changed.
Another cause may be if a server level firewall had been disabled in the past, but if your server went through a restart it may have started again. What base OS are you using?
I have followed the steps provided by Amazon EC2. I have installed a wordpress website in the EC2 Instance.
My public DNS is given as ec2-xx-xxx-xx-xxx.us-west-2.compute.amazonaws.com/
and Public IP is also given as xx-xxx-xx-xxx.
How to view the website from any other machine?
Note:
EC2 Instance is created and running now.
I can view it in the localhost as well as public DNS in the EC2 instance using RDP. (http://ec2-xx-xxx-xx-xxx.us-west-2.compute.amazonaws.com/)
If you can see the web site from the EC2 instance, but not from other machines, there is probably one of the following things wrong:
The DNS entry is not available or is wrong. Since you can RDP using that entry, this can't be the cause.
Access to the correct port is being blocked by the security group or firewall. Since the instructions you referenced specifically say to make sure that both port 80 (HTTP) and 3389 (RDP) are open, and you know that is true from port 3389, this isn't likely, but is possible. Make sure that there are security group rules for both port numbers that look the same.
The Windows server itself is refusing to allow outside access to port 80 on that address. This is unlikely, but not impossible, and the instructions specify that you should "disable Internet Explorer Enhanced Security Configuration", and at the end cover "Making Your WordPress Site Public". Make sure that the web server isn't configured to only respond to requests from localhost (127.0.0.1) and that there are no Windows firewall rules blocking port 80.
I think that the likeliest problem is number 2, above. Perhaps you forgot to open port 80 in the security group, or typed a different port number or a different address range to open it to.