I have a Webserver in a VPC that will occasionally use curl to get or post a resource from itself, using one of the domains associated to that server. I have a restrictive security group assigned to this server, as I only want to allow traffic from specific IP ranges. Additionally, I added the security group itself as a source of inbound traffic, in order to deal with the curl calls.
Unfortunately this isn't working. The connections timeout. Using wget from command-line on the server's IP or one of the domains goes timeout too. The only way to fix it is to allow traffic from '0.0.0.0/0' on the security group, which I don't want to do.
As a workaround I've added '127.0.0.1' entries for every domain to the hosts file, but this isn't a long term solution for me.
Is any help to fixe?
The traffic is basically going out to the internet and back, which means it is leaving the VPC, so it is no longer identified as coming from within the Security Group. To allow traffic from a Security Group, that traffic has to be addressed to the Private IP address, not the public IP or domain name.
One way to do this is add hosts file entries like you have done. You could also create a private hosted zone in Route53 and assign it to the VPC, then override certain DNS records within your VPC to route to the private IP address.
Related
I've been trying to create and connect to a new DB on AWS for days. I made it publicly accessible.
I've done this but it can't connect:
HOST: vepo-qa-database.xxxxxxx.ap-southeast-2.rds.amazonaws.com
URL: jdbc:postgresql://vepo-qa-database.xxxxxxx.ap-southeast-2.rds.amazonaws.com:5432/
Why will it not connect?
Your Security Group inbound rule configuration is:
Allow Inbound traffic on any port as long as it comes from sg-1fefe550 (itself!)
This means that only resources associated with that same security group can communicate with the database. Therefore, it is blocking access from your own computer on the Internet.
To enable access to the database, you should add another Inbound rule that permits inbound access on port 5432 (PostgreSQL) from your own IP address.
(I'm also not sure why you have configured the security group to permit access from 'itself'. This is not a normal way to configure security groups.)
There is not enough information in your question to be certain, but here are two suggestions:
1 - verify that the subnets for the database actually are public and that there is a route to the IGW
2 - add a rule to the inbound security group rules to allow you to connect to port 5431. Generally you'd want to restrict this to just your IP address for a public instance.
Also, I'm not sure why you have 192.31.0.0 as part of your VPC range - that is a public IP range.
Summary
I'd like to lock down access to an ALB to only allow connections from a given source security group in a different VPC and using a CNAME, NOT its AWS provided DNS name
Further Information
I've peered the source VPC and VPC containing the target ALB
I've tried assigning a security group to the ALB allowing access from the source security group over the target ports, but that does not seem to provide access
I'm pretty sure the issue boils down to the usage of the non-internal DNS name for the ALB, resulting in IP resolving to the public - not private - IP of the ALB. What is the best way to achieve access restriction to the ALB while still using it's non-internal DNS name? Do I need to spin up an internal DNS server?
I created an EC2 instance with apache installed on it and allowed HTTP/SSH traffic for my system only. I was able to access Web page using public IP of EC2. Then I configured ALB with same SG, registered same EC2 instance with ALB. Tried to access Web page using DNS name of ALB, got error -504 Gateway Time-out.
Increased time out interval to see if this resolves issue, didn't work. Then I revisited lesson and thought lets allow HTTP traffic to everyone(since it was allowed in lecture) in SG to see if it works and YES, it worked. I again changed SG to allow traffic only for my system and it failed again.
In this configuration, your security group needs to allow traffic from itself -- create rules that allow the appropriate ports, but use the security group sg-xxxx in place of an IP address, as the source. Merely being members of the same security group does not allow two systems to communicate with each other.
A better configuration would be for the balancer to have its own security group, and your instance's group would allow traffic from the balancer's group.
Note also that without the security group configuration being correct, you should also find that the health checks on the balancer are failing.
I am seeking some guidance on the best approach to take with EC2 security groups and services with dynamic IP's. I want to make use of services such as SendGrid, Elastic Cloud etc which all use dyanmic IP's over port 80/443. However access to Port 80/443 is closed with the exception of whitelisted IPs. So far the solutions I have found are:
CRON Job to ping the service, take IP's and update EC2 Security Group via EC2 API.
Create a new EC2 to act as a proxy with port 80/443 open. New server communicates with Sendgrid/ElasticCloud, inspects responses and returns parts to main server.
Are there any other better solutions?
Firstly, please bear in mind that security groups in AWS are stateful, meaning that, for example, if you open ports 80 and 443 to all destinations (0.0.0.0/0) in your outbound rules, your EC2 machines will be able to connect to remote hosts and get the response back even if there are no inbound rules for a given IP.
However, this approach works only if the connection is always initiated by your EC2 instance and remote services are just responding. If you require the connections to your EC2 instances to be initiated from the outside, you do need to specify inbound rules in security group(s). If you know a CIDR block of their public IP addresses, that can solve the problem as you can specify it as a destination in security group rule. If you don't know IP range of the hosts that are going to reach your machines, then access restriction at network level is not feasible and you need to implement some form of authorisation of the requester.
P.S. Please also bear in mind that there is a soft default limit of 50 inbound or outbound rules per security group.
I have 2 AWS instances, i-1 and i-2. They are each on a different security group: sg-1 and sg-2, respectively. Both machines have elastic IPs.
sg-2 is configured to allow all traffic from sg-1, regardless of port, source IP or protocol.
When i-1 tries to talk to i-2 its traffic is being blocked. It seems AWS doesn't account for the fact that i-1's traffic is actually coming from its elastic IP.
Is this expected? Is there anything I can do to work around it, apart from manually adding i-1's elastic IP to sg-2?
sg-2 is configured to allow all traffic from sg-1
When you do this, only traffic from Private IP address is allowed. However, as you as using EIP, you explicitly need to allow traffic from that ip address.
Read this: https://forums.aws.amazon.com/thread.jspa?messageID=414060
Quoting from above link:
Out of curiosity, are you perhaps connecting using a public IP address? When you use a rule with a security group as the source, it will only match when connecting over the internal network. The private IP address can change though. If you have an Elastic IP associated with the instance, the public DNS name happens to be static and will always resolve to the current private IP address when used from within the same EC2 region. That allows you to easily connect internally without worrying about any address changes.
You haven't really provided enough information to diagnose the problem, but there are a few things to check:
Is I-1 definitely in SG-1? If you've got the instances muddled, the SG rules would be around the wrong way.
Does the machine in SG-2 have a firewall running that might be blocking incoming traffic even though the SG rules are allowing it?
You've tagged this with the VPC tag - do you have any network ACL settings that might be preventing traffic flow? Are the machines private, using a NAT appliance to get out to the Internet, or public, routing through the standard AWS gateway? Can I-1 see the Internet? If you're routing through a NAT, assigning an EIP to a machine effectively cuts it off from the Internet because EIP and NAT are mutually incompatible, and although I haven't tried it this might also screw up SG routing.
Does SG-1 have any egress rules that might be preventing traffic from leaving?
The answer to your question is likely to be found in the resolution of one of these questions if the answer to any of them is 'Yes'.
As previously stated by slayedbylucifer, you will need to explicitly allow traffic from the EIP.
Here's the reasoning from the official AWS documentation about Security Groups:
When you specify a security group as the source for a rule, traffic is allowed from the network interfaces that are associated with the source security group for the specified protocol and port. Incoming traffic is allowed based on the private IP addresses of the network interfaces that are associated with the source security group (and not the public IP or Elastic IP addresses).