Building a Linux Server - Secure Server and Networking
Introduction
When building a Linux server there are some points that we have to embed in our planning in order to choose the necessary tools to do our job. In this article we will cover these in general and throughout the series we will underline the key points to assist you in your tasks.
Hardware
This multi-core server with some terabytes of capacity is a big investment for your small office, while on the other hand you cannot manage a couple of hundred users with an off-the-shelf desktop. In your hardware choice, try to predict the future. You may be five people now, but what if the best-case scenario happens and your company grows to fifty in one year? How will you migrate user data, preferences, and e-mails? How will you back up them? What will you deploy as a test system? What about virtualization? You have to note all these points and many more before making the final purchase. Although this is not a clear-cut thing, your needs, predictions, budget, and common sense will guide you, not the salesperson.
Security
Security is an area that can not be thoroughly covered in a single article, nor in article series. But we will cover the basics in order to make your server and your network more secure.
Many administrators have different approaches to security and they are right in their positions. However, there are also some key points that that are/have to be present in each of them. The first one is choosing a stable distribution. When choosing your server, the distribution is very important. Instead of going with the latest and greatest distribution that you will be installing on your personal desktop, choose one with the well-known security history. Debian is one of these, openSuSE is another. In our articles we have gone with Ubuntu Server Edition, which is Debian-based and, if in need of assitance, has commercial support available from the vendor. Whichever distro you choose, do not forget to activate and use SE (Security Enhanced) Linux features. Security Enhanced features are various security policies, including some US Department of Defense style mandatory access controls, running at the kernel level.
Next, the updates. There should be strict procedures to download, test, and install the updates. Most of the time you should be comfortable with the security patches, but there are times when things may go wrong. In order to be prepared for the worst-case scenario and not to let all the network go down, I suggest you to go with virtualization technology. Make an exact clone of your main server and run it on a physically different computer to download and test the updates. If you are satisfied with the overall stability, then first connect a couple of users to the virtual server and see if everything goes well. If you do not encounter any problems, then you can go for a network-wide implementation. It will also be a good practice to monitor the security bulletins of the well-known anti-malware developers to be informed of the level of malware activity.
Security - continued
Physical access to the computer systems is one of the biggest things that you should take care of. As an IT policy, restrict access to your server room. Open plugs are one of the biggest dangers, and the easiest intrusion possible is through the meeting rooms. This can be considered normal psychologically: there is a stranger in the meeting room, everybody thinks he is waiting for somebody from the office, and in the meantime he is connected to the company network and checking e-mails. Are you sure? What about this stranger watching your unsecured network shares and silently copying unprotected documents? Develop strict procedures for telephone calls and emergencies. Are you sure that the person calling in on Saturday evening asking for his blocked password to be reset is the one who he claims to be?
Do not under- or overestimate the technical background of your users. Some can be very talented while for some a computer is no more than an electronic typewriter. Communicate your IT procedures simply and enforce them. Tell them that torrent, peer-to-peer, HTTP and FTP protocols are not allowed in the company. If a user needs to download files from an HTTP/FTP server, develop procedures to assist them immediately and let them have the files. Do not force your users to go home, download files from their own computer and bring them to work with their malware-infected USB sticks. Tell them the risks associated with doing particular things, give examples, and explain why you have to take such action. Do not be the “Preventer of Information Systems.” Your users are smart enough to understand everything if it is communicated clearly.
Make use of virtualization technology extensively. I suggest you to check all the incoming connections on a virtual “controlling” computer and then let in the network, but only if the scan results provide no question marks. An example of this can be to scan incoming e-mails in a virtual server and then letting it go to the Intranet. This way, you will keep your network safe to some degree. And if something goes wrong with a false negative, you can shutdown or isolate the virtual mail server without taking down all the network connections/file shares etc. and work on the problem. It will also be a good idea to block all the e-mails containing executable (exe) files and scan the contents of the attached zip files.
Read the Securing and Optimizing Linux. The book is available for download free and will get you started in a very short time. Do not forget to check your bookstore for the newer edition or other books on the subject. Try them on your virtual test server and when it is ok, pass them to the production server.
Training
There are many articles and webcasts on the Internet stressing the importance of training, in addition to the books already published. When you are training your users, be sure to communicate to them in daily language, not in your everyday jargon. Instead of saying, “We have migrated to Evolution from Kontact because it supports the MAPI protocol through a proprietary plug-in,” try, “We have decided to use Evolution instead of Kontact, because we will have an Exchange server coming in a few days and Kontact has problems in taking advantage of all the Exchange features. For example, Linux users will be able to see shared calendars of Windows users.” And then your users will understand why they will have to learn a new program. Tell them that - in the Kontact/Evolution example - nothing will change except some interface cosmetics, some small layouts, and that the basics of e-mail management programs are the same. Go with the simple examples of sending/receiving e-mails, making calendar entries, assigning tasks between users. Make them comfortable. No technology professional will be sure that almost all of the users will be willing to use PINE, no matter how much it rocks.
One of the biggest mistakes that you can make is assuming that you, yourself, do not need training. If you are still in the nineties thinking that the only thing that matters are viruses and not the cross-site-scripting attacks, better think again. The origin of the threats are the same: Internet and removable media. But in this age, almost no malware-writing creep is satisfied by corrupting your Word files; they are interested in your personal and financial information. Try to stay a couple of steps ahead of the current events and try to predict the future by training and updating yourself.
Of course this brings being proactive about your servers and your network. Scan your network for vulnerabilities. Read about the past attacks and try to close all the holes to avoid having a script kiddie take down your server. Read about the recent attacks and responses. If you are unsure about what to do, limit your network activity. It’s better to be safe than sorry.
Conclusion
We tried to mention some basics to consider with and after building a server. As we have mentioned before, building and maintaining a server and a network environment is not making the cabling and installing and configuring some applications. Although what we mentioned seems obvious, you can not imagine in how many companies these simple rules are ignored, leaving their systems vulnerable. An example? I am working in one of the business centers in Istanbul and my notebook computer receives wireless signals from unprotected company wireless networks, which I can access by typing 192.168.1.1 and entering admin/admin as username/password pair. Once inside, a quick scan gives me all the information.
This post is part of the series: Building a Linux Server
In this series we look at building and configuring a Linux server from scratch. We will look at configuration in detail and we will determine ways to keep our server as secure as possible.
