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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space