11

At a maximum, a VPC network ACL can have 40 rules applied.

I have a list of over 50 IP addresses that I need to explicitly block access to in our systems, over any port and any protocol. This is an ideal purpose for an ACL, but the limit is hindering me completing this task.

Of course, I can do this in IPTables on each host, but I want to block any and all traffic to all components in the VPC (to ELB's for example). Furthermore it's far more ideal to manage these rules in one place rather than on each and every host.

I am hoping there is some way I am not understanding doing this at the system/platform level. Security groups are explicit allow, with no deny action, so they won't do the trick.

  • Use provisioning software like Ansible for iptables management and you are done. Obviously it will work only in EC2 instances; not LBs etc. – Kyslik Apr 14 at 16:29
  • Yes I agree doing iptables is fine for EC2 but 99% of my inbound traffic hits our ELB structure. We would be paying for many hits from these known scammers we have to deal with. Thanks for the input – emmdee Apr 14 at 20:53
  • 1
    Blocking 50 individual IPs seems like an odd requirement. – immibis Apr 14 at 22:34
  • @immibis Odd for you maybe. We get a lot of scammers trying to screw with our legit customers. We block their accounts but also d full IP bans for like obvious Russian/Nigerian/Chinese scammers. Our product has a lot of user interaction, chat/etc - totally not odd for a platform like that. – emmdee Apr 14 at 22:50
  • 1
    ... and none of your scammers have dynamic IPs? – immibis Apr 14 at 23:38
8

Here’s a left-field idea.. you could “null-route” the 50 blocked IPs, by adding an “broken” route to the VPC route table for each IP.

This wouldn’t prevent the traffic from the IPs hitting your infrastructure (only the NACLs and the SGs will prevent that), but it’ll prevent the return traffic from every making it “back home”..

  • I accidentally null routed traffic once by creating a transit gateway, setting up routing, then deleting the transit gateway. There may be an easier way though. – Tim Apr 14 at 20:08
  • Not a bad idea. Very out of the box thinking thanks. I'll do some experimentation. Might be the right way to go without paying for WAF – emmdee Apr 14 at 20:54
0

There's no way to increase the limit on NACLs, and a high number of NACL rules impacts network performance.

You may have an architectural issue above all.

  1. Do your instances have to be in public subnets?
  2. Have you set up NAT gateways to limit inbound traffic?
  3. For those instances that must be in public subnets do you have minimal inbound security group rules?
  4. Are you using AWS WAF IP match conditions to block unwanted traffic to CloudFront and your load Balancers?

If you're hitting the NACL rule limit it's most likely because you're not taking the AWS recommended approach to VPC architecture and use of services like WAF (and Shield for DDoS) to block unwanted traffic and overt attacks.

If your concern is DDoS attacks: How to Help Protect Dynamic Web Applications Against DDoS Attacks by Using Amazon CloudFront and Amazon Route 53

  • NAT gateways are for outbound traffic rather than inbound. – Tim Apr 14 at 20:09
  • Correct @Tim, so putting your instances in private subnets behind NAT gateways gives them outbound connectivity without opening them up to inbound attacks, and no need to block IPs in NACLs – Fo. Apr 14 at 20:28
  • WAF is pretty expensive for very high traffic websites. Trying to avoid it for that reason. The fact that security groups can't explicit block and web ACL has this limit seems just like a major cash grab. – emmdee Apr 14 at 20:52
  • I guess it depends on the use case, which hasn't been explained. If the reason to block these IPs is they've been attacking a web server, there still needs to be public access to the servers, which means a load balancer or proxy. A private subnet wouldn't help in that case. – Tim Apr 14 at 20:52
  • My use case is 99% ELB's taking the inbound traffic. EC2 instances are private behind ELB's. – emmdee Apr 14 at 20:55
0

This isn't exactly what you asked for, but may do the job well enough.

Set up CloudFront in front of your infrastructure. Use IP Match Conditions to effectively block traffic. CloudFront works with both static and dynamic content, and can accelerate dynamic content as it uses the AWS backbone rather than the public internet. Here's what the docs say

If you want to allow some web requests and block others based on the IP addresses that the requests originate from, create an IP match condition for the IP addresses that you want to allow and another IP match condition for the IP addresses that you want to block.

When using CloudFront you should block direct access to any public resources using security groups. The AWS Update Security Groups lambda will keep your security groups up to date to allow CloudFront traffic in but reject other traffic. If you redirect http to https using CloudFront you can tweak the scripts a bit to prevent http hitting your infrastructure. You can also whitelist any IPs that need direct admin access.

Alternately, you could use a third party CDN such as CloudFlare. CloudFlare have an effective firewall, but for the number of rules you want it's $200 per month. That may well be cheaper than CloudFront, AWS bandwidth is fairly expensive. The free plan only gives you 5 firewall rules.

  • We already use cloud front for static content but lots of the sites are dynamic web content. – emmdee Apr 14 at 20:57
  • CloudFront can also be used for dynamic content aws.amazon.com/blogs/networking-and-content-delivery/… – Fo. Apr 14 at 21:08
  • CloudFront can accelerate dynamic content, I believe it uses the AWS backbone rather than the public internet. CloudFront has slightly cheaper bandwidth than EC2, and I think I saw an announcement a while back that bandwidth CloudFront back to EC2 is free. – Tim Apr 14 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.