mirror
/
openwrt-packages
mirror of https://git.openwrt.org/feed/packages.git
1
0
Fork 0
Code Releases Activity

Merge fc35918026 into 660aa8091f

This commit is contained in:
friendly-bits 2024-04-18 15:35:07 +03:00 committed by GitHub
parent 660aa8091f fc35918026
commit 4efd1d6444
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
6 changed files with 680 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

147
net/geoip-shell/DETAILS.md Normal file
View File

@ -0,0 +1,147 @@
## **Prelude**
- This document only covers scripts installed on OpenWrt systems and only options available on OpenWrt.
- geoip-shell supports a numer of different use cases, many different platforms, and 2 backend firewall utilities (nftables and iptables). For this reason I designed it to be modular rather than monolithic. In this design, the functionality is split between few main scripts. Each main script performs specific tasks and utilizes library scripts which are required for the task with the given platform and firewall utility.
- This document provides some info on the purpose and core options of the main scripts and how they work in tandem.
- The main scripts display "usage" when called with the "-h" option. You can find out about some additional options specific to each script by running it with that option.
## **Overview**
### Main Scripts
- geoip-shell-install.sh
- geoip-shell-uninstall.sh
- geoip-shell-manage.sh
- geoip-shell-run.sh
- geoip-shell-fetch.sh
- geoip-shell-apply.sh
- geoip-shell-backup.sh
- geoip-shell-cronsetup.sh
### Helper Scripts
**geoip-shell-geoinit.sh**
- This script is sourced from all main scripts. It sets some essential variables, checks for compatible shell, then sources the -lib-common script, then sources the /etc/geoip-shell/geoip-shell.const file which stores some system-specific constants.
**geoip-shell-detect-lan.sh**
This script is only used under specific conditions:
- During initial setup, with whitelist mode, and only if wan interfaces were set to 'all', and LAN subnets were not specified via command line args. geoip-shell then assumes that it is being installed on a machine belonging to a LAN, uses this script to detect the LAN subnets and offers the user to add them to the whitelist, and to enable automatic detection of LAN subnets in the future.
- At the time of creating/updating firewall rules, and only if LAN subnets automatic detection is enabled. geoip-shell then re-detects LAN subnets automatically.
### Library Scripts
- lib/geoip-shell-lib-common.sh
- lib/geoip-shell-lib-setup.sh
- lib/geoip-shell-lib-ipt.sh
- lib/geoip-shell-lib-nft.sh
- lib/geoip-shell-lib-status.sh
- lib/geoip-shell-lib-arrays.sh
- lib/geoip-shell-lib-uninstall.sh
The -lib-common script includes a large number of functions used throughout the suite, and assigns some essential variables.
The lib-setup script implements CLI interactive and noninteractive setup and arguments parsing. It is used in the -manage script.
The -lib-status script implements the status report which you can get by issuing the `geoip-shell status` command.
The -ipt and -nft scripts implement support for iptables and nftables, respectively. They are sourced from other scripts which need to interact with the firewall utility directly.
The -lib-arrays script implements a minimal subset of functions emulating the functionality of associative arrays in POSIX-compliant shell. It is used in the -fetch script. It is a part of a larger project implementing much more of the arrays functionality. You can check my other repositories if you are interested.
The -lib-uninstall script has some functions which are used both for uninstallation and for reset if required.
### OpenWrt-specific scripts
- geoip-shell-lib-owrt-common.sh
- geoip-shell-init
- geoip-shell-mk-fw-include.sh
- geoip-shell-fw-include.sh
- geoip-shell-owrt-uninstall.sh
For more information about integration with OpenWrt, read [OpenWrt-README.md](OpenWrt-README.md)
### User interface
The scripts intended as user interface are **geoip-shell-install.sh**, **geoip-shell-uninstall.sh**, **geoip-shell-manage.sh** and **check-ip-in-source.sh**. All the other scripts are intended as a back-end. If you just want to install and move on, you only need to run the -install script.
After installation, the user interface is provided by running "geoip-shell", which is a symlink to the -manage script.
## **Main scripts in detail**
**geoip-shell-manage.sh**: serves as the main user interface to configure geoip after installation. You can also call it by simply typing `geoip-shell`. As most scripts in this suite, it requires root privileges because it needs to interact with the netfilter kernel component and access the data folder which is only readable and writable by root. Since it serves as the main user interface, it contains a lot of logic to generate a report, parse, validate and initiate actions requested by the user (by calling other scripts as required), check for possible remote machine lockout and warn the user about it, check actions result, update the config and take corrective actions in case of an error. Describing all this is beyond the scope of this document but you can read the code. Sources the lib-status script when generating a status report. Sources lib-setup for some of the arguments parsing logic and interactive dialogs implementation.
`geoip-shell <on|off> [-c <"country_codes">]` : Enable or disable the geoip blocking chain (via a rule in the base geoip chain)
`geoip-shell <add|remove> [-c <"country_codes">]` :
* Adds or removes the specified country codes to/from the config file.
* Calls the -run script to fetch the ip lists for specified countries and apply them to the firewall (or to remove them).
`geoip-shell status`
* Displays information on the current state of geoip blocking
* For a list of all firewall rules in the geoip chain and for detailed count of ip ranges, run `geoip-shell status -v`.
`geoip-shell restore` : re-fetches and re-applies geoip firewall rules and ip lists as per the config.
`geoip-shell configure [options]` : changes geoip-shell configuration
**Options for the `geoip-shell configure` command:**
`-m [whitelist|blacklist]`: Change geoip blocking mode.
`-c <"country codes">`: Change which country codes are included in the whitelist/blacklist (this command replaces all country codes with newly specified ones).
`-f <ipv4|ipv6|"ipv4 ipv6">`: Families (defaults to 'ipv4 ipv6'). Use double quotes for multiple families.
`-u [ripe|ipdeny]`: Change ip lists source.
`-i <[ifaces]|auto|all>`: Change which network interfaces geoip firewall rules are applied to. `auto` will attempt to automatically detect WAN network interfaces. `auto` works correctly in **most** cases but not in **every** case. Don't use `auto` if the machine has no direct connection to WAN. The automatic detection occurs only when manually triggered by the user via this command.
`-l <"[lan_ips]"|auto|none>`: Specify LAN ip's or subnets to exclude from blocking (both ipv4 and ipv6). `auto` will trigger LAN subnets re-detection at every update of the ip lists. When specifying custom ip's or subnets, automatic detection is disabled. This option is only avaiable when using geoip-shell in whitelist mode.
`-t <"[trusted_ips]|none">`: Specify trusted ip's or subnets (anywhere on the Internet) to exclude from geoip blocking (both ipv4 and ipv6).
`-p <[tcp|udp]:[allow|block]:[all|<ports>]>`: specify ports geoip blocking will apply (or not apply) to, for tcp or udp. To specify ports for both tcp and udp, use the `-p` option twice. For more details, read [NOTES.md](NOTES.md), sections 9-11.
`-r <[user_country_code]|none>` : Specify user's country code. Used to prevent accidental lockout of a remote machine. `none` disables this feature.
`-s <"schedule_expression"|disable>` : enables automatic ip lists updates and configures the schedule for the periodic cron job which implements this feature. `disable` disables automatic ip lists updates.
`-o <true|false>` : No backup. If set to 'true', geoip-shell will not create a backup of ip lists and firewall rules after applying changes, and will automatically re-fetch ip lists after each reboot. Default is 'true' for OpenWrt, 'false' for all other systems.
`-a <path>` : Set custom path to directory where backups and the status file will be stored. Default is '/tmp/geoip-shell-data' for OpenWrt, '/var/lib/geoip-shell' for all other systems.
`-O <memory|performance>`: specify optimization policy for nftables sets. By default optimizes for low memory consumption if system RAM is less than 2GiB, otherwise optimizes for performance. This option doesn't work with iptables.
`geoip-shell showconfig` : prints the contents of the config file.
**geoip-shell-run.sh**: Serves as a proxy to call the -fetch, -apply and -backup scripts with arguments required for each action. Executes the requested actions, depending on the config set by the -install and -manage scripts, and the command line options, and writes to system log when starting and on action completion (or if any errors encountered). If persistence or autoupdates are enabled, the cron jobs (or on OpenWrt, the firewall include script) call this script with the necessary options. If a non-fatal error is encountered during an automatic update function, the script enters sort of a temporary daemon mode where it will re-try the action (up to a certain number of retries) with increasing time intervals. It also implements some logic to account for unexpected issues encountered during the 'restore' action which runs after system reboot to impelement persistnece, such as a missing backup, and in this situation will automatically change its action from 'restore' to 'update' and try to re-fetch and re-apply the ip lists.
`geoip-shell-run add -l <"list_id [list_id] ... [list_id]">` : Fetches ip lists, loads them into ip sets and applies firewall rules for specified list id's.
A list id has the format of `<country_code>_<family>`. For example, ****US_ipv4** and **GB_ipv6** are valid list id's.
`geoip-shell-run remove -l <"list_ids">` : Removes iplists and firewall rules for specified list id's.
`geoip-shell-run update` : Updates the ip sets for list id's that had been previously configured. Intended for triggering from periodic cron jobs.
`geoip-shell-run restore` : Restore previously downloaded lists from backup (skip fetching). Used by the reboot cron job (or by the firewall include on OpenWrt) to implement persistence.
**geoip-shell-fetch.sh**
- Fetches ip lists for given list id's from RIPE or from ipdeny. The source is selected during installation. If you want to change the default which is RIPE, install with the `-u ipdeny` option.
- Parses, validates, compiles the downloaded lists, and saves each one to a separate file.
- Implements extensive sanity checks at each stage (fetching, parsing, validating and saving) and handles errors if they occur.
(for specifics on how to use the script, run it with the -h option)
**geoip-shell-apply.sh**: directly interfaces with the firewall. Creates or removes ip sets and firewall rules for specified list id's. Sources the lib-apply-ipt or lib-apply-nft script which does most of the actual work.
`geoip-shell-apply add -l <"list_ids">` :
- Loads ip list files for specified list id's into ip sets and applies firewall rules required for geoip blocking.
List id has the format of `<country_code>_<family>`. For example, **US_ipv4** and **GB_ipv6** are valid list id's.
`geoip-shell-apply remove -l <"list_ids">` :
- removes ip sets and geoip firewall rules for specified list id's.
**geoip-shell-cronsetup.sh** manages all the cron-related logic and actions. Called by the -manage script. Cron jobs are created based on the settings stored in the config file. Also used to validate cron schedule provided by the user at the time of installation or later.
**geoip-shell-backup.sh**: Creates a backup of current geoip-shell firewall rules and ip sets and current geoip-shell config, or restores them from backup. By default (if you didn't run the installation with the '-o' option), backup will be created after every change to ip sets in the firewall. Backups are automatically compressed and de-compressed with the best utility available to the system, in this order "bzip2, xz, gzip", or simply "cat" as a fallback if neither is available (which generally should never happen on Linux). Only one backup copy is kept. Sources the lib-backup-ipt or the lib-backup-nft script which does most of the actual work.
`geoip-shell-backup create-backup` : Creates a backup of the current firewall state and geoip blocking config.
`geoip-shell-backup restore` : Restores the firewall state and the config from backup. Used by the *run script to implement persistence. Can be manually used for recovery from fault conditions.

162
net/geoip-shell/Makefile Normal file
View File

@ -0,0 +1,162 @@
# Copyright 2024 friendly-bits, antonk (antonk.d3v@gmail.com)
# This is free software, licensed under the GNU General Public License v3.
include $(TOPDIR)/rules.mk
PKG_NAME:=geoip-shell
PKG_VERSION:=0.5
PKG_RELEASE:=r2
PKG_LICENSE:=GPL-3.0-or-later
PKG_MAINTAINER:=antonk <antonk.d3v@gmail.com>
PKG_SOURCE_PROTO:=git
PKG_SOURCE_VERSION:=3b56796aea49d7ae1e5ce3de1f5ccfafd36c7f3f
PKG_SOURCE_URL:=https://github.com/friendly-bits/geoip-shell-openwrt.git
PKG_MIRROR_HASH:=2a6cb1996fc7c48f146267e193fe1812addeb228adc5fe16a55341509d4a5353
include $(INCLUDE_DIR)/package.mk
define Package/geoip-shell/Default
CATEGORY:=Network
TITLE:=Flexible geoip blocker
URL:=https://github.com/friendly-bits/geoip-shell
MAINTAINER:=antonk <antonk.d3v@gmail.com>
DEPENDS:=+ca-bundle
PROVIDES:=geoip-shell
PKGARCH:=all
endef
define Package/geoip-shell
$(call Package/geoip-shell/Default)
TITLE+= with nftables support
DEPENDS+= +kmod-nft-core +nftables +firewall4
DEFAULT_VARIANT:=1
VARIANT:=nftables
endef
define Package/geoip-shell-iptables
$(call Package/geoip-shell/Default)
TITLE+= with iptables support
DEPENDS+= +kmod-ipt-ipset +IPV6:ip6tables +iptables +ipset
VARIANT:=iptables
CONFLICTS:=geoip-shell firewall4
endef
define Package/geoip-shell/description/Default
Flexible geoip blocker with a user-friendly command line interface (currently no LuCi interface).
For readme, please see
https://github.com/openwrt/packages/blob/master/net/geoip-shell/OpenWrt-README.md
endef
define Package/geoip-shell/description
$(call Package/geoip-shell/description/Default)
endef
define Package/geoip-shell-iptables/description
$(call Package/geoip-shell/description/Default)
endef
define Package/geoip-shell/postinst/Default
#!/bin/sh
rm "/usr/bin/geoip-shell" 2>/dev/null
ln -s "/usr/bin/geoip-shell-manage.sh" "/usr/bin/geoip-shell"
[ -s "/etc/geoip-shell/geoip-shell.conf" ] && /usr/bin/geoip-shell configure -z && exit 0
logger -s -t "geoip-shell" "Please run 'geoip-shell configure' to complete the setup."
exit 0
endef
define Package/geoip-shell/postinst
$(call Package/geoip-shell/postinst/Default)
endef
define Package/geoip-shell-iptables/postinst
$(call Package/geoip-shell/postinst/Default)
endef
define Package/geoip-shell/prerm/Default
#!/bin/sh
sh /usr/lib/geoip-shell/geoip-shell-owrt-uninstall.sh
exit 0
endef
define Package/geoip-shell/prerm
$(call Package/geoip-shell/prerm/Default)
endef
define Package/geoip-shell-iptables/prerm
$(call Package/geoip-shell/prerm/Default)
endef
define Package/geoip-shell/postrm
#!/bin/sh
sleep 1
echo "Reloading the firewall..."
fw4 -q reload
exit 0
endef
define Package/geoip-shell-iptables/postrm
#!/bin/sh
sleep 1
echo "Reloading the firewall..."
fw3 -q reload
exit 0
endef
define Build/Configure
endef
define Build/Compile
endef
define Package/geoip-shell/install/Default
$(INSTALL_DIR) $(1)/etc/init.d
$(INSTALL_BIN) $(PKG_BUILD_DIR)/etc/init.d/geoip-shell-init $(1)/etc/init.d
$(INSTALL_DIR) $(1)/etc/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/etc/geoip-shell/cca2.list $(1)/etc/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/etc/geoip-shell/geoip-shell.const $(1)/etc/geoip-shell
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-fetch.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-fw-include.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-backup.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-geoinit.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-run.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-mk-fw-include.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-manage.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-apply.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-detect-lan.sh $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/bin/geoip-shell-cronsetup.sh $(1)/usr/bin
$(INSTALL_DIR) $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-status.sh $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-owrt-common.sh $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-common.sh $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-owrt-uninstall.sh $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-arrays.sh $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-setup.sh $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-uninstall.sh $(1)/usr/lib/geoip-shell
endef
define Package/geoip-shell/install
$(call Package/geoip-shell/install/Default,$(1))
$(INSTALL_DIR) $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-nft.sh $(1)/usr/lib/geoip-shell
endef
define Package/geoip-shell-iptables/install
$(call Package/geoip-shell/install/Default,$(1))
$(INSTALL_DIR) $(1)/usr/lib/geoip-shell
$(INSTALL_CONF) $(PKG_BUILD_DIR)/usr/lib/geoip-shell/geoip-shell-lib-ipt.sh $(1)/usr/lib/geoip-shell
endef
$(eval $(call BuildPackage,geoip-shell))
$(eval $(call BuildPackage,geoip-shell-iptables))

108
net/geoip-shell/NOTES.md Normal file
View File

@ -0,0 +1,108 @@
## **Notes**
1) On OpenWrt, geoip-shell expects that the default shell (called by the `sh` command) is _ash_, and the automatic shell detection feature implemented for other platforms is disabled on OpenWrt.
2) Firewall rules structure created by geoip-shell:
<details> <summary>Read more:</summary>
### **iptables**
- With **iptables**, all firewall rules created by geoip-shell are in the table `mangle`. The reason to use `mangle` is that this table has a built-in chain called `PREROUTING` which is attached to the `prerouting` hook in the netfilter kernel component. Via a rule in this chain, geoip-shell creates one set of rules which applies to all ingress traffic for a given ip family, rather than having to create and maintain separate rules for chains INPUT and FORWARDING which would be possible in the default `filter` table.
- This also means that any rules you might have in the `filter` table will only see traffic which is allowed by geoip-shell rules, which may reduce the CPU load as a side-effect.
- Note that **iptables** features separate tables for ipv4 and ipv6, hence geoip-shell creates separate rules for each family (unless the user restricts geoip-shell to a certain family during installation).
- Inside the table `mangle`, geoip-shell creates the custom chain `GEOIP-SHELL` and redirects traffic to it via a rule in the `PREROUTING` chain. geoip-shell calls that rule the "enable" rule which can be removed or re-added on-demand with the commands `geoip-shell on` and `geoip-shell off`. If the "enable" rule is not present, system firewall will act as if all other geoip-shell rules (for a given ip family) are not present.
- If specific network interfaces were set during installation, the "enable" rule directs traffic to a 2nd custom chain `GEOIP-SHELL_WAN` rather than to the `GEOIP-SHELL` chain. geoip-shell creates rules in the `GEOIP-SHELL_WAN` chain which selectively direct traffic only from the specified network interfaces to the `GEOIP-SHELL` chain.
- With iptables, geoip-shell removes the "enable" rule before making any changes to the ip sets and rules, and re-adds it once the changes have been successfully made. This is a precaution measure intended to minimize any chance of potential problems. Typically ip list updates do not take more than a few seconds, and on reasonably fast systems less than a second, so the time when geoip blocking is not enabled is typically very brief.
### **nftables**
- With **nftables**, all firewall rules created by geoip-shell are in the table named `geoip-shell`, family "inet", which is a term nftables uses for tables applying to both ip families. The `geoip-shell` table includes rules for both ip families and any nftables sets geoip-shell creates. geoip-shell creates 2 chains in that table: `GEOIP-BASE` and `GEOIP-SHELL`. The base chain attaches to netfilter's `prerouting` hook and has a rule which directs traffic to the `GEOIP-SHELL` chain. That rule is the geoip-shell "enable" rule for nftables-based systems which acts exactly like the "enable" rule in the iptables-based systems, except it applies to both ip families.
- **nftables** allows for more control over which network interfaces each rule applies to, so when certain network interfaces are specified during installation, geoip-shell specifies these interfaces directly in the rules inside the `GEOIP-SHELL` chain, and so (contrary to iptables-based systems) there is no need in an additional chain.
- **nftables** features atomic rules updates, meaning that when issuing multiple nftables commands at once, if any command fails, all changes get cancelled and the system remains in the same state as before. geoip-shell utilizes this feature for fault-tolerance and to completely eliminate time when geoip blocking is disabled during an update of the sets or rules.
- **nftables** current version (up to 1.0.8 and probably 1.0.9) has some bugs related to unnecessarily high transient memory consumption when performing certain actions, including adding new sets. These bugs are known and for the most part, already have patches implemented which should eventually roll out to the distributions. This mostly matters for embedded hardware with less than 512MB of memory. geoip-shell works around these bugs as much as possible. One of the workarounds is to avoid using the atomic replacement feature for nftables sets. Instead, when updating sets, geoip-shell first adds new sets one by one, then atomically applies all other changes, including rules changes and removing the old sets. In case of an error during any stage of this process, all changes get cancelled, old rules and sets remain in place and geoip-shell then destroys the new sets. This is less efficient but with current versions of nftables, this actually lowers the minimum memory bar for the embedded devices. Once a new version of nftables will be rolled out to the distros, geoip-shell will adapt the algorithm accordingly.
### **nftables and iptables**
- With both **nftables** and **iptables**, geoip-shell goes a long way to make sure that firewall rules and ip sets are correct and matching the user-defined config. Automatic corrective mechanisms are implemented which should restore geoip-shell firewall rules in case they do not match the config (which normally should never happen).
- geoip-shell implements rules and ip sets "tagging" to distinguish between its own rules and other rules and sets. This way, geoip-shell never makes any changes to any rules or sets which geoip-shell did not create.
- When uninstalling, geoip-shell removes all its rules, chains and ip sets.
</details>
3) geoip-shell uses RIPE as the default source for ip lists. RIPE is a regional registry, and as such, is expected to stay online and free for the foreseeable future. However, RIPE may be fairly slow in some regions. For that reason, I implemented support for fetching ip lists from ipdeny. ipdeny provides aggregated ip lists, meaning in short that there are less entries for same effective geoip blocking, so the machine which these lists are installed on has to do less work when processing incoming connection requests. All ip lists the suite fetches from ipdeny are aggregated lists.
4) The scripts intended as user interface are: **-install**, **-uninstall**, **-manage** (also called by running '**geoip-shell**' after installation) and **check-ip-in-registry.sh**. The -manage script saves the config to a file and implements coherence checks between that file and the actual firewall state. While you can run the other scripts individually, if you make changes to firewall geoip rules, next time you run the -manage script it may insist on reverting those changes since they are not reflected in the config file. The **-backup** script can be used individually. By default, it creates a backup of geoip-shell state after every successful action involving changes to or updates of the ip lists. If you encounter issues, you can use it with the 'restore' command to restore geoip-shell to its previous state. It also restores the config, so the -manage script will not mind.
5) How to manually check firewall rules created by geoip-shell:
- With nftables: `nft -t list table inet geoip-shell`. This will display all geoip-shell rules and sets.
- With iptables: `iptables -vL -t mangle` and `ip6tables -vL -t mangle`. This will report all geoip-shell rules. To check ipsets created by geoip-shell, use `ipset list -n | grep geoip-shell`. For a more detailed view, use this command: `ipset list -t`.
6) The run, fetch and apply scripts write to syslog in case an error occurs. The run and fetch scripts also write to syslog upon success. To verify that cron jobs ran successfully, on Debian and derivatives run `cat /var/log/syslog | grep geoip-shell`. On other distributions, you may need to figure out how to access the syslog.
7) These scripts will not run in the background consuming resources (except for a short time when triggered by the cron jobs). All the actual blocking is done by the netfilter component in the kernel. The scripts offer an easy and relatively fool-proof interface with netfilter, config persistence, automated ip lists fetching and auto-update.
8) Sometimes ip list source servers are temporarily unavailable and if you're unlucky enough to attempt installation during that time frame, the fetch script will fail which will cause the installation to fail as well. Try again after some time or use another source. Once the installation succeeds, an occasional fetch failure during autoupdate won't cause any issues as last successfully fetched ip list will be used until the next autoupdate cycle succeeds.
9) How to geoblock or allow specific ports (applies to the _-install_ and _-manage_ scripts).
The general syntax is: `-p <[tcp|udp]:[allow|block]:[all|<ports>]>`
Where `ports` may be any combination of comma-separated individual ports or port ranges (for example: `125-130` or `5,6` or `3,140-145,8`).
You can use the `-p` option twice to cover both tcp and udp, for example: `-p tcp:allow:22,23 -p udp:block:128-256,3`
Examples with the -install script:
`sh geoip-shell-install -c de -m whitelist -p tcp:allow:125-135,7` - for tcp, allow incoming traffic on ports 125-135 and 7, geoblock incoming traffic on other tcp ports (doesn't affect UDP traffic)
`sh geoip-shell-install -c de -m blacklist -p udp:allow:3,15-20,1024-2048` - for udp, allow incoming traffic on ports 15-20 and 3, geoblock all other incoming udp traffic (doesn't affect TCP traffic)
Examples with the -manage script (also called via 'geoip-shell' after installation) :
`geoip-shell configure -p tcp:block:all` - for tcp, geoblock all ports (default behavior)
`geoip-shell configure -p udp:allow:all` - for udp, don't geoblock any ports (completely disables geoblocking for udp)
`geoip-shell configure -p tcp:block:125-135,7` - for tcp, only geoblock incoming traffic on ports 125-135 and 7, allow incoming traffic on all other tcp ports
10) How to remove specific ports assignment:
use `-p [tcp|udp]:block:all`.
Example: `geoip-shell configure -p tcp:block:all` will remove prior port-specific rules for the tcp protocol. All tcp packets on all ports will now go through geoip filter.
11) How to make all packets for a specific protocol bypass geoip blocking:
use `p [tcp|udp]:allow:all`
Example: `geoip-shell configure -p udp:allow:all` will allow all udp packets on all ports to bypass the geoip filter.
12) Firewall rules persistence, as well as automatic list updates, is implemented via cron jobs: a periodic job running by default on a daily schedule, and a job that runs at system reboot (after 30 seconds delay). Either or both cron jobs can be disabled (run the *install script with the -h option to find out how, or read [DETAILS.md](DETAILS.md)). On OpenWrt, persistence is implemented via an init script and a firewall include rather than via a cron job.
13) You can specify a custom schedule for the periodic cron job by passing an argument to the install script. Run it with the '-h' option for more info.
14) If you want to change the autoumatic update schedule but you don't know the crontab expression syntax, check out https://crontab.guru/ (no affiliation). geoip-shell includes a script which validates cron expressions you request, so don't worry about making a mistake.
15) Note that cron jobs will be run as root.
16) If you have nftables installed but for some reason you are using iptables rules (via the nft_compat kernel module which is provided by packages like nft-iptables etc), you can and probably should install geoip-shell with the option `-w ipt` which will force it to use iptables+ipset. For example: `geoip-shell install -w ipt`.
17) If you upgrade your system from iptables to nftables, you can either re-install geoip-shell and it will then automatically use nftables, or you can use this command without reinstalling: `geoip-shell configure -w nft`, which will remove all iptables rules and ipsets and re-create nftables rules and sets based on your existing config. If you are on OpenWrt, this does not apply: instead, you will need to install the geoip-shell package for nftables-based OpenWrt.
18) To test before deployment:
<details> <summary>Read more:</summary>
- You can run the install script with the "-N true" (N stands for noblock) option to apply all actions and create all firewall rules except the geoip-shell "enable" rule. This way you can make sure that no errors are encountered and check the resulting firewall rules before committing to actual blocking. To enable blocking later, use the command `geoip-shell on`.
- You can run the install script with the "-n true" (n stands for nopersistence) option to skip creating the reboot cron job which implements persistence and with the '-s disable' option to skip creating the autoupdate cron job. This way, a simple machine restart should undo all changes made to the firewall (unless you have some software which restores firewall settings after reboot). For example: `sh geoip-shell-install -c <country_code> -m whitelist -n true -s disable`. To enable persistence and automatic updates later, reinstall without both options.
</details>
19) How to get yourself locked out of your remote server and how to prevent this:
<details> <summary>Read more:</summary>
There are 4 scenarios where you can lock yourself out of your remote server with this suite:
- install in whitelist mode without including your country in the whitelist
- install in whitelist mode and later remove your country from the whitelist
- blacklist your country (either during installation or later)
- your remote machine has no dedicated WAN interfaces (it is behind a router) and you incorrectly specified LAN subnets the machine belongs to
As to the first 3 scenarios, the -manage script will warn you in each of these situations and wait for your input (you can press Y and do it anyway), but that depends on you correctly specifying your country code during installation. The -install script will ask you about it. If you prefer, you can skip by pressing Enter - that will disable this feature. If you do provide the -install script your country code, it will be added to the config file on your machine and the -manage script will read the value and perform the necessary checks, during installation or later when you want to make changes to the blacklist/whitelist.
As to the 4th scenario, geoip-shell implements LAN subnets automatic detection and asks you to verify that the detected LAN subnets are correct. If you are not sure how to verify this, reading the [SETUP.md](SETUP.md) file should help. Read the documentation, follow it and you should be fine. If you specify your own LAN ip addresses or subnets (rather than using the automatically detected ones), geoip-shell validates them, meaning it makes sure that they appear to be valid by checking them with regex, and asking the kernel. This does not prevent a situation where you provide technically valid ip's/subnets which however are not actually used in the LAN your machine belongs to. So double-check. Also note that LAN subnets **may** change in the future, for example if someone changes some config in the router or replaces the router etc. For this reason, when installing the suite for **all** network interfaces, the -install script offers to enable automatic detection of LAN subnets at each periodic update. If for some reason you do not enable this feature, you will need to make the necessary precautions when changing LAN subnets your remote machine belongs to.
As an additional measure, during installation you can specify trusted ip addresses anywhere on the Internet which will not be geoblocked, so in case something goes very wrong, you will be able to regain access to the remote machine. This does require to have a known static public ip address or subnet. To specify ip's, call the install script with this option: `-t <"[trusted_ips]">`.
</details>

52
net/geoip-shell/OpenWrt-README.md Normal file
View File

@ -0,0 +1,52 @@
## geoip-shell on OpenWrt
Currently geoip-shell fully supports OpenWrt, both with firewall3 + iptables and with firewall4 + nftables, while providing the same user interface and features as on any other Linux system. So usage is the same as described in the main [README.md](README.md) file, while some parts of the backend (namely persistence implementation), some defaults and the location of the data directory are different.
The _geoip-shell-iptables_ package is for firewall3+iptables OpenWrt systems, while the _geoip-shell_ package is for firewall4+nftables OpenWrt systems.
A LuCi interface has not been implemented (yet). As on any other Linux system, all user interface is via a command line (but my goal is to make this an easy experience regardless). If this discourages you from using geoip-shell, please let me know. A few people asking for this feature may motivate me to prioritize it.
## Usage after installation via ipk
After installing the ipk package, geoip-shell will be inactive until you configure it. To do so, run `geoip-shell configure` and follow the interactive setup. You can also run `geoip-shell -h` before that to find out about configuration options and then append certain options after the `configure` action, for example: `geoip-shell configure -c "de nl" -m whitelist` to configure geoip-shell in whitelist mode for countries Germany and Netherlands. The interactive setup will ask you about all the important options but some niche options are only available non-interactively (for example if you want to configure geoblocking for certain selection of ports). You can always change these settings after initial configuration via the same `geoip-shell configure` command.
## Uninstallation of geoip-shell if installed via ipk
- For nftables-based systems: `opkg remove geoip-shell`
- For iptables-based systems: `opkg remove geoip-shell-iptables`
## Resources management on OpenWrt
Because OpenWrt typically runs on embedded devices with limited memory and very small flash storage, geoip-shell implements some techniques to conserve these resources as much as possible:
- During installation on OpenWrt, comments and the debug code are stripped from the scripts to reduce their size.
- Only the required modules are installed, depending on the system (iptables- or nftables- based).
- I've researched the most memory-efficient way for loading ip lists into nftables sets. Currently, nftables has some bugs related to this process which may cause unnecessarily high memory consumption. geoip-shell works around these bugs as much as possible.
- To avoid unnecessary flash storage wear, all filesystem-related tasks geoip-shell does which do not require permanent storage are done in the /tmp directory which in the typical OpenWrt installation is mounted on the ramdisk.
- Some defaults on OpenWrt are different to further minimize flash storage wear (read below).
### Scripts size
Typical geoip-shell installation on an OpenWrt system currently consumes around 120kB. The distribution folder itself weighs quite a bit more (mainly because of documentation) but you can install via an ipk which doesn't remain in storage after installation, or if installing via the -install script, delete the distribution folder and free up space taken by it. geoip-shell does not install its documentation into the system.
I have some plans to reduce that size by compressing certain scripts which provide user interface and implementing automatic extraction to /tmp when the user wants to access them, but this is not yet implemented.
To view all installed geoip-shell scripts in your system and their sizes, run `ls -lh /usr/bin/geoip-shell-* /usr/lib/geoip-shell/*`.
## Persistence on OpenWrt
- Persistence of geoip firewall rules and ip sets works differenetly on OpenWrt than on other Linuxes, since geoip-shell has an OpenWrt-specific procd init script.
- The cron job which implements persistence on other Linuxes and runs at reboot is not created on OpenWrt.
- geoip-shell integrates into firewall3 or firewall4 via what's called a "firewall include". On OpenWrt, a firewall include is a setting which tells firewall3 or firewall4 to do something specific in response to certain events.
- The only task of the init script for geoip-shell is to call the geoip-shell-mk-fw-include.sh script, which makes sure that the firewall include exists and is correct, if not then creates the include.
- The firewall include is what does the actual persistence work. geoip-shell firewall include triggers on firewall reload (which happens either at reboot or when the system decides that a reload of the firewall is necessary, or when initiated by the user).
- When triggered, the include script calls the -run script with the "restore" action.
- The -run script verifies that geoip nftables/iptables rules and ip sets exist, and if not then it restores them from backup, or (if backup doesn't exist) initiates re-fetch of the ip lists and then re-creates the rules and the ip sets.
- By default, geoip-shell does not create backups on OpenWrt because typically the permanent storage is very small and prone to wear.
- Automatic updates of ip lists on OpenWrt are triggered from a cron job like on other Linuxes.
## Defaults for OpenWrt
Generally the defaults are the same as for other systems, except:
- the data directory which geoip-shell uses to store the status file and the backups is by default in `/tmp/geoip-shell-data`, rather than in `/var/lib/geoip-shell` as on other Linux systems. This is to avoid flash wear. You can change this by running the install script with the `-a <path>` option, or after installation via the command `geoip-shell configure -a <path>`.
- the 'nobackup' option is set to 'true', which configures geoip-shell to not create backups of the ip lists. With this option, geoip-shell will work as usual, except after reboot (and for iptables-based systems, after firewall restart) it will re-fetch the ip lists, rather than loading them from backup. You can change this by running the -install script with the `-o false` option (`-o` stands for nobackup), or after installation via the command `geoip-shell configure -o false`. To have persistent ip list backups, you will also need to change the data directory path as explained above.
- if using geoip-shell on a router with just a few MB of embedded flash storage, consider either leaving the nobackup and datadir path defaults as is, or connecting an external storage device to your router (preferably formatted to ext4) and configuring a directory on it as your geoip-shell data directory, then enabling automatic backups. For example, if your external storage device is mounted on _/mnt/somedevice_, you can do all this via this command: `geoip-shell configure -a /mnt/somedevice/geoip-shell-data -o false`.
- the default ip lists source for OpenWrt is ipdeny (rather than ripe). While ipdeny is a 3rd party, they provide aggregated lists which consume less memory (on nftables-based systems the ip lists are automatically optimized after loading into memory, so there the source does not matter, but a smaller initial ip lists size will cause a smaller memory consumption spike while loading the ip list).
This is about it for this document. Much more information is available in the main [README.md](README.md) and in the extra _.md_ files inside the Documentation directory. If you have any questions, contact me in this thread:
https://forum.openwrt.org/t/geoip-shell-flexible-geoip-blocker-for-linux-now-supports-openwrt/189611
If you use this project, I will be happy to hear about your experience in the above thread. If for some reason geoip-shell is not working for you, I will want to know that as well so I can improve it.

144
net/geoip-shell/README.md Normal file
View File

@ -0,0 +1,144 @@
# **geoip-shell**
Geoip blocker for Linux. Supports both **nftables** and **iptables** firewall management utilities.
The idea of this project is making geoip blocking easy on (almost) any Linux system, no matter which hardware, including desktop, server, VPS or router, while also being reliable and providing flexible configuration options for the advanced users.
Supports running on OpenWrt. Supports ipv4 and ipv6.
## Table of contents
- [Main Features](#main-features)
- [Usage](#usage)
- [Pre-requisites](#pre-requisites)
- [Notes](#notes)
- [In detail](#in-detail)
- [OpenWrt](#openwrt)
- [Privacy](#privacy)
## **Main Features**
* Core functionality is creating either a whitelist or a blacklist in the firewall using automatically downloaded ip lists for user-specified countries.
* ip lists are fetched either from **RIPE** (regional Internet registry for Europe, the Middle East and parts of Central Asia) or from **ipdeny**. Both sources provide updated ip lists for all regions.
* All firewall rules and ip sets required for geoip blocking to work are created automatically during installation or setup.
* Implements optional (enabled by default) persistence of geoip blocking across system reboots and automatic updates of the ip lists.
* After installation, a utility is provided to check geoip status and firewall rules or change country codes and geoip-related config.
### **Reliability**:
- Downloaded ip lists go through validation which safeguards against application of corrupted or incomplete lists to the firewall.
<details> <summary>Read more:</summary>
- With nftables, utilizes nftables atomic rules replacement to make the interaction with the system firewall fault-tolerant and to completely eliminate time when geoip is disabled during an automatic update.
- All scripts perform extensive error detection and handling.
- All user input is validated to reduce the chance of accidental mistakes.
- Verifies firewall rules coherence after each action.
- Automatic backup of geoip-shell state (optional, enabled by default except on OpenWrt).
- Automatic recovery of geoip-shell firewall rules after a reboot (a.k.a persistence) or in case of unexpected errors.
- Supports specifying trusted ip addresses anywhere on the Internet which will bypass geoip blocking to make it easier to regain access to the machine if something goes wrong.
</details>
### **Efficiency**:
- Utilizes the native nftables sets (or, with iptables, the ipset utility) which allows to create efficient firewall rules with thousands of ip ranges.
<details><summary>Read more:</summary>
- With nftables, optimizes geoip blocking for low memory consumption or for performance, depending on the RAM capacity of the machine and on user preference. With iptables, automatic optimization is implemented.
- Ip list parsing and validation are implemented through efficient regex processing which is very quick even on slow embedded CPU's.
- Implements smart update of ip lists via data timestamp checks, which avoids unnecessary downloads and reconfiguration of the firewall.
- Uses the "prerouting" hook in kernel's netfilter component which shortens the path unwanted packets travel in the system and may reduce the CPU load if any additional firewall rules process incoming traffic down the line.
- Supports the 'ipdeny' source which provides aggregated ip lists (useful for embedded devices with limited memory).
- Scripts are only active for a short time when invoked either directly by the user or by the init script/reboot cron job/update cron job.
</details>
### **User-friendliness**:
- Good command line interface and useful console messages.
<details><summary>Read more:</summary>
- Extensive and (usually) up-to-date documentation.
- Sane settings are applied during installation by default, but also lots of command-line options for advanced users or for special corner cases are provided.
- Provides a utility (symlinked to _'geoip-shell'_) for the user to change geoip config (turn geoip on or off, change country codes, change geoip blocking mode, change ip lists source, change the cron schedule etc).
- Provides a command _('geoip-shell status')_ to check geoip blocking status, which also reports if there are any issues.
- In case of an error or invalid user input, provides useful error messages to help with troubleshooting.
- All main scripts display detailed 'usage' info when executed with the '-h' option.
- The code should be fairly easy to read and includes a healthy amount of comments.
</details>
### **Compatibility**:
- Since the project is written in POSIX-compliant shell code, it is compatible with virtually every Linux system (as long as it has the [pre-requisites](#pre-requisites)). It even works well on simple embedded routers with 8MB of flash storage and 128MB of memory (for nftables, 256MB is recommended if using large ip lists such as the one for US until the nftables team releases a fix reducing memory consumption).
<details><summary>Read more:</summary>
- Supports running on OpenWrt.
- The project avoids using non-common utilities by implementing their functionality in custom shell code, which makes it faster and compatible with a wider range of systems.
</details>
## **Usage**
If you want to change geoip blocking config or check geoip blocking status, you can do that via the provided utilities.
A selection of options is given here, for additional options run `geoip-shell -h` or read [NOTES.md](NOTES.md)and [DETAILS.md](DETAILS.md).
**To check current geoip blocking status:** `geoip-shell status`. For a list of all firewall rules in the geoip chain and for a detailed count of ip ranges in each ip list: `geoip-shell status -v`.
**To add or remove ip lists for countries:** `geoip-shell <add|remove> -c <"country_codes">`
_<details><summary>Examples:</summary>_
- example (to add ip lists for Germany and Netherlands): `geoip-shell add -c "DE NL"`
- example (to remove the ip list for Germany): `geoip-shell remove -c DE`
</details>
**To enable or disable geoip blocking:** `geoip-shell <on|off>`
**To change ip lists source:** `geoip-shell configure -u <ripe|ipdeny>`
**To change geoip blocking mode:** `geoip-shell configure -m <whitelist|blacklist>`
**To have certain trusted ip addresses or subnets bypass geoip blocking:** `geoip-shell configure -t <["ip_addresses"]|none>`. `none` removes previously set trusted ip addresses.
**To have certain LAN ip addresses or subnets bypass geoip blocking:** `geoip-shell configure -l <["ip_addresses"]|auto|none>`. `auto` will automatically detect LAN subnets (only use this if the machine has no dedicated WAN interfaces). `none` removes previously set LAN ip addresses. This is only needed when using geoip-shell in whitelist mode, and typically only if the machine has no dedicated WAN network interfaces. Otherwise you should apply geoip blocking only to those WAN interfaces, so traffic from your LAN to the machine will bypass the geoip filter.
**To change protocols and ports geoblocking applies to:** `geoip-shell configure -p <[tcp|udp]:[allow|block]:[all|<ports>]>`
_(for detailed description of this feature, read [NOTES.md](NOTES.md), sections 9-11)_
**To enable or change the automatic update schedule:** `geoip-shell configure -s <"schedule_expression">`
_<details><summary>Example</summary>_
`geoip-shell configure -s "1 4 * * *"`
</details>
**To disable automatic updates of ip lists:** `geoip-shell configure -s disable`
**To update or re-install geoip-shell:** run the -install script from the (updated) distribution directory. It will first run the -uninstall script of the older/existing version, then install the new version.
On OpenWrt, if installed via an ipk package: `opkg uninstall <geoip-shell|geoip-shell-iptables>`
## **Pre-requisites**
- **Linux**. Tested on Debian-like systems and on OPENWRT, should work on any desktop/server distribution and possibly on some other embedded distributions.
- **POSIX-compliant shell**. Works on most relatively modern shells, including **bash**, **dash**, **ksh93**, **yash** and **ash** (including Busybox **ash**). Likely works on **mksh** and **lksh**. Other flavors of **ksh** may or may not work _(please let me know if you try them)_. Does **not** work on **tcsh** and **zsh**.
- **nftables** - firewall management utility. Supports nftables 1.0.2 and higher (may work with earlier versions but I do not test with them).
- OR **iptables** - firewall management utility. Should work with any relatively modern version.
- for **iptables**, requires the **ipset** utility - install it using your distribution's package manager
- standard Unix utilities including **tr**, **cut**, **sort**, **wc**, **awk**, **sed**, **grep**, **pgrep**, **pidof** and **logger** which are included with every server/desktop linux distribution (and with OpenWrt). Both GNU and non-GNU versions are supported, including BusyBox implementation.
- **wget** or **curl** or **uclient-fetch** (OpenWRT-specific utility).
- for the autoupdate functionality, requires the **cron** service to be enabled.
## **Notes**
For some helpful notes about using this suite, read [NOTES.md](NOTES.md).
## **In detail**
For specifics about each script, read [DETAILS.md](DETAILS.md).
## **OpenWrt**
For information about OpenWrt support, read the [OpenWrt README](OpenWrt-README.md).
## **Privacy**
geoip-shell does not share your data with anyone.
If you are using the ipdeny source then note that they are a 3rd party which has its own data privacy policy.

67
net/geoip-shell/SETUP.md Normal file
View File

@ -0,0 +1,67 @@
# Notes about questions asked during the initial setup
## **'Your shell 'A' is supported by geoip-shell but a faster shell 'B' is available in this system, using it instead is recommended. Would you like to use 'B' with geoip-shell?'**
geoip-shell will work with the shell A you ran it from, but it will work faster with a shell B which is also installed in your system. Your call - type in `y` or `n`. The recommendation is clear. If you type in `y`, geoip-shell installer will launch itself using shell B and configure geoip-shell to always use shell B.
## **'I'm running under an unsupported/unknown shell shell 'A' but a supported shell 'B' is available in this system, using it instead is recommended. Would you like to use 'B' with geoip-shell?'**
Whether geoip-shell will work correctly or at all with the shell A you ran it from is unknown, but a supported shell B is available in your system. You can try to run geoip-shell with A but the recommendation is clear. Generally, geoip-shell works best with shells `ash` and `dash`. If you type in `y`, geoip-shell installer will launch itself using shell B and configure geoip-shell to always use shell B.
## **'Please enter your country code':**
If you answer this question, the _-manage_ script will check that changes in ip lists which you request to make will not block your own country and warn you if they will. This applies both to the initial setup, and to any subsequent changes to the ip lists which you may want to make in the future. The idea behind this is to make this tool as fool-proof as possible. This information is written to the geoip-shell config file (only readable by root) on your device and geoip-shell does not send it anywhere. You can remove this config entry any time via the command `geoip-shell configure -r none`. You can skip the question by pressing Enter if you wish.
## **'Does this machine have dedicated WAN interface(s)? [y|n]':**
Answering this question is mandatory because the firewall is configured differently, depending on the answer. Answering it incorrectly may cause unexpected results, including having no geoip blocking or losing remote access to your machine.
A machine may have dedicated WAN network interfaces if it's a router or in certain cases a VPS (virtual private server). When geoip-shell is configured to work with certain network interfaces, geoip firewall rules are applied only to traffic arriving from these interfaces, and all other traffic is left alone.
Otherwise, geoip rules are applied to traffic arriving from all network interfaces, except the loopback interface. Besides that, when geoip-shell is installed in whitelist mode and you picked `n` in this question, additional firewall rules may be created which add LAN subnets or ip's to the whitelist in order to avoid blocking them (you can approve or configure that on the next step of the installation). This does not guarantee that your LAN subnets will not be blocked by another rule in another table, and in fact, if you prefer to block some of them then having them in whitelist will not matter. This is because while the 'drop' verdict is final, the 'accept' verdict is not.
## **'Autodetected ipvX LAN subnets: ... [c]onfirm, c[h]ange, [s]kip or [a]bort installation?'**
You will see this question if installing the suite in whitelist mode and you chose `n` in the previous question. The reason why under these conditions this question is asked is to avoid blocking your LAN from accessing your machine.
If you are absolutely sure that you will not need to access the machine from the LAN then you can type in 's' to skip.
Otherwise I recommend to add LAN subnets to the whitelist. You can either confirm the automatically detected subnets, or specify any combination of ip's and subnets on your LAN which you wish to allow connections from.
The autodetection code should, in most cases, detect correct LAN subnets. However, it is up to you to verify that it's done its job correctly.
One way to do that is by typing in 'c' to confirm and once installation completes, verifying that you can still access the machine from LAN (note that if you have an active connection to that machine, for example through SSH, it will likely continue to work until disconnection even if autodetection of LAN subnets did not work out correctly).
Of course, this is risky in cases where you do not have physical access to the machine.
Another way to do that is by checking which ip address you need to access the machine from, and then verifying that said ip address is included in one of the autodetected subnets. For example, if your other machine's ip is `192.168.1.5` and one of the autodetected subnets is `192.168.1.0/24` then you will want to check that `192.168.1.5` is included in subnet `192.168.1.0/24`. Provided you don't know how to make this calculation manually, you can use the `grepcidr` tool this way:
`echo "192.168.1.5" | grepcidr "192.168.1.0/24"`
The syntax to check in multiple subnets (note the double quotes):
`echo "[ip]" | grepcidr "[subnet1] [subnet2] ... [subnetN]"`
(also works for ipv6 addresses)
If the ip address is in range, grepcidr will print it, otherwise it will not. You may need to install grepcidr using your distribution's package manager.
Alternatively, you can use an online service which will do the same check for you. There are multiple services providing this functionality. To find them, look up 'IP Address In CIDR Range Check' in your preferred online search engine.
A third way to do that is by examining your network configuration (in your router) and making sure that the autodetected subnets match those in the configuration.
If you find out that the subnets were detected incorrectly, you can type in 'h' and manually enter the correct subnets or ip addresses which you want to allow connections from.
## **'A[u]to-detect LAN subnets when updating ip lists or keep this config c[o]nstant?'**
As the above question, you will see this one if installing the suite in whitelist mode and you answered `n` to the question about WAN interfaces. You will not see this question if you specified custom subnets or ips in the previous question.
The rationale for this question is that network configuration may change, and if it does then previously correctly configured LAN subnets may become irrelevant.
If you type in 'a', each time geoip firewall rules are initialized or updated, LAN subnets will be re-detected.
If you type in 'c' then whatever subnets have been detected during installation will be kept forever (until you re-install geoip-shell).
Generally if automatic detection worked as expected during initial setup, most likely it will work correctly every time, so it is a good idea to allow auto-detection with each update. If not then, well, not.
## **Extra options**
- geoip-shell supports an additional setting: trusted ip's or subnets. Currently this is only configurable by running the -install script with the option `-t <"[trusted_ips]">` (or after installation via the `geoip-shell configure -t <"[trusted_ips]">` command). You can specify trusted ip addresses or subnets anywhere on the LAN or on the Internet. To remove this setting later, run `geoip-shell configure -t none`.
- geoip-shell supports lots of additional command-line options. You can find out more by running `sh geoip-shell-install.sh -h`, or after installation `geoip-shell -h`, or by reading [NOTES.md](NOTES.md) and [DETAILS.md](DETAILS.md).