Thanks, the reported feed issues are addressed in the latest update:
4 Likes
Thank you! Great!
ipthreat, correct me if I'm wrong, seems to have both in and out. They track phishing links too - it's shown on their page (bottom part).
In my experience ipthreat is an abuse/attack aggregator (lists.ipthreat.net, threat-30 = threats reported in the last 30 days). The entries are IPs observed as an attack source — scanners, brute-forcers, etc. That's the same profile as cinsscore, debl, etc. which are all set to 'in'. The unwanted connection is initiated from outside to inbound.
Anyway, it's only a single click to change the default chain behaviour ... and it's now documented as well ... 
1 Like
Another thing... e.g. urlhaus has plenty of links with ports specified. Those are different from 80 and 443. Probably there is no need for specifying port numbers since it can be anything.
Hahaha.. i've been using tor, threatview and proxy in "inout" mode since the start
heads-up: new banIP release/log monitor source-IP extraction changed
The release of banIP 1.8.10 changes how the log monitor picks the attacker IP out of a
matched log line — please read if you use custom ban_logterm filters,
especially for web-server access logs (nginx/apache/lighttpd/haproxy).
What changed
Previously the monitor took the first IP found in a matched line. It now
takes the last IP by default. The real source address is structurally the
last field in all shipped login formats (dropbear, sshd, LuCI, openvpn,
asterisk, AdGuardHome, …), so this is both correct and more robust: a value
placed before the source (e.g. an attacker-controlled login name) can no
longer be mistaken for the source.
This closes a spoofing issue — see the
advisory [GHSA-r6hx-4f83-vp8m] for details.
Action required if you filter web-server access logs:
Access logs put the client IP first, so with the new default last your existing access-log filters would pick a wrong or no token/IP and silently stop banning the real client.
For those terms, prefix the pattern with first::
# before (relied on old first-IP behavior)
list ban_logterm '"GET /wp-login.php'
# now
list ban_logterm 'first:"GET /wp-login.php'
The pattern itself stays the same — you only prepend first:. The prefix is
per-term, so you can freely mix first: and default (last:) terms. This also
applies to conntrack src= style events. All the built-in/login-style filters
need no change.
For reference:
3 Likes
Question:
It is possible to exclude some VLANs from banip?
Means: I currently see e.g. guest-lan in banip log and want to have no blocking therefor...
THX
Look for the option 'ban_vlanallow' in the readme ... Table/Chain Settings in LuCI ...
1 Like
Thanks, I completely overlooked that.
Hello I'm new to banIP I installed it and added recommended feed lists from GitHub so I wanted to test out to see if it's actually working is there a way to do that?
Can check Status -> Firewall and look for rules with the list names in them. Rules being there is a good sign. Depending on the direction of the rule you can generate traffic that should be caught by the rule and see if the matched count goes up.
Rule container chain "_outbound"
....
Destination IP in set @firehol1.v4
Hover over: Traffic matched by rule: 88 Packets, 4.6 KBytes
You can then block for example www.google.com domain in the blocklist section to test blocking. Don't forget to reload banIP
I finished the test and it works fine. Thanks.
Hi.
I've been successully using banip 0.9.2-2 on OpenWRT 23.05.0 to block DoH servers.
I've moved to OpenWRT 25.12.4 and I just installed banIP 1.8.10-rc1
I've configured banIP as close to the way I had it but It's not blocking DoH any more.
I can't find this setting in 1.8.10-rc1
Services > banIP > Settings > Chain/Set settings
- Lan-Forward Chain: doh
Has it been removed or relocated?
The doh feed is still there — nothing removed. What changed is that feeds now ship with a sensible default direction (doh defaults to outbound), so you normally don't need to assign a chain manually anymore — the per-chain assignment still exists if you want it, it's just no longer required.
If blocking stopped working right after the upgrade, my guess is you carried over your old 0.9.x config. The config layout changed a lot since then and old settings won't map 1:1. I'd suggest starting from the current defaults rather than porting the old one. Please consult the readme (see first post or link on the banIP app front page).
If it still doesn't work after that, post your /etc/config/banip plus the banIP status — hard to say more without seeing the actual config.
I did a clean install and then tried to configure it from my old notes.
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'
option ban_fetchcmd 'uclient-fetch'
option ban_protov4 '1'
list ban_ifv4 'wan'
list ban_feed 'doh'
option ban_triggerdelay '12'
option ban_fetchretry '5'
option ban_nicelimit '0'
option ban_filelimit '1024'
option ban_deduplicate '1'
option ban_nftpriority '-100'
option ban_icmplimit '25'
option ban_synlimit '10'
option ban_udplimit '100'
option ban_nftpolicy 'memory'
option ban_nftretry '3'
option ban_blockpolicy 'drop'
option ban_nftloglevel 'warn'
option ban_logprerouting '0'
option ban_loginbound '0'
option ban_logoutbound '0'
option ban_loglimit '100'
option ban_logratelimit '10'
option ban_logburstlimit '5'
option ban_autoallowlist '1'
option ban_autoallowuplink 'subnet'
option ban_autoblocklist '1'
option ban_allowlistonly '0'
list ban_trigger 'wan'
list ban_dev 'pppoe-wan'
The banIP status is still missing....and how did you test the feed?
Sorry. I missed that bit.
I test it with ping and and nslookup
nslookup doubleclick.net 8.8.8.8
ping 8.8.8.8
# /etc/init.d/banip status
::: banIP runtime information
+ status : active (nft: ✔, monitor: ✔)
+ frontend_ver : 1.8.10-r1
+ backend_ver : 1.8.10-r1
+ element_count : 1 555 (chains: 7, sets: 9, rules: 36)
+ active_feeds : allowlist.v4MAC, allowlist.v6MAC, allowlist.v4, allowlist.v6, blocklist.v4MAC, blocklist.v6MAC, blocklist.v4, blocklist.v6, doh.v4
+ active_devices : wan: pppoe-wan / wan-if: wan, - / vlan-allow: - / vlan-block: -
+ active_uplink : 45.33.421.67/32
+ nft_info : ver: 1.1.6-r1, priority: -100, policy: memory, loglevel: warn, expiry: -, limit (icmp/syn/udp): 25/10/100, loglimit (rate/burst): 10/5
+ run_info : base: /tmp, backup: /tmp/banIP-backup, report: /tmp/banIP-report, error: /tmp/banIP-error
+ run_flags : auto: ✔, proto (4/6): ✔/✘, bcp38: ✘, log (pre/in/out): ✘/✘/✘, count: ✘, dedup: ✔, split: ✘, custom feed: ✘, allowed only: ✘, debug: ✔
+ last_run : mode: start, date / time: 16/07/2026 08:23:22, duration: 0m 2s, memory: 383.18 MB available
+ system_info : cores: 2, log: logread, fetch: uclient-fetch, Linksys E8450 (UBI), mediatek/mt7622, OpenWrt 25.12.4 (r32933-4ccb782af7)