That's already implemented in banIP, it uses ETAGs for that.
What did you mean with "bad lists"? The backup files are all checked and OK ...
Yes, I didn't express myself correctly. I mean, IIUC you are using the backups to both restore firewall state after reboot etc, and to correct for downloads that went wrong. While the former can't be avoided, the latter can be if you check the downloaded list and avoid applying it if it's bad. Maybe I'm misunderstanding how your algorithm works, and if that's the case then my apologies.
Interesting, perhaps that's a better solution. I'll check it out.
This might be an ignorant question, but I'm trying to understand the value add of banIP given the default firewall setup for OpenWrt.
If we're just using the default firewall configuration, with no open ports for SSH/HTTP/etc to the open world, is there still a use case for using banIP to blocklist external IPs?
There are technically still a few open ports with the default firewall (I believe ping + DHCP/etc) but I'm not sure if those are a risk that would warrant the use of banIP or not.
Nope, than you don't need such package.
Edit: one exception - you can block effectively DoH connections from connected LAN clients ... 
Ah gotcha - that's a use case that I do not have. 
Thank you for your quick response, and your work on projects like this (even if I'm not using it immediately).
Traffic from internal hosts to "bad" IP addresses and any return traffic are not blocked by the default firewall setup and rules. One use of banIP is to block such traffic.
Just to follow up my previous posts, if it's of any use to anyone, I upgraded from OpenWRT 22.03.5 to 23.05.0 and banIP is now working perfectly.
1 Like
I spoke too soon, now banIP fails to work after a router reboot.
It seems to be because the external WAN IP which is automatically added to the Allowlist fails to get updated after the reboot.
Also under the LuCi banIP 'Information' section the "Active Uplink" item is blank.
Restarting banIP fixes the issue (and the WAN IP is updated on Allowlist)
This error line also appears in the log (I guess because of WAN IP issue above)
download for feed 'dohv4' failed (rc: 4/log: Downloading 'https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/master/doh-ipv4.txt' Failed to send request: Operation not permitted)
Why is banIP missing the WAN IP change after a reboot?
Your config please and the output of /etc/init.d/banip status - thanks.
Apologies if this is a silly question, but I'm fairly new to BanIP.
I just updated to the latest version (from 0.9.0-1 to 0.9.2-1) and the BanIP service then failed to start with this error message:
Fri Nov 17 15:53:13 2023 user.err banIP-0.9.2-2[18019]: banIP service autostart is disabled
I fixed it by re-enabling the service on the command line:
/etc/init.d/banip enable
Is this expected when updating, or did I do something wrong?
# /etc/init.d/banip status
::: banIP runtime information
+ status : active (nft: ✔, monitor: ✔)
+ version : 0.9.2-2
+ element_count : 2
+ active_feeds : allowlistv4MAC, allowlistv6MAC, allowlistv4, allowlistv6, blocklistv4MAC, blocklistv6MAC, blocklistv4, blocklistv6
+ active_devices : wan: pppoe-wan / wan-if: wan, - / vlan-allow: - / vlan-block: -
+ active_uplink : -
+ nft_info : priority: -200, policy: memory, loglevel: warn, expiry: -
+ run_info : base: /tmp, backup: /tmp/banIP-backup, report: /tmp/banIP-report
+ run_flags : auto: ✔, proto (4/6): ✔/✘, log (wan-inp/wan-fwd/lan-fwd): ✔/✔/✘, dedup: ✔, split: ✘, custom feed: ✘, allowed only: ✘
+ last_run : action: boot, log: logread, fetch: uclient-fetch, duration: -, date: 2023-11-17 17:35:10
+ system_info : cores: 2, memory: 407, device: Linksys E8450 (UBI), OpenWrt 23.05.0 r23497-6637af95aa
# cat /etc/config/banip
config banip 'global'
option ban_enabled '1'
option ban_debug '1'
option ban_autodetect '1'
list ban_logterm 'Exit before auth from'
list ban_logterm 'luci: failed login'
list ban_logterm 'error: maximum authentication attempts exceeded'
list ban_logterm 'sshd.*Connection closed by.*\[preauth\]'
list ban_logterm 'SecurityEvent=\"InvalidAccountID\".*RemoteAddress='
option ban_fetchcmd 'uclient-fetch'
option ban_protov4 '1'
list ban_ifv4 'wan'
list ban_dev 'pppoe-wan'
list ban_feed 'doh'
option ban_deduplicate '1'
option ban_loginput '1'
option ban_logforwardwan '1'
option ban_logforwardlan '0'
option ban_autoallowlist '1'
option ban_autoblocklist '1'
option ban_allowlistonly '0'
Thanks, set the trigger delay ban_triggerdelay on pppoe interfaces to 30 seconds and limit the doh feed to the lan forward chain, set ban_blockforwardlan accordingly. See the online readme for further information...
Edit: all options are available via LuCI, too.
1 Like
Excelent. Thank you very much.
I made the changes via LuCI.
I think this is how they should be
# cat /etc/config/banip
config banip 'global'
---[snip]---
list ban_blockforwardlan 'doh'
option ban_triggerdelay '30'
list ban_trigger 'wan'
I think I've found a bug.
The URLHaus feed contains this line:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"URLhaus Known malware download URL detected (1327898)"; flow:established,from_client; content:"GET"; http_method; content:"/inst77player/inst77player_1.0.0.1.exe"; http_uri; depth:38; isdataat:!1,relative; nocase; content:"softdl.360tpcdn.com"; http_host; depth:19; isdataat:!1,relative; metadata:created_at 2021_06_05; reference:url, urlhaus.abuse.ch/url/1327898/; classtype:trojan-activity;sid:82190998; rev:1;)
When used in the LAN-Forward chain (which makes sense for this feed, because it is designed to block sites used for malware distribution), this results in packets destined for 1.0.0.1 being dropped.
Presumably the BanIP code is misidentifying 1.0.0.1 in this fragment as an IP address?
content:"/inst77player/inst77player_1.0.0.1.exe";
Thanks, you can fix it on your own ... just use a custom feed and change the regex for urlhaus, e.g.:
match($0,/(content:"([0-9]{1,3}\.){3}(1?[0-9][0-9]?|2[0-4][0-9]|25[0-5]))/){printf "%s,\n",substr($0,RSTART+9,RLENGTH-9)}
1 Like
@dibdot hey.. how are you?
I just noticed this the other day and have been checking it. Is this normal? The script is still in the process list even after hours it has finished. I have checked all my routers with banip and all of them showing the same. Using the latest 0.9.2-2
Posting status just in case:
# /etc/init.d/banip status
::: banIP runtime information
+ status : active (nft: ✔, monitor: ✔)
+ version : 0.9.2-2
+ element_count : 44969
+ active_feeds : allowlistv4MAC, allowlistv6MAC, allowlistv4, allowlistv6, bruteforceblockv4, binarydefensev4, deblv4, deblv6, dohv4, etcompromisedv4, dohv6, firehol1v4, greensnowv4, ipthreatv4, proxyv4, iblockspyv4, ipblackholev4, sslblv4, threatv4, threatviewv4, torfullv4, torfullv6, urlvirv4, urlhausv4, blocklistv4MAC, blocklistv6MAC, blocklistv4, blocklistv6
+ active_devices : wan: wan / wan-if: wan, wan6 / vlan-allow: - / vlan-block: -
+ active_uplink : 10.0.0.2/24, 2001:44xx:xxxx:xxxx::2/128
+ nft_info : priority: -200, policy: memory, loglevel: warn, expiry: 1h
+ run_info : base: /tmp, backup: /tmp/usb/openwrt/banip, report: /tmp/banIP-report
+ run_flags : auto: ✔, proto (4/6): ✔/✔, log (wan-inp/wan-fwd/lan-fwd): ✔/✔/✔, dedup: ✔, split: ✔, custom feed: ✘, allowed only: ✘
+ last_run : action: reload, log: logread, fetch: curl, duration: 1m 13s, date: 2023-11-22 05:16:21
+ system_info : cores: 4, memory: 252, device: D-Team Newifi D2, OpenWrt SNAPSHOT r24125-9188c77cbe
yep, that's related to the logread/logfile monitor pipe(s) running in the background after banIP list processing.
1 Like
Ok thanks. 
I've been unable to find if this subject has already been discussed in the thread, about having a remote fail2ban.
I have a server on my LAN accessible from the WAN by port forwarding. I plan to install fail2ban on that server and write a custom action to call banIP on the router whenever it needs to ban/unban IPs.
Is there a banIP CLI command to ban/unban an IP? I can write a shell script to add/remove the IP parameter to /etc/banip/banip.blocklist file but it would be safer (future proof) if banIP provided such command.
Also with a shell script as described in the wiki, restarting the whole banip service probably reloads the full set of rules of banned IPs in the firewall. This is not an atomic action. It could probably spiral to a DDOS as the router restarts banip after a flow of banned IPs.
What's the best approach to remotely drive banIP with banning/unbanning IP addresses?