The whois lookups for links in the IPSet Report for IPv6 addresses in the entry details with a /nn doesn't work . The JSON API used returns {"success":false,"message":"invalid IP address"}. Looks like the /nn needs to be trimmed off for IPv6 addresses while it doesn't have to be for IPv4.
Fail: https://ipwhois.app/json/2a02%3A6b8%3A%3A%2F29
OK: https://ipwhois.app/json/2a02%3A6b8%3A%3A
Hi Guys, what the difference between banIP and AdBlock? . To me seem sligtly different due to different lists. Can be used together or are clones one of other?
Is there anything I need to do to update the blacklists? or do they automatically update in the background?
Hello there
When I activate banip, I cannot access some greek websites (for example: https://nanagoldenbeach.gr/).
I do not see any reason for that (I did not check Greek as blocked country) neither this website seems to be in any black list
Sounds strange to me
I recently updated to 0.7.10 from 0.3.11 and had to do a lot of editing in the sources. I'm still having problems with some of the data sources. In 0.3.11 it was possible to make a local file in the UCI filesystem that contained a set of IP's but I'm having troubles finding a way to do that with the new version; Some of the ipsets are very large and the blacklist is unable to handle all of the IP's - banIP never finishes loading the rest of the IPsets if the blacklist gets too large. Also, I've found that there are IP ranges that are getting skipped from IPDeny.com - I never had that issue when it was using the RIPE stat data set. At anyrate - I've been trying to find a way to add another country code black list that still uses ripestat - can anyone give some advice here? Another problem with the data sources is for the iblocklist data sets - they are not working becuase the site requires a captcha before it will give you the ipset so it never fully downloads the list...
Thanks for the hints. Was firehol_4 the culprit!
For snapshot builds with the imagebuilder selecting -firewall4 firewall -nftables iptables-legacy ip6tables-legacy -kmod-nft-offload kmod-ipt-offload for PACKAGES seems to work around the dependency on fw3. [1]
(Eventually fw3 will be unsupported though as fw4 is chosen as the new default.)
@dibdot, is that along the lines of your private build?
I did this after the fact and continue to use snapshot builds with fw3. Basically I just uninstalled nftables fw4 and installed fw3 and it seems to work just fine even through updates.
You need to add a scheduled task to reload banIP so it will update it's blocklists. Same with Adblock as well if you use it. You can copy and paste my entries below into your Scheduled Tasks and Adblock will update at 2am every day, and banIP will update at 2:30am everyday. Omit the line that contains Adblock if you don't use it.
00 02 * * * /etc/init.d/adblock reload
30 02 * * * /etc/init.d/banip reload
No, it's not.
I ended up hosting my own iplists and using an internal url to download them......... Wish there was an easier way; I've noticed that the more IPSets you are using, the slower your speed becomes. I completely did away with the ctstate NEW in banip.sh for both 4 and 6 - I don't think it's processing those correctly... If it's going into the banip chain they should be RELATED,ESTABLISHED at least...
Apart from the number and size of IPsets used, ignoring the ct state will provide additional/unnecessary load. banIP is intended to prevent the "first contact" - hence the restriction to "new".
IMHO, if you're working on your own solution you should directly build an approach based on nftables. Said that, I've just started to port/rewrite banIP to support nftables ... but it's a long way to go.
Thank you for working to support nftables.
Hope it's not at least years ago.
I admit that I have made a couple of modifications to the way BanIP injects chains - the ctstate (connection state) of a packet has a couple of definitions. From iptables(8) - Linux man page (die.net) they say that possible states are INVALID, NEW, ESTABLISHED, RELATED, and a couple of of other virtual states. I've adjusted my chains so that the input rule is the first chain below IO. If I include ctstate NEW at the top of the banip chain and use RETURN on it - it will not DROP packet probes and immediately return the probe for further processing. NEW in ctstate means that a connection state is brand new and the packet needs to be filtered - if it is RELATED,ESTABLISHED and instructed to RETURN then that means that it is a connection that has already been filtered through the banip chain once and can then be returned back to the main chain for further processing. We're basically talking about the connection state of packets here so yes, there is extra load that must be processed for each new incoming packet but not after it's made an established connection. Looking forward to the nftables rewrite. The main thing I notice in speed is the number of IPSets being used. Each packet has to filter through the injected sets that are injected in BanIP and it is worse than the load that would supposedly happen from filtering each packet. If I combine IPSets to a single set with more entires then the packet filtering is MUCH MUCH faster - at least in firewall3. I had 57 Sets being injected at one point and had to start combining the sets to increase speed. I suspect that if all of the data sources were being injected into a single formatted list with only one ipset that it would be so fast it wouldn't even be noticeable with fw3.
In lines 494 and 495 of banip.sh you have:
f_iptrule "-A" "${ban_chain}" "-p udp --dport 67:68 --sport 67:68 -j RETURN"
f_iptrule "-A" "${ban_chain}" "-m conntrack ! --ctstate NEW -j RETURN"
The whitelist uses "return" but you're also using it for ctstate NEW- meaning that it is returning the packet back to the main chain it came from instead of checking to filter - not as an ESTABLISHED connection that has already gone through the filtering process.
f_iptrule "-A" "${ban_chain}" "-m conntrack --ctstate ESTABLISHED -j RETURN"
seems to work without acknowledging SYN packets from blocked sources and keeps the speed up. I don't have a need for DHCP ports 67 and 68 so I've removed that line. I've been using cloudshark personal for packet analysis. If I were to consider adding another entry here it would be to help prevent DDOS attacks and add a burst limit for SYN packets at the top of the banIP list along with the ESTABLISHED rule. One thing to keep in mind when using this rule is that if you have a VPN and initiated a connection while using it and it disconnects then there is a chance that the established connection you were speaking with over the VPN will try and re-initialize depending on if it has a kill-switch or not - if you were talking to an IP behind one of your block lists then this may or may not be desirable.
I've found that using RELATED results in handshakes attempting to acknowledge SYN packets but using ESTABLISHED solves this in one of my follow-up posts.
Thank-you.
Some users have no choice but to use the snapshot builds, so no BanIP. 
Hi,
I have a question in general. Is it necessary that banip injects a rule into "input_lan_rule" by default, even when no "ban_lan_inputchains_4/6" is configured?
I'm asking, because all my destination banip ipsets only affects traffic leaving the wan interface. Therefore traffic which is processed via INPUT chain "input_lan_rule" looks up banip, but logically will never be match while the implicit outgoing interface (wan) is set - thus they are a waste of time/ resources during packet processing.
Example of my config below
Chain zone_lan_input (2 references)
pkts bytes target prot opt in out source destination
1004 83942 input_lan_rule all -- any any anywhere anywhere /* !fw3: Custom lan input rule chain */
0 0 ACCEPT all -- any any anywhere anywhere ctstate DNAT /* !fw3: Accept port redirections */
1004 83942 zone_lan_src_ACCEPT all -- any any anywhere anywhere /* !fw3 */
Chain input_lan_rule (1 references)
pkts bytes target prot opt in out source destination
2442 185K banIP all -- any any anywhere anywhere
Chain banIP (5 references)
pkts bytes target prot opt in out source destination
2 652 RETURN udp -- any any anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
0 0 RETURN all -- any any anywhere anywhere ! ctstate NEW
0 0 RETURN all -- pppoe-wan_vdsl any anywhere anywhere match-set whitelist_4 src
0 0 RETURN all -- any pppoe-wan_vdsl anywhere anywhere match-set whitelist_4 dst
0 0 DROP all -- pppoe-wan_vdsl any anywhere anywhere match-set bogon_4 src
70 3037 DROP all -- pppoe-wan_vdsl any anywhere anywhere match-set dshield_4 src
0 0 REJECT all -- any pppoe-wan_vdsl anywhere anywhere match-set dshield_4 dst reject-with icmp-port-unreachable
...
@dibdot - thanks for your great work!