AWS - VPC Security - Security Group

• AWS - Security Group

---

AWS - Security Group

---

• acts as a virtual firewall for instance network interface
  • the first layer of protection around instances.
  • Specifically security groups operate at the network interface level.
• act at the instance level, not subnet level.
  • So each instance in a subnet in VPC can be assigned to a different set of security groups.
  • At the most basic level, a security group is a way to filter traffic to instances.
• controlling inbound and outbound traffic for one or more instances.
  • use rules to control traffic, filter based network protocols.
  • use an entire CIDR block or another security group to create layers of security to define who or what has access to assets.
  • cannot delete the security group that’s created by default within a VPC
  • can use security group names as the source or destination in other security groups.
  • can use the security group name as a source in its own inbound rules.
  • Security group members can be within any AZ or subnet within the VPC.
  • Security group membership can be changed whilst instances are running.
  • Any changes made will take effect immediately.
• security groups spans Availability Zones.
  • Security groups can be shared across:
    • AWS accounts in the same region
    • two VPCs in the same region
    • multiple EC2s instances in a VPC
  • possible to combine security groups within a VPC.
    • By allowing another security group, you’ll not only combine rules but also allow other users to access resource.
    • Apply multiple security groups within the same VPC to an EC2
  • limit
    • Up to 5 security groups per EC2 instance interface.
      • a single Elastic Network Interfaces (ENI)
    • no limit on the number of EC2 instances within a security group.
• Security groups have rules control the inbound and outbound traffic.
  • By default includes an outbound rule that allows all outbound traffic.
  • access is determined by the traffic type (such as HTTP/S, SSH), protocol (such as ALL/TCP/UDP), port range, source, and optional description.
  • 
• stateful
  • state information is kept even after a request is processed.
  • request from instance, the response traffic is allowed to flow in regardless of inbound security group rules.
  • Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.
  • Automatically allow EC2s inbound response traffic based on its outbound request
    • if inbound request is allowed, the outbound response is allowed automatically.
    • if send a request from instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules.
  • initiate an HTTP request to instance from home computer,
    • inbound security group rules allow HTTP traffic, information about the connection (source IP address, port number) is tracked.
    • The HTTP response from instance to home computer is recognized as part of an established connection
    • allowed through the security group
    • even if the security group rules restrict outbound HTTP Traffic.

• custom security group, specify allow rules, not deny rules

• All rules are evaluated before the decision to allow traffic.

• When create a Security Group, it has no inbound rules
  • can add allow rules, not deny rules
  • By default will deny all incoming traffic. allow all outbound traffic.
    • By default, default security groups do have inbound allow rules (allowing traffic from within the group).
    • By default, custom security groups do not have inbound allow rules (all inbound traffic is denied by default).
  • there is an implicit deny rule at the end of the security group
    • All rules are evaluated until a permit is encountered or continues until the implicit deny.
    • cannot block specific IP addresses using security groups, use NACLs instead.
  • not to make security groups too complex.
    • Modifying the default outbound rule increases complexity
    • not recommended unless it’s required for compliance.
  • create inbound rules for each functional tier (web, application, and data) within an application.
    • chain of security groups rules per application tier.
    • The inbound and outbound rules are set up so that traffic can only flow from the top tier to the bottom tier, and back up again.
    • The security groups act as firewalls that prevent a security breach in one tier from automatically providing subnet-wide access to all resources in the compromised client.
    • web tier Elastic Load Balancing security group.
    • It’s allowed to talk to the web tier security group over port 80, but that traffic has to come from the web tier elastic load balancer. The traffic can’t come directly from the internet and access the web tier security group and its servers.
    • The third tier is the application tier elastic load balancer, only accepts traffic that comes from the web tier security group over port 8080.
    • The application tier security group servers will only accept traffic that comes from the application tier elastic load balancer group from port 8080.
    • Finally, get to the data tier, only accept inbound traffic from the application tier over port 3306.
    • With this kind of security chaining, someone from the internet can’t get beyond the web tier load balancer security group.
• receive an alert about an issue between an application and the database servers.
  • Since the issue is communication between the application and server, should check security group rules since security groups control access at the instance ENI level.

{
	"tags": [
		{
			"key": "Name",
			"value": "value"
		},
	],
	"vpcId": "vpc-abc",
	"region": "us-1",
	"groupId": "sg-123",
	"ownerId": "123",
	"isShared": false,
	"groupName": "sg123",
	"description": "hi",
	"ipPermissions": [
		{
			"toPort": 1,
			"fromPort": 2,
			"ipRanges": [],
			"ipProtocol": "tcp",
			"ipv4Ranges": [],
			"ipv6Ranges": [],
			"prefixListIds": [],
			"userIdGroupPairs": [
				{
					"userId": "123",
					"groupId": "sg-123",
					"description": "xxx"
				}
			]
		},
		{
			"toPort": 22,
			"fromPort": 22,
			"ipRanges": [
				"0.0.0.0/16"
			],
			"ipProtocol": "tcp",
			"ipv4Ranges": [
				{
					"cidrIp": "0.0.0.0/16",
					"description": "xxx"
				}
			],
			"ipv6Ranges": [],
			"prefixListIds": [],
			"userIdGroupPairs": []
		},
	],
	"ipPermissionsEgress": [
		{
			"ipRanges": [
				"0.0.0.0/0"
			],
			"ipProtocol": "-1",
			"ipv4Ranges": [
				{
					"cidrIp": "0.0.0.0/0"
				}
			],
			"ipv6Ranges": [],
			"prefixListIds": [],
			"userIdGroupPairs": []
		}
	]
}