By using AWS re:Post, you agree to the Terms of Use
/AWS WAF/

Questions tagged with AWS WAF

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

AWS Load Balancer not reaching LightSail instance

I would like to protect my lightsail instances with a AWS-WAF. For that, I need an EC2 Load Balancer instead of the lightsail one. I´ve implemented the following steps (all with root user): 1. Enable VPC peering in lightsail, on the correspondent zone, let say 'Ireland'. 2. AWS VPC is default and in Ireland. 3. Create a Target Group of type IP Address, on previous default VPC; Network 'Other Private IP Address' and the private address of the lightsail instance (instance has an apache listening on port 80). Checked that targets are 'Healty' on Target Group. 4. Create a LoadBalancer in the Default VPC, with the previous created Target Group, and with zones 'a' and 'b' of Ireland. Zone 'a' is the zone of where the lightsail instance is. 5. On Route 53 created a public hosted zone, with the name of my domain (registered directly in Route 53). 6. Create a DNS A record of type 'Alias', with linked point 'Alias Application Load Balancer', in region Ireland and pointing to previous created Load Balancer (showed for selection with the name of the LB, but wit 'dualstack.' appended to it). 6.1. Also tried resolving the LB DNS and creating the DNS A record to point directly to the IP instead of the 'Alias'. After all these steps, when trying to browse to my domain, I´m getting an "ERR_CONNECTION_TIMED_OUT". Ping to domain resolves to same ip that Load Balancer DNS; Security Groups in AWS allow all traffic; there is route in AWS to internal network of LightSail (created automatically when peering VPCs in step 1); ACL or Firewall are allowing all traffic; on ligthsail all traffic is allowed as well. What I could be missing? At that point and with all the steps reviewed, I can´t not figure out where the issue is.
2
answers
0
votes
6
views
Pepelu
asked 2 months ago

WAF blocking requests because of the ELB cookie values

Hi. I've noticed that the WAF **AWSManagedRulesCommonRuleSet** is **BLOCKING** (or COUNTING) legitimate requests because it matches the value of the **Elastic Load Balancer** cookie ("AWSALBTG") as a **false positive** matched by the rule **CrossSiteScripting_COOKIE** This is an example request that I extracted from WAF cloudwatch logs (only the relevant info): ``` httpRequest.headers.13.name: cookie httpRequest.headers.13.value: AWSALBTG=0naHdSsqK2TVnPXcAgo8cGqiA0X1v/4rqyWrE/OsL7eubnXAm8tJRmtFzcv5XbAmDVq6UpKw2ZY0BHcOMwuQLRh7lU3TMoHbHnA00gY2R+yG/4vtzy2meQptVHelSdfnAPR5heRTALuqaHUf/oNyw1kZibZHTTkzpONuiJZkpUIr2pVVqsQ=; AWSALBTGCORS=0naHdSsqK2TVnPXcAgo8cGqiA0X1v/4rqyWrE/OsL7eubnXAm8tJRmtFzcv5XbAmDVq6UpKw2ZY0BHcOMwuQLRh7lU3TMoHbHnA00gY2R+yG/4vtzy2meQptVHelSdfnAPR5heRTALuqaHUf/oNyw1kZibZHTTkzpONuiJZkpUIr2pVVqsQ=; AWSALB=zyyDqgOFJzOv2HVSswKA0mw8yNNjHrAyJkhe7SRNFzOJSD6jFX6+5/T8ELUvvHIYeKW0XuxPDTBTG0gZO3d2FSCohf1jHsk2mDmTkoOh7BZCQKTmtJn4X4jbDDjL; ..... nonTerminatingMatchingRules.0.action: COUNT nonTerminatingMatchingRules.0.ruleId: AWS-AWSManagedRulesCommonRuleSet nonTerminatingMatchingRules.0.ruleMatchDetails.0.conditionType: XSS nonTerminatingMatchingRules.0.ruleMatchDetails.0.location: HEADER nonTerminatingMatchingRules.0.ruleMatchDetails.0.matchedData.0: oNyw1kZibZHTTkzpONuiJZkpUIr2pVVqsQ nonTerminatingMatchingRules.0.ruleMatchDetails.0.matchedData.1: ; ``` As you can see, the "**matchedData**" field contains a string ("oNyw1kZibZHTTkzpONuiJZkpUIr2pVVqsQ") that is inside the AWSALBTG cookie value generated by the ELB. This means that currently we can't use WAF and ELB together because it is blocking legitimate requests because of the ELB cookie. Am I correct or missing something? Is there any way to avoid this?
0
answers
0
votes
4
views
Pedro
asked 2 months ago
3
answers
1
votes
12
views
Keonwoong Ho
asked 5 months ago

Protecting Origin for Exclusive CloudFront access: Best Practices

A customer wants to protect his origin server (**ALB** + **EC2**) of a **CloudFront** distribution, allowing it to receive only the traffic coming from the CloudFront distribution, and preventing it to be accessible by other sources that basically would bypass CloudFront. The customer might consider to use **WAF**. The **approaches** we discussed are basically **3**: 1. Given that the ALB has his Security Group (SG), use a Lambda function to update a SG rule that only allows requests coming from CloudFront Edge Locations service IP range. This IP range could be modified every time a new Edge Location is added/removed to the global Amazon PoPs. Therefore an SNS topic can be used in order to trigger the automatic editing of the rule in the SG (with the updated IP range), through the Lambda function. This is well described in this [blog post][2]; 2. Use the same setup of solution 1, with WAF between the CloudFront distribution and the ALB (users -> CF -> WAF -> ALB -> compute_service). The difference with solution 1 would be that instead of updating the ALB Security Group rule, the Lambda function would update WAF rules based on [IP Set][3]. 3. Just use WAF between the CloudFront Distribution (users -> CF -> WAF -> ALB -> compute_service), and configure CF such that it [adds a custom secret header to origin requests][4] in order to identify all the requests coming from CloudFront and set up WAF such that only allows requests with that specific custom header, denying all the other requests to the origin (ALB). There is an **external** [blog post][5] that actually uses this approach, but not actually well documented in AWS doc/blog as a possible use case. My **questions**/**doubts** are: 1. Which of the following approaches do you think is the best option in terms of configuration effort/operational efficiency? My idea is that the 1st is the more old-fashion, even if it has the advantages of being cost-efficient (since no WAF is used and SGs are free) and well proofed. I would move towards the 3rd approach, if possible. 2. Regarding the **3rd approach**, is it a best practice to use WAF just for this task (to only allow requests coming from CloudFront)? I know that WAF fits both with CloudFront and with ALB, but in the most part of architectural patterns I've seen so far, WAF is always in front of a CloudFront (users -> WAF -> CF -> ALB -> compute_service). 3. Regarding the **3rd approach**, is it secure to use a custom header that is basically a constant string over time? Or should I disregard this, as at the end of the day we encrypt it through HTTPS? Thanks for sharing your perspective on that. [2]: https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/ [3]: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-ipset-match.html [4]: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html [5]: https://www.metaltoad.com/blog/how-to-protect-origin-with-aws-waf-shield
1
answers
0
votes
2
views
Emanuele Cuoccio
asked 2 years ago

Can't Associate WebACL to API Gateway by CloudFormation

I have an issue to use CloudFormation to add WAF to my API Gateway. My yaml is like: ``` AWSTemplateFormatVersion: "2010-09-09" Transform: AWS::Serverless-2016-10-31 Description: "Service" Resources: WebACL: Type: AWS::WAFv2::WebACL Properties: DefaultAction: Allow: {} Scope: REGIONAL VisibilityConfig: CloudWatchMetricsEnabled: true MetricName: WafACL SampledRequestsEnabled: true Rules: - Name: AWS-AWSManagedRulesCommonRuleSet Priority: 0 Statement: ManagedRuleGroupStatement: VendorName: AWS Name: AWSManagedRulesCommonRuleSet ExcludedRules: - Name: GenericRFI_BODY OverrideAction: None: {} VisibilityConfig: CloudWatchMetricsEnabled: true MetricName: AWSManagedRulesCommonRuleSet SampledRequestsEnabled: false WebACLAssociation: Type: AWS::WAFv2::WebACLAssociation Properties: ResourceArn: !Sub "arn:aws:apigateway:ap-northeast-1::/restapis/${ServerlessRestApi}/stages/${ServerlessRestApiProdStage}" WebACLArn: !Ref WebACL ``` Then the WebACL can create successfully. But the association will fail. The error message is: An error occurred (WAFInvalidParameterException) when calling the AssociateWebACL operation: Error reason: The ARN isn’t valid. A valid ARN begins with arn: and includes other information separated by colons or slashes., field: RESOURCE_ARN I also try to write the ARN directly without using Sub and confirmed it is same format as in the article: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html I found an question on StackOverflow is exactly same as my issue and he also use aws-cli to do the same job and got the same error: https://stackoverflow.com/questions/60955745/applying-webacl-to-api-gateway Edited by: othree3 on Apr 6, 2020 11:37 PM
3
answers
0
votes
0
views
othree3
asked 2 years ago
  • 1
  • 90 / page