Telium Support Group

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

HAAst performance data written to the database is recorded using the timetamp of the source system, and they are displayed in the order they arrived. If entries from different servers appear out of order, that means that the clocks on the two servers are out of sync.

The solution is to install the network time service (NTP) on both peers and ensure they synchronize from the same source.

You are experiencing a network/routing issue somewhere on your network. It could be an ARP table is corrupt somewhere, or a device is simply not routing packets out the interface it should. This type of problem is common with multihoming (this is not a HAAst issue, it’s a network issue).

A complete solution is beyond the scope of this document. In fact, understanding and diagnosing ARP cache and routing problems is complex – don’t expect a simple answer. If you want to ensure that your Asterisk server is sending packets out the right interface on a multihomed system, you can set an iproute policy as follows:

1. edit the /etc/iproute2/rt_tables file and add the following line:

200 haastrt

2. add the following two lines to your asterisk.start.pre file (assuming the device you are dynamically creating is called eth0.haast):

ip rule add dev eth0.haast table haastrt
ip route add default dev eth0.haast table haastrt

3. Reboot your system and retry the ping test mentioned above.

If the problem remains then the most likely cause if your router.