Elastix securing, preventing, monitoring
•Télécharger en tant que PPT, PDF•
9 j'aime•11,654 vues
Bob Fryer Australia Bluepackets 5Th conference - ElastixWorld 2011 Elastix securing, preventing, monitoring Elastix, asegurando, previniendo, monitoreando
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (18)
Similaire à Elastix securing, preventing, monitoring
Similaire à Elastix securing, preventing, monitoring (20)
Plus de PaloSanto Solutions
Plus de PaloSanto Solutions (20)
Dernier
Dernier (20)
Elastix securing, preventing, monitoring
- 1. Elastix® Security Securing, Prevention, Monitoring
- 2. Security Reality – the hard facts
- 4. Toll Fraud - A growing issue
- 5. Toll Fraud – what is the potential damage?
- 6. What do they gain from Toll Fraud?
- 7. Toll Fraud - Highly organised & Smart
- 8. A Quick Analysis of an Attack: SIP Port Probe
- 9. A Quick Analysis of an Attack: Extension Harvest
- 10. A Quick Analysis of an Attack: Dictionary Attack
- 11. A Quick Analysis of an Attack Quick Facts
- 15. Securing - Remote Extensions
- 16. Securing - Elastix® PBX Security
- 17. Securing – Network Firewall Security
- 18. Securing - Elastix® Firewall
- 21. Prevention – Don’t Install applications!!
- 22. Prevention – Change Control
- 23. Prevention - Use a VPN
- 24. Prevention – Outbound options
- 31. Monitoring - Router/Firewall Log Review
- 32. Monitoring – Via Network Management
- 34. Security - Common Mistakes
- 36. Elastix Security - More info Application Note releases and updates are posted on twitter @ElastixBob
- 37. Any Questions?
Notes de l'éditeur
- Thank you for the opportunity to speak to you today. This presentations purpose is to provide a holistic look at security and how it applies to Elastix® and how it can be applied in Elastix®. It is divided into Four main sections which will include A quick look at Toll Fraud to provide the context A review of methods of securing Elastix® at the install and pre-production phase A look at prevention techniques whilst the system is in production And finally a look at monitoring to limit exposure in the event of toll fraud occurring
- Before we proceed further, I want to go over a few basic Security realities. I believe most of you know these facts, but I want to go over them to reinforce them. No functional IP PBX system will be 100% secure and I use the word functional. If it is connected to the network (and which IP PBX system will not be), it is possible that it can be attacked. You should never guarantee and you cannot guarantee that your Elastix® system is 100% secure. Like all things in life, there is a risk. You risk your life every time you get into a car. Yes you can mitigate risks by driving a car with all the safety features such as air-bags and traction control, you might do an advanced driving course, and you mitigate your costs with car insurance, but in the end it is still possible to have a serious accident. The costs of trying to achieve 100% security is truly an exponential curve. The closer you get to 100%, the more costs that are involved. These costs are not necessarily directly attributable such as a new Firewall, or a new Network Management system, but also include employee time reviewing logs and systems and keeping them updated. Then there is the reporting time, and the management time to review and present the reports. Finally we come the other golden rule which is, the security in the system is only as strong as your weakest link. You might have the world’s best firewall in place, and a company monitoring your firewall and managing changes to your firewall. However, this may not stop a rogue employee running SIP scanning services on the Elastix® system from the Internal Network. You also have the possibility that a “Trojan” may perform the attack internally. I personally haven’t seen one yet, but it is a definite possibility that a Trojan can be designed quite easily that does a Brute-Force SSH attack and reports its findings to an IRC channel or similar. With the proliferation of IP PBX systems, it is likely that this sort of trojan will have a high strike rate, especially if it comes down disguised as a SIP related tool.
- Toll Fraud is nothing new, but it is nothing specific either. To use the Webster’s Online dictionary it is “ A crime in which a hacker obtains telecommunication services by: breaching computer security, using or selling stolen long-distance credit-card codes, or, accessing a private branch exchange and using its communication facilities illegally” It can be done by various methods, which include, but are not limited to Tone Generation (not common nowadays) Via Modem access (to older PBX systems) Accessing a PBX via DISA Accessing a PBX via Voicemail systems SIP Hacking via the Internet As I mentioned, it is nothing new, but the shear number of IP PBX systems being put online by both experienced and inexperienced implementers with SIP Trunks, has given a new lease of life and opportunities for Toll Fraud And it is not just in the domain of Open Source PBX systems, but Brand name systems as well, as many legacy installers are coming to grips with understanding Networks and security. Something many of them are failing to understand.
- Toll Fraud is a real issue – its not something that happens to the next guy, it can happen to you. Toll Fraud is committed by Criminal Elements (including Terrorist organisations), not just by hackers looking for a thrill. In 2009 Communications Fraud Control Association (CFCA) has estimated that global fraud losses to be in the range of $72-$80 Billion (USD). Many of the losses are not announced, especially for many businesses, it’s an embarrassment, and something they don’t wish to advertise to their clients or their competitors. With the increase in IP PBX systems in use, these systems are contributing heavily to these numbers. As previously mentioned, Toll Fraud is not new, but the techniques, methods and tools are easily within reach of anyone who wants to learn. Especially with SIP being universal, no longer do you have to learn the insides of a particular model, you now have a script that will cover many of the SIP PBX systems today.
- It is fair to say, on a system where security has been compromised, it is envisaged that the majority of SME systems (usually 10 channels, either SIP or PRI) that over one weekend, it is possible to incur direct costs from anywhere near $20,000 through to $150,000+ Then there are further costs to the business, which includes the phone system offline (which can also be time locating a suitable engineer). The costs of a security review, and if necessary other Network engineers to assist in locking the attackers out. And inevitably, you have an issue with either management confidence in the system, which may extend to the staff level. It is even more of a concern in a call center. A stance has been taken by most of the worlds carriers, and many authorative bodies, such as the FCC, that the IP PBX owner is fully responsible for any traffic that the system generates. This is further iterated by many carriers publishing documents stating that fact as well. They might be able to negotiate a better price for the calls, especially as it is a fraud event, but this will differ from carrier to carrier, it may depend on re-signing a new 2/3 year contract. In a recent case the business was able to negotiate successfully, a reduction in the bill from $20,000+ to $11,000. You might be thinking that the Carriers need to take some responsibility for allowing that amount of calls through, especially as it is an increase of say 20 times the normal call volume. I agree with you, and to be fair, some carriers have this capability to limit or close outgoing calls but at the moment for many carriers, this is a manual operation, and usually only done in conjunction with a the business owner. Trying to perform this operation over a weekend with no one at the business is close to impossible. To perform this off their own back, would leave them open to legal ramifications It actually needs everyone to take responsibility, the owner of the business to keep a maintained PBX system, the PBX provider to take a more serious approach to Security, which includes monitoring. The Carrier to implement automatic systems that allow businesses to set a pre-determined daily spend limit, which automatically locks down all or just international calls. These are all items that can be achieved right now.
- They can on-sell the calls by selling Calling Cards. The number of calling cards in the world is impossible to calculate. Especially in some of the poorer countries, the number of cards available is endless, and with no way of telling which ones are using legitimate means, and which ones are utilising Toll Fraud to traffic their calls. Even the design of the Best Minutes PhoneCard was made up in 5 minutes, and actually looks far more professional than many other cards I have seen. The issue with the calling cards is that there is very little regulation. The U.S. and other countries have begun to, and may have interim regulations in place, but in many other countries, no regulations exist and the local print shop can produce these cards, and basically anyone can sell them. Furthermore, the quality of service is not regulated, with many people reporting poor lines, engaged signals, no dialtone. You have to wonder are they using “illegal” lines, and the consumer would have no idea. If they are not being used for Calling Card purposes, the details may be sold on the street. And we also can’t discount the attacks that are just done for the challenge, or to prove to themselves or to their friends that they can hack into a system. For a system that has not been secured, it is relatively simple.
- Don’t make the mistake of believing that the Toll Fraud instigators are stupid. Don’t think that you will be able to trace them back using the IP address, and provide the information to authorities. The majority of attacks on your system will come from other systems that have already been hacked (e.g. Brute Force SSH), or from legitimate hosting Servers where in some cases, the account has been setup with fraudulent details, or a legitimate company is running a hosted PBX solution, but inadvertently left the door open for hackers, quite often implementing a solution that has a security flaw. A large percentage perform their attack when there is the least amount of possibility of being detected, so quite often, attacks occur on Friday nights and persist through the weekend. Likewise the attacks increase during the festive season. It’s peak season for callers calling home to talk to family, it again is the time when many businesses close up shop or have minimal staff onboard.
- First step in a SIP attack is that they probe your open ports on your router, in particular looking for SIP Port 5060, the most common SIP port. However don’t make the simple mistake of changing your SIP port to a higher number. There is absolutely no reason why they can’t modify their software to scan some of the higher SIP ports. Agreed it might stop 95% of the attacks, but just as you thought of another way to protect your system, they think just the same way, and in fact they read constantly learning new ways people are protecting their system. They scan a range of addresses, looking for any address with the port 5060 open. They build a database of IP addresses where Port 5060 is open. They may do this over several days/weeks. Once they have database, they move to the next stage.
- The Extension Harvest Methodically, with the database of open SIP Ports, they start probing away by performing fake registrations of extensions. The purpose here is not to actually register but to look at the responses. Many of these attacks start with a port such as 100 and continue through to 10000. This doesn’t take long. The top picture is an excerpt from the logs of a system being attacked, and is from the /var/log/Asterisk®/full logs. The middle picture is a blow up showing some extensions did not register an error in the log (e.g. No matching peer found). What it means, with the line not being the log is that the system has responded with an invalid password or similar response. Again a database of responding extensions is compiled ready for the next stage
- The Dictionary Attack. Now with their database of IP addresses and possible live extensions, they commence the final part of their attack, which is to run a database of common words and passwords and run it against each responding extension on your PBX. This will continue until they have exhausted their dictionary of passwords, or until they have made a successful registration. At this point they may start placing calls via your PBX or at least within a few hours. That’s all there is to performing an attack on your system. Your PBX joins a long list of PBX systems that they can use to route their calls. Your system will be one of a number of systems that their systems can use to place calls. They work with the numbers game, probably 50% of PBX owners will recognise that they have an issue (but not before they have placed $20,000 worth of calls through your system), and shut the system down or improve their security. The other 50% they will keep using until the owner is alerted by the carrier, or the owner gets the bill for the month.
- Just a few quick facts to consider. Like yourself, they know the trick of adding a couple of numbers to the ends of words. Whilst almost all attackers do not try every number combination after a word, many are trying simple suffixes of 01 or 02 on the end of words. Some use a number generator to run through sequence of numbers. If you are using extension numbers or even a number from 1 to 10000, they will successfully register a connection. Finally, just so you don’t think that running through a large database is impossible, one a standard ADSL line e.g. 12Mb down/1Mb up, it is possible to run through 80 extensions per second in an extension harvest, and a dictionary attack, they can test 60 passwords per second. And to put it into real perspective, the entire unabridged Oxford Dictionary (700,000+ words) can be applied against the PBX in just over 3 hours.
- Sip hacking tools are readily available, and within reach of anyone. SIPVicious is one such tool and probably one of the most well known. Use it to your advantage by reading the blogs at SIPVicious to get an insight on how these attacks occur. SIPVicious is written in Python, but anyone with any ounce of programming skills could port this to another language or modify the existing SIPVicious code to utilise MYSQL databases. Think of SIPVicious as proof of concept code. Toll Fraud is serious and it can happen to anyone with a system that is not secure. Anyone implementing an IP PBX system, Securing, Prevention & Monitoring is of the utmost importance. It cannot be regarded as a task that gets done a few months down the track, as many attacks can occur within a couple of weeks of opening the SIP Port. It starts from the minute you commence your initial site review & quotation, through your install of Elastix®, and finally to monitoring.
- We will now look at a high level view of some of the simple techniques to reduce the probability of your PBX systems being hacked. Think of it this way.... If you leave home and you leave your doors wide open, the probability that someone will enter your home is quite high. If you at least leave home and lock your doors, you have probably averted a possibly home invasion, but you have not eliminated it entirely as they may break a window and enter that way. On the whole however you improved your chances that your home is secure. Same applies to IP PBX systems
- We will have a quick look at Extension Security. Don’t use simple numbers or standard words for passwords, or even words with a couple of numbers on the end as I previously mentioned. The same goes even more importantly, don’t use the extension number for the password I would have to say that greater than 50% of IP PBX systems I am asked to look at, the passwords fit into the categories above. Passwords with a clear, non-repeated mix of numbers, upper and lower case characters, and symbols are the best. I generally stick with 12 characters. You might think that this is too much, but with the proliferation of 100Mb Internet connections into many businesses, whilst the advantage of the slower internet is in the PBX favour, it is not always going to be that way, and as I mentioned previously, you need to think of attacks from internal as well, which can occur a far lot quicker. Something I find is that very few people use the Permit/Deny on the Extension configuration. This is simple method of denying registrations from IP addresses that are not on your particular network. If you are really serious about your security, you could lock each extension down to only allowing one phone IP address to connect, which in itself is not a bad thing, especially if you set reserved addresses in your DHCP for your phones. One of the largest security holes I find on many systems, which is also one of the strengths of IP PBX systems is the use of remote extensions. Many open up the SIP Port on the Firewall/Router to allow Remote extensions to connect in. These extensions may be Directors home extension, and as such they have a basic internet connection from home, usually with a dynamic IP address. Naturally this is almost impossible to lock down the firewall with an address that can change, so it is important to persuade them to obtain an Internet connection with a static IP address. Many complain that it costs extra for the static IP address, but point out the cost of not doing so. Sometimes, it is impossible to obtain a static IP address, so it is necessary to utilise to a VPN to make this connection. Finally, look at the possibility of using a different port for SIP. Now this requires changes on the phone, changes in the Extension setup in Elastix®, changes to the Firewall setup and it may affect some of the tools that you might use, but it is a useful tool. This is by no means a complete list of ways to secure an extension, but just a few basic improvements to greatly reduce the possibility of intrusion.
- Just to take the Remote extensions security a little further as it is quite often a major source of intrusion.... As mentioned before, strongly recommend that remote extensions have Static IP addresses. If this is not possible, then implement a VPN solution from router to router. Another alternative is to implement phones that have a VPN client built in. The Yealink T28 (and some other models) have an OpenVPN Client built into the phone. With the ability to implement OpenVPN onto the Elastix® system, the Yealink provides a good option. The same applies to staff running Softphones on laptops (e.g. Sales staff) or SmartPhones. Look at the options of ensuring that they utilise a VPN to connect from the outside to the office
- Now we will move onto securing the Elastix® box itself Since Elastix® 2.0, the installation process has allowed the setting of passwords for console, MYSQL, FreePBX® and add-on products. Don’t use the same password all the way through. I strongly recommend not implementing DISA unless absolutely required. DISA is an idea carried over from Legacy PBX systems, and like the older systems, it is a major source of attack. There is no simple way to secure it, as it relies on a simple pin number (e.g. Something that can be typed in on a phone), so I strongly recommend to clients we look at other solutions (e.g. Remote Phones, softphones etc). If a client ever asks for DISA to be implemented, I actually get them to sign a document stating that they recognise the security implications of using DISA. Anonymous SIP – I recommend to most that it is turned off. Unless you need it, it is one more possible source of intrusion, especially in an unsecure system Finally, something I do on most systems is to modify the SSH port to something completely different such as Port 3673. It is such a simple change, but again reduces the possibility of a brute force SSH attack.
- One of the most common mistakes is the automatic opening up of SIP and RTP ports on some Firewall/Routers by default. Many of the Pro-sumer routers / professional firewall/routers are SIP aware utilising various technologies, but on the whole they perform packets inspection and understand what ports are required. For those routers/firewalls that require the ports forwarded, you need to take the time to limit the address range that the SIP traffic can come from. The number of implementers who wont take the time to determine the range (especially where their SIP Provider is using round-robin servers), or won’t take the time to understand the capabilities of the routers is quite surprising. The firewall is an important part of your security, if the router does not perform basic firewalling, it is time to replace the router. Ideally your firewall/router will have an endpoint VPN capability. If your router does not have a VPN capability, then consider installing something like OpenVPN.
- When Elastix® 2.2 is released as stable, the Elastix® system will have an IPTables based firewall. For those of you that know your IPTables, you may have already been using it. IPTables is included in almost every Linux distribution since it replaced IPChains. It forms the basis of many Appliance style firewalls that are available today. What Palosanto has done is produce a great looking GUI around IPTables. Now I will be honest and say you still need to learn a little of how IPTables works, but this GUI has helped improve that learning curve. What’s more, all the basic rules have been created that are required by Elastix®, so it is possible to just turn it on, and provide a level of protection. However it is recommended that you may want to limit the addresses for SIP, and in fact you may need to duplicate the SIP rule, so you can limit the addresses for the trunk, and limit the addresses for the extensions. If you modify the SIP rule to only allow your voice provider in, you may find that you lockout all of your internal extensions. The GUI makes it visually easy to see what rules you have in place. After years of reading IP Tables, I still struggle to quickly locate what I am looking for, or miss it entirely. Quite simply, after many years of looking for Open Source GUI options, this is one of the best I have some across.
- One of the other misunderstood areas is Trunk security. It is fair to say that a large number of implementers don’t understand it, or choose to ignore it. Sometimes the insecure trunk is the result of just trying to get something to work, such as a GSM gateway, or FXO gateway. It doesn’t help when some of the suppliers of these products provide the basic “Asterisk® compatible” configuration, and users just implement it as gospel. They don’t realise that they have configured a very insecure trunk, as they are more elated that they have got the solution working. Some Voice providers are now starting to think and some are now considering providing their SIP services over a VPN. Now these sort of features are probably not from your lowest cost SIP providers, as it is another server they need to worry about, but for some of the newer breed of SIP providers, who realise that feature laden SIP provider can compete well with a low cost SIP provider, especially when you offer features such as VPN SIP Trunks, failover solutions, smooth transitions and porting of numbers, emergency hosted solutions. If you are connecting a number of offices, consider using IAX trunks with RSA Keys. Whilst a little bit of time is needed for setup, once done, you can generally be rest assured that your trunks are secure. And finally, as I just previously mentioned, really take the time to understand the configurations that you are using. This presentation can go for the day, discussing each configuration line and what the ramifications are. There are a few good documents on the Internet and I hope to complete the document on SIP Trunks which has been a work in progress for several months now.
- Well that covers the basics of securing your Elastix® PBX system. It was by no means comprehensive, but provides a couple of simple methods of securing your Elastix® system. We will now move onto the next area which is prevention. You might think that it is the same as securing your system, but actually it is one of the most common areas where security fails, and probably 50% of cases I have investigated, have been the direct result of lack of prevention.
- This is one rule that I am particularly strong on, even to the point that I may lose a client over my decision. Your Elastix® system is foremost an IP PBX system. Agreed there are some applications that are installed or can be installed as part of its role as a Unified Communications server. Most of these have a direct application in supporting the Elastix® product, and as such as a product supported by Elastix®, I live in the knowledge that a company like Palosanto, has some understanding of the risks, and this is further backed up by the fact that the community as a whole, contributes and would be diligent if they come across a possible security risk. But to install a FTP Server on your Elastix® system for the public to transfer files to for another business process, is unnecessary and opening the doors for an attack. In fact I use this example, as it was a real life example. Fortunately their system wasn’t used to make calls, however it was “Owned”, and was used for 6 months to launch attacks on other systems, both Denial of Service attacks, and SIP Port scans. This FTP install was done by an IT company, and yet when the customer complained that their Internet was slow or not connecting, their IT company for months, told them to turn off the IP PBX, which solve it for the next few days. Something didn’t click when they were over their Internet limit every month either. As you can imagine, the attackers managed to obtain root access by a well know flaw in the FTP Server (it is also fair to say there we some permissions issues as well). This mentality follows through from installers of Windows systems where the server is installed with every application imaginable. The worst that can occur on a Windows server is a crash, a few million SPAM, possible Web page graffiti, and if you are really unfortunate, some corporate data, but if you keep corporate data on a public facing system, then I am sorry, we can’t help you. This is why I shudder when I see that people run a PBX system on a Windows Server, and boast that it runs beautifully with other applications (never mind the new security holes that you have just created). Don’t get me wrong, I have been implementing and working on Windows systems since Windows 2.0, and some things are meant for Windows, and some are better suited to Linux. Webmin is another tool, I hate seeing installed on a Elastix® system. Not that Webmin itself is going to be used as a point of attack, but how simple it makes it for users to install a range of applications. Again it hides the need to understand the security ramifications of the product that they are configuring. This is an argument that could go till the end of time. But the simple rule it comes down to is, why do I need it, and why do I need it on the Elastix® system. I talked about the weakest link before, one of these applications with a security flaw, could be your weakest link, and all the Security work you had performed could be circumvented.
- Change Control is something that many small to medium businesses have no idea of what it means. In the larger corporate businesses, you wont get through the day without hearing the word or needing to consider it. Now with an IP PBX, we don’t need to go to the lengths that the corporate businesses go, with meetings, and several days of discussion and sign off’s, but the methodology can be used and applied to changes made to the Elastix® system and its environment. Now each business is going to be different. With some, you are the only IT Provider, you manage the firewalls, routers, servers, and the IP PBX. That’s the best position to be in, but consider that you might not be the only engineer from your business working on this system, especially while you are on holidays. Making sure that everyone that works on the system and its environment has an understanding of what has been done recently and why is important. Even a simple document stating the changes you have made, when, by who will provide some traceability, and understanding. Then we move to the worse scenario, where you are the IP PBX Vendor, someone else looks after the Router/Firewall, someone else looks after the Network, and not one vendor talks to each other. It is, in many cases, a perfect recipe for a security disaster waiting to happen and it has. With your knowledge of security and its possible ramifications, it is up to you to make it clear to a client that they cant deal with each vendor in isolation. Whether you implement an Email based change control mechanism, or you take on the role yourself (depending on your involvement with the business), or you implement a simple formatted spreadsheet, that everyone fills out, and you review when you perform your maintenance. As I have pointed out to Palosanto, it would be a nice feature within Elastix®, and easy to implement a simple database allowing changes to the system to be logged (manually), with a date, time and person involved. This could be extended further with automatic logging of system reboots or changes to the configuration (not necessarily what changes, but the fact that the “apply changes” has been activated), and a good mechanism to check whether changes were logged. But it can be this simple.
- Another area of concern is the opening of ports to perform quick changes. Sure there are reasons for doing this, especially if getting remote support from a vendor that you don’t deal with on a regular basis. The number of times, the person thinks I will leave that port open, just in case it still needs some further work, only to forget that they left it open. If you open it, as soon as you are finished, close it. Occasionally I am called upon to assist remotely, and there is no VPN capability, and the only method is via SSH. As soon as I am finished with the work, I make a point of asking them to close the port again, and I make it very clear. Usually after performing some remote work, I actually set a reminder 2 hours later to check that the port has been closed by trying to connect to that port. But realistically, there is no reason not to implement a VPN of some sort, whether its router that has a VPN capabilty, or you install OpenVPN on your Elastix® system. Not implementing some sort of VPN solution is just waiting for a breach to happen. If you really can’t implement a VPN solution, consider using some of the remote desktop tools to control a PC within the internal Network.
- This is a nice prevention tool. When Elastix® 2.2 stable is released, one of the new features is the ability to place time conditions on outbound routes. As we spoke about previously, many of the SIP attacks are timed to utilise your system when you are closed or in a low staff situation and this option allows you to place a time condition on say your International Outbound route, limiting all International calls to day time hours only. Another common thing I find is the blanket Outbound International route which consists of the IDD code for that country with a dot after it. Many businesses deal with a select number of countries. In most cases, the number doesn’t exceed 10 to 20 common ones, add each of these routes in, instead of the obligatory match anything.
- Here is another great prevention tool. Daily cost limits. Again this is more likely to be something your can obtain from a value-add SIP Provider (e.g. Not the lowest cost), but being able to set daily limits on your call costs. It is a great indicator when calls can’t be made from a system, that something is very wrong. But it isn’t just an indicator that something is wrong, it actually limits the clients exposure should an attack occur. So imagine their system was attacked over a weekend, and on Monday it was realised, and you had set a $100 limit per day. The exposure for the client may tally $400, and you could put that down to a lesson learned, and far more palatable than $20000+, which is not just a lesson learned but a knock out punch. Ideally this SIP provider allows you access to a secure Web GUI, so that you can make instant changes as the business model changes, or add a bit of headroom, whilst you sort the issue out. The general public does not get to know about it either as calls continue to come in when the limit has be reached as it only affects outgoing calls.
- Finally we come to the final section of Elastix® Security which is monitoring. No matter how good you are, how well you keep up with latest security techniques, how much money you have thrown at your security solution, there is always the possibility that someone is going to get through. This is where monitoring comes in. Basically your last line of defence, and in many cases your saviour if correctly setup and maintained.
- It cannot be understated the importance of regular maintenance on your Elastix® system. Agreed, 99% of the time, there will be nothing to find, the same old thing month after month, but it is when that 1% occurs, you will be glad you did. As a minimum I recommend a review of your system, which includes checking the logs, testing SIP access, checking that the firewall rules are still in place. Basically running through a check list. As you get used to it, you will probably find that 15-30 minutes is all that is required. Another 15-30 minutes writing up a report if required, and know with confidence that your system is not wide open.
- As mentioned in the previous slide, reviewing the logs is relatively simple. You don’t necessarily need to scan every line. Use the tools and perform searches for phrases like “wrong password”, look for “unreachable” which could could be an indicator that someone is flooding your Elastix® PBX. I suggested that these checks be performed monthly at least, but this should be your first and immediate option when users complain that their phone is going offline, or they are getting a number of calls with no one on the other end of the line. The logs I recommend reviewing are the /var/log/messages which is a general dump log for many of the services running on your Elastix® system /var/log/secure which will show you attempts being made to logon to the console or via SSH and also the Asterisk® log, which is /var/log/full
- One of the new items that joins the long list of Add-ons in Elastix® 2.2 is the Humbug add-on. Humbug is best described as Telecom Analytics, allowing you to view your inbound and outbound call usage. It also allows you to view your trunk usage, which is especially important if you use multiple trunks, and can provide you historical data to allow you to plan for future increases in channels or bandwidth. But, where the real power of Humbug is in the ability to provide fraud prevention and detection. With the ability to receive alerts from a variety of methods, include SMS, email and phone calls when certain thresholds are met, which can include hourly and daily limits, calls to blacklisted areas, calls at odd times, long calls exceeding a pre-determined limit, and as Humbug call it Specific Statistically Significant Anomolies, which are call traffic that is inconsistent with your historic call traffic patterns. This service runs externally to your Elastix® PBX, which provides the confidence that doesn’t get shutdown just because someone has managed to gain access to your system. Ok, so its not free for the Fraud Prevention and detection option, but its a decent price, and very easy to build into a maintenance contract. The reports and information available would take you hours to compile, and to be alerted when something is triggered, the value cannot be measured.
- One of the most common failings I find in many businesses is the lack of log review of the Firewall/Router. It becomes even more important with businesses implementing IP PBX solutions. The majority of pro-sumer and professional router/firewall solutions have a logging capability either internally or at least the ability to provide logs to an external Syslog server. Again it is not necessary to spend hours on the logs, but look for common scans on SIP port 5060 or port 22 for SSH. It is when these show up or increase beyond a small number, it is a good indicator that it is time to increase your vigilance and/or increase your review of the Elastix® logs.
- The use of Network Management Systems (NMS) is also useful for identifying unusual trends. There are number of simple tools such as Cacti, Munin to name a few. Naturally these do not provide alerts, but they can give an instant review of issues that may be occurring, especially of the number of active SIP channels has increased, since the day or hour before. Then we move on to Open Source Network Management systems such as Nagios, Opsview, OpenNMS, and Zenoss to name a few that are available. These NMS systems have Asterisk® plugins or interfaces available, and if not, you can write your own scripts and execute these as part of the monitoring. These NMS systems can be configured to alert you when certain Key indicators are reached. And of course you have the commercial solutions rounding it off. Many of these commercial systems may not have Asterisk® aware plugins, but they will support SNMP. You can implement SNMP on the Elastix® system and have it monitored by your Corporate NMS system with current MIB’s available.
- This is a very good question, and it matters on how you package it and sell it to your client. You could sell maintenance contracts to your clients, ideally you will include this as part of your quotation of the Elastix® IP PBX system. We find this works best, and maintains that customer relationship, especially if you are just the IP PBX supplier. It may be possible to additionally sell them Monitoring contracts, utilising something like Humbug. It is very easy to absorb the cost into such a contract and the reporting as part of the monitoring contract will provide them with the reassurance that monitoring is being performed. As mentioned, you are also able to provide future planning, such as additional trunks or bandwidth required, before they reach their limits. Another opportunity is the selling of Security reviews. Completion of a pre-defined check list with a report, and subsequent recommendations is an opportune moment to showcase your services and abilities.
- Here are some common mistakes with Security No time is quoted for Security review/check. This should be included in your quotation at the start. It should be conducted after the completion of the installation and just before you go live. Ideally, it is best done with a alternative engineer, someone that has not been involved with the installation, but regardless, it needs to be done. Many implementers, and IT departments, especially ones that have not seen an attack before, have a mentality that this only occurs to others who have made a mistake with their implementation. It can happen to anyone and will. We gave already spoken about software applications being installed on the Elastix® system, but it is a common mistake. Someone needs put their hand up and take some ownership (not necessarily responsibility) of the environment or at least changes to the Elastix® environment, especially where multiple vendors are involved.
- This presentation will be made available on Elastix®connection.com within the next week or so. Review the presentation again in your own time, and think about how you can apply some of the techniques or methods. Don’t just pick a couple of ideas and implement. You need to think holistically about Security. It is not just one new wonder tool and you are covered (although many of us wish it was). It is a combination of all that you have been shown. I personally, when securing a system, I always look at three layers of security. This way, if one layer is degraded (e.g. The firewall ports left wide open), then you have the safety of knowing that the next two layers of security will hold you in good stead.
- Finally more information can be found on the Elastix® Forums, under the Security forum. There are various blogs and papers on security at Elastix®.org. Also for many of the hands on Application notes, you can find these at www.Elastix®connection.com. A few papers I have listed above are still be finalised, but they will be out shortly. I was hoping to complete them before Elastix®World 2011, but time got away. If you want to keep up with the updates and releases of these application notes, then follow me on twitter @Elastix®Bob.