What's new

Country Whitelist and Explicit Deny with ipset

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

WQ6N

Occasional Visitor
First, I do wish to say thank you for the ipset wiki and ASUSWRT-Merlin resources.

I have taken a different approach from the BlockedCountry ipset nethash configuration. Instead of creating lists for multiple blocked countries, I have created a WhitelistCountry ipset nethash, which is allowed, and the default to explicitly deny all other IP's.

The script was rearranged to insert (I) the allowed iptable INPUT rules last (e.g. Whitelist and WhitelistCountry) which puts them before any blocked rules. The last rule for INPUT was appended (A) -j DROP default.

Prior to the allowed whitelists, I have created additional Blocks (e.g. DShield, Spider...) from the iblocklist site to address emerging threats. As of right now this is a manual process to create the specific lists with in the ipset_lists folder.

Realizing there is a balance between how many countries you want to block and how many you allow. The explicit deny rule was the main driver for my implementation.

Any pre-routing (port forwarding) rules (VSERVER) bypass the ipset rules. As secondary Firewall/IPS is recommended for those protocols.

So far, the router seems to be happy and functional providing a filtered outer DMZ. Hope this provides food for thought when creating your enclave.
 
Very good, can you share your script? If that is something that is more useful, feel free to update the wiki with a working script.

Prior to the allowed whitelists, I have created additional Blocks (e.g. DShield, Spider...) from the iblocklist site to address emerging threats. As of right now this is a manual process to create the specific lists with in the ipset_lists folder.

You can probably leverage the generic iblocklist loader. It aims to automate the list creation. You can use BLOCKLIST_INDEXES="13 15" for spider and dshield you can add more from the list.

I can probably create a ALLOWLIST_INDEXES and have the countries defined in https://www.iblocklist.com/lists?category=country to implement something similar to what you are trying to implement. I can have both ALLOWLIST_INDEXES and BLOCKLIST_INDEXES work off both lists, for example.
 
Last edited:
Thank you for you comments. I am embarrassed to say that I just used the original create-ipset-lists.sh script as the baseline and made some adjustments. For the most part, any incoming packet will filter through the suite of ipset rules prior to being allowed.

The Whitelist is a leap of faith exception. By listing this at the top of the stack, you are accepting these IP address/subnets as trusted resources and they will not be hijacked or impacted. The other side of the sword is, if one changes the location of the Whitelist, a bad actor could potentially place the address/subnet on one of the blocked list which would deny the source address. For example, if someone places a trusted source on the TorNodes list and the Whitelist is below that list, your system would deny that source. We put a lot of trust in the maintainers of those blocked lists. As with any filter configuration it is highly advised to know your customers/sources first prior to blocking.

With-in any whitelisted country, there are undesired sites that one would want to filter prior to accepting the WhitelistCountries sources. That is where the BlockBadDomain nethash comes in. I have been collecting these for some 10 years now and the list keeps growing. The BlockBadDomain list mainly consist of hosting sites that allow enumeration from with in (e.g. Several sell IP address space to China, Russia... which allows the enumeration to happen inside of the US address space [Rackspace, Yandex, Level 3 and even AWS are examples]) and/or ISP's that never update the infrastructure (e.g. WAN modems, routers, security appliances... [COMCAST, VOIP Servers, RR and even AT&T) that have been compromised by bad actors. These compromised platforms are rarely blocked by the egress filters that allows them to spread at leisure. I do not plan to share this list but one can always create their own.

As a note one can always change the location of the Insert (iptables -I INPUT <line number> -m set --match-set <ipset-list> src -j ACCEPT) and 'ipset flush <ipset-list>' is an easy way to update a list and don't forget to save your individual ipset lists 'ipset save <ipset-list>'.

Keeping the though regarding a limited number of writes to the internal SSD in mind. I do not mind doing manual updates. The pfBlockerNG is a wonderful reference and source. It is my opinion that anyone standing up a enclave, from home to small-medium businesses, should employ multiple layers of Defense in Depth (DiD) in front of any internal Trusted LAN segment. I do not recommend someone using an old platform for internal firewalls or IDS/IPS. Instead, spend a little on a embedded quad processor with decent RAM for a low power security appliance solution. I also recommend a similar SIEM opensource appliance to keep tabs on what your enclave is doing (e.g. Elastic Stack, OSSEC...). It is a good thing to know what is Normal and provide an alert for anything outside of that definition internal of ones enclave. Humans are indeed the weakest link to any security boundary.

That attached file will need some adjustment to address proper line carriage returns/line length.

This is a work in progress for me. All good.
 

Attachments

  • create-ipset-lists.txt
    11.1 KB · Views: 517

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top