[Basspig]

Is it possible to block whole countries' IP blocks in the present firmware version for this router? I'm doing it in the Windows Firewall, but I'd like to block it at the router if possible.
If this is possible, how does one go about it?

[eibgrad]

Outbound? Inbound? Both?

It matters because, for example, you could block DNS for specific countries by adding something like the following to DNSMasq.

address=/.ru/0.0.0.0

IOW, any domain name for the Russia TLD can't be resolved. But that does NOTHING to prevent inbound access from public IPs for the same TLD. In this latter case, you'd need a database containing information that links domain names to location (they do exist but are usually prohibitively large for the router, and sometimes costly since it needs continual updating) and an iptables netfilter/extension (iirc, geoip) that references that database, or instead, perhaps firewall rules using ipset w/ that same database.

All that said, even if "technically" it works, it's a simple matter for the inbound traffic to be routing through a VPN w/ a public IP that's unlikely to be blocked.

BTW, your PC's firewall stands a far better chance of supporting such functionality because of its much greater resources, both processing power and storage capacity. Anything done on the router itself is unlikely to be as efficient and functional. You'd be better off offloading it to something like a pihole (which probably has this capability built-in).

So unless you only have a need for outbound protection through DNSMasq as I described above (simple and lightweight), I would NOT recommend using the router.

[Basspig]

The reason I asked is because there's been a sudden uptick in hackerbots hitting my router since June 12. My nginx logs used to average 250MB for a whole year. In just a few days, the newest log grew to 9GB!

So I wish to block entire countries INcoming traffic for that reason. The server is a small fanless mini computer, not much horsepower. Would prefer to reserve it for serving webpages and media if possible.

The database doesn't have to be updated constantly. Even if I can block 70% of the traffic, it would take huge load off my server.

[Per Yngve Berg]

My only suggestion is to put another server in front with Nginx or Træffik configured as a Reverse Proxy.

[Basspig]

I had been thinking about a PFSense box ahead of the main router to pre filter all that traffic, but I am not that knowledgeable on this stuff, and don't understand how a reverse proxy works or how to configure it.

[eibgrad]

Is this web server open to the public generally, or ONLY for your own use? Because if it's the latter, you shouldn't be exposing it directly anyway. Instead, use a VPN server and reference the web server's private ip. Or else use something other than the well-known ports (80/443) for the web server. For home users, the use of well-known ports for *any* services offered via the WAN is just asking for trouble. A little bit of "security through obscurity" can go a long way.

[Basspig]

It's a public server, a "web" server, so it has to be exposed.

I have an nginx server running RTMP streaming and that server's logs are seeing a lot of traffic since 6/12. Strings with /XX0/00X/ like strings.

VPNs are expensive, and slow, so I don't think that would be a good solution for the server.

I thought about Cloudfare, which is said to have free tier for filtering requests to the server. Might try that.

But from the responses here, I assume the answer is "no" for blocking countries in DD-WRT.

[eibgrad]

The following is how *I* would do it on the router.

https://blog.ip2location.com/knowledge-base/how-to-block-ip-addresses-from-a-country-using-ipset/

This assumes that ipset is enabled on the router (I know it is for some builds, but not all (e.g., x86 does NOT (which frankly baffles me)). You can verify whether your router does support it w/ the following command.

[eibgrad]

I should add that the link I provided is the "general" approach I would take. It assumes the target device itself is filtering via iptables. That's why it does the checking on the INPUT chain of the filter table. For router purposes, it would make more sense to check on the PREROUTING chain of the nat table. That would limit the checking to only when a new connection is being attempted. If no match is found, subsequent packets do NOT need to be checked! That link makes the mistake of having to check each and every packet on the INPUT chain, unless there's a RELATED/ESTABLISHED ... ACCEPT rule before it. If not, then he could have just checked on the first packet (i.e., -m state --state NEW) to avoid further checking.

IOW, you need to slightly adapt what the author suggests to meet the unique needs of the router.