Forum Replies Created
-
AuthorPosts
-
in reply to: Cluster status via socket #6634
The best way to communicate programmatically with HAAst is through the socket interface. When haast is running it creates a socket in the directory /var/run. This socket looks and acts just like a regular file; you can write to the file and read from the file to command HAAst and gather status information.
To retrieve the status of the cluster via the socket interface, use the ‘getstatus’ command. The pseudocode to do so is as follows:
Open file /var/run/haast.sock as read+write
Read ‘ready>’ prompt from file
Optionally write command ID and newline to file, e.g. ‘id: 123n’
Write get status command and newline to file, e.g. ‘command:getstatus\n\n’
Read response from file
Close file
Parse response
The ID sent can be any string (to uniquely identify the response) but is optional. In general we recommend sending an auto-incremented counter. Once all required parameters (of this command) have been sent, send a second newline (i.e. 2 sequential newline characters) to tell HAAst the command is complete and ready for processing.
The following is the actual output (read) in red color, and input (written) in blue color, from the above pseudo code:
haast socket interface v1.1 ready>id: 123 command:getstatus id: 123 result: ok cluster name: Telium cluster start time: 1459816998033 cluster start time formatted: Mon Apr 4 20:43:18 2016 cluster run duration: 12404571 cluster run duration formatted: 71 days, 13 hours, 42 minutes, 51 seconds cluster fail over count: 79 local peer name: PBX1 in Waterloo data center wall local haast state: 4 local haast state formatted: Active local peer health state: 1 local peer health state formatted: Normal local asterisk state: 2 local asterisk state formatted: Started local asterisk connection state: 7 local asterisk connection state formatted: Logged in local start time: 1464643147663 local start time formatted: Mon May 30 17:19:07 2016 local haast run duration: 2740022 local haast run duration formatted: 15 days, 17 hours, 7 minutes, 2 seconds local fail over count: 11 local previous fail over timestamp: 1465102805740 local previous fail over timestamp formatted: Sun Jun 5 01:00:05 2016 local previous fail over cause: 2 local previous fail over cause formatted: Dual standby peer contention detected local previous haast state: 3 local previous haast state formatted: Standby local to remote peerlink connection state: 7 local to remote peerlink connection state formatted: Up remote data available: 1 remote peer name: PBX2 VM in Mississauga data center remote haast state: 3 remote haast state formatted: Standby remote peer health state: 1 remote peer health state formatted: Normal remote asterisk state: 4 remote asterisk state formatted: Stopped remote asterisk connection state: 4 remote asterisk connection state formatted: Connect failed remote start time: 1464643407951 remote start time formatted: Mon May 30 17:23:27 2016 remote haast run duration: 2739761 remote haast run duration formatted: 15 days, 17 hours, 2 minutes, 41 seconds remote fail over count: 8 remote previous fail over timestamp: 1465102804675 remote previous fail over timestamp formatted: Sun Jun 5 01:00:04 2016 remote previous fail over cause: 23 remote previous fail over cause formatted: Local peer automatic demotion request remote previous haast state: 4 remote previous haast state formatted: Active remote to local peerlink connection state: 7 remote to local peerlink connection state formatted: Up ready>To learn how to use the HAAst socket interface you can use the ‘socat’ command to interact with the HAAst socket from a Bash command line. (You may need to add the socat command / package to your particular Linux installation). The exact syntax for the socat command is as follows:
socat – UNIX-CONNECT:/var/run/haast.sock
You can then send any invalid command (eg: XXXX) and HAAst will respond with a list of valid commands.
in reply to: Check if an IP address is used by hackers? #6633If 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.
in reply to: 600 calls per minute capability #6632SecData is a cloud based service, with load spread over multiple different cloud providers (including Amazon and GoDaddy). We have tested many times the load you require and SecData has no difficulty keeping up.
If you are using SecAst to access the SecData, then by design your calls will never be delayed/dropped. SecAst allows calls to proceed in parallel to checking the SecData service for fraudulent phone numbers and IP addresses. If a match is found (and the score exceeds the threshold you define) then the call is disconnected and the caller’s IP is blocked.
in reply to: Why are my sensor graphs blank in the web GUI? #6629The 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).
in reply to: Shared library error on start #6628The most likely cause is that one or more shared libraries are not installed. Ensure that all prerequisite libraries are installed. First, use the “ldd” command to show what libraries HAAst needs, and are available:
root@pbx~$ldd haast
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)You would then 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 7 of the instructions for details on how to add the Qt libraries to your Linux distribution.
in reply to: IP’s not blocked despite SecAst saying they are #6627The 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 anywherein reply to: SecAst ignoring attacker #6626The most likely cause is that Asterisk is not providing enough information about an account violation.
If you are running Asterisk 13 or later, then you should tell SecAst to use the AMI for talking to Asterisk (don’t use a security log file). This exposes a lot more information to SecAst.
If you must use the Asterisk log file, please send that log file and the SecAst log file to support for assistance in identifying the attack type and adjusting your setting to recognize the attack.
in reply to: Attacker IP is not available and can’t be blocked #6625The 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.
in reply to: Incomplete startup email #6624The SecAst executable has started, but a critical connection to Asterisk has not been successful. This in turn is preventing SecAst from protecting the Asterisk server.
A delay in starting Asterisk, or a delay in Asterisk responding to SecAst may be the root cause, and no action is needed as the connection will succeed momentarily. Depending on the alert settings, a successful start email may be forthcoming. If not, examine the secast.log file for clues as to what Asterisk connection has been unsuccessful. The most common cause is that the AMI is unavailable because either the Asterisk is not started (yet), or the AMI connection settings mismatch.
in reply to: SecAst shuts down unexpectedly with AMI error #6623Confirm 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.
in reply to: SecAst logs not rotating #6622The SecAst log file or its parent directory has world write permissions, and newer versions of logrotate do not allow this to rotate. Manually running logrotate shows the results below:
$logrotate -d -v secast
reading config file secast
Handling 1 logs
rotating pattern: /var/log/secast after 1 days (7 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/secast
error: skipping “/var/log/secast” because parent directory has insecure permissionsThe solution is to uncomment the line in the /etc/logrotate.d/secast file to allow rotating regardless of permission:
su root rootin reply to: Shared library error on start #6621One 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.
in reply to: GLIBC error #6620The wrong SecAst package has been installed. SecAst is looking for libraries that are more modern (recent) than those offered by your Linux distribution.
If you are sure you downloaded the right SecAst package then try a system wide update using your package manager (eg: “yum update”). Otherwise, return to the Telium web site and download a more suitable SecAst package.
If you don’t see a SecAst package that exactly matches your Linux distribution, try downloading the package for the oldest Linux distribution. The
LTS (Long Term Support) versions of Red Hat (eg: v6) and Ubuntu (eg: v12) are usually the best packages to try.in reply to: Error untarring package #6619The 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.
in reply to: Warning on sync completion #6618The solution is to enable debug for the sync id which is generating the warning, then examine the /tmp/haast.sync.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).
-
AuthorPosts
