Telium Support Group

If you are using the Commercial Unlimited edition of SecAst, then you can check how an IP address scores on the SecData service using the telnet interface to SecAst. Connect to your local SecAst server by telnet and issue the ‘hackerdb check’ command. For example:

$ telnet 172.1.1.1 3000
Trying 172.1.1.1…
Connected to 172.1.1.1.
Escape character is ‘^]’.
SecAst telnet interface on ‘PBX1 on Waterloo data center wall’
SecAst>hackerdb check 1.2.3.4
Action: checking Telium hacker database
Database match: exact IP
IP address: 1.2.3.4
Score: 25
SecAst>[/color]

Alternatively, if you subscribe to the SecData service directly then you can check how an IP address scores from a browser by entering the query into the address bar; for example:
https://XXX.telium.io/check-ipaddress?key=YYY&ip=1.2.3.4&format=p
(you will need to substitute the hostname and key with those assigned to your account.)

Please note that manual queries of the SecData service through SecAst are throttled, so if you issue too many queries too quickly you will receive a warning to try again later.

The sensor/health graphs show current and historical health scores, as generated by non-core sensors. Core sensor are the ones built into HAAst (non-configurable) and trigger an immediate failover upon detection of a critical issue.

User defined sensors generate scores that show up in the graphs and reporting. So if you have not defined any sensors then you will not see any graphs.

Note that some installations are satisfied with the core sensors only. But as you become more familiar with HAAst you will likely want to add some sensors (e.g. monitor the network/cable carrying SIP/RTP traffic from the PBX to the ITSP).

The most likely cause is that the banned IP’s are not being handled properly by the firewall. There is also a known issue with fail2ban – in case you are attempting to run fail2ban alongside SecAst.

If you are using local IPtables to block attackers, ensure that the SECAST chain exists, and that the first rule on the INPUT chain jumps to target chain SECAST. For example, the command “iptables –L” should show something like:

Chain INPUT (policy ACCEPT)
target prot opt source destination
SECAST all — anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain SECAST (1 references)
target prot opt source destination
RETURN all — anywhere anywhere

The attacker is providing a fake IP address (your server) as the source IP address in the SIP header, and this confuses Asterisk and results in the above error. SecAst is able to detect this type of attack and block the attacker at the network edge.

Digium is aware of the underlying issue and has resolved it in Asterisk version 10 and later, but older Asterisk versions will not receive updated code. (Some users have posted changes to the Asterisk C code but this is beyond most users to apply). In versions of Asterisk 10 through 12, you can enable the Asterisk security log as described here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Security+Event+Logger) to view more accurate error messages; and you can tell SecAst to use the security log you specified (as described in the detailed installation guide).

However, there are still dangers remaining from this type of attack. In version 13 and later of Asterisk you should not be using a security log file, and instead set SecAst to use the AMI for notification of events. Setting SecAst to use the AMI not only increases the speed and accuracy of blocking attackers, it allows SecAst access to detailed caller behavior which can be used to identify fraud and hacking before any damage has been done.

If SecAst communicates with Asterisk through the AMI then numerous other protective measures are also enabled, including detection of stolen credentials, suspicious dialing patterns, etc.

Confirm that your Asterisk (AMI) configuration in secast.conf matches the AMI configuration in manager.conf. If you are certain the interface credentials, port, and settings are correct, please contact support for further assistance.

One or more shared libraries are not installed. The solution is to ensure that all prerequisite libraries are installed.

First, use the “ldd” command to show what libraries SecAst needs, and are available. You should see something like this:

root@pbx~$ ldd secast-0.345.3.0-x86_64-ub12/secast
linux-vdso.so.1 => (0x00007ffffbded000)
libQt5Sql.so.5 => not found
libQt5Xml.so.5 => not found
libQt5Network.so.5 => not found
libQt5Core.so.5 => not found
libpthread.so.0 => /lib/x86_64-linuxgnu/
libpthread.so.0 (0x00007ff6b71c4000)
libstdc++.so.6 => /usr/lib/x86_64-linuxgnu/
libstdc++.so.6 (0x00007ff6b6ec3000)
libgcc_s.so.1 => /lib/x86_64-linuxgnu/
libgcc_s.so.1 (0x00007ff6b6cad000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x00007ff6b68ed000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff6b73ef000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
(0x00007ff6b65f0000)

Based on the response shown in your case, you will have to add the missing libraries (normally through your package manager like apt-get or yum). In the above example case, the Qt libraries are missing; see section 5 of the instructions for details on how to add the Qt libraries.

The archive you downloaded is incomplete and/or contains errors.

The solution is to try again to download the file again. Before expanding the archive, check the md5sum value and compare it to that shown on the Telium website for that file.

Some browsers / locations have difficulty downloading large files, in which case Telium recommends using FTP to transfer the file instead.

The solution is to enable debug for the syncjob id which is generating the warning, then examine the /pbxsync/id.pbxsync.XXX.debuglog file for details of the warning. If the warning is correct or acceptable then no further action is required. If you wish to eliminate the warning completely you can edit the pre or post-sync script file to remove reference to the data (or correct the file to match your implementation).