0

I'm using SecAst on my Asterisk server as well as fail2ban. (Setup as an option as per the SecAst installation guide). I did this to test if SecAst is working right. I planned to remove fail2ban if SecAst is working right.

The list of banned IP's on the SecAst list is way longer than the fail2ban list - why? I don't see any attacks in the Asterisk message log from these addresses. Is SecAst pulling these addresses out of thin air? Is there any proof these addresses are doing anything wrong?

locked by Michael Hampton Jul 4 '14 at 16:33

This post has been locked while disputes about its content are being resolved. For more info visit meta.

Read more about locked posts here.

  • 1
    Why are you pretending to be a customer you work for this company? – Iain Jul 4 '14 at 16:33
0

There can be many reasons for this (and I can assure you SecAst isn't pulling addresses out of thin air).

  1. 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.

  2. 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.

  3. 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)


UPDATE:

Here's feedback based on the files you sent:

  1. 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.
  2. 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.

  • I sent you the log files (i didn't want to blank out the IPs so that you could lookup geographic IP). I also sent our config file. – user220412 Jul 3 '14 at 20:51
  • I think I misunderstood the secast log file - I thought blocked ip's would be warnings but instead are marked "S" (for super important, or security?). Not that I know what I'm looking for I see all of the explanations - very cool. – user220412 Jul 3 '14 at 21:33
  • 2
    BTW, you really should not be doing what you're doing. Serverfault is not tech support for the internet, and you should not be pushing your customers here for you to support them. – EEAA Jul 3 '14 at 22:12
  • 3
    The most serious problem with this Q&A is that the relevant information was not posted in the question, making it impossible for anyone else to either answer the question or learn from it. Please do not ask for information to be privately submitted to you and use it as the basis for an answer. All information necessary to answer the question should be in the question. If you wish to provide product support privately, you should do it at your own site. – Michael Hampton Jul 4 '14 at 16:16
  • 1
    I think there is a more serious problem, the user Gooroo appears to be an employee of this company and not a customer. They are not being entirely honest with us. – Iain Jul 4 '14 at 16:41