Categories
Peripherals

2N IP Door Intercoms comparison chart

2N offer a range of stylish solutions for door communication. The 2N® Helios IP door and security intercoms will ensure comfort for you and your visitors and with a range of different models and feature enhancing accessories there will be an option to suit your needs.

Due to the complexity and multiple configurations possible please call or email for pricing and options.

2N® Helios IP Uni 2N® Helios IP Vario 2N® Helios IP Verso 2N® Helios IP Force 2N® Helios IP Safety 2N® Helios IP Base
Uni Vario Verso Force Safety Base
Integrated camera No Optional Optional (HD) Optional

(Standard or HD)

No yes
Buttons 1 or 2 up to 54 up to 146 1, 2 or 4 1 or 2 1 or 2
Keypad No Optional Optional Optional No No
Internal RFID card reader No Optional Optional Optional No Optional Card reader sold separately
NFC support No No Optional Optional No No NFC supported card reader and licence required
Display No Optional Optional No No No
Pictograms for visual signalling Optional No yes Optional No yes
Integrated electric switch yes yes yes yes yes yes
10W loud speaker No No No Optional Optional No
PoE yes yes yes yes yes yes
Tamper Switch yes No Optional Optional Optional yes Independent circuit control

Tamper switch sold separately

IP Rating IP54 IP53 with roof IP54 IP65/IP69K IP69K IP65 IP65 ~ on 1W speaker models

IP69 ~ on 10W speaker models

IK Rating IK10 IK07 IK08 IK10 IK10 IK07
Phone book entries 2 2000 2000 2000 2000 2000
Security Relay support yes yes yes yes yes yes Security relay sold separately
2N® Helios IP Eye & 2N® Mobile Video Support No yes yes yes No yes Only models equipped with camera
Categories
Asterisk Support Knowledge Base Security

Catching the IP of anonymous callers on Asterisk servers

Hi just sharing a simple bit of dialplan to catch anon callers ip addresses when using freepbx and Anonymous callers is set to yes, which is needed for some suppliers.

Normally I would say lock your firewall to only known IPs, but in some cases this isn’t possible

Im sure if you have a Asterisk server with a public IP you will have seen calls on the console screen where the call is to a destination but the callers are exten@yourserver . Well this little bit of dialplan at the end of you default sip context should catch them and log them with the ip of the originating server

In extensions_custom.conf add the dialplan below

[catchall]
exten => s,1,Noop(Dead calls rising)
exten => s,n,Set(uri=${SIPCHANINFO(uri)})
exten => s,n,Verbose(3,Unknown call from ${uri} to ${EXTEN})
exten => s,n,System(echo "[${STRFTIME(${EPOCH},,%b %d %H:%M:%S)}] SECURITY[] Unknown Call from ${CALLERIDNUM} to ${FROM_DID} IPdetails ${uri}" >> /var/log/asterisk/sipsec.log)
exten => s,n,Hangup()

Then in Custom Destinations add a destination as  catchall,s,1

so you now get in your logs

[May 1 00:11:06] SECURITY[] Unknown Call from  to 900441516014742 IPdetails sip:101@37.75.209.113:21896

 I hope this is some help to you, It allows other scripts to pick up this address and add it to your firewall.
Categories
Elastix Support Security

SSLv3 Poodle and Elastix

Google has just disclosed SSL POODLE vulnerability which is a design flaw in SSLv3.  By default SSLv3 is enabled by default in Elastix and many other servers, Since it is a design flaw in the protocol itself and not an implementation bug, there will be no patches. Only way to mitigate this is to disable SSLv3 in your web server or application using SSL.

How to test for SSL POODLE vulnerability?

The following simple script will test, its a re-write of Redhats that would give a false negative if the script fails in anyway giving a false sense of security.

#!/bin/bash
chmod 755 /usr/share/doc/bash-3.2/scripts/timeout
ret=$(echo Q | /usr/share/doc/bash-3.2/scripts/timeout 5 openssl s_client -connect "127.0.0.1:${2-443}" -ssl3)
if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
 if echo "${ret}" | grep -q 'Cipher.*0000'; then
 echo "SSL 3.0 disabled"
 else
 echo "SSL 3.0 enabled"
 fi
else
 echo "SSL disabled or other error"
fi

The outputs will be similar to below on Elastix

[root@elastix24 ~]# ./sslv3.sh 
depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=10:certificate has expired
notAfter=Jun 15 18:30:20 2014 GMT
verify return:1
depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
notAfter=Jun 15 18:30:20 2014 GMT
verify return:1
DONE
SSL 3.0 enabled

As we can see its enabled.

Now edit the file  /etc/httpd/conf.d/ssl.conf

and change line 100 (in Elastix 2.4)

from SLProtocol all -SSLv2    to  SLProtocol all -SSLv2 -SSLv3

The restart the httpd service.

then test again and you should get

13033:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1086:SSL alert number 40
13033:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:
SSL disabled or other error

If you want to read the background here is the relevant document

Click to access ssl-poodle.pdf

Categories
Asterisk Support Elastix Support Knowledge Base Security

Elastix 2.4 ARI vulnerability Patch

The recent vulnerability in the Asterisk and Freepbx ARI login.php file is not addressed in an update to ARI in the unembedded freepbx on Elastix 2.4.

This will mean that your systems will still be vulnerable.

We have produced a patch that you can apply to address this. The patch can be downloaded  from https://s3.amazonaws.com/filesandpatches/ari.patch and applied as detailed below.

logon to the server console

cd /var/www/html/recordings/includes
cp login.php /root/login.php.ari
wget https://s3.amazonaws.com/filesandpatches/ari.patch
patch < ari.patch 

Then to check either login to server ARI interface or 

cat login.php |grep json

and you should get the following output

$buf = json_decode($_COOKIE['ari_auth'],true);
$data = json_decode($crypt->decrypt($data,$ARI_CRYPT_PASSWORD),true);
$data = $crypt->encrypt(json_encode($data),$ARI_CRYPT_PASSWORD);
$buf = json_encode(array($data,$chksum));


also check to see if you have the file in the fw_ari directory.

ls -l /var/www/html/admin/modules/fw_ari/htdocs_ari/includes

if there is a login.php there then copy over the patched version.

cp /var/www/html/recordings/includes/login.php  /var/www/html/admin/modules/fw_ari/htdocs_ari/includes/login.php

After these actions check that the file ownership is still correct

if not 

chown asterisk:asterisk /var/www/html/recordings/includes/login.php 

This patch also applies to any older version of ARI out there.

also to be on the lookout for two suspicious files, named “c.sh” or “c2.pl” respectively. If you see these two files remove them immediately!

More details here. http://community.freepbx.org/t/critical-freepbx-rce-vulnerability-all-versions-cve-2014-7235/24536 or here http://support.freepbx.org/node/92822

 

 

 

Categories
Asterisk Support Elastix Support Knowledge Base Security

Keeping the Bots at bay out and allowing your friends in

Recently we have seen an upsurge in Bots attacking Asterisk servers, Interestingly its not good old sipvicious anymore but a Windows program called sipcli and originating mainly from the US and Germany.

Normally our iptables firewalls are updated but for some reason these keep getting through, So we have now based rules on the User-Agent in iptables as well

Here are a few examples to get rid of many of the favourites

-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: friendly-scanner" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipcli" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: VaxSIPUserAgent" --algo bm --to 65535 -j DROP

Also its worth adding these ranges as little good will ever come from them

# Ponytelecom ranges
-A INPUT -s 62.210.0.0/16 -j DROP
-A INPUT -s 195.154.0.0/16 -j DROP
-A INPUT -s 212.129.0.0/18 -j DROP
-A INPUT -s 62.4.0.0/19 -j DROP
-A INPUT -s 212.83.128.0/19 -j DROP
-A INPUT -s 212.83.160.0/19 -j DROP
-A INPUT -s 212.47.224.0/19 -j DROP
-A INPUT -s 163.172.0.0/16 -j DROP
-A INPUT -s 51.15.0.0/16 -j DROP
-A INPUT -s 151.115.0.0/16 -j DROP

# VITOX TELECOM
-A INPUT -s 77.247.109.0/255.255.255.0 -p udp -j DROP 
-A INPUT -s 185.53.88.0/24 -p udp -j DROP 
-A INPUT -s 185.53.89.0/24 -p udp -j DROP 
-A INPUT -s 37.49.224.0/24 -p udp -j DROP 
-A INPUT -s 37.49.230.0/24 -p udp -j DROP 
-A INPUT -s 37.49.231.0/24 -p udp -j DROP 
-A INPUT -s 77.247.110.0/255.255.255.0 -p udp -j DROP

For Freepbx format add following to /etc/firewall-4.rules

-A fpbxreject -s 37.49.231.0/24  -m udp -p udp -j DROP
-A fpbxreject -s 37.120.129.0/19   -p udp -j DROP
-A fpbxreject -s 185.53.88.0/24  -p udp -j DROP
-A fpbxreject -s 185.53.89.0/24  -p udp -j DROP
-A fpbxreject -s 185.53.90.0/24  -p udp -j DROP
-A fpbxreject -s 185.53.91.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.224.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.225.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.227.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.228.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.229.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.230.0/24  -p udp -j DROP
-A fpbxreject -s 37.49.231.0/24  -p udp -j DROP
-A fpbxreject -s 77.247.108.0/24  -p udp -j DROP
-A fpbxreject -s 77.247.109.0/24  -p udp -j DROP
-A fpbxreject -s 77.247.110.0/24  -p udp -j DROP
-A fpbxreject -s 77.247.111.0/24  -p udp -j DROP
-A fpbxreject -s 62.210.0.0/16 -p udp -j DROP
-A fpbxreject -s 195.154.0.0/16 -p udp -j DROP
-A fpbxreject -s 212.129.0.0/18 -p udp -j DROP
-A fpbxreject -s 62.4.0.0/19 -p udp -j DROP
-A fpbxreject -s 212.83.128.0/19 -p udp -j DROP
-A fpbxreject -s 212.83.160.0/19 -p udp -j DROP
-A fpbxreject -s 212.47.224.0/19 -p udp -j DROP
-A fpbxreject -s 163.172.0.0/16 -p udp -j DROP
-A fpbxreject -s 51.15.0.0/16 -p udp -j DROP
-A fpbxreject -s 151.115.0.0/16 -p udp -j DROP

If you are still getting problems check out a sip trace and look for the contact part of the

Contact: <sip:100@xxx.www.rrr.zzz:5070>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE
User-Agent: sipcli/v1.8                       <<<<<<<<<<<<<<<< here it is 
Content-Type: application/sdp
Below is a simple Bash script to create iptables entry for Linux. Create a script and paste the code in , if you just run it it created entries ready for Centos iptables id you run  ‘scriptname freepbx’ it created the entry for /etc/firewall-4.rules
#!/usr/bin/bash
SCANNERS='owenee Custom SIP gazllove pplsip sipcli sipvicious sip-scan sipsak sundayddr friendly-scanner iWar CSipSimple SIVuS Gulp sipv smap friendly-request VaxIPUserAgent VaxSIPUserAgent siparmyknife Test'
SYS=$1
if [ "$SYS" != "freepbx" ]
then
SYS=NOOP
fi
echo This is for a $SYS system
echo Copy and paste below
echo
PORTS='5060:5261'
PROTOS='udp tcp'
for scanner in $SCANNERS; do
for port in $PORTS; do
for proto in $PROTOS; do
if [ "$SYS" = "freepbx" ]
then
echo -A fpbxreject -p $proto -m $proto --dport $port -m string --string '"User-Agent:' $scanner'"' --algo bm --to 65535 -j DROP
else
echo -A INPUT -p $proto -m $proto --dport $port -m string --string '"User-Agent:' $scanner'"' --algo bm --to 65535 -j DROP
fi
done
done
done

In this case just set as we have in iptables and it will catch all versions.

Hope this helps you as much as it has helped us

Also this idea can be reversed to only allow user agents (phones) you want to accept.

Here are a few examples of common soft and hardphones

-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: Yealink" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: FPBX" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: Linphone" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT  -p udp -m udp --dport 5060 -m string --string "User-Agent: DX800" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT  -p udp -m udp --dport 5060 -m string --string "User-Agent: 3CX" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT  -p udp -m udp --dport 5060 -m string --string "User-Agent: Grand" --algo bm --to 65535 -j ACCEPT

Again to find others just do a sip trace and note down the user agent.

This can also be extended to make you system more secure by only allowing in devices that register to you FQDN and not just ip address

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
# -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#ssh moved from 22 to random port
-A INPUT -m state --state NEW -m tcp -p tcp --dport 65432 -j ACCEPT
#Web interface moved to new port.
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8765 -j ACCEPT
#drop sipvicious traffic
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A INPUT -i eth0 -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p udp --dport 4569 -m state --state ESTABLISHED,RELATED -j ACCEPT
#only allow Yealink phones
-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: Yealink" --algo bm --to 65535 -j ACCEPT
#That register to your domain name directly
-A INPUT -i eth0 -p udp --dport 5060 -m string --string "REGISTER sip:yoursip.yourdomain.co.uk" --algo bm -j ACCEPT 
#only allow iax from known server
-A INPUT -s xxx.xxx.xxx.0/22 -p udp -m udp --dport 4569 -j ACCEPT
-A INPUT -i eth0 -p udp --dport 5060 -j DROP
-A INPUT -i eth0 -p udp --dport 10000:20000 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

The above example should keep you secure. (but things and methods change so keep your eye on the ball)

Categories
Knowledge Base

Better SIP security

In Seven Steps

Original Text by J Todd March 28th, 2009

In case any of you were wondering why there has been a fairly notable upswing in the attacks happening on SIP endpoints, the answer is “script kiddies.”  In the last few months, a number of new tools have made it easy for knuckle-draggers to attack and defraud SIP endpoints, Asterisk-based systems included.  There are easily-available tools that scan networks looking for SIP hosts, and then scan hosts looking for valid extensions, and then scan valid extensions looking for passwords.You can take steps, NOW, to eliminate many of these problems.  I think the community is interested in coming up with an integrated Asterisk-based solution that is much wider in scope for dynamic protection (community-shared blacklists is the current thinking) but that doesn’t mean you should wait for some new tool to defend your systems.  You can IMMEDIATELY take fairly common-sense measures to protect your Asterisk server from the bulk of the scans and attacks that are on the increase. The methods and tools for protection already exists – just apply them, and you’ll be able to sleep more soundly at night.

Seven Easy Steps to Better SIP Security on Asterisk:

 

1) Don’t accept SIP authentication requests from all IP addresses.  Use the “permit=” and “deny=” lines in sip.conf to only allow a reasonable subset of IP addresess to reach each listed extension/user in your sip.conf file.  Even if you accept inbound calls from “anywhere” (via [default]) don’t let those users reach authenticated elements!

 

2) Set “alwaysauthreject=yes” in your sip.conf file.  This option has been around for a while (since 1.2?) but the default is “no”, which allows extension information leakage.  Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks.

 

3) Use STRONG passwords for SIP entities.  This is probably the most important step you can take.  Don’t just concatenate two words together and suffix it with “1? – if you’ve seen how sophisticated the tools are that guess passwords, you’d understand that trivial obfuscation like that is a minor hinderance to a modern CPU.  Use symbols, numbers, and a mix of upper and lowercase letters at least 12 digits long.

 

4) Block your AMI manager ports.  Use “permit=” and “deny=” lines in manager.conf to reduce inbound connections to known hosts only.  Use strong passwords here, again at least 12 characters with a complex mix of symbols, numbers, and letters.

 

5) Allow only one or two calls at a time per SIP entity, where possible.  At the worst, limiting your exposure to toll fraud is a wise thing to do.  This also limits your exposure when legitimate password holders on your system lose control of their passphrase – writing it on the bottom of the SIP phone, for instance, which I’ve seen.

 

6) Make your SIP usernames different than your extensions.  While it is convenient to have extension “1234? map to SIP entry “1234? which is also SIP user “1234?, this is an easy target for attackers to guess SIP authentication names.  Use the MAC address of the device, or some sort of combination of a common phrase + extension MD5 hash (example: from a shell prompt, try “md5 -s ThePassword5000?)

 

7) Ensure your [default] context is secure.  Don’t allow unauthenticated callers to reach any contexts that allow toll calls.  Permit only a limited number of active calls through your default context (use the “GROUP” function as a counter.)  Prohibit unauthenticated calls entirely (if you don’t want them) by setting “allowguest=no” in the [general] part of sip.conf.

 

These 7 basics will protect most people, but there are certainly other steps you can take that are more complex and reactive.  Here is a fail2ban recipe which might allow you to ban endpoints based on volume of requests.  There is discussion on the asterisk-user and asterisk-dev mailing lists of incorporating this type of functionality into Asterisk – let’s hear your ideas!

 

If you’d like to see an example of the tools that you’re up against, see this demo video of an automated attack tool that does scan, guess, and crack methods via a click-and-drool interface.
In summary: basic security measures will protect you against the vast majority of SIP-based brute-force attacks.  Most of the SIP attackers are fools with tools – they are opportunists who see an easy way to defraud people who have not considered the costs of insecure methods.  Asterisk has some methods to prevent the most obvious attacks from succeeding at the network level, but the most effective method of protection are the administrative issues of password robustness and username obscurity.

 

JTodd
Digium
Categories
Knowledge Base Technical

Nagios plugin for reading the Asterisk Database

This is a simple plugin that is based on one by Jason Rivers We have changed it now to read the ASTDB (Asterisk internal Database and then based on ok and Critical keys it will report OK or Critical staus reports to Nagios.

This was written for reporting if an Elastix system is in Day or Night mode.

You can define the Database Family, Key, Critical value and OK value. This means you can cutomise it to what ever you need to report.

 

The Code is below, make you may need to change /usr/bin/nc for what ever you use for netcat.

any issues email us, but dont forget this is given for free not supported for free.

#!/bin/bash
#
# Program : check_asterisk_ami
# :
# Author : Original code by Jason Rivers < jason@jasonrivers.co.uk >
# : Modified by Cyber-cottage.co.uk for checking the asterisk Database
# :
# Purpose : Nagios plugin to return Information from an Asterisk host using AMI
# :
# Parameters : --help
# : --version
# :
# Returns : Standard Nagios status_* codes as defined in utils.sh
# :
# Licence : GPL
#
# Notes : See --help for details
#============:==============================================================
PROGNAME=`basename $0`
PROGPATH=`echo $0 | /bin/sed -e 's,[\/][^\/][^\/]*$,,'`
REVISION=`echo '$Revision: 1.1.0.6 $' | sed -e 's/[^0-9.]//g'`
. $PROGPATH/utils.sh
print_usage() {
echo "Usage: $PROGNAME [-H hostname] [-u username] [-p password] [-P port] [-k DBkey] [-c critical] [-o ok] [-f family]"
echo " -H Hostname"
echo " -u AMI Username"
echo " -p AMI Password"
echo " -P (optional) AMI PORT"
echo " -k Database key"
echo " -f Database family"
echo " -c Critical Key"
echo " -o OK KEY"
echo ""
echo "SupportedCommands:"
echo " Most DB familiys that toggle such as DayNight in elastix"
echo "Usage: $PROGNAME --help"
echo "Usage: $PROGNAME --version"
}
print_help() {
print_revision $PROGNAME $REVISION
echo ""
echo "Nagios Plugin to check Asterisk ASTDB using AMI"
echo ""
print_usage
echo ""
echo "Asterisk Call Status Check. orignal version by © Jason Rivers 2011 changes to do ASTDB by cyber-cottage.co.uk"
echo ""
exit 0
# support
}
# If we have arguments, process them.
#
exitstatus=$STATE_WARNING #default
while test -n "$1"; do
case "$1" in
--help)
print_help
exit $STATE_OK
;;
-h)
print_help
exit $STATE_OK
;;
--version)
print_revision $PROGNAME $REVISION
exit $STATE_OK
;;
-V)
print_revision $PROGNAME $REVISION
exit $STATE_OK
;;
-H)
REMOTEHOST=$2;
shift;
;;
-P) AMIPORT=$2;
shift;
;;
-u) AMIUSER=$2;
shift;
;;
-p) AMIPASS=$2;
shift;
;;
-c)
CRITICALNAME=$2
shift;
;;
-o)
OKNAME=$2
shift;
;;
-k)
DBKEY=$2;
shift;
;;
-f)
FAMIL=$2;
shift;
;;
*)
echo "Unknown argument: $1"
print_usage
exit $STATE_UNKNOWN
;;
esac
shift
done
if [ "${AMIPORT}" = "" ]; then
AMIPORT="5038"
fi
if [ "${FAMIL}" = "" ]; then
##WARNING
echo="CRITICAL: Unknown KEY"
print_help
exit=$STATE_CRITICAL
else
## Checking Astdb
CHANNELS=`/bin/echo -e "Action: login Username: ${AMIUSER} Secret: ${AMIPASS} Events: off Action: DBGet Family: ${FAMIL} Key: ${DBKEY} Action: Logoff " | /usr/bin/nc $REMOTEHOST ${AMIPORT} | awk '/Val/ {print $2}'|tr -d " "`
if [ "$CHANNELS" = "" ]; then
echo "UNKNOWN: Unable to get ASTDB status"
exit $STATUS_UNKNOWN
fi
if [ "$CHANNELS" = "${OKNAME}" ]; then
exitstatus=$STATU_OK
MSG="OK: ${DBKEY} Asterisk Emergency message not active"
elif [ "$CHANNELS" = "" ]; then
exitstatus=$STATU_WARNING
MSG="WARNING: Asterisk Unknown status"
elif [ "$CHANNELS" = "$CRITICALNAME" ]; then
exitstatus=$STATU_CRITICAL
MSG="CRITICAL: ${DBKEY} Asterisk Emergency message active"
fi
fi
echo $MSG
exit $exitstatus