Telium Support Group

If your cluster needs to withstand penetration testing (or the equivalent of exposing the management ports to the internet), then there are a number of steps you must take to harden your cluster.

1. Ensure you set complex id and passwords for the Asterisk management interface.
2. Set the Asterisk management interface to listen to localhost only.
3. Ensure you set complex credentials for HAast peerlink.
4. Protect the HAast GUI (https) interface with the htpasswd utility
5. Ensure you set complex credentials for rsync.
6. Ensure you set complex credentials for database(s) in use.
7. Limit database port access to localhost and the remote peer.
8. Set iptables rules to further limit interface/port combinations of the above to the peer and any trusted management workstations.
9. Set iptables connection rate rules to the max necessary for your cluster to operate.

The HAast GUI and ReST interface can be disabled altogether if you do not need that functionality. Note that the GUI and ReST interfaces do not use ANY 3rd party libraries; it is all hand coded in PHP and tested for stability and security. However, it is possible to overload or find a weakness in Apache HTTPD; in which case disabling the GUI and ReST interface is recommended.

If you do not need direct access to the HAast telnet interface, then you should set the HAast telnet interface to listen to the localhost address only. Once that change is made, you must SSH to the node first and then telnet to HAast in order to access the interface.

HAast is designed to support even the most heavily loaded systems. However, HAast on it’s own is not designed to withstand loads/connection attempts beyond what can be found in a normal production environment. In other words, HAast is not meant to withstand the challenges of penetration testing or open internet access without first hardening the cluster. The above hardening recommendations do add additional load to the cluster nodes, so in general we do not recommend implementing the above unless you have a real need to harden your cluster.

This error means that the connection to the database server has closed unexpectedly. HAast will immediately try to reopen the connection to recover, which is why you see data still being written to the database. However, the database operation that triggered the error has failed and it’s data will not be recorded (if it operation was trying to add data).

The root cause is that your MySQL/MariaDB server is configured to automatically close the connection after a period of inactivity, and that period is too short. To solve the problem, edit the MySQL configuration file (usually /etc/mysql/my.conf and add the following:

[mysqld]
wait_timeout = 31536000
interactive_timeout = 31536000

If you have chosen USB Dongle activation, then there a few more steps required to pair your new dongle with your license. Once your dongle arrives plug it into the computer and restart the HAast service. Reconnect to the product’s telnet interface and issue the “license usbdongle” command. For example:


[root@pbx_qa_17:/usr/local/haast] $ telnet 172.31.224.14 3001
Trying 172.31.224.14…
Connected to 172.31.254.14.
Escape character is ‘^]’.
HAast telnet interface on ‘PBX QA 17’
HAast>license usbdongle
Your USB dongle has been detected but is not yet paired with your license.
To pair your USB dongle with your license send the following dongle ID to
support@telium.io to receive a pairing code :
5010-5473-C839-94B9


Copy the pairing code and paste it into an email to support@telium.io and include your license number. We will reply with an activation code that you must enter. For example:


When ready enter the pairing code below (or . to abort)
activation code>46A9-9907-43DB-4F06
 
Your activation code has been accepted. Please restart the HAast service to use the activated license.


Now exit the telnet session and restart the HAast service. HAast will restart fully licensed and you are ready to use your licensed product. You can also verify the license by repeating the “license usbdongle” command, and it should indicate that the dongle has been paired to your license. For example


[root@pbxqa17:/usr/local/haast] $ telnet 172.31.224.14 3001
Trying 172.31.224.14…
Connected to 172.31.224.14.
Escape character is ‘^]’.
HAast telnet interface on ‘PBX QA 17’
HAast>license usbdongle
Serial number: 3040504215618650775
Paired: yes, on Tue Jun 14 17:52:40 2022 EDT
Locked out: no
HAast>


All of the libraries and components used by HAast are IPv6 capable, and HAast is designed to accept IPv6 settings. However, due to lack of customer demand IPv6 functionality is not currently tested or certified.

You are welcome to try IPv6 settings with HAast and everything may work. However, we do not officially support IPv6 yet. As of May 2022 we have not had any customer need IPv6 (though a few customers have inquired).

If IPv6 is essential for your implementation Telium would undertake a (for fee) project to certify HAast (only the platform and architecture of HAast you are using). There is not enough overall demand to justify doubling the entire QA process indefinitely for IPv6.

If you are an OEM or volume license customer please contact your account manager to discuss your needs.

You have described two very different needs in your question, so I’ll try to answer them separately. If you choose Hardware Fingerprint activation on AWS, then your license is tied to your instance ID and MAC address. So you can safely move the instance between hosts (i.e. hypervisors, not guest VM’s), change instance size, etc. The license will remain activated (tied to that instance). You can safely start/stop the instance, just don’t ever delete it or delete the NIC as that will invalidate your license.

If you plan to have multiple AWS instances ready to start but will only use one at a time, then you should choose Cloud activation. Cloud activation is not tied to any (virtual/physical) hardware so whichever instance is running is the one that will use the license. However, do not start more than one instance at a time (i.e. don’t try to use a single license on multiple instances simultaneously) or that will invalidate your license.

I should point out that we use a third party license product, and they have no obligation to issue a new license once an existing one has been invalidated. In other words, if you invalidate your license you will most likely have to buy an entirely new license (full price). So plan your deployment carefully to avoid wasting a license. We have no ability to “un-invalidate” a license – we are at the mercy of the license vendor, and we understand their need to prevent license fraud as that’s the only way they can stay in business.

There are a few ways to address your problem.

First, you can limit access to the HAAst config files (or even entire /etc/xdg/telium directory) so that only the root user can read them. Using the chmod command will allow you to set these files to readonly (r – -) for root:

chmod 400 haast.conf

Second, you can also encrypt the password before placing it into the config file. For example, using md5sum we can generate a hash of your obvious password:

[root@qa14 dev]# echo "MyObviousPassword" | md5sum
7f1e7328e9c668dbc73485eecd91b7ba -

Then you would use 7f1e7328e9c668dbc73485eecd91b7ba as your password entered into the haast.conf file on both nodes.

Third, you can store sensitive config file information in the HAast keychain.   To use a keychain value in a configuration item simply replace the value with @KEYNAME. Applicable configuration items show @KEYNAME as an option in the documentation. Note that a KEYNAME can contain only letters, numbers, and underscore, and case of the letters is ignored.  See section 3.1 of the installation guide (as of Jan 2021) for further details of the keychain.

HAAst is written entirely in C/C++, so it is highly efficient with a minimal footprint. Since HAAst runs on the same hardware platform as Asterisk, we cannot describe HAAst’s minimum requirements in absolute terms (since HAAst alone on a server makes no sense).

However, if you have a properly sized server (for the target Asterisk volume), HAAst will consume:

• Maximum 2% of available CPU
• 400MB of memory (in use, not swapped)
• 50MB of disk storage

In case you meant from a hardware compatibility standpoint, HAAst can run with many different CPU’s and system boards/chipsets. Since HAAst communicates with the system board to determine health, check with our support team if you are using a non X86/X86_64 standard PC motherboard. As well, releases for non-X86/X86_64 CPU’s are targeted at specific processors for optimization/power management reasons, so please check with our support team for the specific CPU you are targeting.

For more information see FAQ 1070

You don’t mention the version of FreePBX you are running but we can guess the cause; based on the timing of your message we are aware of a particular corrupt SIP packet attack which appeared in June 2020.

Please upgrade your SecAst to version 1.7.1 and your system will no longer be vulnerable to this attack. If you want want to send us detailed Asterisk/SecAst/Firewall logs we can help you confirm the cause and the resolution. (Please send by email, don’t post in the forum)