SATAN: Analyzing Your Network
The creators of SATAN (System Administrator's Tool for Analyzing Networks) feel that the reason most systems are vulnerable to attack is that most System Administrators don't think like system crackers. Actually, thinking this way may require you to look at simple, seemingly harmless network services in a new light.
To the system cracker, basic network services are a doorway into a computer system. So, before you go into the office one morning and see a bunch of unusual utmp entries, it is beneficial to check just how accessible those doorways are. A great starting point for checking the doors is to run a SATAN scan on your network.
SATAN can be run on Linux with a few modifications. Requirements for running SATAN are:
A machine that can handle it—which means a box with a relatively fast processor (e.g., Alpha, 486) and at least 32MB of RAM
A recent distribution of the SATAN source code (satan-1.1.1)
Perl 5 or greater
A set of BSD-4.4 compatible include files, available from ftp://ftp.wooddimensions.com/webserv/security/linux/
A patch to fix the mistaken assumptions about how select() works in tcp_scan.c (tcp_scan.c.diff)
A WWW browser (A graphical browser like Netscape or Mosaic is preferable, but you can also use a text browser like Lynx.)
A C compiler like gcc
When you have all of these elements, you can begin to build SATAN. First you want to untar the archive. Just issue the command:
zcat satan-1.1.1.tar.Z | tar xvf -
This command creates a subdirectory called satan-1.1.1. Next, apply the patch to tcp_scan.c. I tend to use Emacs for patching, as it makes everything a little more visual. Load the patch into one buffer, tcp_scan.c into another, and choose Patch. Of course, using the patch command works fine too. Now, untar the BSD-4.4 compatible include files. The easiest way to do this is to gunzip the archive and move it into the root of the satan-1.1.1 directory, and then type:
tar xvf BSD-4.4.includes.tarThe archive will expand into the include/netinet/ directory.
Having done this, you are ready to compile SATAN. The program comes with a script, called reconfig, which will configure it on your system. Any Linux user who has used SATAN before knows that bash has trouble with the syntax of this script. The easiest way around this is to type:
at the command prompt, rather than:
./reconfigThe reconfig script will detect your web browser and Perl and compile the SATAN binaries. If it detects the wrong web browser, edit the script config/paths.pl and change the line:
$MOSAIC="program name"You are now ready to run SATAN. Type ./satan at the command prompt, and SATAN will fire up your web browser.
If Netscape is your browser of choice, make sure you have a mime type defined for application/x-perl, and no suffix is defined for this type. Defining the suffix as .pl will result in errors every time you try to execute a script.
Even if all of the above steps sound like a major pain, you should still get the sources and build SATAN yourself. I would strongly urge you not to request, post or use precompiled binaries of SATAN. SATAN must be run as root, and a bad or malicious build can do volumes of damage. There have already been several reports of Trojans found in builds for Linux. Building SATAN for Linux might take a few extra steps, but it is definitely worth the effort.
SATAN will dutifully scan your network and report back all the potential weaknesses that it finds—that is its job. It will even tell you how those weaknesses might be exploitable. It will not fix any problems or keep unwanted guests out—that is your job. No program can be a substitute for an astute Security Administrator.
To run a tight ship you must keep the crew in line, which means educating your users on the importance of a good password. (It's up to you whether you send out security memos, post in the MOTD or actually periodically attempt to crack /etc/passwd and lock out accounts you were able to crack.) Along with password education, educate your users on the dangers of keeping large .rhosts files in their home directories. The more unknown systems trusted, the greater the risk to your own system.
Finally, take a look at your system in the same way an educated cracker might. Subscribe to 2600 and Phrack, if your hacking skills are not up to snuff. Take a look at the network services you are running and think of possible ways you could exploit them. Read the latest CERT (http://www.cert.org/). advisories for all systems (as many common programs come from the same roots, they sometimes share the same weaknesses) and, using this information, periodically try to break into your own system. If you are new to system security or if you are unsure how to go about exploiting network services, try all the cookbook approaches used in such texts as The System Administrator's Guide to Cracking (included with the SATAN distribution). There are also a lot of IRC channels and web sites where hacking and cracking are discussed. Visit these sites and listen in or ask questions. Your users are depending on you to have the system up and running—with a little work, you won't disappoint them.
|diff -u: What's New in Kernel Development||May 06, 2015|
|Chrome-Colored Parakeets||May 05, 2015|
|Mumblehard--Let's End Its Five-Year Reign||May 04, 2015|
|An Easy Way to Pay for Journalism, Music and Everything Else We Like||May 04, 2015|
|When Official Debian Support Ends, Who Will Save You?||May 01, 2015|
|May 2015 Issue of Linux Journal: Cool Projects||May 01, 2015|
- diff -u: What's New in Kernel Development
- Mumblehard--Let's End Its Five-Year Reign
- Chrome-Colored Parakeets
- When Official Debian Support Ends, Who Will Save You?
- An Easy Way to Pay for Journalism, Music and Everything Else We Like
- Ubuntu Ditches Upstart
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Picking Out the Nouns
- Return of the Mac