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?

1 Answers1

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.

TSG
  • 1,674
  • 7
  • 32
  • 51
  • 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. –  Jul 03 '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. –  Jul 03 '14 at 21:33
  • I also forgot to tell SecAst our internal address range. Extesion 100 is a front door phone at the building entrance - sometimes idiots will dial every extension within 60 seconds hoping someone answers. So now that makes sense why SecAst would block it. I will add the extension to the exception list too. –  Jul 03 '14 at 21:42
  • 2
    BTW, you really [should not be doing what you're doing](http://meta.stackexchange.com/questions/234700/reach-out-to-generation-d-systems-about-outsourcing-their-support-to-serverfault). Serverfault is not tech support for the internet, and you should not be pushing your customers here for you to support them. – EEAA Jul 03 '14 at 22:12
  • All support for customers is through email. We do monitor serverfault for secast questions (only for free/community edition), and hope to add to the body of knowledge on the topic. (much like Digium reps commenting on Asterisk questions). Our hope is that users start to answer each others questions once community is large enough. :) – TSG Jul 03 '14 at 22:50
  • Apparently you are directing people here from your website. That's not quite the same as monitoring serverfault. – user9517 Jul 04 '14 at 06:28
  • 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 04 '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. – user9517 Jul 04 '14 at 16:41