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).
For todays article I wanted to put together a quick little cheat sheet for some GNU find command examples.
Some of these commands will be basic some will be more advanced, but they all will be useful. As a caveat some commands don't work in all Unix environments and this is especially true with older releases. If you find yourself in one of those situations there is a way to make the find command work you will just need to use different methods like the -exec flag.
Zombies don't just appear in scary movies anymore, sometimes they also appear on your Linux systems; but don't fret they are mostly harmless.
What is a Zombie Process? Before we get started I wanted to first cover what exactly a Zombie process is.
Linux and Unix both have the ability for a process to create a sub process otherwise known as a “Child Process”. Once a process creates a new sub process the first process then becomes a “Parent Process” as it has spawned a child process during its execution.
Access Control Lists aka ACL's are one of those obscure Linux tools that isn't used every day; and if you find yourself using ACL's every day than you probably have a very complicated Linux environment.
A few years ago I had an engineer tell me “Any thing you want to solve with ACL's can be solved with standard unix permissions” and while he may have just been justifying why he didn't know ACL's very well.
Stat is a command that I never knew about until somewhat recently but afterwards have had more and more reasons to use it. When run against a file stat will show detailed information about the file, this information can be extremely useful and I want to highlight some of the information I've found useful from stat.
$ stat rsync.out File: `rsync.out' Size: 696506 Blocks: 1368 IO Block: 4096 regular file Device: fc00h/64512d Inode: 13862 <strong>Links: 1</strong> Access: (0644/-rw-r--r--) Uid: ( 1000/madflojo) Gid: ( 1000/madflojo) Access: 2012-05-21 19:28:00.
One of the primary tricks in my sysadmin bag-o-tricks is Input/Output Redirection; I have found that while many people use Shell I/O Redirection throughout their day not everyone fully understands why and how it works.
The Input and Output In the Unix environment there is always 3 streams open stdin, stdout, & stderr; these special streams are used for interacting with the user input and program output within the Unix/Linux shell environment.
While it is getting more common for companies to allow their IT staff to choose their own OS not every company allows this. In fact most companies require their IT staff to use Windows, as Windows has historically been the dominate OS for the business world. While I personally believe it is easier to administer Linux/Unix servers using a Linux desktop this doesn't mean that I get to be the exception to the rule; sometimes I have had to use a Windows desktop.
Today I want to cover one of the best troubleshooting tools in any sysadmins arsenal; strace. Strace is a command that will trace the system calls and signals from a specified command. What does that mean in layman's terms? Strace will output all of the inner workings of a process you run it against.
If a process opens a file or binds a port, strace will print that action; it is a great utility for troubleshooting when a process is not behaving as expected and you can't find any reason in the commands output or log 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.
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.