In our example, Alice is the CEO of a small consulting firm (CTO). Despite her small size, her company has many key customers and Alice has worked hard to earn her trust. Alice has a set of strict firewall policies and has deployed several security tools over the years.
As the company begins migrating applications to the cloud, Alice's team discusses how to implement similar policies through Amazon Web Services (AWS). The first thing in business is blocking internet access. Developers should not be able to download files from the Internet, except in some supported scenarios. These scenarios include access to the Yum repository to update Amazon Linux, and the use of AWS services such as Amazon S3. Alice plans to implement this policy through an IP address restriction in the Amazon Elastic Compute Cloud (EC2) security suite.
Eliss finds several posts in the AWS blog forums of people who request IP address ranges for Yum and Amazon S3 repositories. However, Amazon does not publish this list. Why? In the cloud, resources are very flexible. Applications are growing and declining in response to demand. The IP address assigned to one application today can be assigned to another application tomorrow.
As applications expand and shrink, instances are added and removed, and the Domain Name Service (DNS) is constantly updated with new IP addresses. You can't rely on IP address security rules in the cloud; Therefore, security policies should be based on domain names, as they will not change according to the application standard. However, Amazon EC2 Security Groups and Network Access Control Lists (ACLs) do not support domain-based rules. Should we not look for another solution to implement its security policy?
Note that AWS provides both a security suite and a network access control list to protect your application. The security group is applied to the instance; The network ACL applies to the entire subnet. Alice uses the ACL to ensure that the applications apply to all instances distributed by the subnet. See the Amazon VPC documentation for more information on security groups and network access control lists.
After installing Squid, I started configuring it. The configuration is saved in a text file located in /etc/squid/squid.conf. Alice uses Vima to edit the file.
Squid uses rules called ACLs to determine traffic. Don't confuse the Squid ACL with the Amazon EC2 ACL we've created before. Alice's first encounter rule is src, which is used to identify traffic from the request source IP. In other words, the agent will only allow requests from these addresses. By default, Squid will allow requests from any private address.
Alice wants to further restrict access to VPC instances only, so she circumvents these rules and creates a single rule that allows requests from her VPC 10.1.0.0/16 cross-domain routing range (CIDR).
Some important things to know about the previous team:
The proxy configuration used here is valid only for the current session. It is suitable for testing, but you must add these records to continue
Most, but not all, applications will use these environment variables. For more information about configuring a proxy server, see the application's documentation.
The squid listens by default on port 3128. You can change the port in the AWS blogs for beginners file.
169,254,169,254 is an Amazon EC2 metadata service. We turn this off because we want our instances to have direct access to the metadata service. If we authorize these requests, the metadata service will return proxy information instead of the request.
