There can be many reasons for this (and I can assure you SecAst isn't pulling addresses out of thin air).
Geofencing: SecAst can block source IP's based on their geographic location. Do you have geogencing setup in the secast.conf file? If so, go to the telnet interface of SecAst and test the blocked IP's to see if they originate in a restricted geographic area.
Heuristic Patterns: Could the source IP / extension be doing things you don't expect? If a set of valid credentials have been leaked it could be that someone is making calls using these credentials, and their usage patterns are what is normally seen during fraud.
Fail2Ban missing it: It's possible that SecAst is catching things fail2ban is not. Attackers are now spreading "tests" of your security/credentials over days and SecAst may be catching those.
So...those are just some of the answers. Can you post the relevant portions of your secast.log and asterisk messages/security file? (Or if you are concerned about exposing extension names or IP information please send them to support at generationd.com)
The bottom line is that fail2ban can detect only a subset of what SecAst detects so don't expect the same IP's detected. If you post your log files (or email them) I can tell you specifically the cause(s)
Here's feedback based on the files you sent:
- The SecAst logs show all of the bans and explain why. Take a look at [Jun-5-2014 6:14:20] as an example; it shows that the IP was on the watch list and this registration attempt tripped it over the edge. Your Secast config file shows you are using a 3 day interval for detection (which is good), and this IP appears to be attempting to register every 15 hours. So fail2ban won't catch this, but SecAst is properly catching it.
- The SecAst log shows LOTS of sudden calls from extension 100, and the IP is a non-routable address. So a couple things are wrong here: first, there is clearly a suspicious calling pattern here so banning was the correct action (and you can change the sensitivity of the detection in the secast.conf). Next, since the IP for this attack is internal - you should have setup the internal IP range so that internal phones are not watched for calling patterns.
I don't see any geofencing violations - at least not in the logs you sent.