Linux Security – Server Hardening
Jumat, 15 Februari 2013
0
komentar
http://pinehead.tv/linux/linux-security-server-hardening
One of the most common areas in Linux that gets overlooked during a production deployment is overall security. Specifically, the hardening of the operating system against common exploits (and hardening can encompass both policy and configuration for both internal and external use). We are going to talk about some common ways to protect our server from both the inexperienced as well as the malicious users it will be exposed to.
There was a time when it was necessary (financially) to run multiple network services on a single system (maximizing infrastructure investment). However, with the vast improvements in virtualization, you can now segregate your services better to limit potential compromises per system (i.e. web services can be separated from caching, proxies or databases).
Enforce a password policy that absolutely requires a password of at least eight characters, one capital letter, one number and one special character. Encourage passwords that are even longer and more complex by setting those passwords to expire less often. You can set the policy in the following location with the following fields:
or
Both commands will let you know what your server is listening for so you can enable it in your firewall(s) or remove it from the the system.
The last thing you want is to be caught flat footed by the boss when he comes by–you really do not want to be in this position and not know what happened.
Use logwatch or logcheck to help you audit those logs or monitor suspicious log activity. You can configure them to send you local system mail or, with exim/sendmail/another mail service, send alerts to one or more email addresses.
One of the most common areas in Linux that gets overlooked during a production deployment is overall security. Specifically, the hardening of the operating system against common exploits (and hardening can encompass both policy and configuration for both internal and external use). We are going to talk about some common ways to protect our server from both the inexperienced as well as the malicious users it will be exposed to.
Protect Yourself From Prying Eyes
First and foremost, avoid using all services that allow unencrypted or unobfuscated traffic whenever possible (with HTTP being the notable exception for obvious reasons). This means not installing or configuring (and for goodness sake, not opening the associated ports on the local or enterprise firewall) for the following:- telnet
- ftp
- rlogin
- rsh/rcp
- vnc
- tftp
Put Your System on a Diet
Just because your repository or installation media comes with 4,123,432 packages does NOT mean you have to install them all. In addition, there are many services that get installed and started that you do not need in a server environment (bluetooth anyone?). The more packages you have, the more services you have running, the more likely something can be exploited.There was a time when it was necessary (financially) to run multiple network services on a single system (maximizing infrastructure investment). However, with the vast improvements in virtualization, you can now segregate your services better to limit potential compromises per system (i.e. web services can be separated from caching, proxies or databases).
Security by Abstraction
One of the strongest methods of protecting your systems is through abstraction. This consists of maintaining an intelligent firewall zoning configuration (web servers are in an “untrusted” zone that can only communicate one zone down to the application services in a “trusted” zone and finally they communicate directly to the “data” zone where your databases are – each one is restricted to the one directly above and/or below). This type of configuration makes it less likely that a compromised system can be used to attack resources in other zones since another firewall interface would have to be defeated.Account Security
Although this should be an obvious place to harden your server, it is an unpopular one. It is sometimes hard to strike a balance between being secure and making access so difficult no one wants to use the system. Your password policy in general should be strong enough that it is barrier to general access, as inconvenient as that may sometimes be.Enforce a password policy that absolutely requires a password of at least eight characters, one capital letter, one number and one special character. Encourage passwords that are even longer and more complex by setting those passwords to expire less often. You can set the policy in the following location with the following fields:
- /etc/shadow
- Format: [username]:[password]:[lastpasswdchanged]:[minimum days]:[maximum days]:[warn]:[inactive]:[expire]
- Note: you can use the chage command rather than editing the shadow file directly
What Did You Say Again?
Just when you think that you have scaled back on your packages and services, stop and listen, or rather find out what your server is listening for. Many times you will find you missed an unintended application or service that is listening on a port it does not need to. You can get a list of everything your server is listening for by port as follows:netstat -tlupn
or
nmap -sT -O localhost
Both commands will let you know what your server is listening for so you can enable it in your firewall(s) or remove it from the the system.
How Did That Happen?
Make sure your system is logging appropriately. Most of the default logs will appear in /var/log and will either have an appropriately named file or subdirectory containing the pertinent logs (/var/log/http for apache for example).The last thing you want is to be caught flat footed by the boss when he comes by–you really do not want to be in this position and not know what happened.
Use logwatch or logcheck to help you audit those logs or monitor suspicious log activity. You can configure them to send you local system mail or, with exim/sendmail/another mail service, send alerts to one or more email addresses.
Final Thoughts
This is by no means intended to be a comprehensive list of hardening procedures or tools. This is meant as a beginning, to get you thinking about what you need to do to secure your server and infrastructure. There are a number of other topics we could discuss (system accounting, intrusion detection systems, no owner or world readable files and directories, kerberos, centralized authentication, etc). If the topic is popular enough, we can go into some of those other areas or do a deeper dive in any of the categories above, including specific tutorials. Leave a comment below and let me know!TERIMA KASIH ATAS KUNJUNGAN SAUDARA
Judul: Linux Security – Server Hardening
Ditulis oleh Unknown
Rating Blog 5 dari 5
Semoga artikel ini bermanfaat bagi saudara. Jika ingin mengutip, baik itu sebagian atau keseluruhan dari isi artikel ini harap menyertakan link dofollow ke http://androidjapane.blogspot.com/2013/02/linux-security-server-hardening.html. Terima kasih sudah singgah membaca artikel ini.Ditulis oleh Unknown
Rating Blog 5 dari 5
0 komentar:
Posting Komentar