I followed a tutorial on here and installed apiban on one of my freepbx instances on the cloud. Everything worked well and I had Fail2ban doing a lot less work but I remember thinking when I was installing - what would happen if it had a bad ip in the blacklist… but everything worked so I was good.
Anyway after a few months my worst nightmare came true. The sip address of my provider managed to get into the blacklist somehow. This is the ip I was registering my trunk on. I added this ip in every single whitelist available on freepbx, but when the apiban cron ran, it added REJECT ALL for the ip which took precedence over all my allow rules. There seemed no way to remove or whitelist that one IP.
As a result I commented out my licence string in the apiban config file and managed to stop apiban from running. This is the only thing that allows me to register the trunk to the provider again.
I looked far and wide where I can search IP’s that are in this blacklist and how I can report a false positive but I could not find any email addresses or any place which I could report this to.
Any ideas how I can
Whitelist this ip from ipbans blacklist on my server
Report this to the guys that maintain the blacklist
APIBAN honeypots are checking for the actual source, not the From or Contact addresses.
If your provider made it to the honeypots, it means that their SBCs/Proxies have an open relay which is a huge red flag.
I would question your provider’s policies if they say “it’s a feature”
APIBAN caches IPs for 7 days, the APIBAN client keeps track using a unix timestamp. So in theory, if you clean your IP Tables, you should only get nee blocked IPs on the next check.
If you have an ip address ACCEPT in your iptables prior to the REJECT rule, then you shouldn’t have that problem, it all depends on the order of the services that insert rules into iptables that you start and whether the rules are “A ppended” or “I nserted” fail2ban has an ignoreip rule, other services probably have something similar, iptables -L -n --line-numbers might help.
It’s not true. I listed all rules iptables -L -n and the said ip was under trusted networks and set to allow, this was added from the freepbx gui which adds the ip to iptables, but a few mins later when the apiban cron runs it adds a new rule under the chain APIBAN which overrides the ALLOW rule and trusted rule.
After apiban updated iptables I would check and the apiban rule would be there aswell as the trusted networks rule and whitelist rule but traffic would be rejected for that ip. If the ip is in apibans list it will override your whitelists. I spent many hours on it that day and can confirm 100%.
Also any idea how I can override a single ip from apiban and contact the guys if a known good ip has somehow be added to their list.
Hi dicko I’m not sure what that means but the ACCEPT rule was definitely in there before apiban added the REJECT rule. I was connected by ssh, I restarted the firewall and checking ip tables -L -n | grep myprovidersip and initially loaded up my trustednetworks and I could see the rule in there. My trunk registered and all was working good… but after a few mins the new apiban rule would be added and it would stop communication to my provider.
Yes apiban adds reject IP’s with higher priorities and therefore freepbx and Fail2ban whitelists are ignored. This creates a big issue. Since I’ve turned off apiban Fail2ban is working much harder, I get tons of blocked IP’s so I’m eager to get it back on.
About the open relay, I did do some checks at the time on the providers ip and it didn’t appear to have any open relays. Left me wondering how the IP managed to get into the blacklist in the first place.
Someone needs to fix that to APPEND not INSERT the apiban chain to INPUT if you are going to use it. Consider moving to a more reputable VSP or just not listening on UDP/5060
// Add APIBAN chain to INPUT
err = ipt.Insert(“filter”, “INPUT”, 1, “-j”, chain)
if err != nil {
return “error”, fmt.Errorf(“failed to add APIBAN chain to INPUT chain: %w”, err)
}
It should probably be
.
.
// Append APIBAN chain to INPUT
.
.
err = ipt.Append(“filter”, “INPUT”, “-j”, chain)
return “error”, fmt.Errorf(“failed to append APIBAN chain to INPUT chain: %w”, err)
.
.
To play nice with other iptables rules and not be totally ‘authoritative’ , but that would depend on your current INPUT chain not having a DROP at the end
In the old days (before fail2ban), an iptables setup typically had the first entry to accept all “ESTABLISHED,RELATED” traffic. This greatly improved performance (most packets are associated with already established connections) and also ensured that replies to outbound requests would get through, regardless of other rules. The implied assumption was that once a connection was allowed, it would be permitted to continue.
However, an important function of fail2ban is to interrupt a sequence of requests from an attacker that is still in progress, so fail2ban chains must precede the ESTABLISHED rule.
IMO, that’s not needed for apiban. It’s exceedingly unlikely that a new address that appears in apiban would correspond to a currently active connection; it almost certainly would have already been blocked by fail2ban. So IMO apiban entries belong after the ESTABLISHED rule, both for performance and to avoid blocking outbound requests, such as REGISTER requests from the OP to his provider.
Last week (or about 10 days ago), some carriers got themselves listed on APIBAN by having their open relay REGISTRATION servers exploited.
To be very clear, not only were these carriers (mostly small b2b carriers) running open relays, those relays were being exploited and sending bad traffic to the world.
If these were your carriers, APIBAN did help prevent the bad traffic… but yes, at the cost of blocking that carrier’s good traffic (assuming they had good traffic to send you).
You could absolutely remove them from iptables with the suggestion above if you wanted both good and bad traffic from the ip.
APIBAN would not re-add the IP unless it was re-exploited and active since the time your client did a “FULL” command. You could also, as stated above, add the IP to an allow list in a chain higher than APIBAN’s chain.
I’m sorry your carrier allowed themselves to send bad, unwanted traffic across the internet and hope you’ll ask them to do a better job of securing their servers from exploitation.
You may also want to really strengthen your own systems if you’re going to allow bad traffic from a carrier that you have in trusted position.
