Meraki MX: how to block “malicious” IPs inbound on an active port-forward?

[AS4IT]

Problem Description

• I have a Meraki MX with a 1:1 NAT + port-forward exposing public IP A to internal host B on TCP/UDP ports X (Remote IPs = any).

• A Barracuda XDR alert flagged suspicious traffic from C (SSH brute-force, VNC on port Y, C2 activity, etc.) and I want to prevent any inbound connections from that IP.

• I tried creating an Outbound rule to deny traffic to C, but that only blocks LAN→WAN traffic: it does not stop the outside from initiating connections to my already-exposed service.

---

My Question

1. Is there a native way on Meraki MX to insert a “deny” for specific Remote IPs in a port-forward (i.e. “any except C”)?

2. If not, what architecture or workaround would you recommend to:

   • continue exposing the service (e.g. HTTPS on ports X)

   • but exclude certain IPs or ranges deemed malicious?

Thanks in advance for your suggestions!

[alemabrahao]

No, what you can do is just release specific IPs.

[PhilipDAth · Accepted solution]

Yes.  You have to create a L7 firewall rule.  This blocks both inbound and outbound traffic.

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_a_Layer_7_Fi...

Other related block categories:

> what architecture or workaround

I would personally recommend using a WAF, like Amazon AWS WAF.

https://aws.amazon.com/waf/

First choice, host the entire web app in AWS and use AWS WAF in front of it.

Second choice, create a VPN to Amazon AWS, create a load balancer that includes your on-premise host,  and attach a WAF to the load balancer.  Close all inbound NATs to the on-premise server.

Third choice, use Amazon CloudFront with a WAF, and have it connect directly to your NAT.

[Tony-Sydney-AU]

Nice @PhilipDAth !! Being an ex-AWS employee I loved your solution! Nothing better than a full armour against DDoS and other attacks. Combining WAF and a Load Balancer or CloudFront and WAF is a powerfull solution.

Migrating the Web App to cloud and protecting it with cloud-native solutions (first choice) would keep your MX firewall mostly out of the hacker's scope. I.e.: allow-list and/or Layer-7 country deny rule filter the attacks BUT the MX would still have to deal with discarding the packets. Therefore, in a DDoS situation MX might slow down or even stop due to high CPU usage.

However, the downside is cost increase plus the time to migrate the web app to cloud.

Second and third choices are great as they don't require migrating the web app to cloud. But still, this is kind of an overkill from a cost perspective.

@alemabrahao solution would be my first choice but I understand most companies don't know the source IP. So the ideal (from a cost perspective) is just do Layer-7 country deny rules.

What I personally do is to google what are the top 10 attacking source countries and add those to my country deny list.

And of course, no solution comes without a downside / side-effect. In my case is the ones I already mentioned (MX would still be a target) but the problem is sometimes you end up blocking legit traffic. E.g.: some web pages might host part of the content on a denied country or maybe some of your web app clients do come from those countries.

If you get affected by those scenarios perhaps it's better to increase your budget and move your web app to the cloud and protect it with cloud native solutions.