self referencing aws security groups - amazon-web-services

my application has ELB, NGNIX and ECS in the web component layer and I am grouping all of them in to one security group and there is internal communication between ELB, NGNIX and ECS. I wanted to create self referential ports for the communication between these three, do i have to write self ingress rule or self outgress rule for this communication is the internal communication between these three inbound or outbound?

The default Outbound security groups permit all traffic, so never change them unless you have a specific network requirement (such as enforcing additional restrictions to meet compliances).
You can configure a Security Group to permit Inbound connections from itself (that is, the security group has its own ID as the Source of the inbound connection). This would enable any Amazon EC2 instance that is associated with the security group to communicate with any other Amazon EC2 instance that is associated with the same security group (on the given port).
The important thing to note is that security groups are enforced at the instance level rather than traditional firewalls that work at the network level. Thus, there is no concept of multiple instances being "inside a security group". Rather, the security group is applied against traffic as it goes into each instance. Thus, the need to allow incoming connections from 'itself'.

A security group can be made to allow traffic from itself, however the SecurityGroup resource and its ingress rule need to be separated to avoid a circular dependency. For example;
ConsumerSG:
Type: 'AWS::EC2::SecurityGroup'
Properties:
VpcId: !ImportValue EnvVpc
GroupDescription: !Sub 'Security group which grants access to consuming apps'
ConsumerSGIngress:
Type: 'AWS::EC2::SecurityGroupIngress'
DependsOn: ConsumerSG
Properties:
GroupId: !Ref ConsumerSG
IpProtocol: tcp
FromPort: '5000'
ToPort: '5000'
SourceSecurityGroupId: !Ref ConsumerSG
This creates a security group which allows access from itself on port 5000

Sure, you will need an ingress rule with the port that the apps is listening.
By default egress is allow all for security group and sg is stateful so you don't need ingress rule for outgoing traffic to return

Related

Configure interdependent security groups in AWS VPC

In the AWS VPC, I added a security group for the database access that allows any request from a specific CIDR IP on port 3306. This CIDR IP includes private subnets as well as public subnets. A public subnet is allowed so that database can explicitly be connected to developers machines using bastion host (EC2 instance configured on VPC's public subnet and assigned an IP from Amazon's pool of public IPs).
Ideally, services on a private subnet should able to connect to a database.
Rather than defining the network mask from where the connection is allowed in one security group, is there any elegant way to do it (probably by creating two security groups as defined in this AWS document)?
Database should connect only on 3306 port but services should be allowed to use any port for the database access. How to configure a security group to achieve this? For example, one security group that allows requests on only 3306 port (this security group can be attached to the database). And, another security that allows connection to all ports (this security group can be attached to microservices instances). Somehow this microservice security group should be mapped to a database security group in such a way that no matter on what port request is coming from it should in turn call database security group on 3306 port. Can this be done?
Tried something along this line:
DBConnectableSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
VpcId: ...
GroupDescription: Allows for connection to the DB cluster.
ServerlessDBSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
VpcId: ...
GroupDescription: Defines rules for connecting to the DB cluster.
OutboundRule:
Type: AWS::EC2::SecurityGroupEgress
Properties:
IpProtocol: tcp
FromPort: 0
ToPort: 65535
DestinationSecurityGroupId: !GetAtt ServerlessDBSecurityGroup.GroupId
GroupId: !GetAtt DBConnectableSecurityGroup.GroupId
InboundRule:
Type: AWS::EC2::SecurityGroupIngress
Properties:
IpProtocol: tcp
FromPort: 3306
ToPort: 3306
SourceSecurityGroupId: !GetAtt DBConnectableSecurityGroup.GroupId
GroupId: !GetAtt ServerlessDBSecurityGroup.GroupId
App-SG -- Inbound Rule
DB-SG -- Inbound Rule (source is pointing to App-SG)
App-SG and DB-SG -- Outbound Rule
Now I associate App-SG with an application. This application can successfully connect to the database on port 3306 (same as configured in Inbound Rule of DB-SG).
I associate App-SG with another application. This application uses a different port to connect to the database, port 3310. As App-SG allows all ports, I expect this to connect to the database but this does not work and the connection is refused.
The preferred configuration is:
A security group on the application resource (App-SG) with appropriate inbound permissions to use the application, and the default All Outbound permissions
A security group on the database (DB-SG) that permits inbound connections on the database port from App-SG and All Outbound
That is, DB-SG specifically references App-SG in its inbound rules. This way, any resource that is associated with App-SG will be allowed to communicate with the database. This method avoids having to specify IP address and CIDR ranges and any new resources that use App-SG will automatically gain access to the database.

How do I make my security group accessible only to my IP address?

I have an EC2 instance for running RServer. I've set up my security group, but AWS sent me a warning saying that my EC2 instance is accessible to anyone in the world.
This is my setup.
I have a VPC with IPv4 CIDR 10.0.0.0/16.
I have two subnets, each in a different availability zone. They are both associated with the VPC.
They both have these same rules.
They are both connected with the same internet gateway, which is also attached to the VPC.
For route tables, they both have 10.0.0.0/16 with target local.
They also have a connection with another route table. Each of them connects with a different route table.
The first connects with route table A, which has two routes. It has 10.0.0.0/16 local active Propagated: No and 0.0.0.0/0 active Propagated: No. The second route is connected with the same internet gateway as the VPC.
The second subnet connects with route table B, which has the same routes as route table A.
I also have a security group. It is associated with the VPC. It has three inbound rules. The first one is type: SSH, Protocol: TCP, Port Range: 22 and source as my personal ip address followed by /32.
The second one is for RStudio Server and is type: Custom TCP Rule, Protocol: TCP, Port Range: 0.0.0.0/0 and the third one is also for RStudio Server and is type: Custom TCP Rule, Protocol: TCP, Port Range: ::/0.
I also have a network ACL which has default settings. It allows all inbound and outbound traffic.
I think you have typo for the RStudio IP range, which is 0.0.0.0/0, why don't restrict to limited IPs rather than global accessible? Even if it's TCP, you still need to limit the IP range
The pictures you have provided are for Network Access Control Lists (NACLs), not Security Groups. In general, you should never change the NACL configuration unless you really understand networking.
Rather, you should configure your Security Group to only permit inbound access from your IP address on the desired ports.

AWS Cloudformation: Security Group Rule to allow all egress

I am using the following egress rule in a security group definition of a cloudformation template
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 0
ToPort: 65535
CidrIp: 0.0.0.0/0
However this does not end up in a rule that allow all outbound traffic;
What is the proper way to define an allow-all-outbound rule?
This is an old thread, but people still find it in searches... True, there are times the default doesn't work well, such as when using cfn_nag_scan to scan the cft.
Here is what you are looking for:
SecurityGroupEgress:
- Description: Allow all outbound traffic
IpProtocol: "-1"
CidrIp: 0.0.0.0/0
I must add this info from the AWS documentation, as defining such a policy might not be necessary,
"When you create a VPC security group, Amazon EC2 creates a default egress rule that allows egress traffic on all ports and IP protocols to any location. The default rule is removed only when you specify one or more egress rules. "
here's the link,
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-security-group.html#w2ab1c21c10d473c17
Typically, you define some specific port/protocol.

At least one security group must open all ingress ports. AWS Glue connecting to RDS

I am still starting out with AWS Glue and I am trying to connect it to my publicly accessible MySql database hosted on RDS Aurora to get its data.
So I start by creating a crawler and in the data store I create a new connection as in the screenshot below:
I go through the rest and eventually try to run the crawler but I get the following error: At least one security group must open all ingress ports.To limit traffic, the source security group in your inbound rule can be restricted to the same security group
I am not sure what I need to change in the security group attached to the RDS but here's what I have right now for the inbound rules:
You'll notice that I have a self-referencing rule in there that's pointing to the same security group.
The outbound rules are going to all traffic.
Any idea what I might be doing wrong?
The inbound rule (Glue Connection security group) is set to allow TCP Port 0 to allow traffic. Instead, it should allow ALL traffic. Edit your rules, and where there's a dropdown that says "Custom TCP Rule", and change it to "All TCP".
The documentation explains how to setup the security group
You need to set a new rule in the security group that is attached to your DB instances where you define:
Type: All TCP
Protocol: TCP
Range: 0 - 65535
Source: Custom sg-(the
id of this/self security group)
Description: whatever you want
To solve the second error mentioned above in the comments (VPC S3 endpoint validation failed for SubnetId: subnet-1944ab40. VPC: vpc-c8605bad. Reason: Could not find S3 endpoint or NAT gateway for subnetId: subnet-1944ab40 in Vpc vpc-c8605bad) you have to create an Amazon VPC Endpoints for Amazon S3.
https://docs.aws.amazon.com/glue/latest/dg/vpc-endpoints-s3.html
I found #David I. Rock solution to be working but has the inconvenience to stop connections via SQL Clients.
On top of that I also added the inbound rule:
Type: MYSQL / Aurora
Protocol: TCP (automatically generated)
Port Range: 3306 (automatically generated)
Source: My IP (or adapt to your requirements)

AWS VPC Setup for RDS access

I am setting up a RDS Maria database on AWS however am unable to get the security settings correct to access it from a non-AWS PC. It is on a VPC in us-west-2b with the following settings:
Subnet Group: Default
Subnets: us-west-2a; us-west-2b; us-west-2c
Security Group: rds-launch-wizard
Publically Accessible: Yes
Encryption Enabled: No
All the subnets have the same Network ALC Settings:
Inbound Rules: <my ip>/32:3306 ALLOW; 0.0.0.0/0:ALL DENY
Outbound Rules: 0.0.0.0/0:3306 ALLOW; 0.0.0.0/0:ALL DENY
The Security group has the same inbound and outbound rules:
Inbound Rules: <my ip>/32:3306 ALLOW; 0.0.0.0/0:ALL DENY
Outbound Rules: 0.0.0.0/0:3306 ALLOW; 0.0.0.0/0:ALL DENY
There is a (default setup) Internet Gateway applied to the VPC. I have not added any subnet associations to the route table.
The database is online. Are there any additional settings which I should be looking at.
Thanks!
You should not limit the port in Subnet Network ACL Outbound Rules, just leave 0.0.0.0/0 ALLOW (that is because the clients will use the random port to connect to mysql). Also, Subnet Network ACL is usually not used for limiting access to resources, only security groups.
In Security group, again do not modify Outbound rules, leave All traffic All All 0.0.0.0/0.
Finally, there are no DENY rules in Security Group settings, please double check which screen are you getting the above rules from?