Nacl aws

Nacl aws DEFAULT

Ephemeral ports on AWS Web server NACL Rule

I am new to AWS and have been experimenting with NACL rules. I went through Amazon VPC NACL default rules evaluation order to understand how NACL rules work.

I've created a test EC2 instance (with NGINX) in a public subnet with some Elastic IP. I have added EC2 to the default security group, which allows all traffic on all ports. I initially configured NACL to block all traffic. This worked fine because I was not able to SSH into or HTTPS my instance. My goal is to let /0 HTTP port 80 into my instance.

Understanding that NACLs are stateless, I added communication to/from /0 on all TCP ports. This worked fine.

Now, I thought of restricting inbound and outbound to Port However, using this, I wasn't able to access test NGINX page.

This doesn't work

I noticed that if I change the outbound rule to allow all ports, I am able to access the NGINX page. I am not sure why this is happening.

Here's the new config: enter image description here

Do I need to add ephemeral ports as well? https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports

Sours: https://stackoverflow.com/questions//ephemeral-ports-on-aws-web-server-nacl-rule

VPC Overview & Components

~ Last updated on : ~ jayendrapatil ~

  • A virtual private cloud (VPC) is a virtual network dedicated to the AWS account. It is logically isolated from other virtual networks in the AWS cloud.
  • VPC allows the user to select IP address range, create subnets, and configure route tables, network gateways, and security settings.
  • VPC Sizing
    • VPC needs a set of IP addresses in the form of a Classless Inter-Domain Routing (CIDR) block for e.g, /16, which allows 2^16 () IP address to be available 
    • Allowed CIDR block size is between
      • /28 netmask (minimum with 2^4 – 16 available IP address) and
      • /16 netmask (maximum with 2^16 – IP address)
    • CIDR block from private (non-publicly routable) IP address can be assigned
      • – (10/8 prefix)
      • – (/12 prefix)
      • – (/16 prefix)
    • It’s possible to specify a range of publicly routable IP addresses; however, direct access to the Internet is not currently supported from publicly routable CIDR blocks in a VPC
    • NOTE – You can now resize VPC. Read AWS blog post.
    • Each VPC is separate from any other VPC created with the same CIDR block even if it resides within the same AWS account
  • VPC allows VPC Peering connections with other VPC within the same or different AWS accounts
  • Connection between your VPC and corporate or home network can be established, however the CIDR blocks should be not be overlapping for e.g. VPC with CIDR /16 can communicate with /16 corporate network but the connections would be dropped if it tries to connect to /16 corporate network cause of overlapping ip addresses.
  • VPC allows you to set tenancy option for the Instances launched in it. By default, the tenancy option is shared. If dedicated option selected, all the instances within it are launched on a dedicated hardware overriding the individual instance tenancy setting
  • Deletion of the VPC is possible only after terminating all instances within the VPC, and deleting all the components with the VPC for e.g. subnets, security groups, network ACLs, route tables, Internet gateways, VPC peering connections, and DHCP options
AWS VPC Components

IP Addresses

Instances launched in the VPC can have Private, Public and Elastic IP address assigned to it and are properties of ENI (Network Interfaces)

  • Private IP Addresses
    • Private IP addresses are not reachable over the Internet, and can be used for communication only between the instances within the VPC
    • All instances are assigned a private IP address, within the IP address range of the subnet, to the default network interface
    • Primary IP address is associated with the network interface for its lifetime, even when the instance is stopped and restarted and is released only when the instance is terminated
    • Additional Private IP addresses, known as secondary private IP address, can be assigned to the instances and these can be reassigned from one network interface to another
  • Public IP address
    • Public IP addresses are reachable over the Internet, and can be used for communication between instances and the Internet, or with other AWS services that have public endpoints
    • Public IP address assignment to the Instance depends if the Public IP Addressing is enabled for the Subnet.
    • Public IP address can also be assigned to the Instance by enabling the Public IP addressing during the creation of the instance, which overrides the subnet’s public IP addressing attribute
    • Public IP address is assigned from AWS pool of IP addresses and it is not associated with the AWS account and hence is released when the instance is stopped and restarted or terminated.
  • Elastic IP address
    • Elastic IP addresses are static, persistent public IP addresses which can be associated and disassociated with the instance, as required
    • Elastic IP address is allocated at an VPC and owned by the account unless released
    • A Network Interface can be assigned either a Public IP or an Elastic IP. If you assign an instance, already having an Public IP, an Elastic IP, the public IP is released
    • Elastic IP addresses can be moved from one instance to another, which can be within the same or different VPC within the same account
    • Elastic IP are charged for non usage i.e. if it is not associated or associated with a stopped instance or an unattached Network Interface

Elastic Network Interface (ENI)

  • Each Instance is attached with default elastic network interface (Primary Network Interface eth0) and cannot be detached from the instance
  • ENI can include the following attributes
    • Primary private IP address
    • One or more secondary private IP addresses
    • One Elastic IP address per private IP address
    • One public IP address, which can be auto-assigned to the network interface for eth0 when you launch an instance, but only when you create a network interface for eth0 instead of using an existing ENI
    • One or more security groups
    • A MAC address
    • A source/destination check flag
    • A description
  • ENI’s attributes follow the ENI as it is attached or detached from an instance and reattached to another instance. When an ENI is moved from one instance to another, network traffic is redirected to the new instance.
  • Multiple ENIs can be attached to an instance and is useful for use cases:
    • Create a management network.
    • Use network and security appliances in your VPC.
    • Create dual-homed instances with workloads/roles on distinct subnets.
    • Create a low-budget, high-availability solution.

Route Tables

  • Route table defines rules, termed as routes, which determine where network traffic from the subnet would be routed
  • Each VPC has a implicit router to route network traffic
  • Each VPC has a Main Route table, and can have multiple custom route tables created
  • Each Subnet within a VPC must be associated with a single route table at a time, while a route table can have multiple subnets associated with it
  • Subnet, if not explicitly associated to a route table, is implicitly associated with the main route table
  • Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted
  • Route priority is decided by matching the most specific route in the route table that matches the traffic
  • Route tables needs to be updated to defined routes for Internet gateways, Virtual Private gateways, VPC Peering, VPC Endpoints, NAT Device etc.

Internet Gateways – IGW

  • An Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in the VPC and the Internet.
  • IGW imposes no availability risks or bandwidth constraints on the network traffic.
  • An Internet gateway serves two purposes:
    • To provide a target in the VPC route tables for Internet-routable traffic,
    • To perform network address translation (NAT) for instances that have been NOT been assigned public IP addresses.
  • Enabling Internet access to an Instance requires
    • Attaching Internet gateway to the VPC
    • Subnet should have route tables associated with the route pointing to the Internet gateway
    • Instances should have a Public IP or Elastic IP address assigned
    • Security groups and NACLs associated with the Instance should allow relevant traffic

NAT

  • NAT device enables instances in a private subnet to connect to the Internet or other AWS services, but prevents the Internet from initiating connections with the instances.
  • NAT devices do not support IPv6 traffic, use an egress-only Internet gateway instead. 

Refer to My Blog Post about VPC NAT

Egress-only Internet gateway

  • Egress-only Internet gateway works as a NAT gateway, but for IPv6 traffic
  • Egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in the VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with the instances.
  • An egress-only Internet gateway is for use with IPv6 traffic only. To enable outbound-only Internet communication over IPv4, use a NAT gateway instead.

VPC & Subnet Sizing

  • VPC supports IPv4 and IPv6 addressing, and has different CIDR block size limits for each
  • IPv6 CIDR block can be optionally associated with the VPC
  • VPC IPv4 CIDR block cannot be modified once created i.e. cannot increase or decrease the size of an existing CIDR block.
  • However, secondary CIDR blocks can be associated with the VPC to extend the VPC
  • Limitations
    • allowed block size is between a  netmask and  netmask.
    • CIDR block must not overlap with any existing CIDR block that’s associated with the VPC.
    • CIDR block must not be the same or larger than the CIDR range of a route in any of the VPC route tables for e.g. for a CIDR block /24, can only associate smaller CIDR blocks like /25
Secondary VPC Limitations

VPC Security

Security within a VPC is provided through

  • Security groups – Act as a firewall for associated EC2 instances, controlling both inbound and outbound traffic at the instance level
  • Network access control lists (ACLs) – Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level
  • Flow logs – Capture information about the IP traffic going to and from network interfaces in your VPC

Security Groups & NACLs

Refer to My Blog Post about AWS Security Group vs NACLs

VPC Flow logs

  • VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in the VPC and can help in monitoring the traffic or troubleshooting any connectivity issues
  • Flow log data is stored using Amazon CloudWatch Logs
  • Flow log can be created for the entire VPC, subnets or each network interface. If enabled, for entire VPC or subnet all the network interfaces are monitored
  • Flow logs do not capture real-time log streams for network interfaces.
  • Flow logs can be created for network interfaces that are created by other AWS services; for example, Elastic Load Balancing, RDS, ElastiCache, Redshift, and WorkSpaces

Subnets

  • Subnet spans a single Availability Zone, distinct locations engineered to be isolated from failures in other AZs, and cannot span across AZs
  • Subnet can be configured with an Internet gateway to enable communication over the Internet, or virtual private gateway (VPN) connection to enable communication with your corporate network
  • Subnet can be Public or Private and it depends on whether it has Internet connectivity i.e. is able to route traffic to the Internet through the IGW
  • Instances within the Public Subnet should be assigned a Public IP or Elastic IP address to be able to communicate with the Internet
  • For Subnets not connected to the Internet, but has traffic routed through Virtual Private Gateway only is termed as VPN-only subnet
  • Subnets can be configured to Enable assignment of the Public IP address to all the Instances launched within the Subnet by default, which can be overridden during the creation of the Instance
  • Subnet Sizing
    • CIDR block assigned to the Subnet can be the same as the VPC CIDR, in this case you can launch only one subnet within your VPC
    • CIDR block assigned to the Subnet can be a subset of the VPC CIDR, which allows you to launch multiple subnets within the VPC
    • CIDR block assigned to the subnet should not be overlapping
    • CIDR block size allowed is between
      • /28 netmask (minimum with 2^4 – 16 available IP address) and
      • /16 netmask (maximum with 2^16 – IP address)
    • AWS reserves 5 IPs address (first 4 and last 1 IP address) in each Subnet which are not available for use and cannot be assigned to an instance. for e.g. for a Subnet with a CIDR block /24 the following five IPs are reserved
      • Network address
      • Reserved by AWS for the VPC router
      • Reserved by AWS for mapping to Amazon-provided DNS
      • Reserved by AWS for future use
      • Network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved.
  • Subnet Routing
    • Each Subnet is associated with a route table which controls the traffic.
  • Subnet Security
    • Subnet security can be configured using Security groups and NACLs
    • Security groups works at instance level, NACLs work at the subnet level

Shared VPCs

  • VPC sharing allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs.
  • In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations.
  • After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.

VPC Endpoints

Refer to My Blog Post about VPC Endpoint

VPC Peering

Refer to My Blog Post about VPC Peering

VPC VPN Connections & CloudHub

Refer to My Blog Post about AWS VPC VPN CloudHub Connections

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have a business-to-business web application running in a VPC consisting of an Elastic Load Balancer (ELB), web servers, application servers and a database. Your web application should only accept traffic from predefined customer IP addresses. Which two options meet this security requirement? Choose 2 answers
    1. Configure web server VPC security groups to allow traffic from your customers’ IPs (Web server is behind the ELB and customer IPs will never reach web servers)
    2. Configure your web servers to filter traffic based on the ELB’s “X-forwarded-for” header (get the customer IPs and create a custom filter to restrict access. Refer link)
    3. Configure ELB security groups to allow traffic from your customers’ IPs and deny all outbound traffic (ELB will see the customer IPs so can restrict access, deny all is basically have no rules in outbound traffic, implicit, and its stateful so would work)
    4. Configure a VPC NACL to allow web traffic from your customers’ IPs and deny all outbound traffic (NACL is stateless, deny all will not work)
  2. A user has created a VPC with public and private subnets using the VPC Wizard. The VPC has CIDR / The private subnet uses CIDR / Which of the below mentioned entries are required in the main route table to allow the instances in VPC to communicate with each other?
    1. Destination : /24 and Target : VPC
    2. Destination : /16 and Target : ALL
    3. Destination : /0 and Target : ALL
    4. Destination : /16 and Target : Local
  3. A user has created a VPC with two subnets: one public and one private. The user is planning to run the patch update for the instances in the private subnet. How can the instances in the private subnet connect to the internet?
    1. Use the internet gateway with a private IP
    2. Allow outbound traffic in the security group for port 80 to allow internet updates
    3. The private subnet can never connect to the internet
    4. Use NAT with an elastic IP
  4. A user has launched an EC2 instance and installed a website with the Apache webserver. The webserver is running but the user is not able to access the website from the Internet. What can be the possible reason for this failure?
    1. The security group of the instance is not configured properly.
    2. The instance is not configured with the proper key-pairs.
    3. The Apache website cannot be accessed from the Internet.
    4. Instance is not configured with an elastic IP.
  5. A user has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is true in this scenario?
    1. AWS VPC will automatically create a NAT instance with the micro size
    2. VPC bounds the main route table with a private subnet and a custom route table with a public subnet
    3. User has to manually create a NAT instance
    4. VPC bounds the main route table with a public subnet and a custom route table with a private subnet
  6. A user has created a VPC with public and private subnets. The VPC has CIDR / The private subnet uses CIDR /24 and the public subnet uses CIDR / The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port ). The user is configuring a security group of the NAT instance. Which of the below mentioned entries is not required for the NAT security group?
    1. For Inbound allow Source: /24 on port 80
    2. For Outbound allow Destination: /0 on port 80
    3. For Inbound allow Source: /24 on port 80
    4. For Outbound allow Destination: /0 on port
  7. A user has created a VPC with CIDR / The user has used all the IPs of CIDR and wants to increase the size of the VPC. The user has two subnets: public (/25) and private (/25). How can the user change the size of the VPC?
    1. The user can delete all the instances of the subnet. Change the size of the subnets to /32 and /32, respectively. Then the user can increase the size of the VPC using CLI
    2. It is not possible to change the size of the VPC once it has been created (NOTE – You can now increase the VPC size. Read Post)
    3. User can add a subnet with a higher range so that it will automatically increase the size of the VPC
    4. User can delete the subnets first and then modify the size of the VPC
  8. A user has created a VPC with the public and private subnets using the VPC wizard. The VPC has CIDR / The public subnet uses CIDR / The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port ). The user is configuring a security group for the public subnet (WebSecGrp) and the private subnet (DBSecGrp). Which of the below mentioned entries is required in the web server security group (WebSecGrp)?
    1. Configure Destination as DB Security group ID (DbSecGrp) for port Outbound
    2. Configure port 80 for Destination /0 Outbound
    3. Configure port for source /24 InBound
    4. Configure port 80 InBound for source /16
  9. A user has created a VPC with CIDR / The user has created one subnet with CIDR /16 by mistake. The user is trying to create another subnet of CIDR / How can the user create the second subnet?
    1. There is no need to update the subnet as VPC automatically adjusts the CIDR of the first subnet based on the second subnet’s CIDR
    2. The user can modify the first subnet CIDR from the console
    3. It is not possible to create a second subnet as one subnet with the same CIDR as the VPC has been created
    4. The user can modify the first subnet CIDR with AWS CLI
  10. A user has setup a VPC with CIDR / The VPC has a private subnet (/24) and a public subnet (/24). The user’s data centre has CIDR of /24 and / If the private subnet wants to communicate with the data centre, what will happen?
    1. It will allow traffic communication on both the CIDRs of the data centre
    2. It will not allow traffic with data centre on CIDR /24 but allows traffic communication on /24
    3. It will not allow traffic communication on any of the data centre CIDRs
    4. It will allow traffic with data centre on CIDR /24 but does not allow on /24 (as the CIDR block would be overlapping)
  11. A user has created a VPC with public and private subnets using the VPC wizard. The VPC has CIDR / The private subnet uses CIDR /24 . The NAT instance ID is i-a Which of the below mentioned entries are required in the main route table attached with the private subnet to allow instances to connect with the internet?
    1. Destination: /0 and Target: i-a
    2. Destination: /0 and Target: 80
    3. Destination: /0 and Target: i-a
    4. Destination: /24 and Target: i-a
  12. A user has created a VPC with CIDR /16 using the wizard. The user has created a public subnet CIDR (/24) and VPN only subnets CIDR (/24) along with the VPN gateway (vgw) to connect to the user’s data centre. The user’s data centre has CIDR / The user has also setup a NAT instance (i) to allow traffic to the internet from the VPN subnet. Which of the below mentioned options is not a valid entry for the main route table in this scenario?
    1. Destination: /24 and Target: i
    2. Destination: /0 and Target: i
    3. Destination: /12 and Target: vgw
    4. Destination: /16 and Target: local
  13. A user has created a VPC with CIDR / The user has created one subnet with CIDR /16 in this VPC. The user is trying to create another subnet with the same VPC for CIDR / What will happen in this scenario?
    1. The VPC will modify the first subnet CIDR automatically to allow the second subnet IP range
    2. It is not possible to create a subnet with the same CIDR as VPC
    3. The second subnet will be created
    4. It will throw a CIDR overlaps error
  14. A user has created a VPC with CIDR /16 using the wizard. The user has created both Public and VPN-Only subnets along with hardware VPN access to connect to the user’s data centre. The user has not yet launched any instance as well as modified or deleted any setup. He wants to delete this VPC from the console. Will the console allow the user to delete the VPC?
    1. Yes, the console will delete all the setups and also delete the virtual private gateway
    2. No, the console will ask the user to manually detach the virtual private gateway first and then allow deleting the VPC
    3. Yes, the console will delete all the setups and detach the virtual private gateway
    4. No, since the NAT instance is running
  15. A user has created a VPC with the public and private subnets using the VPC wizard. The VPC has CIDR / The public subnet uses CIDR / The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port ). The user is configuring a security group for the public subnet (WebSecGrp) and the private subnet (DBSecGrp). Which of the below mentioned entries is required in the private subnet database security group (DBSecGrp)?
    1. Allow Inbound on port for Source Web Server Security Group (WebSecGrp)
    2. Allow Inbound on port from source /16
    3. Allow Outbound on port for Destination Web Server Security Group (WebSecGrp.
    4. Allow Outbound on port 80 for Destination NAT Instance IP
  16. A user has created a VPC with a subnet and a security group. The user has launched an instance in that subnet and attached a public IP. The user is still unable to connect to the instance. The internet gateway has also been created. What can be the reason for the error?
    1. The internet gateway is not configured with the route table
    2. The private IP is not present
    3. The outbound traffic on the security group is disabled
    4. The internet gateway is not configured with the security group
  17. A user has created a subnet in VPC and launched an EC2 instance within it. The user has not selected the option to assign the IP address while launching the instance. Which of the below mentioned statements is true with respect to the Instance requiring access to the Internet?
    1. The instance will always have a public DNS attached to the instance by default
    2. The user can directly attach an elastic IP to the instance
    3. The instance will never launch if the public IP is not assigned
    4. The user would need to create an internet gateway and then attach an elastic IP to the instance to connect from internet
  18. A user has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is not true in this scenario?
    1. VPC will create a routing instance and attach it with a public subnet
    2. VPC will create two subnets
    3. VPC will create one internet gateway and attach it to VPC
    4. VPC will launch one NAT instance with an elastic IP
  19. A user has created a VPC with the public subnet. The user has created a security group for that VPC. Which of the below mentioned statements is true when a security group is created?
    1. It can connect to the AWS services, such as S3 and RDS by default
    2. It will have all the inbound traffic by default
    3. It will have all the outbound traffic by default
    4. It will by default allow traffic to the internet gateway
  20. A user has created a VPC with CIDR /16 using VPC Wizard. The user has created a public CIDR (/24) and a VPN only subnet CIDR (/24) along with the hardware VPN access to connect to the user’s data centre. Which of the below mentioned components is not present when the VPC is setup with the wizard?
    1. Main route table attached with a VPN only subnet
    2. A NAT instance configured to allow the VPN subnet instances to connect with the internet
    3. Custom route table attached with a public subnet
    4. An internet gateway for a public subnet
  21. A user has created a VPC with public and private subnets using the VPC wizard. The user has not launched any instance manually and is trying to delete the VPC. What will happen in this scenario?
    1. It will not allow to delete the VPC as it has subnets with route tables
    2. It will not allow to delete the VPC since it has a running route instance
    3. It will terminate the VPC along with all the instances launched by the wizard
    4. It will not allow to delete the VPC since it has a running NAT instance
  22. A user has created a public subnet with VPC and launched an EC2 instance within it. The user is trying to delete the subnet. What will happen in this scenario?
    1. It will delete the subnet and make the EC2 instance as a part of the default subnet
    2. It will not allow the user to delete the subnet until the instances are terminated
    3. It will delete the subnet as well as terminate the instances
    4. Subnet can never be deleted independently, but the user has to delete the VPC first
  23. A user has created a VPC with CIDR / The user has created a public subnet with CIDR /25 and a private subnet with CIDR / The user has launched one instance each in the private and public subnets. Which of the below mentioned options cannot be the correct IP address (private IP) assigned to an instance in the public or private subnet?
  24. A user has created a VPC with CIDR / The user has created public and VPN only subnets along with hardware VPN access to connect to the user’s datacenter. The user wants to make so that all traffic coming to the public subnet follows the organization’s proxy policy. How can the user make this happen?
    1. Setting up a NAT with the proxy protocol and configure that the public subnet receives traffic from NAT
    2. Setting up a proxy policy in the internet gateway connected with the public subnet
    3. It is not possible to setup the proxy policy for a public subnet
    4. Setting the route table and security group of the public subnet which receives traffic from a virtual private gateway
  25. A user has created a VPC with CIDR /16 using the wizard. The user has created a public subnet CIDR (/24) and VPN only subnets CIDR (/24) along with the VPN gateway (vgw) to connect to the user’s data centre. Which of the below mentioned options is a valid entry for the main route table in this scenario?
    1. Destination: /24 and Target: vgw
    2. Destination: /16 and Target: ALL
    3. Destination: /16 and Target: vgw
    4. Destination: /0 and Target: vgw
  26. Which two components provide connectivity with external networks? When attached to an Amazon VPC which two components provide connectivity with external networks? Choose 2 answers
    1. Elastic IPs (EIP) (Does not provide connectivity, public IP address will do as well)
    2. NAT Gateway (NAT) (Not Attached to VPC and still needs IGW)
    3. Internet Gateway (IGW)
    4. Virtual Private Gateway (VGW)
  27. You are attempting to connect to an instance in Amazon VPC without success You have already verified that the VPC has an Internet Gateway (IGW) the instance has an associated Elastic IP (EIP) and correct security group rules are in place. Which VPC component should you evaluate next?
    1. The configuration of a NAT instance
    2. The configuration of the Routing Table
    3. The configuration of the internet Gateway (IGW)
    4. The configuration of SRC/DST checking
  28. If you want to launch Amazon Elastic Compute Cloud (EC2) Instances and assign each Instance a predetermined private IP address you should:
    1. Assign a group or sequential Elastic IP address to the instances
    2. Launch the instances in a Placement Group
    3. Launch the instances in the Amazon virtual Private Cloud (VPC)
    4. Use standard EC2 instances since each instance gets a private Domain Name Service (DNS) already
    5. Launch the Instance from a private Amazon Machine image (AMI)
  29. A user has recently started using EC2. The user launched one EC2 instance in the default subnet in EC2-VPC Which of the below mentioned options is not attached or available with the EC2 instance when it is launched?
    1. Public IP address
    2. Internet gateway
    3. Elastic IP
    4. Private IP address
  30. A user has created a VPC with CIDR / The user has created a public subnet with CIDR / The user is trying to create the private subnet with CIDR / Which of the below mentioned statements is true in this scenario?
    1. It will not allow the user to create the private subnet due to a CIDR overlap
    2. It will allow the user to create a private subnet with CIDR as /25
    3. This statement is wrong as AWS does not allow CIDR /25
    4. It will not allow the user to create a private subnet due to a wrong CIDR range
  31. A user has created a VPC with CIDR /16 with only a private subnet and VPN connection using the VPC wizard. The user wants to connect to the instance in a private subnet over SSH. How should the user define the security rule for SSH?
    1. Allow Inbound traffic on port 22 from the user’s network
    2. The user has to create an instance in EC2 Classic with an elastic IP and configure the security group of a private subnet to allow SSH from that elastic IP
    3. The user can connect to a instance in a private subnet using the NAT instance
    4. Allow Inbound traffic on port 80 and 22 to allow the user to connect to a private subnet over the Internet
  32. A company wants to implement their website in a virtual private cloud (VPC). The web tier will use an Auto Scaling group across multiple Availability Zones (AZs). The database will use Multi-AZ RDS MySQL and should not be publicly accessible. What is the minimum number of subnets that need to be configured in the VPC?
    1. 1
    2. 2
    3. 3
    4. 4 (2 public subnets for web instances in multiple AZs and 2 private subnets for RDS Multi-AZ)
  33. Which of the following are characteristics of Amazon VPC subnets? Choose 2 answers
    1. Each subnet maps to a single Availability Zone
    2. A CIDR block mask of /25 is the smallest range supported
    3. Instances in a private subnet can communicate with the Internet only if they have an Elastic IP.
    4. By default, all subnets can route between each other, whether they are private or public
    5. Each subnet spans at least 2 Availability zones to provide a high-availability environment
  34. You need to design a VPC for a web-application consisting of an Elastic Load Balancer (ELB). a fleet of web/application servers, and an RDS database The entire Infrastructure must be distributed over 2 availability zones. Which VPC configuration works while assuring the database is not available from the Internet?
    1. One public subnet for ELB one public subnet for the web-servers, and one private subnet for the database
    2. One public subnet for ELB two private subnets for the web-servers, two private subnets for RDS
    3. Two public subnets for ELB two private subnets for the web-servers and two private subnets for RDS
    4. Two public subnets for ELB two public subnets for the web-servers, and two public subnets for RDS
  35. You have deployed a three-tier web application in a VPC with a CIDR block of / You initially deploy two web servers, two application servers, two database servers and one NAT instance tor a total of seven EC2 instances. The web, application and database servers are deployed across two availability zones (AZs). You also deploy an ELB in front of the two web servers, and use Route53 for DNS Web traffic gradually increases in the first few days following the deployment, so you attempt to double the number of instances in each tier of the application to handle the new load unfortunately some of these new instances fail to launch. Which of the following could the root caused? (Choose 2 answers) [PROFESSIONAL]
    1. The Internet Gateway (IGW) of your VPC has scaled-up adding more instances to handle the traffic spike, reducing the number of available private IP addresses for new instance launches.
    2. AWS reserves one IP address in each subnet’s CIDR block for Route53 so you do not have enough addresses left to launch all of the new EC2 instances.
    3. AWS reserves the first and the last private IP address in each subnet’s CIDR block so you do not have enough addresses left to launch all of the new EC2 instances.
    4. The ELB has scaled-up. Adding more instances to handle the traffic reducing the number of available private IP addresses for new instance launches
    5. AWS reserves the first four and the last IP address in each subnet’s CIDR block so you do not have enough addresses left to launch all of the new EC2 instances.
  36. A user wants to access RDS from an EC2 instance using IP addresses. Both RDS and EC2 are in the same region, but different AZs. Which of the below mentioned options help configure that the instance is accessed faster?
    1. Configure the Private IP of the Instance in RDS security group (Recommended as the data is transferred within the the Amazon network and not through internet – Refer link)
    2. Security group of EC2 allowed in the RDS security group
    3. Configuring the elastic IP of the instance in RDS security group
    4. Configure the Public IP of the instance in RDS security group
  37. In regards to VPC, select the correct statement:
    1. You can associate multiple subnets with the same Route Table.
    2. You can associate multiple subnets with the same Route Table, but you can’t associate a subnet with only one Route Table.
    3. You can’t associate multiple subnets with the same Route Table.
    4. None of these.
  38. You need to design a VPC for a web-application consisting of an ELB a fleet of web application servers, and an RDS DB. The entire infrastructure must be distributed over 2 AZ. Which VPC configuration works while assuring the DB is not available from the Internet?
    1. One Public Subnet for ELB, one Public Subnet for the web-servers, and one private subnet for the DB
    2. One Public Subnet for ELB, two Private Subnets for the web-servers, and two private subnets for the RDS
    3. Two Public Subnets for ELB, two private Subnet for the web-servers, and two private subnet for the RDS
    4. Two Public Subnets for ELB, two Public Subnet for the web-servers, and two public subnets for the RDS
  39. You have an Amazon VPC with one private subnet and one public subnet with a Network Address Translator (NAT) server. You are creating a group of Amazon Elastic Cloud Compute (EC2) instances that configure themselves at startup via downloading a bootstrapping script from Amazon Simple Storage Service (S3) that deploys an application via GIT. Which setup provides the highest level of security?
    1. Amazon EC2 instances in private subnet, no EIPs, route outgoing traffic via the NAT
    2. Amazon EC2 instances in public subnet, no EIPs, route outgoing traffic via the Internet Gateway (IGW)
    3. Amazon EC2 instances in private subnet, assign EIPs, route outgoing traffic via the Internet Gateway (IGW)
    4. Amazon EC2 instances in public subnet, assign EIPs, route outgoing traffic via the NAT
  40. You have launched an Amazon Elastic Compute Cloud (EC2) instance into a public subnet with a primary private IP address assigned, an internet gateway is attached to the VPC, and the public route table is configured to send all Internet-based traffic to the Internet gateway. The instance security group is set to allow all outbound traffic but cannot access the Internet. Why is the Internet unreachable from this instance?
    1. The instance does not have a public IP address
    2. The Internet gateway security group must allow all outbound traffic.
    3. The instance security group must allow all inbound traffic.
    4. The instance “Source/Destination check” property must be enabled.
  41. You have an environment that consists of a public subnet using Amazon VPC and 3 instances that are running in this subnet. These three instances can successfully communicate with other hosts on the Internet. You launch a fourth instance in the same subnet, using the same AMI and security group configuration you used for the others, but find that this instance cannot be accessed from the internet. What should you do to enable Internet access?
    1. Deploy a NAT instance into the public subnet.
    2. Assign an Elastic IP address to the fourth instance
    3. Configure a publically routable IP Address in the host OS of the fourth instance.
    4. Modify the routing table for the public subnet.
  42. You have a load balancer configured for VPC, and all back-end Amazon EC2 instances are in service. However, your web browser times out when connecting to the load balancer’s DNS name. Which options are probable causes of this behavior? Choose 2 answers
    1. The load balancer was not configured to use a public subnet with an Internet gateway configured
    2. The Amazon EC2 instances do not have a dynamically allocated private IP address
    3. The security groups or network ACLs are not property configured for web traffic.
    4. The load balancer is not configured in a private subnet with a NAT instance.
    5. The VPC does not have a VGW configured.
  43. When will you incur costs with an Elastic IP address (EIP)?
    1. When an EIP is allocated.
    2. When it is allocated and associated with a running instance.
    3. When it is allocated and associated with a stopped instance.
    4. Costs are incurred regardless of whether the EIP is associated with a running instance.
  44. A company currently has a VPC with EC2 Instances. A new instance being launched, which will host an application that works on IPv6. You need to ensure that this instance can initiate outgoing traffic to the Internet. At the same time, you need to ensure that no incoming connection can be initiated from the Internet on to the instance. Which of the following would you add to the VPC for this requirement?
    1. A NAT Instance
    2. A NAT Gateway
    3. An Internet Gateway
    4. An egress-only Internet gateway

References

AWS_VPC_User_Guide

Like this:

LikeLoading

~ Last updated on : ~ jayendrapatil ~

  • In a VPC, both Security Groups and Network ACLs (NACLS) together help to build a layered network defence.
  • Security groups – Act as a virtual firewall for associated instances, controlling both inbound and outbound traffic at the instance level
  • Network access control lists (NACLs) – Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level

Security Groups vs NACLs

Security Groups

  • Acts at an Instance level and not at the subnet level.
  • Each instance within a subnet can be assigned a different set of Security groups
  • An instance can be assigned 5 security groups with each security group having 60 rules
  • allows separate rules for inbound and outbound traffic
  • allows adding or removing rules (authorizing or revoking access) for both Inbound (ingress) and Outbound (egress) traffic to the instance
    • Default Security group allows no external inbound traffic but allows inbound traffic from instances with the same security group
    • Default Security group allows all outbound traffic
    • New Security groups start with only an outbound rule that allows all traffic to leave the instances
  • can specify only Allow rules, but not deny rules
  • can grant access to a specific IP, CIDR range, or to another security group in the VPC or in a peer VPC (requires a VPC peering connection)
  • are evaluated as a Whole or Cumulative bunch of rules with the most permissive rule taking precedence for e.g. if you have a rule that allows access to TCP port 22 (SSH) from IP address and another rule that allows access to TCP port 22 from everyone, everyone has access to TCP port
  • are Stateful – responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa. Hence an Outbound rule for the response is not needed
  • Instances associated with a security group can’t talk to each other unless  rules allowing the traffic are added.
  • are associated with ENI (network interfaces).
  • are associated with the instance and can be changed, which changes the security groups associated with the primary network interface (eth0) and the changes would be applicable immediately to all the instances associated with the Security group

Connection Tracking

  • Security groups are Stateful as they use Connection tracking to track information about traffic to and from the instance.
  • Responses to inbound traffic are allowed to flow out of the instance regardless of outbound security group rules, and vice versa.
  • Connection Tracking is maintained only if there is no explicit Outbound rule for an Inbound request (and vice versa)
  • However, if there is an explicit Outbound rule for an Inbound request, the response traffic is allowed on the basis of the Outbound rule and not on the Tracking information
  • Tracking flow e.g.
    • If an instance (host A) initiates traffic to host B and uses a protocol other than TCP, UDP, or ICMP, the instance’s firewall only tracks the IP address & protocol number for the purpose of allowing response traffic from host B.
    • If host B initiates traffic to the instance in a separate request within seconds of the original request or response, the instance accepts it regardless of inbound security group rules, because it’s regarded as response traffic.
  • This can be controlled by modifying the security group’s outbound rules to permit only certain types of outbound traffic. Alternatively, Network ACLs (NACLs) can be used for the subnet, network ACLs are stateless and therefore do not automatically allow response traffic.

Network Access Control Lists – NACLs

  • A Network ACLs (NACLs) is an optional layer of security for the VPC that acts as a firewall for controlling traffic in and out of one or more subnets.
  • are not for granular control and are assigned at a Subnet level and is applicable to all the instances in that Subnet
  • has separate inbound and outbound rules, and each rule can either allow or deny traffic
    • Default ACL allows all inbound and outbound traffic.
    • Newly created ACL denies all inbound and outbound traffic
  • A Subnet can be assigned only 1 NACLs and if not associated explicitly would be associated implicitly with the default NACL
  • can associate a network ACL with multiple subnets
  • is a numbered list of rules that are evaluated in order starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL for e.g. if you have a Rule No. with Allow All and with Deny All, the Allow All would take precedence and all the traffic will be allowed
  • are Stateless; responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa) for e.g. if you enable Inbound SSH on port 22 from the specific IP address, you would need to add an Outbound rule for the response as well.

AWS VPC - Security Groups vs NACLs

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Instance A and instance B are running in two different subnets A and B of a VPC. Instance A is not able to ping instance B. What are two possible reasons for this? (Pick 2 correct answers)
    1. The routing table of subnet A has no target route to subnet B
    2. The security group attached to instance B does not allow inbound ICMP traffic
    3. The policy linked to the IAM role on instance A is not configured correctly
    4. The NACL on subnet B does not allow outbound ICMP traffic
  2. An instance is launched into a VPC subnet with the network ACL configured to allow all inbound traffic and deny all outbound traffic. The instance’s security group is configured to allow SSH from any IP address and deny all outbound traffic. What changes need to be made to allow SSH access to the instance?
    1. The outbound security group needs to be modified to allow outbound traffic.
    2. The outbound network ACL needs to be modified to allow outbound traffic.
    3. Nothing, it can be accessed from any IP address using SSH.
    4. Both the outbound security group and outbound network ACL need to be modified to allow outbound traffic.
  3. From what services I can block incoming/outgoing IPs?
    1. Security Groups
    2. DNS
    3. ELB
    4. VPC subnet
    5. IGW
    6. NACL
  4. What is the difference between a security group in VPC and a network ACL in VPC (chose 3 correct answers)
    1. Security group restricts access to a Subnet while ACL restricts traffic to EC2
    2. Security group restricts access to EC2 while ACL restricts traffic to a subnet
    3. Security group can work outside the VPC also while ACL only works within a VPC
    4. Network ACL performs stateless filtering and Security group provides stateful filtering
    5. Security group can only set Allow rule, while ACL can set Deny rule also
  5. You are currently hosting multiple applications in a VPC and have logged numerous port scans coming in from a specific IP address block. Your security team has requested that all access from the offending IP address block be denied for the next 24 hours. Which of the following is the best method to quickly and temporarily deny access from the specified IP address block?
    1. Create an AD policy to modify Windows Firewall settings on all hosts in the VPC to deny access from the IP address block
    2. Modify the Network ACLs associated with all public subnets in the VPC to deny access from the IP address block
    3. Add a rule to all of the VPC 5 Security Groups to deny access from the IP address block
    4. Modify the Windows Firewall settings on all Amazon Machine Images (AMIs) that your organization uses in that VPC to deny access from the IP address block
  6. You have two Elastic Compute Cloud (EC2) instances inside a Virtual Private Cloud (VPC) in the same Availability Zone (AZ) but in different subnets. One instance is running a database and the other instance an application that will interface with the database. You want to confirm that they can talk to each other for your application to work properly. Which two things do we need to confirm in the VPC settings so that these EC2 instances can communicate inside the VPC? Choose 2 answers
    1. A network ACL that allows communication between the two subnets.
    2. Both instances are the same instance class and using the same Key-pair.
    3. That the default route is set to a NAT instance or Internet Gateway (IGW) for them to communicate.
    4. Security groups are set to allow the application host to talk to the database on the right port/protocol
  7. A benefits enrollment company is hosting a 3-tier web application running in a VPC on AWS, which includes a NAT (Network Address Translation) instance in the public Web tier. There is enough provisioned capacity for the expected workload tor the new fiscal year benefit enrollment period plus some extra overhead Enrollment proceeds nicely for two days and then the web tier becomes unresponsive, upon investigation using CloudWatch and other monitoring tools it is discovered that there is an extremely large and unanticipated amount of inbound traffic coming from a set of 15 specific IP addresses over port 80 from a country where the benefits company has no customers. The web tier instances are so overloaded that benefit enrollment administrators cannot even SSH into them. Which activity would be useful in defending against this attack?
    1. Create a custom route table associated with the web tier and block the attacking IP addresses from the IGW (internet Gateway)
    2. Change the EIP (Elastic IP Address) of the NAT instance in the web tier subnet and update the Main Route Table with the new EIP
    3. Create 15 Security Group rules to block the attacking IP addresses over port 80
    4. Create an inbound NACL (Network Access control list) associated with the web tier subnet with deny rules to block the attacking IP addresses
  8. Which of the following statements describes network ACLs? (Choose 2 answers)
    1. Responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa (are stateless)
    2. Using network ACLs, you can deny access from a specific IP range
    3. Keep network ACL rules simple and use a security group to restrict application level access
    4. NACLs are associated with a single Availability Zone (associated with Subnet)
  9. You are designing security inside your VPC. You are considering the options for establishing separate security zones and enforcing network traffic rules across different zone to limit Instances can communications.  How would you accomplish these requirements? Choose 2 answers
    1. Configure a security group for every zone. Configure a default allow all rule. Configure explicit deny rules for the zones that shouldn’t be able to communicate with one another (Security group does not allow deny rules)
    2. Configure you instances to use pre-set IP addresses with an IP address range every security zone. Configure NACL to explicitly allow or deny communication between the different IP address ranges, as required for interzone communication
    3. Configure a security group for every zone. Configure allow rules only between zone that need to be able to communicate with one another. Use implicit deny all rule to block any other traffic
    4. Configure multiple subnets in your VPC, one for each zone. Configure routing within your VPC in such a way that each subnet only has routes to other subnets with which it needs to communicate, and doesn’t have routes to subnets with which it shouldn’t be able to communicate. (default routes are unmodifiable)
  10. Your entire AWS infrastructure lives inside of one Amazon VPC. You have an Infrastructure monitoring application running on an Amazon instance in Availability Zone (AZ) A of the region, and another application instance running in AZ B. The monitoring application needs to make use of ICMP ping to confirm network reachability of the instance hosting the application. Can you configure the security groups for these instances to only allow the ICMP ping to pass from the monitoring instance to the application instance and nothing else” If so how?
    1. No Two instances in two different AZ’s can’t talk directly to each other via ICMP ping as that protocol is not allowed across subnet (i.e. broadcast) boundaries (Can communicate)
    2. Yes Both the monitoring instance and the application instance have to be a part of the same security group, and that security group needs to allow inbound ICMP (Need not have to be part of same security group)
    3. Yes, The security group for the monitoring instance needs to allow outbound ICMP and the application instance’s security group needs to allow Inbound ICMP (is stateful, so just allow outbound ICMP from monitoring and inbound ICMP on monitored instance)
    4. Yes, Both the monitoring instance’s security group and the application instance’s security group need to allow both inbound and outbound ICMP ping packets since ICMP is not a connection-oriented protocol (Security groups are stateful)
  11. A user has configured a VPC with a new subnet. The user has created a security group. The user wants to configure that instances of the same subnet communicate with each other. How can the user configure this with the security group?
    1. There is no need for a security group modification as all the instances can communicate with each other inside the same subnet
    2. Configure the subnet as the source in the security group and allow traffic on all the protocols and ports
    3. Configure the security group itself as the source and allow traffic on all the protocols and ports
    4. The user has to use VPC peering to configure this
  12. You are designing a data leak prevention solution for your VPC environment. You want your VPC Instances to be able to access software depots and distributions on the Internet for product updates. The depots and distributions are accessible via third party CDNs by their URLs. You want to explicitly deny any other outbound connections from your VPC instances to hosts on the Internet. Which of the following options would you consider?
    1. Configure a web proxy server in your VPC and enforce URL-based rules for outbound access Remove default routes. (Security group and NACL cannot have URLs in the rules nor does the route)
    2. Implement security groups and configure outbound rules to only permit traffic to software depots.
    3. Move all your instances into private VPC subnets remove default routes from all routing tables and add specific routes to the software depots and distributions only.
    4. Implement network access control lists to all specific destinations, with an Implicit deny as a rule.
  13. You have an EC2 Security Group with several running EC2 instances. You change the Security Group rules to allow inbound traffic on a new port and protocol, and launch several new instances in the same Security Group. The new rules apply:
    1. Immediately to all instances in the security group.
    2. Immediately to the new instances only.
    3. Immediately to the new instances, but old instances must be stopped and restarted before the new rules apply.
    4. To all instances, but it may take several minutes for old instances to see the changes.

Like this:

LikeLoading

Sours: https://jayendrapatil.com/tag/nacl/
  1. Chuchu and friends
  2. Season 3 fortnite lobby
  3. Sei tv stands

question

I understand that-

1.In Azure, we apply NSG(Network Security Groups) at subnet or individual NIC level(VM) whereas in AWS these can only be applied at individual VM level.
NACL is applied at subnet level in AWS.


2.In Azure, we have a column for source and destination IP address(for each of inbound and outbound categories).

I infer that due to Security Groups being applied at VM level in AWS, we define only destination IP for outbound rules(src being the VM) and source IP for inbound rules(dst being the VM).

Further,even for NACL in AWS, for inbound rule,only src IP can be defined .For outbound rule,only dst IP can be defined.


3.(AWS)Irrespective of inbound/outbound rules segregation, 'port' always refers to 'destination' side which listens on a specific port for traffic.
{This is usually the case with clients using a random port to connect to a server on a specific port like 80}

And unlike Azure, we cannot define both 'to' and 'from' ports while configuring inbound/outbound rules?
(in particular, we cannot define 'source' ports under either inbound/outbound section).


4.AWS defines only Allow rules whereas Azure has options for both allow and deny(security group).
Further,AWS has NACL which can contain both allow and deny statements.


5.Both AWS and Azure have 'stateful' concept, meaning an explicit rule for 'return' traffic response is not needed(define rules for only who gets to initiate the communication)—for security groups.

In AWS,we have NACL concept which is stateless,ie rules needed in both direction for communication to be successful.



Please correct me if I am missing something in my understanding.

Regards,
Aditya

azure-virtual-networkSours: https://docs.microsoft.com/answers/questions//comparing-security-groups-in-aws-and-azure.html
AWS - Public \u0026 Private Instances - NACL DEMO - Network ACL rules

AWS Network ACL and subnets: network level security

Learn how to secure your VPC using an AWS Network ACL and subnets. Network ACLs act as a firewall for controlling traffic in and out of a VPC subnet.

Welcome to part three of my AWS Security overview. Last week, we discussed instance level security. In this post, we&#;ll focus on security at the network level. I will cover two topics: private and public subnets and AWS Network ACLs (Network Access Control Lists, or NACLs).

VPC Subnets

Segmenting your VPC into different networks is important both from a deployment/design perspective and also for security. Segmentation allows you to better refine your security profile as appropriate for each of the services operating within each subnet.

A subnet is a distinct network segment with its own IP address range within the larger VPC CIDR (Classless Inter-Domain Routing) range. As an example, if your VPC was created with a CIDR range of /16, you could choose to create subnets with a /24 mask allowing you to create networks &#; each with available IP addresses &#; following this pattern: /24, /24, /24&#;
Note, that the first four addresses (between .0 and .3) and the last IP address () of any subnet are not available, as they are reserved for router, DNS, Broadcast, and Network addresses, along with future capabilities. This leaves you with addresses to use in the above example in each subnet. You can always use one of the many subnet calculators available online to help you plan and manage your addressing.
When planning your subnets, take the time to properly anticipate how many nodes you might actually need in the future: once you create a subnet, it can&#;t be resized. Also, remember that AWS won&#;t let you create masks lower than /16 or higher than /

Public and Private Subnets

Splitting up your CIDR address space into subnets means that each subnet will have its own ACL and Routing Table. You will have to decide whether each subnet should be public or private. A public subnet is defined by its connection (through a Routing Table) to an Internet Gateway (IGW) within your VPC . The IGW provides a doorway from your environment out to the Public Internet. Any subnet without a route to the IGW is considered private, as there is no practical way for instances on this subnet to directly reach the public Internet.

Creating a Public Subnet

From the AWS Console, select ‘VPC > Subnets > Create Subnet&#;
AWS Network ACL- subnet
Enter the name for your subnet, select the VPC within which you want to create the subnet, select an Availability Zone, and finally enter the CIDR block you&#;d like to use. Click ‘Yes, Create’

Add an Internet Gateway

Select ‘Internet Gateways > Create Internet Gateway
AWS Network ACL - gateway
Enter a name for your IGW and click ‘Yes, Create’. Your newly created IGW will show as ‘Detached’. To attach it to a VPC, click ‘Attach to VPC’.
AWS Network ACL - vpc
Select the VPC you want to attach to your new IGW to and click ‘Yes, Attach

Adding a route to the IGW from your Subnet

Select ‘Route Tables > Create Route Table&#;
AWS Network ACL - route
Enter a name for your public Route Table and select your VPC, then select ‘Yes, Create’. You now need to edit your Route Table and give it a route to the outside world. To do this, select your Route Table and click ‘Routes > Edit > Add Another Route&#;.
AWS ACL - routes06
Enter ‘/0’ in Destination (to allow access to any Internet address) and enter your IGW ID in the ‘Target’ field. Click ‘Save’.

Associate your Route Table with your Subnet

Select ‘Subnet Associations
AWS ACL - associate
Select the Subnet(s) you wish to associate with this Route Table using the check box and click ‘Save’.
Your new Subnet now has a Route Table associated with it that allows access to the outside world via your Internet Gateway. This Subnet is now public.

When setting up your infrastructure, you will most likely be deploying services across multiple regions and availability zones (AZs) for high availability. It&#;s important to remember that subnets are unique and can&#;t be deployed across multiple AZs. If you plan to implement VPC peering, you should be aware that the peered subnets must not use overlapping CIDR blocks!

For tighter security, I would suggest keeping the number of instances within your public subnet(s) to a minimum, using Elastic Load Balancing and Autoscaling for increased availability while, at the same time, minimizing exposure. Only place instances that require public access in your public subnet. ALL other instances &#; like back end databases or application services &#; should live within private subnets. You will, of course, need to ensure proper routing between the two subnets.

The AWS Network ACL

AWS Network ACLs are the network equivalent of the security groups we&#;ve seen attached to EC2 instances. NACLs provide a rule-based tool for controlling network traffic ingress and egress at the protocol and subnet level. In other words, ACLs monitor and filter traffic moving in and out of a network.
You can attach an ACL to one or more subnets within your Virtual Private Cloud (VPC). If you haven’t created a custom ACL, then your subnets will automatically be associated with your VPC&#;s default ACL which ‘Allows’ all traffic to flow into and out of the network.
Inbound:
AWS Network ACL - inbound
Outbound:
AWS Network ACL- outbound
You will notice that the AWS Network ACL rule base works much the same way as the rules within security groups. However, ACL rules include an additional field called ‘Rule #’, which allows you to number your rules. This is important, because ACL rules are read in ascending order, with each rule applied against matching packets regardless of whether a later rule might also match. For this reason, you will want to carefully sequence your rules with an organized numbering system.
You can number of your rules starting at one (which will be read first), and going as high as I would suggest that you leave a gap of at least 50 numbers between each of your rules (i.e., 50, , &#;) to allow you to more easily add new rules in sequence later, if it should be necessary.

From the above example, you will also notice that each list includes a final entry with an asterisk (*) in the ‘Rule #’ column, rather than a number. This rule appears at the end of every rule base and can not be removed or edited. Its job is to act as an automatic fail-safe, to ensure that traffic that doesn’t match any of your custom ACL rules is dropped.

If you read my previous post, you will remember that security groups are stateful by design. ACLs, on the other hand, are stateless. Therefore, when creating your rules, you may need to apply an outbound reply rule to permit responses to inbound requests &#; if desired.

Creating an AWS Network ACL

To create an ACL from the AWS Console, select ‘VPC > Network ACLs > Create Network ACL’. Enter a name for your ACL and select the VPC in which you want it to reside. Then select ‘Yes, Create’.
That’s it: your first custom ACL is born. To view the details of your newly created ACL, select the Summary tab.
AWS Network ACL - create
You will see that Amazon automatically generates an AWS ACL ID and that your new ACL is not yet associated with any subnets in your chosen VPC. To associate it to one or more subnets, select the Subnet Associations tab, and then Edit. Then, select the subnets you wish to be associated and click Save. Those Subnets will then use your NACL for all inbound and outbound traffic.

Now it&#;s time to create some custom rules. Until you do, there will only be a default rule that will ‘Deny’ all traffic that&#;s either inbound or outbound (as opposed to a default AWS Network ACL which starts off fully open). Unless you tell the ACL otherwise, it will block everything.
AWS Network ACL - rules
To configure your ACL&#;s Inbound and Outbound rules, click on the appropriate tab, and then on Edit.
AWS Network ACL - save
Let&#;s explain these fields, one at a time.

Rule #. As we mentioned, ACL rules are read in ascending order, but only until a rule matching the packet is found. Care should be taken to number your rules appropriately when creating your rule base.

Type. This drop down list allows you to select from a list of common protocol types, including SSH, RDP, HTTP, and POP3. You can alternatively specify custom protocols such as varieties of ICMP.

Protocol. Based on your choice for &#;Type&#;, the Protocol option might be greyed out. For custom rules like TCP/UDP however, you should provide a value.

Port Range. If you do create a custom rule, you&#;ll need to specify the port range for the protocol to use.

Source. This can be a network subnet range, a specific IP address, or even left open to traffic from anywhere (using this value: /0).

Allow/Deny. Each rule must include an action specifying whether the defined traffic will be allowed to pass or not.

AWS Network ACL Limitations

When creating your ACLs be aware that there is a default limit of 20 inbound and 20 outbound rules per list. You can request a higher limit from AWS, but the absolute maximum is 40, and network performance could be affected by any increase. There is also a top end limit of ACLs per VPC.
All AWS Network ACL configurations &#; including adding and deleting rules and subnet associations &#; can also be applied using the AWS CLI, PowerShell, and AWS EC2 CLI.

As you can see, there&#;s nothing complicated about implementing ACLs, so I would definitely recommend you take a look at your own setup to see if you can improve it. You should at least try to avoid the default ACL setting that allows all traffic through using all protocols: this is very insecure for a live production environment.

I have seen ACLs used very effectively to prevent DDOS attacks. If, for example, traffic somehow manages to get past AWS’s own DDOS protection undetected and you are now being attacked from a single IP address &#; say &#; you can create an ACL rule that will drop all traffic from that source. For better performance, I would place this rule at very start of your rule base:
AWS Network ACL - deny
Your ACLs will require updating from time to time, and you should regularly review them to ensure they are still optimised for your environment. Network security is an ongoing struggle and needs our regular attention to ensure its effectiveness.
Let&#;s summarise some key points:

  • Remove (or edit) the default AWS Network ACL that is associated with the subnets in your VPC.
  • Set up tighter restrictions on custom ACLs and apply them to your subnets.
  • Segment your VPC into different subnets across different AZs and Regions for increased availability.
  • If you have public-facing services, keep these in their own public subnet and move all other services into private subnets.
  • Set up different routing tables for different subnets.

Next week, I&#;ll look at how to create Bastion Hosts, NAT Instances. We&#;ll also introduce VPC Peering.
Thank you for taking the time to read my article. If you have any feedback please do leave a comment below.

Sours: https://cloudacademy.com/blog/aws-network-acl-vpc-subnets-network-security/

Aws nacl

Time and time again, Amazon Web Services (AWS) practitioners recommend having the right combination of AWS NACLs (Network Access Control Lists, also pronounced as “Nakles”), VPC, and AWS Security Groups (SGs) to secure resources from unwanted attacks.

AWS NACLs act as a firewall for associated subnets, controlling both inbound and outbound traffic. Whereas SGs acts as the firewall at the resource level.

In one of our previous posts, we spoke about 5 Not-to-Ignore Best Practices for AWS Security Groups. In this post, we will walk you through a few best practices for NACLs.

The Stateless Beauty of AWS NACLs

Before exploring the best practices of AWS NACLs, it is important to understand its basic characteristics as well as the ability to fine-tune traffic through its stateless behavior.

Unlike SGs that are stateful, AWS NACLs are stateless. On that account, changes applicable to an incoming rule will not be applicable to the outgoing rule. That is, if you want your instances to communicate over port 80 (HTTP), then you have to add an inbound as well as an outbound rule allowing port  

Before configuring NACLs, one must keep a few recommendations in mind, such as:

Be Mindful of Default NACLs, Especially the Ones With Production Servers

When you create a VPC, it comes with a default Network ACL that allows all inbound and outbound rules. And if you create a custom NACL, both inbound and outbound rules are denied. If you have not created a custom network ACL, then the subnets will be associated with VPC’s default ACL automatically. This will ‘Allow’ all traffic to flow into and out of the network.

“Cautiously allow traffic into or out of NACLs, especially if you are running a production server. Above all, keep a continual check on NACLs that allow all inbound traffic.”  

Here’s an example: assign a NACL to a public subnet with instances that can receive and send Internet traffic over port 80 (HTTP) and ephemeral ports And, block the traffic over port (NFS) or ports vulnerable to denial of service attacks.

“Always ensure you do not use a wide range of ports or overly permissions to NACLs during configuration, unless your applications or containers that require a wide range of ports, like Kubernetes.” 

Use it With Security Groups Inside a VPC for Perfected Security

Configuring SGs and NACLs in VPC helps reduce the attack surface of your applications hosted on AWS. They mutually complement each other, because SGs allow defining the traffic to resources within the applications while NACLs allow defining the port, protocol, and source of traffic that should be explicitly denied at the subnet level.

Here is an example to show how SGs and NACLs complement each other. Say you have a two-tier web application with web servers in one SG and a database in another — the inbound NACL rules allow connections to web servers from around the world, while the database allows an inbound connection from only a list of web servers. So, web servers allow port connections, while the database allows inbound connections for MySQL.

“To prevent the servers from initiating connections over the Internet, you can remove both the web server and the database SGs’ outbound rule. This way, the web servers will allow all outbound traffic to establish sessions. And, the database must limit outbound connections to the web server’s private subnet IP range.” 

Keep an Eye on Ineffective NACL ‘Deny’ Rule

Ineffective or misconfigured DENY rules promotes ‘overly-permissive’ access to a VPC. This results in attacks, such as DoS or DDoS. Be mindful of the order of the DENY rules within your Network ACLs. This is crucial, as ACLs are evaluated in order. For example, in the below image, the DENY rule is defined to block inbound traffic to vulnerable port If the rule does not block access to everyone (/0), the inbound DENY rule is declared ineffective and should be reconfigured to protect against attacks.

Take Limitations Into Consideration

It is always best to know the limitations around NACLs before configuring them in your AWS infrastructure. Here are few limitations you must never ignore:  

  • There is a default limit of 20 to both inbound and outbound rules per list. AWS provides additional rules on request, however, the absolute maximum is

  • The top end limit 

Keep a Check on Unrestricted Outbound Traffic on NACLs

While creating/applying the network ACL, you can apply either inbound restriction or outbound restriction. During configuration, take care of outbound rules that allow traffic from all ports. Limit access to the required ports or port ranges. This provides the least privileges to unwanted roles and reduces the possibility of unauthorized access at the subnet level.

Play By the AWS NACL Rules

While best practices help in avoiding errors or unwanted traffic, there are few NACL rules you must never ignore, such as:

  • NACLs are always read in ascending order, with each rule applied against matching packets. These rules apply regardless of whether a later rule might also match. It is important to carefully sequence the NACL rules with an organized numbering system.

  • AWS Network ACL Rules (both inbound and outbound) are defined in terms of the DESTINATION port.

  • The numbering can start at one and go as high as While assigning, it is recommended to leave a gap of at least 50 numbers between each of the NACL rules, so that there’s enough room for additional rules in the sequence for use later. Plus, never forget to apply an outbound reply rule to permit responses to inbound requests while creating the rules.

  • Each Network ACL includes a rule numbered asterisk (‘*’). This rule ensures the inbound/outbound traffic is denied if a packet does not match any of the other numbered rules. This rule can neither be modified nor removed.

  • Specify the port range for the assigned protocol to use while creating a custom rule.

Conclusion

As a second layer of defense, NACLs run by the rules. But, you will need to configure them aptly under different scenarios. AWS has documented rules for the below scenarios:

Scenario 1: VPC with a Single Public Subnet

Scenario 2: VPC with Public and Private Subnets (NAT)

Scenario 3: VPC with Public and Private Subnets and AWS Managed VPN Access

Scenario 4: VPC with a Private Subnet Only and AWS Managed VPN Access

Additionally, using Terraform, you can program NACLs rules. This helps in creating a secure infrastructure and preserving it in Infrastructure as a Code (IaaC) format.

Taking all the above rules into consideration and applying the best practices, you can always improve your AWS security posture and reduce the attack surface.

But configuring the NACLs as per best practices alone is not enough. Keeping a continual check on these is of paramount importance. It doesn’t matter if you are using Terraform code or a tool, like Cloud-custodian, to monitor and verify NACL rules.

What matters the most is how you analyze the route table and NACL configurations and further map the entire inbound and outbound traffic between subnets and NACLs continually to maintain AWS security in real-time.

Having said that, switching between multiple tabs and dashboards or lines of code is effort-intensive. Using a single visual console, like TotalCloud, which can analyze and show the entire AWS network topology right from the VPC level to the resource level is the best way forward. TotalCloud Inc. will be soon rolling out such a view that will provide a focused visual environment with real-time cues to security loopholes in a 3D space. Stay tuned! 
Sours: https://dzone.com/articles/5-not-to-ignore-best-practices-for-aws-nacls-netwo
AWS Essentials: Network Access Control List (NACLs)

Lab Network ACLs

Modifying default Network ACLs to block, allow subnets

Network ACLs are stateless access controls you configure at a subnet level, to allow or block a CIDR block on a particular port or range of ports. Network ACL rules are numbered list and evaluated top down, with a DENY ALL at the end. If a rule is matched, subsequent rules are not evaluated.

Both inbound and outbound traffic can be controlled with these rules. By default when you have created the above subnets, the default Network ACL attached to them will have an ALLOW ALL rule for both inbound and outbound traffic.

In this lab, we will modify Network ACL on VPC A-AZ1 to allow only VPC B’s CIDR; and test connectivity on port 22 from VPC B to VPC A, and test other connectivity from VPC C to VPC A as well.

According to best practices it is recommended to use a separate subnet for each transit gateway VPC attachment in case of using NACLs with Transit Gateways. We keep the inbound and outbound NACL that is associated with the transit gateway subnets open, and will apply NACLs with filters to your workload subnets. Link.

TGW Subnets & NACL configuration

  1. Create new NACLs for TGW subnets
    • Create new NACL for VPC A (use name e.g. )
    • Repeat for VPC B (with name ) and VPC C (with name )
  2. Associate TGW subnets with newly created NACL for VPC A
    • Choose NACL for VPC A in the list
    • Click Subnet associations tab below
    • Click Edit subnet associations
    • In Edit subnet associations choose from available subnets the ones with in their name (e.g. & ), click Save changes.
    • Repeat for VPC B & VPC C by choosing corresponding subnets with in Subnet name.
  3. Change TGW NACL Inbound rules to allow all traffic
    • (1) Choose NACL for VPC A
    • (2) click INbound Rules tab below
    • (3) notice that we have only all rule
    • (4) Click Edit inbound rules
    • In Edit inbound rules
      • Click Add new rule
      • Input in “Rule Number”
      • Chose “All traffic” in “Type”
      • Click Save changes
    • In the result you should have the following:
    • Repeat for VPC B & VPC C
  4. Change TGW NACL Outbound rules to allow all traffic
    • Follow the same steps described above for Inbound, but work on Outbound Rules tab of NACLs
    • Repeat for VPC B & VPC C

Now we’re ready to proceed to the next section and configure NACLs for EC2 instances to allow the ICMP traffic, TGW NACLs that allow everything will not introduce any blocking for us.

NACL configuration for EC2 subnets in AZ1

  1. Navigate to VPC Dashboard - Subnets
  2. Filter AZ1 subnets and open Network ACL for VPC A
    1. Type ‘AZ1’ in the search box and choose “Potential matches” - “Availability Zone ID” with in name. This allows to filter only subnets in AZ1. The console should now show only the six subnets (3 for EC2 and 3 for TGW attachments) in AZ1 as below.
    2. Click on VPCA subnet and switch to “Network ACL” tab at the bottom, click on Network ACL ID:
  3. In the Network ACL screen, click on ‘Inbound Rules’ to view existing inbound rules

    The default inbound rules in the Network ACL can be seen above. All traffic get evaluated for Protocol, Port and Source IP match. In this default Network ACL, all traffic are allowed into VPC A – AZ1 Subnet by the first rule. The second rule which is a DENY ALL is not evaluated.

We will now modify the first rule () to allow only ICMP traffic from VPC B’s CIDR. Click on ‘Edit inbound rules’ button in the above screen.

In the above screen, enter the following and save the rule. (Note that the catch all rule for DENY ALL cannot be edited)

  1. Select ‘ALL ICMP – Ipv4’ for Type
  2. Enter VPC B’s CIDR /16 for Source
  3. Click on Save
  4. The screen should return to the Network ACL page and the updated rule will display like below. Verify the rule for Type, Protocol, Port and Source for the ‘ALLOW’ rule

We have now completed modifying Network ACL of VPC A’s AZ1 Subnet to allow ONLY ICMP traffic from VPC B’s CIDR and all other traffic will be denied by the catch-all DENY rule. Let us now test this from VPC B AZ1 Subnet for ALLOW, and VPC C AZ1 Subnet for DENY.

Note that we have not modified outbound rules, and the default outbound rule allows ALL traffic to flow out of the subnet.

Testing connectivity from EC2 VPC B AZ1 to EC2 VPC A - AZ1

We have now verified that the Network ACL on VPC A – AZ1 subnet is allowing ICMP traffic to flow in and out, from EC1 VPC B – AZ1.

Testing connectivity from EC2 VPC C AZ1 to EC2 VPC A - AZ1

Similarly, connect to EC2 VPC C - AZ1 from EC2 console, and ping EC2 VPC A - AZ1 as we did from VPC B above. The ping command will freeze without progress because the Network ACL in VPC A - AZ1 subnet is DENYING all traffic from VPC C. Like below.

Conclusion

We modified the default Network ACL in VPC A to allow ICMP traffic only from VPC B; the only other rule is a DENY ALL. We verified that ICMP traffic flows through from EC2 VPC B – AZ1 to EC2 VPC A – AZ1 and DID NOT flow through from EC2 in VPC C – AZ1.

Sours: https://networking.workshop.aws/beginner/lab4/lab4-nacl.html

Now discussing:

AWS Network Firewall: More Than Just Layer 4

_BlogImage_Site-Merch_AWS-Firewall-Manager_Midpage-Banner.0efbbaabe6fdc.pngUp until very recently, network prevention has been quite limited in Amazon Web Services (AWS). Consumers were left with the following options:
  • Create Security Groups to limit various types of layer 3 and 4 traffic to/from Elastic Compute Cloud (EC2) instances
  • Create Network Access Control Lists (NACL) to limit layer 3 and 4 traffic to/from entire Virtual Private Cloud (VPC) subnets
  • Route traffic through a network appliance running as an EC2 instance (not as "cloud-friendly" as this is often less scalable and sized to handle peak traffic)
To add more network protection options, AWS just released an awesome new capability in select regions called AWS Network Firewall. Protections that are afforded here are:
  • Allow or deny based on source IP and/or port, destination IP and/or port, and protocol (also known as 5-tuple)
  • Allow or deny based upon domain names
  • Allow or deny based upon Suricata-compatible IPS rules
Wait we can make forwarding decisions based on PAYLOADS?! Now we're talking!
Similar to physical or virtual firewalls, some thought about which assets to protect, which types of traffic to hone in on, and other major considerations must be determined prior to deployment. Likely, you may have already done this if deploying an EC2 instance-based firewall.
To deploy one or more of these, changes to the existing VPC architecture are required (more on this in a bit).

A best practice outlined by AWS is to architect your VPC to support this VPC Firewall. It is not as simple as turning on the service and being on your merry way. To support the upcoming case study, I'll keep the re-architected VPC (formerly set up by default) to the following:
  • VPC: Create or use a default VPC
  • Subnets: Use two of the existing subnets created by the default VPC
    • Subnet 1: Rename to FirewallSubnet. This will be used to contain the Network Firewall endpoint.
    • Subnet 2 through X: Rename to ProtectedSubnetX. These will be used to house the instances being protected by the Network Firewall
  • EC2 instance(s): Deploy or re-home into the ProtectedSubnet(s)
  • Route Tables: The default Route Table will no longer work, but more on this after the Network Firewall is deployed

The first component to build out the AWS Network Firewall (and last on their list in the VPC service WHY AMAZON?!) is the Network firewall rule group. This is where you decide what to allow or deny based on the previous list (5-tuple, domain names, or IPS rules).
This is very simple to set up:
  • Determine if this rule group will be stateless (inspect packets within the context of the traffic flow) or stateful (inspect individual packets on their own)
  • Give the rule group a name and optional description
  • Assign a capacity (see https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-group-capacity.html for more detail)
  • If a stateful rule group, follow the rest of the wizard to define your rule(s) for the traffic you wish to allow or deny

The next piece of the puzzle is a Firewall policy. These policies simple consist of one or more Firewall rule groups so stepping through the wizard is very straight-forward (give it a name and description, add the rule groups, choose a default action, and tag the policy if you wish).

The Firewall configuration is slightly more complex, but not by much. Here is where the re-architecting decisions begin to make more sense.
To begin configuring this Firewall, yet again, give it a name and description. Selecting the appropriate VPC is the next step (easy if you only have one otherwise, ensure you are choosing the correct one!). After this, choose the FirewallSubnet (or whatever you named it) subnet as this is the subnet in which the Firewall endpoint will be placed.

The only other required step is to select the Firewall policy created earlier.

Your Firewall will deploy in a few minutes, but it won't actually be doing anything until you force traffic through it. To do so, some VPC Route Table adjustments need to be made. Following guidance from https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/, creating a few Route Tables is the easiest-to-understand option. Here is an example of establishing three Route Tables to force traffic through the Network Firewall:
  • ProtectedRouteTable: Used to send any traffic from any instances in the ProtectedSubnet to any destination outside the subnet to the Network Firewall
  • FirewallRouteTable: Used to send any traffic to the Internet Gateway
  • IGWRouteTable: Used to send any traffic destined to the ProtectedSubnet from outside the subnet to the Network Firewall
Sounds complex (and it is!) but the upcoming case study will show how this is set up in more detail. But first
To appease your security analysts (or to at least see the fruits of your labor), you should be logging Network Firewall alerts at the very least. This is achieved by navigating to the Firewall details tab to set up logging as this service does not log AT ALL unless you configure it to. The usual suspects are available as log destinations: S3 bucket, CloudWatch, Kinesis data firehose.

VPC Setup

And now a very detailed walkthrough. To explore this service, I began by using a "clean" and unused region in AWS to not affect some production workloads. I chose us-west-2 as it is one of two US regions that offer this service at the time of this writing (the other being us-east-1).

Since the default VPC is already there, time to make a few changes. I left the subnet configuration as it was (even through I'm only using two or the four subnets for this example) other than changing two names: ProtectedSubnet for one and FirewallSubnet for another.

_BlogImage2.png

EC2 Target Instance

Next up was to deploy an instance I'd like to protect. I simply chose an Amazon Linux 2 AMI, logged in, and added the following to support my upcoming "attack":

sudo yum update -y
sudo yum install httpd -y
echo "Hello Visiter" | sudo tee /var/www/html/Hello
sudo systemctl enable httpd
sudo systemctl start httpd

Network Firewall Rule Group

The major capability that really piqued my interest is the fact that you can not only block traffic based upon known bad IPs, ports, or domains, but also by ingesting Suricata IPS rules! To test this out, I created a stateful rule group that simply blocks any time it sees this very nasty traffic or traffic that contains the text "Hello". Here is what this Suricata IPS-compliant rule looks like:
_BlogImage3.png

Network Policy

The policy, as stated earlier, is very simple. I just have the policy incorporate my lone rule.

_BlogImage4.png

Network Firewall

Again, my setup is very simple as it's ultimately a single rule in a rule group, a single rule group in a policy, and then the policy is used in the Network Firewall configuration.
_BlogImage5.png

Logging

To ensure that my rule is actually doing anything, I'll set up a CloudWatch log group called FirewallAlerts. I'll dig into this log group in a bit once some data is generated.

Back to the Network Firewall configuration under Firewall details, I chose the FirewallAlerts CloudWatch log group as my destination, but was faced with a few options on which types of data to send there:_BlogImage6.pngAnother opportunity to enable Flow logging! To save some money, through, and to keep my CloudWatch log group focused on alerts, I just chose Alerts here.

Route Tables

By far, the most complex part of this setup is the Route Table configuration, so I'll keep it as brief as possible. I followed the previous guidance of creating three Route Tables like so:

ProtectedRouteTable


_BlogImage7.pngThe Target of vpcecf02db represents the Network Firewall. Also, the ProtectedSubnet was associated with this Route Table (for obvious reasons). With this, any traffic sent from the instance to a destination outside the subnet will be forwarded to the Network Firewall.

FirewallRouteTable

_BlogImage8.pngHere, the target of igw-0dde7ab9 represents the Internet Gateway which was already created when setting up the default VPC. The FirewallSubnet was associated with this Route Table and, combined with these rules, will force any traffic meant for the outside world to be routed to the Internet Gateway.

IGWRouteTable

_BlogImage9.png

This Route Table is a bit different as it looks at the traffic as it is returning to the VPC. Since I wish to have the return traffic traverse the firewall, I have any traffic destined for the ProtectedSubnet IP space (/20 in this case) configured to be routed to the Network Firewall. Since this Route Table is to be assigned, not to a subnet, but to an Internet Gateway, an Edge association is configured.

_BlogImagepng

Attack!

And now to trigger the Firewall block. If you remember, the Suricata rule was simply looking for the text "Hello" in any TCP traffic:

deny tcp any any -> any any (msg: "No Hellos"; content: "Hello"; sid: ; rev:1;)

To attempt to trigger this rule, I opened up a web-browser session and navigated to the IP address plus /Hello.

_BlogImagepng

What caused the issue here? Was it the Network Firewall? Let's find out! Going back to the CloudWatch log group, I found an interesting log:

_BlogImage_Code.png
Looks like it worked!

Conclusion

Thus far, I'm really impressed with what can be done using this new service. Yes, it is quite the level of effort if it involves re-architecting an existing deployment and can be costly (well over $/month if my implementation were to run 24/7), but I'm sure as the service really takes off more capabilities will be included to enhance your organization's defense in depth even further.

About The Author

Ryan's passion for information technology started in when he found himself constantly trying to make his high school's computers and even calculators do things that they weren't exactly intended to do. They lacked games, so he learned how to create some. Yes, some may call this hacking. Ryan called it "fun", which led to attending college with intentions of becoming a software engineer. During school, Ryan obtained an internship with a very cybersecurity-minded organization -- the Defense Information Systems Agency (DISA). Ever since then, he’s been hooked on cybersecurity. Ryan is the author for the new SEC Cloud Security Essentials and an instructor for SEC Defensible Security Architecture and Engineering. Read Ryan's full bio here.

Sours: /blog/


510 511 512 513 514