A short introduction to server security
When a computer is attached to the Internet, it is not many minutes before it is being probed and attacked from a variety of directions, using different attack vectors.
There are a number of methodologies that anyone running a linux based server can do to mitigate the risk of getting hacked, losing real money, reputation, data and time to put everything right again.
Minimal Installation
The more software that is installed and listening on external ports, then the larger the surface area there is to attack, and for the admin, a lot of work to keep everything patched and up to date.
For example, one of our main products, A2Billing, is often installed with Elastix, which is a great office PBX with a huge range of features and applications. However, to make use of the features of A2Billing, the web pages have to be exposed to the public internet, and by default, so do all the other web pages installed with Elastix, presenting a large attack surface area. Our advice is to install only A2Billing and Asterisk, and possibly a webUI for management of Asterisk.
Minimal Exposure
If an application is for internal use, e.g. MySQL or a mailserver for outbound mail only, then there is no point exposing it to the Internet. Some Linux distributions expose MySQL as a matter of course.
A useful tool for checking what is listening is nmap to check what is listening internally and externally, e.g. nmap -sT -O localhost and nmap -sT -O 192.168.1.2, where 192.168.1.2 is the external IP.
Block All You Can
Once you have only exposed what you need to the outside world, it makes sense to block everything else as another layer of security. Create a firewall using IPtables that blocks everything from everywhere, then only open the ports that are required to be open for operation of your system.
Iptables is a powerful facility in Linux and will prevent access on selected ports very effectively with little overhead on your server.
Geographical IPtables
If you are running a VoIP server, and your customers are all in your home country, then you can use IPtables to block access from countries other than your own, this dramatically reduces the number of people that can attempt an attack on your server.
Intrusion Detection
When you have got to the point of exposing only what you need to expose to only the people who need access, intrusion detection is a good idea.
Intrusion detection takes two forms. Detection of attacks, and checking nothing has changed. There are two popular open source products for this, Fail2Ban and OSSEC. We prefer OSSEC as it performs both tasks, whereas Fail2Ban only blocks.
Detection of attacks is typically done by looking at the logs, and if suspicious activity is detected, such as failed login attempts and looking for nonexistent web pages, it blocks all traffic from that IP address, usually for a limited period of time, just in case it’s a false positive.
A downside to this is that with a determined attack, producing many megabytes of logs, is that the IDS cannot keep up, and uses all the resources parsing logs. This can be alleviated using rate limiting in iptables, whereby iptables limit the rate at which requests can be made and therefore the logs created.
OSSEC will also look at the MD5 checksum of system files, which in simplistic terms, is a signature on a file. If the file is altered in any way, the MD5 checksum changes. OSSEC flags up any files that have been altered since the last time it checked.
OSSEC comes with default protection for the vast majority of applications and services, it is easy to install, and can be extended to parse almost any log type.
Layered Security
It goes without saying that using good passwords, password managers and two factor authentication where possible should be used. However, many web applications have their own authentication routine, A2Billing and Newfies-Dialer included.
No matter how apparently secure the user / password authentication is, there are new exploits being discovered all the time, so adding a second layer of security, such as htaccess in Apache is sensible, as Apache security is likely to be far more widely used, tested and inspected than your installed web application.
Obfuscation
It’s often said that there is “no security by obscurity” and a better approach is security by design and open security using testing by independent verification and testing as we do at Star2billing.
However in the real world, changing ports to little known or unused ports can cut down on the attacks, but beware…
Many public wifi access points and corporate firewalls prevent connections to non-standard ports, and so it may be that you are blocking potential users and customers, as well as causing yourself problems when a disaster happens, and you as the admin have to access the server remotely.
SSL Certificates
SSL certificates are a way of encrypting the data sent between your PC and the server you are talking to. they also confirm that the server you are talking to is the server you expect to be talking to, and not a fake site set up for the purposes of stealing your information. Any site that stores personal data should come with an SSL certificate, and you should see the little yellow padlock in your browser confirming they are who they say they are.
When you are on any public network. e.g. Wifi, or your data traverses networks that are not physically secure, anyone with a network sniffer can record a stream of your data, and from it, if not encrypted, can copy every single piece of information you have seen, each document you send, listen to unencrypted VoIP conversations,, as well as extract the username and password you used to get that information. It’s frighteningly easy!
It makes sense for anyone to encrypt all data passing over public networks, but you, as the server administrator, are not responsible for how people connect to you, but you can easily ensure that the data you are responsible for is encrypted end to end, simply by installing an signed authorised SSL certificate on your server for very little cost and ensure your customers use the HTTPS address.
How it works
The way that SSL encryption communicates is elegant, secure and simple. It can be explained by the the following analogy:
Imagine a box with places to put two padlocks on it –
- You put your data in the box, lock it with your padlock, and keep the key, then send it to the person you are communicating with.
- They put their padlock on your box, keeping their key, and send it back to you with both padlocks attached.
- When you receive the box, you remove your padlock, and send the box back again.
- Now the person you are communicating with can remove their padlock, open the box, and take out your data.
During the process or transmission, no-one can read your data even if they intercept it, it’s always had one or two padlocks on it. It is secure end to end. They send information back to you using the same process in reverse.
Clearly this is done with electronically, the above is only an analogy. But, you can see that each piece of data has to traverse the network twice, and there is some overhead from encryption.
However, on modern powerful servers, with good broadband, the advantages of not having your data exposed to the world as it traverses networks outweighs these minor disadvantages, and in any case, A2Billing and Newfies-Dialer are not high volume websites, so the loads are not heavy.
Where do I get certificates from
The certificate that proves the server is who they say they are is issued by a certificate authority, who effectively vouches that the server is the one they say it is. There are many certificate authorities who will issue you a certificate for a small annual cost.
It is possible to self-sign the certificate, which will have the effect of encrypting the data, but the trouble is that they are not trusted, so you cannot be certain who you are talking to.
Purchasing and Installing a Certificate
Prepare your server by setting up your desired DNS entry, e.g. www.star2billing.com pointing at your server, and updating WHOIS records.
- Generate a CSR (Certificate Signing Request) which is usually done on your server to uniquely identify your server.
- Send your CSR along with your name, FQDN and other information to the Certificate Authority
- They will validate your domain and company and send you your certificate.
- You configure your server to use the certificate they sent you.
If you find all of this a bit daunting, then Star2billing will be happy to assist you. But if you are keeping personal information about your customers such as name, address and call records, then you owe it to them to ensure that the information they send and receive from you cannot be intercepted and used against them. It’s easy and cheap.
Caveat: On corporate networks, sysadmin may have installed a corporate trusted certificate on a proxy, so everything is decrypted at the proxy, and re-encrypted for onwards transmission. When you are using a corporate machine (installed with the corporate certificate) , everything will appear as normal, but can be decrypted. If you are using a private device on a corporate network, then you will get certificate warnings from your browser. So in these circumstances, you cannot rely on the HTTPS certificate ensuring complete privacy.
Conclusion
Security has many layers, and a balance has to be sought between usability and security, without being too burdensome on either the administrator, customer and users.
We intend to publish more articles on security and running a VoIP business in the coming weeks.