Best Practices

Managing DNS locally with /etc/hosts

Before the advent of a distributed domain name system; networked computers used local files to map hostnames to IP addresses. On Unix systems this file was named /etc/hosts or “the hosts file”. In those days, networks were small and managing a file with a handful of hosts was easy. However as the networks grew so did the methods of mapping hostnames and IP addresses. In modern days with the internet totaling at somewhere around 246 million domain names (as of 2012) the hosts file has been replaced with a more scalable distributed DNS service.

Understanding a little more about /etc/profile and /etc/bashrc

Recently I was working on an issue where an application was not retaining the umask setting set in the root users profile or /etc/profile. After looking into the issue a bit it seemed that the application in question only applied the umask setting that was set in /etc/bashrc and would not even accept the values being the applications own start scripts. After doing a bit of researched I learned a little bit more about what exactly these files do, the differences between them and when they are executed.

Adding and Modifying Users and Groups in Linux

Adding and Modifying Users and Groups is a core systems administration task. The act of adding a user and group is fairly easy however there are some tricks that help make the long-term management of users easier. Tips for easier management Keep user attributes consistent amongst all systems A common mistake sysadmins make when building a new environment is they will allow uid’s, gid’s, home directories and other user attributes to be mis-matched from system to system.

Mitigating DoS Attacks with a null (or Blackhole) Route on Linux

In a world where the Anonymous group is petitioning the US Government to make DDoS attacks a legal means of protest; For internet facing systems the threat of Denial of Service attacks are very real. The cold harsh reality of DoS attacks are that there is no way to stop them. While there are services out there that are designed to take the brunt of the attack for you these costs a significant amount of money (update: CloudFlare seems pretty decent).

Sudoedit: Securely allow users to edit files

Allowing unprivileged users to edit files that are normally beyond their rights is a task that is easy to perform however it requires a great deal of forethought to implement without opening security holes. You can give users the ability to edit privileged files by using User/Group Permissions, ACL’s, or even sudo; but no matter which way you choose there are some things you must consider. For an example lets take a look at 2 files /etc/services and /etc/cron.

Why you should avoid running applications as root

I’m going to start this post by saying what I’m really thinking. 90% of the time if an application is running as the root user on a Unix/Linux machine; it is because the sysadmin who setup or designed the environment was being lazy. Now before getting offended, being a lazy sysadmin is a good thing. The fact is that most systems administrators are lazy in some way, and that is the reason why most systems administration tasks end up being scripted.

When it's Ok and Not Ok to use rc.local

On System V based OS’s the /etc/rc.local file is executed by the init process at the end of the systems boot process. The fact that the rc.local file is executed during the boot process makes it an easy target for misuse by lazy Sysadmins. Since I started my Unix experience on FreeBSD which relies primarily on the /etc/rc.* configuration files, I’ve seen and shamefully contributed to my fair share of misuse in the rc.

mount: Disabling execution of scripts

One of the common ways of securing your system is by making the /tmp filesystem unable to run executables. This prevents users from executing scripts in /tmp which is generally writable by everyone. You can restrict this with the mount option noexec. Here is an example: [[email protected] playground]# mount | grep play /dev/mapper/vgfirst-lv_test1 on /var/tmp/playground type ext3 (rw) [[email protected] playground]# ./helloworld.sh Hello World [[email protected] playground]# mount -o remount,noexec /dev/mapper/vgfirst-lv_test1 /var/tmp/playground [[email protected] playground]# mount | grep play /dev/mapper/vgfirst-lv_test1 on /var/tmp/playground type ext3 (rw,noexec) [[email protected] playground]# .

Truncating a large log file

This is actually one of my favorite questions to ask Jr. Systems Administrators. I believe the way they answer this question really helps me gauge where they are at in their Administration skills. How do you clear a large log file that an application is actively writing to? Some will answer honestly and say “by removing the file” and others will pretend like they careful of everything and say “move the file out of the way and create a new one”.

sudoers: Syntax Checking

As you may recall I posted recently about the safest way to deploy a crontab. One of my points was using certain commands you can perform syntax checking on the file. Well crontab isn’t the only command that performs syntax checking. When you edit your sudoers file it is best practice that you use visudo rather than editing the /etc/sudoers file directly. Visudo will perform syntax checking when you save the file.