I work for the platform team of my company and we have a central AWS Network Firewall in a central VPC. We provide AWS accounts for different teams and if they need internet access, we connect the VPCs of the teams with a transit gateway to our central VPC and route traffic through our central VPC and firewall into the internet.
We currently only allow to reach certain domains that we whitelist. The problem is, that if we whitelist a URL, every AWS account can reach this URL. Sometimes an aws account needs to reach just one endpoint and not every endpoint, that is whitelisted.
My question is, is it possible to use some kind of conditional rules that only apply to certain accounts/VPCs?
We use Cloudformation for IaC. Any help and examples are highly appreciated!
Cheers
Related
How can we restrict outbound traffic from AWS VPC to the internet, for example limiting outbound traffic to certain trusted domains (URL “whitelisting”).
I was thinking on AWS WAF but it seems it filter trrafic traffic traveling to the web application not from web application.
Any thoughts, suggestions, Thanks in advance.
It seems to be that you‘re looking for a proxy solution. As I know there aren‘t any managed proxy AWS services offered yet but you can use cloudformation, terraform or similar to setup it your own way with open source solutions f.e..
There is a good blog post on AWS about exactly your issue: https://aws.amazon.com/de/blogs/security/how-to-set-up-an-outbound-vpc-proxy-with-domain-whitelisting-and-content-filtering/
Maybe there is something useful for you on AWS Marketplace:
https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=Proxy
The simplest and easiest way is to implement an Aviatrix FQDN egress filter. It just serves the purpose from a centralized user interface to discover then whitelist/blacklist the URLs/FQDN in every VPC.
Proxy implementation could become complex, esp. when you have to manage it seprately in every VPC. and doesn't provide centralized control, every VPC has to be managed separately.
The easiest way is to get an Aviatrix launch partner like SDxWORx, enable it with discounted PAYG pricing.
https://aws.amazon.com/marketplace/pp/prodview-laruhupdkcpuy/
I have hosted few services on AWS however all are public and can be accessed from anywhere which is a security threat, could you please let me know how to keep the services specific to internal users of organization without any authentication medium.
I found a workaround for this, if you have list of IP range may be a network administrator can help you, take that and put them in load balancers under security group.
You should spend some time reviewing security recommendations on AWS. Some excellent sources are:
Whitepaper: AWS Security Best Practices
AWS re:Invent 2017: Best Practices for Managing Security Operations on AWS (SID206) - YouTube
AWS re:Invent 2017: Security Anti-Patterns: Mistakes to Avoid (FSV301) - YouTube
AWS operates under a [Shared Responsibility Model, which means that AWS provides many security tools and capabilities, but it is your responsibility to use them correctly!
Basic things you should understand are:
Put public-facing resources in a Public Subnet. Everything else should go into a Private Subnet.
Configure Security Groups to only open a minimum number of ports and IP ranges to the Internet.
If you only want to open resources to "internal users of organization without any authentication medium", then you should connect your organization's network to AWS via AWS Direct Connect (private fiber connection) or via an encrypted VPN connection.
Security should be your first consideration in everything you put in the cloud — and, to be honest, everything you put in your own data center, too.
Consider a LEAST PRIVILEGE approach when planning Network VPC Architecture, NACL and Firewall rules as well as IAM Access & S3 Buckets.
LEAST PRIVILEGE: Configure the minimum permission and Access required in IAM,Bucket Policies, VPC Subnets, Network ACL and Security Groups with a need to know White-list approach.
Start from having specific VPCs with 2 Main Segments of Networks 1-Public and the other 2-Private.
You will place your DMZ components on the Public segment,
Components such as Internet Facing Web Server, load Balancers,
Gateways, etc falls here.
For the Rest such as Applications, Data, or Internal Facing
LoadBalancers or WebServers make sure you place them in the Private
Subnet where you will use an Internal IP address from specified
Internal Range to refer to the Components Inside the VPC.
If you have Multiple VPCs and you want them to talk with each
other you can Peer them together.
You also can use Route53 Internal DNS to simplify naming.
Just in case, If you need to have Internet access from the Private segment
you can Configure a NAT Gateway on the public subnet and handle
Outgoing Traffic routed to Internet from the NAT Gateway.
S3 Buckets can be Configured and Servered as VPC-END points. (Routing via an Internal Network rather than Internet Routed to S3 Buckets/Object).
In IAM you can create Policies to whitelist source IP and attached to Roles and Users which is a great combination to Mix Network VPN Connections/white-listed IPs and keep Network Access in harmony with IAM. That means even Console Access could be governed by a White-listed Policy.
We are having several microservices on AWS ECS. We have single ALB which has different target group for different microservices. We want to expose some endpoints externally while some endpoints just for internal communication.
The problem is that if we put our load balancer in public VPC than it means that we are exposing all register endpoints externally. If we move load balancer to private VPC, we have to use some sort of proxy in public VPC, which required additional infra/cost and custom implementation of all security concerns like D-DOS etc.
What possible approaches we can have or does AWS provide some sort of out of the box solution for this ?
I would strongly recommend running 2 albs for this. Sure, it will cost you more (not double because the traffic costs won't be doubled), but it's much more straight forward to have an internal load balancer and an external load balancer. Work hours cost money too! Running 2 albs will be the least admin and probably the cheapest overall.
Checkout WAF. It stands for web application firewall and is available as AWS service. Follow these steps as guidance:
Create a WAF ACL.
Add "String and regex matching" condition for your private endpoints.
Add "IP addresses" condition for your IP list/range that are allowed to access private endpoints.
Create a rule in your ACL to Allow access if both conditions above are met.
Assign ALB to your WAF ACL.
UPDATE:
In this case you have to use external facing ALB in a public subnet as mentioned by Dan Farrell in comment below.
I would suggest doing it like this:
one internal ALB
one target group per microservice, as limited by ECS.
one Network load balancer(NLB), with one ip based target group.
The Ip based target group will have the internal ALB ip addresses,as the private ip addresses for ALB are not static, you will need to setup cloudwatch cron rule with this lambda function(forked from aws documentation and modified to work on public endpoints as well):
https://github.com/talal-shobaita/populate-nlb-tg-withalb/
Both ALB and NLB are scalable and protected from DDOS by AWS, AWS WAF is another great tool that can be attached directly to your ALB listener for extended protection.
Alternatively, you can wait for AWS to support multiple target group registration per service, it is already in their roadmap:
https://github.com/aws/containers-roadmap/issues/104
This how we eventually solved.
Two LB one in private and one in public subnet.
Some APIs meant to be public, so directly exposed through public LB.
For some private APIs endpoints need to be exposed, added a proxy in public LB and routed those particular paths from public LB to private LB through this proxy.
These days API Gateway is the best way to do this. You can have your API serve a number of different endpoints while serving only the public ones via API Gateway and proxying back to the API.
I don't see it mentioned yet so I'll note that we use a CloudMap for internal routing and an ALB for "external" (in our case simply intra/inter-VPC) communication. I didn't read in depth, but I think this article describes it.
AWS Cloud Map is a managed solution that lets you map logical names to the components/resources for an application. It allows applications to discover the resources using one of the AWS SDKs, RESTful API calls, or DNS queries. AWS Cloud Map serves registered resources, which can be Amazon DynamoDB tables, Amazon Simple Queue Service (SQS) queues, any higher-level application services that are built using EC2 instances or ECS tasks, or using a serverless stack.
...
Amazon ECS is tightly integrated with AWS Cloud Map to enable service discovery for compute workloads running in ECS. When you enable service discovery for ECS services, it automatically keeps track of all task instances in AWS Cloud Map.
You want to look at AWS Security Groups.
A security group acts as a virtual firewall for your instance to control inbound and outbound traffic.
For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.
Even more specific to your use-case though might be their doc on ELB Security Groups. These are, as you may expect, security groups that are applied at the ELB level rather than the Instance level.
Using security groups, you can specify who has access to which endpoints.
I would like to restrict access to objects stored in an Amazon S3 bucket.
I would like to allow all the users on our LAN (they may or may not have amazon credentials since the entire infrastructure is not on AWS). I have seen some discussion around IP address filtering and VPC endpoint. Can someone please help me here? I am not sure if I can use VPC endpoint since all users on our lan are not in Amazon VPC.
Is this possible?
Thanks
Most likely your corporate LAN uses static IP addresses. You can create S3 policies to allow access (or deny) based upon IP addresses. Here is a good AWS article on this:
Restricting Access to Specific IP Addresses
VPC Endpoints are for VPC to AWS Services connectivity (basically using Amazon's private Internet instead of the public Internet. VPC Endpoints won't help you with Corporate connectivity (except if you are using Direct Connect).
Here is how I would solve it,
Configure
Configure Users from a corporate directory who use identity federation with SAML.
Create Groups
Apply Policies to Group
This will give fine-grained control and less maintenance overhead.
This will help you not only to control S3 but any future workloads you migrate to AWS and permissions to those resources as well.
IP based filtering are prone to security risk and with high maintenance in the long run and not scalable.
EDIT:
Adding more documentation to do the above,
Integrating ADFS with AWS IAM:
https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/
IAM Groups:
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html
Ok, so our setup is as follows:
We have a VPC with some instances in them. For most of the traffic, we want to go back to our existing physical hosting centre and from there to the internet, with our nat'ed public ip. Since we are dependent on this ip to be whitelisted.
The remaining traffic needs to go through the local IGW, because it is high volume. Some of this is going to specific ips, so we have added those to the routing tables. The rest is going to other Amazon webservices, like Kinesis and DynamoDB. These services all have multiple ips associated with them and can change at the discretion of Amazon. This means that just resolving the dns locally and then adding it to the routing table won't work. At least not in a robust manner.
So is there any nice way of doing this?
You can use services endpoints and route through it.