Open Notepad and copy the below code and save as locker.bat. At first time start it will create folder with Locker automatically for u. Don't forget to change your password in the code its shown the place where to type your password.
after creation of Locker folder again click on the locker.bat.it will ask.press Y then Locker folder will be disappeared.again to get it click on locker.bat. and give ur password u will get the folder again.
**********************************************************
cls
@ECHO OFF
title Folder Locker
if EXIST "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" goto UNLOCK
if NOT EXIST Locker goto MDLOCKER
:CONFIRM
echo Are you sure u want to Lock the folder(Y/N)
set/p "cho=>"
if %cho%==Y goto LOCK
if %cho%==y goto LOCK
if %cho%==n goto END
if %cho%==N goto END
echo Invalid choice.
goto CONFIRM
:LOCK
ren Locker "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
attrib +h +s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
echo Folder locked
goto End
:UNLOCK
echo Enter password to Unlock folder
set/p "pass=>"
if NOT %pass%==type your password here goto FAIL
attrib -h -s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
ren "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" Locker
echo Folder Unlocked successfully
goto End
:FAIL
echo Invalid password
goto end
:MDLOCKER
md Locker
echo Locker created successfully
goto End
:End
----------------------------------
Written by Cyvamp
(with a few notes added by Raven)
July 2000
http://blacksun.box.sk
----------------------------------
Warning:
DO NOT use this to damage cisco systems, or gain unauthorized access to systems. This tutorial is just something to
use for educational purposes. Only use this information in a legal way (the hacker wargames for instance), and do
not damage or destroy anything. This is a step-by-step guide on how a series of proven cisco exploits can be used to
gain access. If you get caught breaking into a cisco router, or screw the system up, you can interrupt hundreds of
internet clients, and cost thousands of dollars, so only use this when you are allowed!! Using this the wrong way
will get you into a lot of trouble.
Note: some of this tutorial was written on a Unix system, and the text was not converted to be DOS /
Windows-compatible, so you'll have to view this text from either your Internet browser, or from an advanced editor
such as Microsoft Word.
----------------------------------
Table of Contents:
----------------------------------
Before you start:
- What is an IP address?
- What is an ISP?
- What is a TCP/IP packet?
- How to spoof your IP
- How to use Telnet
- How to use HyperTerminal
- How to use Ping
- How to use TraceRoute
- How to use a proxy server
-------------------------------------
- Section 1: why hack a cisco router?
- Section 2: how to find a cisco router
- Section 3: how to break into a cisco
- Section 4: how to break the password
- Section 5: how to use a cisco router
-----------------------------------
Stuff you'll need to know BEFORE you start:
-----------------------------------
What is an IP address?
IP stands for Internet Protocol, IP addresses are used by other computers to identify computers that connect to
them. This is how you can be banned from IRC, and how they can find your ISP. IP addresses are easily obtained, they
can be retrieved through the following methods:
-you go to a website, your IP is logged
-on IRC, anyone can get your IP
-on ICQ, people can get your IP, even if you have the option set "do not show ip"
they can still get it
-if you are connected to someone, they can type "systat", and see who is connected to them
-if someone sends you an email with IP-logging java, they can also get your IP address
There are many more ways of obtaining IP addresses, including using back-door programs such as Sub7 or NetBus.
------------------------------------
What is an ISP?
ISP stands for Internet Service Provider, they are the ones that give you the internet. You connect to one everytime
you dial-up and make a connection. People can find your ISP simply by running a traceroute on you (traceroute is
later explained). It will look something like this:
tracert 222.222.22.22
Tracing route to [221.223.24.54]
over a maximum of 30 hops.
1 147ms 122ms 132ms your.isp [222.222.22.21]
2 122ms 143ms 123ms isp.firewall [222.222.22.20]
3 156ms 142MS 122ms aol.com [207.22.44.33]
4 * * * Request timed out
5 101ms 102ms 133ms cisco.router [194.33.44.33]
6 233ms 143ms 102ms something.ip [111.11.11.11]
7 222ms 123ms 213ms netcom.com [122.11.21.21]
8 152ms 211ms 212ms blahblah.tts.net [121.21.21.33]
9 122ms 223ms 243ms altavista.34.com [121.22.32.43] <<< target's isp
10 101ms 122ms 132ms 221.223.24.54.altavista.34.com [221.223.24.54]
Trace complete.
-----------------------------------
What is a TCP/IP packet?
TCP/IP stands for Transmission Control Protocol and Internet Protocol, a TCP/IP packet is a block of data which is
compressed, then a header is put on it and it is sent to another computer. This is how ALL internet transfers occur,
by sending packets. The header in a packet contains the IP address of the one who originally sent the packet. You
can re-write a packet and make it seem like it came from anyone!! You can use this to gain access to lots of systems
and you will not get caught. You will need to be running Linux or have a program which will let you do this. This
tutorial does not tell you to use this on a Cisco router, but it does come in handy when hacking any system. If
something goes wrong when you try to hack a system, you can always try this...
------------------------------------
How to spoof your IP:
Find a program like Genius 2 or DC IS, which will let you run IdentD. This will let you change part of your
computer's identity at will! Use this when you get banned from some IRC chat room.... you can get right back in! You
can also use it when you are accessing another system, so it logs the wrong id...
------------------------------------
How to use telnet:
You can open telnet simply by going to your Start Menu, then to Run, and typing in "telnet".
Once you have opened telnet, you may want to change some features. Click on Terminal>Preferences. Here you can
change the buffer size, font, and other things. You can also turn on/off "local echo", if you turn local echo on,
your computer will show you everything you type, and the other computer you are connected to will show you aswell.
So you may get something like this;
You type "hello", and you get
hhelelollo
This is because the information has bounced back and got scrambled with what you typed. The only reason I would use
this is if the machine does NOT return what you are typing.
By default, telnet will connect to a system on the telnet port, which is port 23. Now you will not always want to
connect to port 23, so when you go to connect, you can change the port to maybe 25, which is the port for mail
servers. Or maybe port 21, for FTP. There are thousands of ports, so make sure you pick the right one!
----------------------------------
How to use HyperTerminal:
HyperTerminal allows you to open a "server" on any port of your computer to listen for incoming information from
specified computers. To use this, go to
Start>Programs>Accessories>Communications>HyperTerminal. First you will need to select the connection, pick "TCP/IP
Winsock", and then put in the computer to communicate with, and the port #. You can tell it to listen for input by
going to Call>Wait for Call. Now the other computer can connect to you on that port, and you can chat and transfer
files.
----------------------------------
How to use Ping:
Ping is easy, just open the MS-DOS prompt, and type "ping ip.address", by default it will ping 3 times, but you can
type
"ping ip.address -t"
Which will make it ping forever. To change the ping size do this:
"ping -l (size) ip.address"
What ping does is send a packet of data to a computer, then sees how long it takes to be returned, which determines
the computer's connection speed, and the time that it takes for a packet to go back and forth (this is called the
"trip time"). Ping can also be used to slow down or even crash a system if the system is overloaded by ping floods.
Windows 98 crashes after one minute of pingflooding (it's connections buffer is overflown - too many connections are
registered, and so Windows decides to take a little vacation).
A ping flood attack takes a lot of bandwidth from you, and you must have more bandwidth than your target (unless
the target is a Windows 98 box and you have an average modem, that way you'll knock it down after approximately a
single minute of ping flooding). Ping flooding isn't effective against stronger targets, unless you have quite a few
evil lines to yourself, and you have control over a few bandwidth-saavy hosts that can ping flood your target as
well.
Note: DOS's -t option doesn't do a ping flood, it just pings the target continously, with intervals from one ping to
another. In every Unix or Linux distribution, you can use ping -f to do a real pingflood. Actually ping -f is
required if you want your distribution to be POSIX-compliant (POSIX - Portable Operating System Interface based on
uniX), otherwise it's not a real Unix/Linux distribution, so if you have an OS that calls itself either Unix or
Linux, it has the -f switch.
----------------------------------
How to use TraceRoute:
To trace your connection (and see all the computer's between you and a target), just open the MS-DOS prompt, and
type "tracert ip.address" and you will see a list of computers, which are between you and the target computer.
You can use this to determine if there are firewalls blocking anything. And will also allow you to determine
someone's ISP (internet service provider).
To determine the ISP, simple look at the IP address before the last one, this should be one of the ISP's routers.
Basically, this is how traceroute works - a TCP/IP packet has a value in it's header (it's in the IP header. If you
don't know what this means, then ignore it and continue reading, it's not that crucial) called TTL, which stands
for Time To Live. Whenever a packet hops (travels through a router) it's TTL value is decreased by one. This is just
a countermeasure against the possibility that something would go wrong and a packet would ricochet all around the
net, thus wasting bandwidth.
So when a packet's TTL reaches zero, it dies and an ICMP error is sent back to the sender.
Now, traceroute first sends a packet with a TTL value of 1. The packet quickly returns, and by looking at the
sender's address in the ICMP error's header, the traceroute knows where the packet has been in it's first hop. Then
it sends a packet with a TTL value of 2, and it returns after the second hop, revealing it's identity. This goes on
until the packet reaches it's destination.
Now isn't that fun? :-)
----------------------------------
How to use a proxy server:
Do a search on the web for a proxy server which runs on the port of your choice. Once you find one, connect to it
with either telnet or hyperterminal and then connect to another computer through the proxy server. This way the
computer at the other end will not know your IP address.
----------------------------------
Section 1: why hack a cisco router?
You probably are wondering.. why hack into a cisco router?
The reason being is that they are useful when it comes to breaking into other systems...
Cisco routers are very fast, some with 18 T1 connections on one system, and they are very flexible and can be used
in DoS attacks or to hack other systems since most of them run telnet.
They also have thousands of packets going through them at any one time, which can be captured and decoded... A lot
of cisco routers are also trusted systems, and will let you have a certain amount of access to other computers on
it's network.
----------------------------------
Section 2: finding a cisco router
Finding a cisco router is a fairly easy task, almost every ISP will route through at least one cisco router. The
easiest way to find a cisco router is to run a traceroute from dos (type "tracert" and then the IP address of
anyone's computer), you can trace pretty much anyone because the trace will show all of the computer systems between
your computer and their computer. One of these systems will probably have the name "cisco" in it's name. If you find
one like this, copy down it's IP address.
Now you have the location of a cisco router, but it may have a firewall protecting it, so you should see if it's
being blocked by pinging it a couple times, if you get the ping returned to you, it might not be blocked. Another
way is to try to access some of the cisco router's ports, you can do this simply by using telnet, and opening a
connection to the router on port 23.. If it asks for a password, but no username, you are at the router, but if it
wants a username aswell, you are probably at a firewall.
Try to find a router without a firewall, since this tutorial is on the routers and not how to get past the
firewalls. Once you're sure you have found a good system, you should find a proxy server which will allow you to use
port 23, this way your IP will not be logged by the router.
---------------------------------
Section 3: how to break into a cisco router
Cisco routers running v4.1 software (which currently is most of them) will be easily disabled. You simply connect to
the router on port 23 through your proxy server, and enter a HUGE password string, something like;
10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk10293847465qpwoeirutyalskdjfhgzmxncbv019dsk
Now wait, the cisco system might reboot, in which case you can't hack it because it is offline.. But it will
probably freeze up for a period of 2-10 minutes, which you must use to get in.
If neither happens, then it is not running the vulnerable software, in which case you can try several DoS attacks,
like a huge ping. Go to dos and type "ping -l 56550 cisco.router.ip -t", this will do the same trick for you.
While it is frozen, open up another connection to it from some other proxy, and put the password as "admin", the
reason for this is because by default, this is the router's password, and while it is temporarily disabled, it will
revert to it's default state.
Now that you have logged in, you must acquire the password file! The systems run different software, but most will
have a prompt like "htl-textil" or something, now type "?" for a list of commands, you will see a huge list of
commands, somewhere in there you will find a transfer command, use that to get the password file of admin (which is
the current user) and send it to your own IP address on port 23. But before you do this, set up HyperTerminal to
wait for a call from the cisco router. Now once you send the file, HyperTerminal will ask you if you want to accept
the file that this machine is sending you, say yes and save it to disk. Logout.
You are now past the hardest part, give yourself a pat on the back and get ready to break that password!
------------------------------
Section 4: breaking the password
Now that you have acquired the password file, you have to break it so you can access the router again. To do this,
you can run a program like John the Ripper or something on the password file, and you may break it.
This is the easiest way, and the way i would recommend. Another way would be to try and decrypt it. For this you
will need some decryption software, a lot a patience, and some of the decryption sequences.
Here is a sequence for decrypting a cisco password, you have to compile this in linux:
#include
#include
char xlat[] = {
0x64, 0x73, 0x66, 0x64, 0x3b, 0x6b, 0x66, 0x6f,
0x41, 0x2c, 0x2e, 0x69, 0x79, 0x65, 0x77, 0x72,
0x6b, 0x6c, 0x64, 0x4a, 0x4b, 0x44
};
char pw_str1[] = "password 7 ";
char pw_str2[] = "enable-password 7 ";
char *pname;
cdecrypt(enc_pw, dec_pw)
char *enc_pw;
char *dec_pw;
{
unsigned int seed, i, val = 0;
if(strlen(enc_pw) & 1)
return(-1);
seed = (enc_pw[0] - '0') * 10 + enc_pw[1] - '0';
if (seed > 15 || !isdigit(enc_pw[0]) || !isdigit(enc_pw[1]))
return(-1);
for (i = 2 ; i <= strlen(enc_pw); i++) {
if(i !=2 && !(i & 1)) {
dec_pw[i / 2 - 2] = val ^ xlat[seed++];
val = 0;
}
val *= 16;
if(isdigit(enc_pw[i] = toupper(enc_pw[i]))) {
val += enc_pw[i] - '0';
continue;
}
if(enc_pw[i] >= 'A' && enc_pw[i] <= 'F') {
val += enc_pw[i] - 'A' + 10;
continue;
}
if(strlen(enc_pw) != i)
return(-1);
}
dec_pw[++i / 2] = 0;
return(0);
}
usage()
{
fprintf(stdout, "Usage: %s -p
fprintf(stdout, " %s
As the size of hard drives increase, more people are using partitions to separate and store groups of files.
XP uses the C:\Program Files directory as the default base directory into which new programs are installed if your . However, you can change the default installation drive and/ or directory by using a Registry hack.
Run the Registry Editor (regedit) and go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
Look for the value named ProgramFilesDir. by default,this value will be C:\Program Files. Edit the value to any valid drive or folder and XP will use that new location as the default installation directory for new programs.
Here is some common buzzwords thats you will encounter while surfing Internet. You should care to look at them to know what they really stands for.
0-Day - Release of the same day;
0-Sec - Instant release;
AC3 - Audio Coding 3, audio codec, usually 5.1 audio channels;
AFFiLS - Websites affiliated to the groups, where they put the releases;
ANiME - Release of a anime movie;
ASF - Advanced Streaming Format, audio/video compression codec based in MPEG-4;
CE - Classical Edition, of a original movie;
CLSC - Classical release;
COLOUR EDiTiON - Release of a movie with edit in color level;
COURiER - Dumper/racer of a groups, has the job of distribute the releases through websites;
CUT/CUTED - Partial release of a movie;
DC - Director's Cute, release of a movie with selections of the director's;
DSYNCH - Not synchronized;
DiRFiX - Fix of a release name;
DiVX - Division X, compression video codec;
DOWNSAMPLED - Manipulation of the video/audio format because of low bitrates;
DUBBED - Movie with double language (original one or other);
DUMP - Release transfer;
DUMPER - Who makes the dumps;
DUPE - Doubled release;
DVDR - Release format fot a complete DVD or Downsampled;
DVDRiP - Rip which source is the original DVD;
DVDSCR/DVDSCREENER - Rip which source is a pre-release DVD.
FiX - Correction for something;
FS - Full screen, resolution 4:3;
FTP - File Transfer Protocol, way of transfer files;
FXP - File eXchange Protocol, way of share data through FTP;
GRP.RQT - Group Request, request of a new release because some other is nuked;
iNT, iNTERNAL - Internal release group, doesn't count for release races;
LDRiP - Rip which source is a laser disc;
LiMiTED - Release of a limited movie (in some theaters);
NTSC - National Television System Committe, video stream system of South America and east Asia;
NUKED - Bad release, release with problems;
PAL - Phase Altering Line, stream video system of Europe;
PROPER - Good release, substitutes a nuked release;
PROMO - Promotional;
REPACK - Repacked released;
RETAiL - Rip which source is a commercial DVD;
SRT - Sequense Real Time, text subtitles format;
SUB - Text subtitles format;
SYNCFiX - Synchronization fix;
TS - Theather screener, movie recorded in theathers;
VCD - Video Compact Disc, distibution of MPEG content;
VCDRiP - Rip which source is a VCD;
VHSRiP - Rip which source is a VHS
WS - Wide Screen, resolution 16:9
XViD - Video compression codec based in MPEG-4
XXX - Porn release;
Access Stored User Names and Passwords with rundll
The Stored User Names and Passwords applet lets you assign user names and passwords to use when needing to authenticate yourself to services in domains other than the one you are currently logged into. The normal way of running this applet can be difficult to find quickly, so here is a way to launch it using a desktop shortcut using the rundll32.exe
program:
-------------------------------------------------
Click on START - RUN and type the following (follwed by ENTER):
rundll32.exe keymgr.dll,KRShowKeyMgr
Step 1 - Modify Explorer.exe File
In order to make the changes, the file explorer.exe located at C:\Windows needs to be edited. Since explorer.exe is a binary file it requires a special editor. For purposes of this article I have used Resource Hacker. Resource HackerTM is a freeware utility to view, modify, rename, add, delete and extract resources in 32bit Windows executables and resource files (*.res). It incorporates an internal resource script compiler and decompiler and works on Microsoft Windows 95/98/ME, Windows NT, Windows 2000 and Windows XP operating systems.
get this from h**p://delphi.icm.edu.pl/ftp/tools/ResHack.zip
The first step is to make a backup copy of the file explorer.exe located at C:\Windows\explorer. Place it in a folder somewhere on your hard drive where it will be safe. Start Resource Hacker and open explorer.exe located at C:\Windows\explorer.exe.
The category we are going to be using is "String Table". Expand it by clicking the plus sign then navigate down to and expand string 37 followed by highlighting 1033. If you are using the Classic Layout rather than the XP Layout, use number 38. The right hand pane will display the stringtable. We’re going to modify item 578, currently showing the word “start” just as it displays on the current Start button.
There is no magic here. Just double click on the word “start” so that it’s highlighted, making sure the quotation marks are not part of the highlight. They need to remain in place, surrounding the new text that you’ll type. Go ahead and type your new entry. In my case I used Click Me!
You’ll notice that after the new text string has been entered the Compile Script button that was grayed out is now active. I won’t get into what’s involved in compiling a script, but suffice it to say it’s going to make this exercise worthwhile. Click Compile Script and then save the altered file using the Save As command on the File Menu. Do not use the Save command – Make sure to use the Save As command and choose a name for the file. Save the newly named file to C:\Windows.
Step 2 – Modify the Registry
!!!make a backup of your registry before making changes!!!
Now that the modified explorer.exe has been created it’s necessary to modify the registry so the file will be recognized when the user logs on to the system. If you don’t know how to access the registry I’m not sure this article is for you, but just in case it’s a temporary memory lapse, go to Start (soon to be something else) Run and type regedit in the Open field. Navigate to:
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon
In the right pane, double click the "Shell" entry to open the Edit String dialog box. In Value data: line, enter the name that was used to save the modified explorer.exe file. Click OK.
Close Registry Editor and either log off the system and log back in, or reboot the entire system if that’s your preference. If all went as planned you should see your new Start button with the revised text.[/b]
BASIC C Socket Programming In Unix For Newbies
<=================================================>
Written by: BracaMan
E-mail : BracaMan@clix.pt
ICQ : 41476410
URL : http://www.BracaMan.net
For more tutorials: http://code.box.sk
http://blacksun.box.sk
For comments, errors or just to say hello:
CONTENTS
=======================================
1. Introduction
2. Different types of Internet Sockets
3. Structures
4. Conversions
5. IP Addresses
6. Important Functions
6.1. socket()
6.2. bind()
6.3. connect()
6.4. listen()
6.5. accept()
6.6. send()
6.7. recv()
6.8. sendto()
6.9. recvfrom()
6.10. close()
6.11. shutdown()
6.12. gethostname()
7. Some words about DNS
8. A Stream Server Example
9. A Stream Client Example
10. Last Words
11. Copyright
1. INTRODUCTION
=======================================
Are you trying to learn c socket programming? Or do you think that it's hard stuff?
Well, then you must read this basic tutorial to get basic ideas and concepts and to start
to work with sockets. Don't expect to be a "socket programming master" after reading this
tutorial. You'll only be that if you practice and read a lot.
2. DIFFERENT TYPES OF INTERNET SOCKETS
=======================================
In the first place I must explain what a socket is. In a very simple way, a socket is a way
to talk to other computer. To be more precise, it's a way to talk to other computers using
standard Unix file descriptors. In Unix, every I/O actions are done by writing or reading
to a file descriptor. A file descriptor is just an integer associated with an open file and it
can be a network connection, a terminal, or something else.
About the different types of internet sockets, there are many types but I'll just describe two
of them - Stream Sockets (SOCK_STREAM) and Datagram Sockets (SOCK_DGRAM).
"And what are the differences between this two types?" you may ask. Here's the answer:
Stream Sockets - they're error free; if you send through the stream socket three
items "A,B,C", they will arrive in the same order - "A,B,C" ;
they use TCP ("Transmission Control Protocol") - this protocol
assures the items' order.
Datagram Sockets - they use UDP ("User Datagram Protocol"); they're connectionless
because you don't need to have an open connection as in Stream
Sockets - you build a packet with the destination information and
send it out.
A lot more could be explained here about this two kind of sockets, but I think this is enough
to get the basic concept of socket. Understanding what a socket is and this two types of
internet sockets is a good start, but you need to learn how to "work" with them. You'll learn
it in the next sections.
3. STRUCTURES
=======================================
The purpose of this section is not to teach you structures but to tell you how are they
used in C socket programming. If you don't know what a structure is, my advice is to read
a C Tutorial and learn it. For the moment, let's just say that a structure is a data type
that is an aggregate, that is, it contains other data types, which are grouped together into
a single user-defined type.
Structures are used in socket programming to hold information about the address.
The first structure is struct sockaddr that holds socket information.
struct sockaddr{
unsigned short sa_family; /* address family */
char sa_data[14]; /* 14 bytes of protocol address */
};
But, there's another structure (struct sockaddr_in) that help you to reference to the socket's
elements.
struct sockaddr_in {
short int sin_family; /* Address family */
unsigned short int sin_port; /* Port */
struct in_addr sin_addr; /* Internet Address */
unsigned char sin_zero[8]; /* Same size as struct sockaddr */
};
Note: sin_zero is set to all zeros with memset() or bzero() (See examples bellow).
The next structure is not very used but it is defined as an union.
As you can see in both examples bellow (Stream Client and Server Client) , when I declare for
example "client" to be of type sockaddr_in then I do client.sin_addr = (...)
Here's the structure anyway:
struct in_addr {
unsigned long s_addr;
};
Finally, I think it's better talk about struct hostent. In the Stream Client Example, you can
see that I use this structure. This structure is used to get remote host information.
Here it is:
struct hostent
{
char *h_name; /* Official name of host. */
char **h_aliases; /* Alias list. */
int h_addrtype; /* Host address type. */
int h_length; /* Length of address. */
char **h_addr_list; /* List of addresses from name server. */
#define h_addr h_addr_list[0] /* Address, for backward compatibility. */
};
This structure is defined in header file netdb.h.
In the beginning, this structures will confuse you a lot, but after you start to write some
lines, and after seeing the examples, it will be easier for you understanding them. To see
how you can use them check the examples (section 8 and 9).
4. CONVERSIONS
=======================================
There are two types of byte ordering: most significant byte and least significant byte.
This former is called "Network Byte Order" and some machines store their numbers internally
in Network Byte Order.
There are two types you can convert: short and long.
Imagine you want to convert a long from Host Byte Order to Network Byte Order. What would you
do? There's a function called htonl() that would convert it =) The following functions are
used to convert :
htons() -> "Host to Network Short"
htonl() -> "Host to Network Long"
ntohs() -> "Network to Host Short"
ntohl() -> "Network to Host Long"
You must be thinking why do you need this. Well, when you finish reading this document, it will
all seems easier =) All you need is to read and a lot of practice =)
An important thing, is that sin_addr and sin_port (from struct sockaddr_in) must be in Network
Byte Order (you'll see in the examples the functions described here to convert and you'll start
to understand it).
5. IP ADRESSES
=======================================
In C, there are some functions that will help you manipulating IP addresses. We'll talk about
inet_addr() and inet_ntoa() functions.
inet_addr() converts an IP address into an unsigned long. An example:
(...)
dest.sin_addr.s_addr = inet_addr("195.65.36.12");
(...)
/*Remember that this is if you've a struct dest of type sockaddr_in*/
inet_ntoa() converts string IP addresses to long. An example:
(...)
char *IP;
ip=inet_ntoa(dest.sin_addr);
printf("Address is: %s\n",ip);
(...)
Remember that inet_addr() returns the address in Network Byte Order - so you don't need to
call htonl().
6. IMPORTANT FUNCTIONS
=======================================
In this section I'll put the function' syntax, the header files you must include to call it,
and little comments. Besides the functions mentioned in this document, there are more, but
I decided to put only these ones here. Maybe I'll put them in a future version of this
document =) To see examples of these functions, you can check the stream client and stream
server source code (Sections 8 and 9)
6.1. socket()
=============
#include
#include
int socket(int domain,int type,int protocol);
Let's see the arguments:
domain -> you can set "AF_INET" (set AF_INET to use ARPA internet protocols)
or "AF_UNIX" if you want to create sockets for inside comunication.
Those two are the most used, but don't think that there are just
those. There are more I just don't mention them.
type -> here you put the kind of socket you want (Stream or Datagram)
If you want Stream Socket the type must be SOCK_STREAM
If you want Datagram Socket the type must be SOCK_DGRAM
protocol -> you can just set protocol to 0
socket() gives you a socket descriptor that you can use in later system calls or
it gives you -1 on error (this is usefull for error checking routines).
6.2. bind()
===========
#include
#include
int bind(int fd, struct sockaddr *my_addr,int addrlen);
Let's see the arguments:
fd -> is the socket file descriptor returned by socket() call
my_addr -> is a pointer to struct sockaddr
addrlen -> set it to sizeof(struct sockaddr)
bind() is used when you care about your local port (usually when you use listen() )
and its function is to associate a socket with a port (on your machine). It returns
-1 on error.
You can put your IP address and your port automatically:
server.sin_port = 0; /* bind() will choose a random port*/
server.sin_addr.s_addr = INADDR_ANY; /* puts server's IP automatically */
An important aspect about ports and bind() is that all ports bellow 1024 are reserved.
You can set a port above 1024 and bellow 65535 (unless the ones being used by other
programs).
6.3. connect()
==============
#include
#include
int connect(int fd, struct sockaddr *serv_addr, int addrlen);
Let's see the arguments:
fd -> is the socket file descriptor returned by socket() call
serv_addr -> is a pointer to struct sockaddr that contains destination IP
address and port
addrlen -> set it to sizeof(struct sockaddr)
connect() is used to connect to an IP address on a defined port. It returns -1 on
error.
6.4. listen()
=============
#include
#include
int listen(int fd,int backlog);
Let's see the arguments:
fd -> is the socket file descriptor returned by socket() call
backlog -> is the number of allowed connections
listen() is used if you're waiting for incoming connections, this is, if you want
someone to connect to your machine. Before calling listen(), you must call bind()
or you'll be listening on a random port =) After calling listen() you must call
accept() in order to accept incoming connection. Resuming, the sequence of system calls
is:
1. socket()
2. bind()
3. listen()
4. accept() /* In the next section I'll explain how to use accept() */
As all functions above described, listen() returns -1 on error.
6.5. accept()
=============
#include
int accept(int fd, void *addr, int *addrlen);
Let's see the arguments:
fd -> is the socket file descriptor returned by listen() call
addr -> is a pointer to struct sockaddr_in where you can determine which host
is calling you from which port
addrlen -> set it to sizeof(struct sockaddr_in) before its address is passed
to accept()
When someone is trying to connect to your computer, you must use accept() to get the
connection. It's very simple to understand: you just get a connection if you accept =)
Next, I'll give you a little example of accept() use because it's a little different
from other functions.
(...)
sin_size=sizeof(struct sockaddr_in);
if ((fd2 = accept(fd,(struct sockaddr *)&client,&sin_size))==-1){ /* calls accept() */
printf("accept() error\n");
exit(-1);
}
(...)
From now on, fd2 will be used for add send() and recv() calls.
6.6. send()
===========
int send(int fd,const void *msg,int len,int flags);
Let's see the arguments:
fd -> is the socket descriptor where you want to send data to
msg -> is a pointer to the data you want to send
len -> is the length of the data you want to send (in bytes)
flags -> set it to 0
This function is used to send data over stream sockets or CONNECTED datagram sockets.
If you want to send data over UNCONNECTED datagram sockets you must use sendto().
send() returns the number of bytes sent out and it will return -1 on error.
6.7. recv()
===========
int recv(int fd, void *buf, int len, unsigned int flags);
Let's see the arguments:
fd -> is the socket descriptor to read from
buf -> is the buffer to read the information into
len -> is the maximum length of the buffer
flags -> set it to 0
As I said above about send(), this function is used to send data over stream sockets or
CONNECTED datagram sockets. If you want to send data over UNCONNECTED datagram sockets
you must use recvfrom().
recv() returns the number of bytes read into the buffer and it'll return -1 on error.
6.8. sendto()
=============
int sendto(int fd,const void *msg, int len, unsigned int flags,
const struct sockaddr *to, int tolen);
Let's see the arguments:
fd -> the same as send()
msg -> the same as send()
len -> the same as send()
flags -> the same as send()
to -> is a pointer to struct sockaddr
tolen -> set it to sizeof(struct sockaddr)
As you can see, sendto() is just like send(). It has only two more arguments : "to"
and "tolen" =)
sendto() is used for UNCONNECTED datagram sockets and it returns the number of bytes
sent out and it will return -1 on error.
6.9. recvfrom()
===============
int recvfrom(int fd,void *buf, int len, unsigned int flags
struct sockaddr *from, int *fromlen);
Let's see the arguments:
fd -> the same as recv()
buf -> the same as recv()
len -> the same as recv()
flags -> the same as recv()
from -> is a pointer to struct sockaddr
fromlen -> is a pointer to a local int that should be initialised
to sizeof(struct sockaddr)
recvfrom() returns the number of bytes received and it'll return -1 on error.
6.10. close()
=============
close(fd);
close() is used to close the connection on your socket descriptor. If you call close(),
it won't be no more writes or reads and if someone tries to read/write will receive an
error.
6.11. shutdown()
================
int shutdown(int fd, int how);
Let's see the arguments:
fd -> is the socket file descriptor you want to shutdown
how -> you put one of those numbers:
0 -> receives disallowed
1 -> sends disallowed
2 -> sends and receives disallowed
When how is set to 2, it's the same thing as close().
shutdown() returns 0 on success and -1 on error.
6.12. gethostname()
===================
#include
int gethostname(char *hostname, size_t size);
Let's see the arguments:
hostname -> is a pointer to an array that contains hostname
size -> length of the hostname array (in bytes)
gethostname() is used to get the name of the local machine.
7. SOME WORDS ABOUT DNS
=======================================
I created this section, because I think you should know what DNS is. DNS stands for "Domain
Name Service" and basically, it's used to get IP addresses. For example, I need to know the
IP address of queima.ptlink.net and through DNS I'll get 212.13.37.13 .
This is important, because functions we saw above (like bind() and connect()) work with IP
addresses.
To see you how you can get queima.ptlink.net IP address on c, I made a little example:
/* <---- SOURCE CODE STARTS HERE ----> */
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct hostent *he;
if (argc!=2){
printf("Usage: %s
exit(-1);
}
if ((he=gethostbyname(argv[1]))==NULL){
printf("gethostbyname() error\n");
exit(-1);
}
printf("Hostname : %s\n",he->h_name); /* prints the hostname */
printf("IP Address: %s\n",inet_ntoa(*((struct in_addr *)he->h_addr))); /* prints IP address */
}
/* <---- SOURCE CODE ENDS HERE ----> */
8. A STREAM SERVER EXAMPLE
=======================================
In this section, I'll show you a nice example of a stream server. The source code is all
commented so that you ain't no possible doubts =)
Let's start:
/* <---- SOURCE CODE STARTS HERE ----> */
#include
#include
#include
#include
#define PORT 3550 /* Port that will be opened */
#define BACKLOG 2 /* Number of allowed connections */
main()
{
int fd, fd2; /* file descriptors */
struct sockaddr_in server; /* server's address information */
struct sockaddr_in client; /* client's address information */
int sin_size;
if ((fd=socket(AF_INET, SOCK_STREAM, 0)) == -1 ){ /* calls socket() */
printf("socket() error\n");
exit(-1);
}
server.sin_family = AF_INET;
server.sin_port = htons(PORT); /* Remember htons() from "Conversions" section? =) */
server.sin_addr.s_addr = INADDR_ANY; /* INADDR_ANY puts your IP address automatically */
bzero(&(server.sin_zero),8); /* zero the rest of the structure */
if(bind(fd,(struct sockaddr*)&server,sizeof(struct sockaddr))==-1){ /* calls bind() */
printf("bind() error\n");
exit(-1);
}
if(listen(fd,BACKLOG) == -1){ /* calls listen() */
printf("listen() error\n");
exit(-1);
}
while(1){
sin_size=sizeof(struct sockaddr_in);
if ((fd2 = accept(fd,(struct sockaddr *)&client,&sin_size))==-1){ /* calls accept() */
printf("accept() error\n");
exit(-1);
}
printf("You got a connection from %s\n",inet_ntoa(client.sin_addr) ); /* prints client's IP */
send(fd2,"Welcome to my server.\n",22,0); /* send to the client welcome message */
close(fd2); /* close fd2 */
}
}
/* <---- SOURCE CODE ENDS HERE ----> */
9. A STREAM CLIENT EXAMPLE
=======================================
/* <---- SOURCE CODE STARTS HERE ----> */
#include
#include
#include
#include
#include
#define PORT 3550 /* Open Port on Remote Host */
#define MAXDATASIZE 100 /* Max number of bytes of data */
int main(int argc, char *argv[])
{
int fd, numbytes; /* files descriptors */
char buf[MAXDATASIZE]; /* buf will store received text */
struct hostent *he; /* structure that will get information about remote host */
struct sockaddr_in server; /* server's address information */
if (argc !=2) { /* this is used because our program will need one argument (IP) */
printf("Usage: %s
exit(-1);
}
if ((he=gethostbyname(argv[1]))==NULL){ /* calls gethostbyname() */
printf("gethostbyname() error\n");
exit(-1);
}
if ((fd=socket(AF_INET, SOCK_STREAM, 0))==-1){ /* calls socket() */
printf("socket() error\n");
exit(-1);
}
server.sin_family = AF_INET;
server.sin_port = htons(PORT); /* htons() is needed again */
server.sin_addr = *((struct in_addr *)he->h_addr); /*he->h_addr passes "*he"'s info to "h_addr" */
bzero(&(server.sin_zero),8);
if(connect(fd, (struct sockaddr *)&server,sizeof(struct sockaddr))==-1){ /* calls connect() */
printf("connect() error\n");
exit(-1);
}
if ((numbytes=recv(fd,buf,MAXDATASIZE,0)) == -1){ /* calls recv() */
printf("recv() error\n");
exit(-1);
}
buf[numbytes]='\0';
printf("Server Message: %s\n",buf); /* it prints server's welcome message =) */
close(fd); /* close fd =) */
}
/* <---- SOURCE CODE ENDS HERE ----> */
10. LAST WORDS
=======================================
As I'm just a simple human, it's almost certain that there are some errors on this document.
When I say errors I mean English errors (because my language is not the English) but also
technical errors. Please email me if you detect any error =)
But you must understand that this is the first version of this document, so , it's natural not
to be very complete (as matter of fact I think it is ) and it's also very natural to have
stupid errors. However, I can be sure that source code presented in this document works fine.
If you need help concerning this subject you can email me at
SPECIAL THANKS TO: Ghost_Rider (my good old mate), Raven (for letting me write this tutorial)
and all my friends =)
11. COPYRIGHT
=======================================
All copyrights are reserved. You can distribute this tutorial freely, as long you don't change any name or URL.
An Architectural Overview of UNIX Network Security
February 18, 1993
Robert B. Reinhardt
breinhar@access.digex.com
ARINC Research Corporation
2551 Riva Road
Annapolis, MD 21401
1. Introduction
The goal of this paper is to present my concept of a UNIX network security architecture based on the Internet connectivity model and Firewall approach to implementing security. This paper defines several layers of a firewall, which depict the layers of vulnerability. This paper also provides some subjective comments on some of the most widely known tools and methods available to protect UNIX networks today, plus a brief discussion of the threat and the risk.
The list of tools and methods that I present in this paper were chosen loosely on the basis of the following: (a) My attempt to find at least one, maybe several examples of a tool or method designed to address a part of the architectural model (some duplication or overlap is accepted); (b) my preference to discuss tools that are well-known and/or part of the public domain (this is not a strict rule, although I did not purposely seek out commercial products); and (c) I hoped to find tools that had a recent paper written by the tools' author, for the reader to use as detailed reference beyond the scope of this document.
Nothing in this paper should be construed as a product endorsement. I apologize in advance to the authors of these tools and methods; since I am only presenting a brief overview, I cannot do justice to a comprehensive description of them. I also apologize to any authors whom I may have left out of this discussion; it was not intentional. The reader should check the availability information that accompanies each tool and obtain additional information prior to proceding with any plans or implementation. Of course, there is no warranty expressed or implied in this paper.
2. Risk, Threat, and Vulnerability
This section presents a general overview of the risk and the threat to the security of your network. These are general statements that apply to almost every network. A complete analysis of your network's risk, threat, and vulnerability should be done in order to assess in detail the requirements of your own network.
2.1 Risk
The risk is the possibility that an intruder may be successful in attempting to access your local-area network via your wide-area network connectivity. There are many possible effects of such an occurence. In general, the possibility exists for someone to:
READ ACCESS. Read or copy information from
your network.
WRITE ACCESS. Write to or destroy data on
your network (including planting trojan
horses, viruses, and back-doors).
DENIAL OF SERVICE. Deny normal use of your
network resources by consuming all of your
bandwidth, CPU, or memory.
2.2 Threat
The threat is anyone with the motivation to attempt to gain unauthorized access to your network or anyone with authorized access to your network. Therefore it is possible that the threat can be anyone. Your vulnerability to the threat depends on several factors such as:
MOTIVATION. How useful access to or
destruction of your network might be to
someone.
TRUST. How well you can trust your authorized
users and/or how well trained are your users
to understand what is acceptable use of the
network and what is not acceptable use,
including the consequences of unacceptable
use.
2.3 Vulnerability
Vulnerability essentially is a definition of how well protected your network is from someone outside of your network that attempts to gain access to it; and how well protected your network is from someone within your network intentionally or accidently giving away access or otherwise damaging the network.
Motivation and Trust (see Threat, section 2.2) are two parts of this concern that you will need to assess in your own internal audit of security requirements and policy, later I will describe some references that are available to help you start this process.
The rest of this paper is a presentation of my concept of the architectural model of UNIX network security (the focus of this paper). This is geared toward connectivity to the Internet (or Internet Protocol connectivity in general), employing the FIREWALL method of reducing vulnerability to the risks and the threat.
3. UNIX Network Security Architecture
For each of the layers in the UNIX Network Security Architecture (UNIX/NSA) model below, there is a subsection that follows that gives a brief description of that layer and some of the most widely used tools and methods for implementing security controls. I am using the ISO/OSI style of model since most people in the UNIX community are familiar with it. This architecture is specifically based on UNIX Internet connectivity, but it is probably general enough to apply to overall security of any network methodology. One could argue that this model applies to network connectivity in general, with or without the specific focus of UNIX network security.
Layer Name Functional Description
LAYER 7 POLICY POLICY DEFINITION AND DIRECTIVES
LAYER 6 PERSONNEL PEOPLE WHO USE EQUIPMENT AND DATA
LAYER 5 LAN COMPUTER EQUIPMENT AND DATA ASSETS
LAYER 4 INTERNAL-DEMARK CONCENTRATOR - INTERNAL CONNECT
LAYER 3 GATEWAY FUNCTIONS FOR OSI 7, 6, 5, 4
LAYER 2 PACKET-FILTER FUNCTIONS FOR OSI 3, 2, 1
LAYER 1 EXTERNAL-DEMARK PUBLIC ACCESS - EXTERNAL CONNECT
The specific aim of this model is to illustrate the relationship between the various high and low level functions that collectively comprise a complete security program for wide-area network connectivity. They are layered in this way to depict (a) the FIREWALL method of implementing access controls, and (b) the overall transitive effect of the various layers upon the adjacent layers, lower layers, and the collective model. The following is a general description of the layers and the nature of the relationship between them. After this brief discussion of what each layer is, the next section of this paper will discuss examples of common methods and tools used to implement some of your options at each level, or at least try to tell you where to find out how to get started. Note that there may be some overlap between the definitions of the various levels, this is most likely between the different layers of the FIREWALL itself (layers 2 and 3).
The highest layer [ 7 - POLICY ] is the umbrella that the entirety of your security program is defined in. It is this function that defines the policies of the organization, including the high level definition of acceptable risk down to the low level directive of what and how to implement equipment and procedures at the lower layers. Without a complete, effective, and implemented policy, your security program cannot be complete.
The next layer [ 6 - PERSONNEL ] defines yet another veil within the bigger umbrella covered by layer 7. The people that install, operate, maintain, use, and can have or do otherwise have access to your network (one way or another) are all part of this layer. This can include people that are not in your organization, that you may not have any administrative control over. Your policy regarding personnel should reflect what your expectations are from your overall security program. Once everything is defined, it is imperitive that personnel are trained and are otherwise informed of your policy, including what is and is not considered acceptable use of the system.
The local-area network layer [ 5 - LAN ] defines the equipment and data assets that your security program is there to protect. It also includes some of the monitor and control procedures used to implement part of your security policy. This is the layer at which your security program starts to become automated electronically, within the LAN assets themselves.
The internal demarkation layer [ 4 - INTERNAL DEMARK ] defines the equipment and the point at which you physically connect the LAN to the FIREWALL that provides the buffer zone between your local- area network (LAN) and your wide-area network (WAN) connectivity. This can take many forms such as a network concentrator that homes both a network interface for the FIREWALL and a network interface for the LAN segment. In this case, the concentrator is the internal demarkation point. The minimum requirement for this layer is that you have a single point of disconnect if the need should arise for you to spontaneosly separate your LAN from your WAN for any reason.
The embedded UNIX gateway layer [ 3 - GATEWAY ] defines the entire platform that homes the network interface coming from your internal demark at layer 4 and the network interface going to your packet filtering router (or other connection equipment) at layer 3. The point of the embedded UNIX gateway is to provide FIREWALL services (as transparent to the user or application as possible) for all WAN services. What this really is must be defined in your policy (refer to layer 1) and illustrates how the upper layers overshadow or are transitive to the layers below. It is intended that the UNIX gateway (or server) at this layer will be dedicated to this role and not otherwise used to provide general network resources (other than the FIREWALL services such as proxy FTP, etc.). It is also used to implement monitor and control functions that provide FIREWALL support for the functions that are defined by the four upper ISO/OSI layers (1-Application, 2-Presentation, 3- Session, 4-Transport). Depending on how this and the device in layer 2 is implemented, some of this might be merely pass-thru to the next level. The configuration of layers 3 and 2 should collectively provide sufficient coverage of all 7 of the functions defined by the ISO/OSI model. This does not mean that your FIREWALL has to be capable of supporting everything possible that fits the OSI model. What this does mean is that your FIREWALL should be capable of supporting all of the functions of the OSI model that you have implemented on your LAN/WAN connectivity.
The packet filtering layer [ 2 - FILTER ] defines the platform that homes the network interface coming from your gateway in layer 3 and the network interface or other device such as synchronous or asynchronous serial communication between your FIREWALL and the WAN connectivity at layer 1. This layer should provide both your physical connectivity to layer 1 and the capability to filter inbound and outbound network datagrams (packets) based upon some sort of criteria (what this criteria needs to be is defined in your policy). This is typically done today by a commercial off-the- shelf intelligent router that has these capabilities, but there are other ways to implement this. Obviously there is OSI link-level activity going on at several layers in this model, not exclusively this layer. But, the point is that functionally, your security policy is implemented at this level to protect the overall link- level access to your LAN (or stated more generally; to separate your LAN from your WAN connectivity).
The external demarkation layer [ LAYER 1 ] defines the point at which you connect to a device, telephone circuit, or other media that you do not have direct control over within your organization. Your policy should address this for many reasons such as the nature and quality of the line or service itself and vulnerability to unauthorized access. At this point (or as part of layer 2) you may even deploy yet another device to perform point to point data link encryption. This is not likely to improve the quality of the line, but certainly can reduce your vulnerability to unauthorized access. You also need to be concerned about the dissemination of things at this level that are often considered miscellaneous, such as phone numbers or circuit IDs.Illustration of the UNIX/NSA Model
------------------------------------------------------------------
| POLICY |
------------------------------------------------------------------
|
|
---------------------------------------------------
| PERSONNEL |
---------------------------------------------------
|
|
---------------------------------
| LAN |
---------------------------------
Enet |
Enet |
-----------------
| INTERNAL-D |
-----------------
Enet |
Enet |
----------------- UNIX server with two Ethernet interfaces and
| GATEWAY-SERVER| custom software and configuration to implement
----------------- security policy (proxy services, auditing).
Enet |
Enet |
-----------------
| PACKET-FILTER | cisco IGS router with access lists
-----------------
X.25 |
|
-----------------
| EXTERNAL-D | leased DID line to WAN service
-----------------
|
|
+ Public Access +
3.1 PUBLIC or NON-PRIVATE CONNECTIVITY
This layer of the model characterizes all external physical connectivity to your network. This normally includes equipment and telephone lines that you do not own or do not have control over. The point of illustrating this is to show this part of the connectivity as part of the overall model. At some point at this layer, equipment that you do own or have control of will connect to the external or public network. Your own policy and implementation must take the dynamics of this connectivity into account.
3.2 ROUTER (FIREWALL PHYSICAL LAYER)
This layer of the model depicts the point at which your physical connectivity and your data stream become one. Without going into hysterics about all of what a router is and does; the point is that at this layer, your electrical connectivity, which contains encapsulated data in some form, becomes information. Your router will decode the electrical signals from the physical connectivity and turn it into packets of encapsulated data for any one of various networking protocols. Within this packet of information is contained the source address, destination address, protocol ID, the datagram itself, etc.
Many routers available today include the capability to create access control lists (ACL) for either one or both of the outgoing and the incoming data interfaces [1][5]. This normally includes the capability to filter out or allow in packets based upon source address, destination address, protocol (such as TCP, UDP, ICMP, etc.) and specific port numbers (TCP and UDP). This provides you the flexibility to design your own network access control policy, enforced at the router, before access to your internal network resources is required or granted. In this way, routers alone are often used to provide the firewall functionality.
While the router ACL capability offers a big advantage, it should not be your only protection because, basically the router only provides protection at the first three levels of the OSI model (Physical, Data Link, and Network layers). The rest of the layers of this firewall model discuss ways to address functional security of the other four OSI layers (Transport, Session, Presentation, and Application).
Availability: I only have personal experience with CISCO routers, however I've been told that Wellfleet and Proteon routers also have this feature. There may be other vendors as well, but they probably all implement it a little differently.
3.3 DUAL-HOMED UNIX GATEWAY SERVER (FIREWALL LOGICAL LAYER)
This layer of the model illustrated the point at which your various IP packets (to and from the router) are used by the network operating system (such as TCP/IP under UNIX) to provide the services identified in the upper four layers of the OSI model. Of course, this UNIX server is actually doing work at the bottom three OSI layers also, in order to communicate with: (a) the router on one side of the server, and (b) the local-area network on the other side of the server.
At this point the router is already implementing your security policy for the bottom three OSI layers, now it's up to your dual- homed [10] UNIX server (acting as a gateway) to implement your security policy relating to functions of the network for the upper four OSI layers. This can mean a lot of things. Depending on what your security policy says you are supposed to enforce, what you do at this point varies. The following tools and methods are example of some of the tools and methods (functionality) available today:
3.3.1 TCP Wrapper
The "TCP WRAPPER" tool [2] provides monitoring and control of network services. Essentially, what happens is that you configure inetd on your dual-homed gateway to run the TCP WRAPPER software whenever certain services (ports) are connected to. Depending on how you configure TCP WRAPPER, it will then LOG information about the connection and then actually start the intended SERVER program that the connection was intended for. Since you have the source to the tool, you can modify it to do more depending on what your needs are. For example, you may want TCP WRAPPER to connect the user to a proxy service instead of the actual program, then have your proxy software handle the transaction in whatever way your security requirements demand.
Availability: This is available from several sources, but to ensure that you get the most recent copy that CERT has verified, you should use anonymous FTP to retrieve it from cert.org in ~/pub/tools/tcp_wrappers/tcp_wrappers.*.
3.3.2 SOCKS library and sockd
The "sockd" and "SOCKS Library" [3] provide another way to implement a "TCP Wrapper." It is not intended to make the system it runs on secure, but rather to centralize ("firewall") all external internet services. The sockd process is started by inetd whenever a connection is requested for certain services, and then only allows connections from approved hosts (listed in a configuration file). The sockd also will LOG information about the connection. You can use the Socks Library to modify the client software to directly utilize the sockd for outgoing connections also, but this is described as very tedious and of course requires you to have the source to those client programs.
Availability: The socks package, which in addition to including both the daemon and the library, has a pre-modified FTP client and finger client; it is available via anonymous FTP from s1.gov in ~/pub as socks.tar.Z. Contact the authors for more information. David Koblas (koblas@netcom.com) or Michelle R. Koblas (mkoblas@nas.nasa.gov).
3.3.3 Kernel_Wrap for SunOS RPC via Shared Libraries
Essentially this is a wrapper for SunOS daemons that use RPC [4], such as portmap, ypserv, ypbind, ypupdated, mountd, pwdauthd, etc. To utilize this, you must have SunOS 4.1 or higher and must have the capability to rebuild your shared libraries (but, you don't need the source to your entire system). Essentially what happens is that you modify the function calls that the kernel uses to establish RPC connections, such as accept(), recvfrom() and recvmsg(). Since these calls are maintained in the shared libraries, you have access to modify them without rewriting the kernel.
Availability: The secured C library package to implement this is available via anonymous FTP from eecs.nwu.edu in ~/pub/securelib.
3.3.4 Swatch
Simple WATCHER [6] is really two things, it is a program used to parse through the myriad of LOG data generated by the various security programs, in particular "syslog." But, it's more than that. It is fully configurable with triggers (actions), so that while it is continuously monitoring the LOG in "real-time," it can take actions based upon certain high-priority events that you tell it to watch for. To get full use of this, you will need to modify your network service daemons such as ftpd and telnetd so that enhanced logging is added to syslog, to feed SWATCH.
Availability: The SWATCH source and documentation is available via anonymous FTP from sierra.stanford.edu in ~/pub/sources.
3.3.5 Controlled Access Point (CAP)
This is more of a method or protocol definition than a specific product. CAP [7] provides a network mechanism intended to reduce the risk of: password guessing, probing for well-known accounts with default passwords, trusted host rlogin, and password capture by network snooping. It is really a design for a variation or enhancement to the general firewall approach to connecting two or more networks. In the paper describing this there is an example of two local nets, one a secure segment with an authentication service, and the other an unsecure segment. Both communicate with each other via a CAP, while there is a router for communication to public networks connected on the unsecure side of the CAP. The CAP is essentially a router with additional functionality to detect incoming connection requests, intercept the user authentication process, and invoke the authentication server.
Availability: Unknown. Contact the authors for more information. J. David Thompson (thompsond@orvb.saic.com) and Kate Arndt (karndt@mitre.org).
3.3.6 Mail Gateway
This is more of a procedure than a software package (although there are packages designed just to do this). I included this to maintain continuity with what I'm trying to illustrate in this paper. This really should be applied to all network services that require external connectivity (meaning any communication over non-private or non-secure channels). In the simplest implementation of this, you configure your router to filter packets so that all mail traffic (SMTP protocol for example) is only allowed to and from one host, the "Mail Gateway." Likewise, your DNS and MTA software will need to be configured for this as well.
3.3.7 Tty Wrapper
This is one of my pet ideas. I have not seen something like this around, and I'll probably never have time to develop it. But, essentially this would be like "TCP Wrapper," only it is designed specifically for serial communications. After that, we will need a "Pseudo-Tty Wrapper," (something more than just filtering out the telnet port) but that is for another day.
3.3.8 HSC-Gatekeeper
The HSC-Gatekeeper from Herve' Schauer Consultants [8], is a complete solution to both layers 1 and 2 of this firewall model. It consists of a thorough firewall methodology and authentication server, providing pass-thru FTP and TELNET services. The author (Herve Schauer) noted that HSC-Gatekeeper is alone to be able to offer fully transparent authentication for these services. I have not had personal experience with HSC's products, so I cannot make a conclusive statement about it other than to comment that the description of it in HSC's paper "An Internet Gatekeeper" (available in the USENIX Proceedings) depicts it (IMHO) as a very comprehensive solution.
Availability: For more information, contact Herve Schauer via e-mail at Herve.Schauer@hsc-sec.fr.
3.3.9 AT&T Inet
Since I discussed HSC's firewall solution, I thought it only fair to mention AT&T's INET Gateway. For a complete description of AT&T's internal solution, you should read Bill Cheswick's paper [9] "The Design of a Secure Internet Gateway." For additional information, contact the author via e-mail at ches@research.att.com. I do not believe that AT&T is in the business of selling this solution to anyone, but the paper describes in good detail how it was done. It should provide the puritan firewaller additional depth to the problems and possible solutions to an Internet firewall approach.
3.4 COMPUTERS ON THE LOCAL-AREA NETWORK
This layer of the model depicts the place where you you are potentially at the greatest risk. The previous layers discussed ways to protect access to this layer of the network. This layer includes all of you local-area network, workstations, file servers, data bases, and other network resources. This is also the point at which your user community sits at their desks and use the network.
There are several things to be concerned about here, access to this layer in the first place notwithstanding. Just because you think you have protected and may be monitoring access to this layer within the previous layers, does not mean that use of computers and other resources within your local-area network should become a free for all. Again, this depends on what you identify in your own particular security policy but, at this layer you should do some routine checking for possible breaches of your firewall that would leave its mark at this layer and pay close attention to effective password handling, etc. This is also the layer of this model at which you want to concern yourself with training your users, after all this is where they can potentially make their mistakes (and harm your network).
3.4.1 Computer Oracle and Password System (COPS)
COPS is a UNIX security status checker. Essentially what it does is check various files and software configurations to see if they have been compromised (edited to plant a trojan horse or back door), and checks to see that files have the appropriate modes and permissions set to maintain the integrity of your security level (make sure that your file permissions don't leave themselves wide open to attack/access).
Many vendors of UNIX are now bundling a security status checker with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them.
Additional Comments: The current version of COPS (1.04) makes a limited attempt to detect bugs that are posted in CERT advisories. Also, it has an option to generate a limited script that can correct various security problems that are discovered. Dan also offers a quick hint that should easily get you started using COPS. After you have unarchived the COPS package, perform the following steps: './reconfig', 'make', and './cops -v -s . - b bit_bucket'. -- There is a lot of README documentation included if you need more help.
Availability: COPS can be retrieved via anonymous FTP from cert.org in ~/pub/tools/cops.
3.4.2 Chkacct
Chkacct [11] is a COPS for the ordinary user. This tool is made available to the users to run, or it is run for them once per day. It will do an integrity check on the status of files in their own account and then mail them the results (such as "Dear user: Your .rhosts file is unsafe"). This package can help make your users more aware of security controls and raise their level of participation in the program.
Availability: Chkacct is distributed with the COPS package (>= COPS 1.04), for additional information contact shabby@mentor.cs.purdue.edu.
3.4.3 Crack
Crack helps the security administrator identify weak passwords by checking for various weaknesses and attempting to decrypt them. If Crack can figure out your password, then you must choose a better password. It is very likely that a determined intruder will be able to get the password too (using similar techniques, or the Crack program itself, since it is publicly available).
Availability: Crack is available via anonymous FTP from cert.org in ~/pub/tools/crack/crack_4.1-tar.Z.
3.4.4 Shadow
The shadow password suite of programs [12] replaces the normal password control mechanisms on your system to remove the encrypted password from the publicly readable file /etc/passwd and hides them in a place that only this program has permission to read. It consists of optional, configurable components, provides password aging to force users to change their passwords once in awhile, adds enhanced syslog logging, and can allow users to set passwords up to a length of sixteen characters.
Many vendors of UNIX are now bundling a shadow password suite with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them.
Availability: Shadow is available from USENET archives which store the comp.sources.misc newsgroup. Distribution is permitted for all non-commercial purposes. For more information contact the author, John F. Haugh III (jfh@rpp386.cactus.org).
3.4.5 Passwd+
Passwd+ is a proactive password checker [13] that replaces /bin/passwd on your system. It is rule-based and easily configurable. It prevents users from selecting a weak password so that programs like "CRACK" can't guess it, and it provides enhanced syslog logging.
Many vendors of UNIX are now bundling a proactive password checker with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them.
Availability: Passwd+ (developed by Matt Bishop) is available via anonymous FTP from dartmouth.edu in ~/pub/passwd+tar.Z.
3.4.6 Audit
Audit is a policy-driven security checker for a heterogeneous environment [14]. It is fully configurable so that you can set up Audit to exactly match your site's security policy. This program functionally does what COPS is intended to do, but does not hard-code your policy decisions for you the way that COPS does.
Many vendors of UNIX are now bundling an auditing subsystem with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them. One particular subject to note is that most (IMHO) vendors auditing subsystems only collect and regurgitate tons of raw data, with no guidance and assistance for using that information. They leave that up to you. The Audit and/or Swatch tools are probably better.
Availability: The final version of Audit will eventually be posted to USENET. However, the beta release will only be made available on a limited basis, to larger, heterogeneous sites. If your interested in participating in the beta test, send e-mail to the auther, Bjorn Satdeva (bjorn@sysadmin.com).
3.4.7 Miro
Miro [14] is a suite of tools for specifying and checking security contraints (like COPS and Audit), including a couple programming languages. It is general because it is not tied to any particular OS, and it is flexible because security administrators express site policies via a formal specification language. It is easy to extend or modify a policy by simply augmenting or changing the specification of the current policy.
Availability: Miro is the product of a large research project, and to understand it you need more than the paragraph I've written above. For more information about the Miro project send e-mail to (miro@cs.cmu.edu), there is even a video available. The authors Ph.D thesis, as well as the sources for the Miro tools, are available via anonymous FTP from ftp.cs.cmu.edu. When you connect there, type "cd /afs/cs/project/miro/ftp" and "get ftp-instructions"; this will explain how to get the thesis and/or software.
3.5 ADDITIONAL SECURITY ENHANCEMENTS
The tools described in firewall layers {1...4} (sections 3.1 to 3.4) above, are what I consider part of a "base" set of tools and functional requirements for general security administration. The tools and methods described in this section are additional measures that can be combined with or added to your overall security program at any of the other levels.
3.5.1 One-time Password Key-Card
Since reusable passwords can be captured and used/reused by intruders, consider a "one-time password" scheme. One-time passwords can be implemented using software-only solutions or software/hardware solutions, and there are several commercial products available. The following is an example of what CERT uses. Each user is assigned a "Digital Pathways" key-card (approximately $60 per user). When you enter your PIN code, it supplies a password that is good only one time. The only other piece to this, is software that replace the login shell on your "firewall" server.
Availability: The source-code for this shell is based on code from the key card vendor and is currently not available to the public domain via anonymous FTP. For additional information about this, send e-mail to (cert@cert.org).
3.5.2 Privacy Enhanced Mail (PEM)
PEM is a RSA-based encryption scheme that encrypts sensitive information, but more than that it checks for message integrity and non-repudiation of origin, so that the originator cannot deny having sent the message. PEM is actually a protocol that is designed to allow use of symmetric (private-key) and asymmetric (public-key) cryptography methods. In this example, Trusted Information Systems, Inc. (TIS) has implemented a PEM package using the public-key technique together with the Rand MH Message Handling System (version 6.7.2). TIS/PEM libraries [16] can be adapted for implementation of non-mail applications as well.
Availability: TIS/PEM is a commercially available product, for additional information send e-mail to (pem-info@tis.com).
3.5.3 Kerberos
Kerberos is a DES-based encryption scheme that encrypts sensitive information, such as passwords, sent via the network from client software to the server daemon process. The network services will automatically make requests to the Kerberos server for permission "tickets." You will need to have the source to your client/server programs so that you can use the Kerberos libraries to build new applications. Since Kerberos tickets are cached locally in /tmp, if there is more than one user on a given workstation, then a possibility for a collision exists. Kerberos also relies upon the system time to operate, therefore it should be enhanced in the future to include a secure time server (timed is not appropriate). There are two versions of Kerberos, one for OSF ported by HP, and one BSD-based developed by the author.
Availability: Kerberos is distributed via anonymous FTP from athena-dist.mit.edu in ~/pub/kerberos or ~/pub/kerberos5.
3.5.4 Private-Key Certificates
This is not really a product, but rather a design proposal [17] that is an alternative method to PEM for adding network security to applications such as mail. Simply put, it uses the public-key style of implementation with private-key cryptography. It can be adapted to different types of applications and it is boilerplate so that you can essentially plug-in any encryption algorithm. This is designed so that public-key protocols no longer have to rely on public-key encryption.
Availability: Unknown. For more information, contact Don Davis, at Geer Zolot Assoc., Boston, MA (formerly of Project Athena at MIT). His paper "Network Security via Private-Key Certificates" better describes this techique.
3.5.5 Multilevel Security (MLS)
After you've done everything else (above) to make your network secure, then MLS will probably be one of your next logical steps. That doesn't mean you have to wait until you've done everything else before implementing MLS, it's just (IMHO) that you would be wasting your time to go to the n'th degree before covering the fundamentals. However, if you are just now deciding to which variant of the UNIX operating system to buy, consider buying an MLS variant now. After you configure it to manage your security policy, go back through layers {1...4} to see what you might add to make it more secure in a networked environment. Many UNIX vendors are now shipping or preparing to ship a MLS version. A couple examples that immediately come to mind is SecureWare CMW+ 2.2 (based on A/UX or SCO ODT 1.1) and AT&T USL System V-Release 4-Version 2-Enhanced Security (SVR4.2ES).
For additional information regarding MLS implementations within the Department of Defense (DoD), contact Charles West at (703) 696-1891, Multilevel Security Technology Insertion Program (MLS TIP), Defense Information Systems Agency (DISA).
For additional information regarding SecureWare CMW+, send e-mail to info@sware.com. For additional information regarding AT&T USL SVR4.2ES, send e-mail to fate@usl.com.
3.5.6 File Encryption
Users should get into the habit of encrypting sensitive files whenever they are stored in a public place or transmitted via public communication circuits. File encryption isn't bulletproof, but it is better than clear text for sensitive information. The UNIX crypt utility is the least secure of these tools, since it can be broken using well-known decryption techniques. The UNIX des utility (US export restriction apply) is more secure. It has not been known to be broken, however DoD does not sanction its use for transmitting classified material. A new UNIX tool PGP 2.2 is available (uses RSA encryption), however there may be licensing issues to be concerned with.
3.5.7 Secure Programming Methods
Programmers can assist in the effort of security by reducing the chance that a potential intruder can exploit a hole or bug that is coded into locally developed software. There is probably a lot that can be said about this, and their are probably many books on the subject somewhere. But, here are some common recommendations: (a) Never create a SETUID shell script. There are well-known techniques used by intruders to gain access to a shell program that is running as root; (b) List the complete file name, including the full path in any system() or popen() call; and (c) Since there is no reason for users to have read access to a SETUID file (or any exectuble for that matter), set permissions to 4711 (SETUID) or 711 (Non-SETUID).
3.5.8 Counterintelligence
To extend your security program to seek out, identify, and locate intruders; you may want to modify some of the security tools (especially those proxy service daemons and event-driven auditors) to trace intruders back to their source, and otherwise maintain logs of data on intrusion attempts. This information can prove vital in taking an offensive stance against security break-in's and can help prosecute offenders.
3.5.9 Other Possibilities
Depending on your requirements you might look into specialized solutions such as Compartmented Mode Workstations (CMW), end-to-end Data Link Encryption (STU-III, Motorola NES, and XEROX XEU are examples), and TEMPEST. The NCSC (Rainbow Series) and ITSEC specifications can help you define what level of need you have for security and help lead you to additional types of solutions.
3.6 SECURITY POLICY
Everything discussed in layers {1...5} (sections 3.1 to 3.5) above involve specific things you can do, tools and techniques to implement, to address a particular area or "hole" in security. Your SECURITY POLICY is what ties all of that together into a cohesive and effective SECURITY PROGRAM. There are many diverse issues to consider when formulating your policy, which alone is one of the biggest reasons why you must have one:
What are the functional requirements of your
network?
How secure do you need to be? What needs to
be protected?
How will you handle incident reporting and
prosecution?
What does the law require you to do? What
about privacy? Since break-ins often occur
via multiple hops on computers throughout the
US and the rest of the world, you will need
to consider a variation of federal, state,
local, as well as foreign laws.
Make security a dedicated and deliberate
effort.
User training and security awareness.
What is considered acceptable use for users?
Do the users understand what it is they are
permitted to do and what it is they are not
permitted to do?
What is considered acceptable use for system
administration staff? Is using Crack to test
passwords okay? Is giving friends outside
the organization accounts okay?
Maintain a working relationship with the
Computer Emergency Response Team (CERT) at
Carnegie Mellon University (CMU) and your
Forum of Incident Response and Security Teams
(FIRST) regional representative "CERT" team.
PLUS a myriad of different issues too
numerous to go into in a summary paper.
By answering these questions you determine what packages and methods in layers {1...5} (or their equivalent) that you want to implement, and in what ways you want to modify or configure them. "A security policy is a formal specification of the rules by which people are given access to a computer and its resources." (and to extend that to say...a network and its resources). Whatever tools you install to help you maintain the security of your network and monitor it, they must be configured to implement YOUR POLICY, or else they are not doing the whole job that needs to be done. Therefore, you must first have a POLICY.
For additional help in the area of policy development, contact cert@cert.org. They can direct you to useful documentation on the subject and guide you to your FIRST regional CERT team representative. A good starting point is Request For Comments (RFC) 1244 "Site Security Handbook" (96 pages), which is available via anonymous FTP from numerous RFC archive sites (for example: nic.ddn.mil).
4. SUMMARY OF AVAILABILITY
Section Name Availability
3.2 Router Cisco, Wellfleet, Proteon
3.3.1 Tcp_wrapper cert.org:/pub/tools/tcp_wrappers
3.3.2 Socks s1.gov:/pub/socks.tar.Z
3.3.3 Kernel_wrap eecs.nwu.edu:/pub/securelib
3.3.4 Swatch sierra.stanford.edu:/pub/sources
3.3.5 CAP e-mail to thompsond@orvb.saic.com
3.3.6 Mail Gateway
3.3.7 Tty_wrapper
3.3.8 HSC-Gatekeeper e-mail to Herve.Schauer@hsc-sec.fr
3.3.9 AT&T INET e-mail to ches@research.att.com
3.4.1 COPS cert.org:/pub/tools/cops
3.4.2 Chkacct cc.perdue.edu:/pub/chkacctv1.1.tar.Z
3.4.3 Crack cert.org:/pub/tools/crack/crack_4.1-tar.Z
3.4.4 Shadow comp.sources.misc (jfh@rpp386.cactus.org).
3.4.5 Passwd+ dartmouth.edu:/pub/passwd+tar.Z
3.4.6 Audit e-mail to bjorn@sysadmin.com
3.4.7 Miro e-mail to miro@cs.cmu.edu
3.5.1 Key-card e-mail to cert@cert.org
3.5.2 TIS/PEM e-mail to pem-info@tis.com
3.5.3 Kerberos athena-dist.mit.edu:/pub/kerberos5
3.5.4 Private-key contact Don Davis, at Geer Zolot Assoc.
3.5.5 MLS contact your UNIX vendor
3.5.6 File encrypt contact your UNIX vendor
3.5.7 Programming
3.5.8 Counter-Intel
3.5.9 Other Poss. research and contact various vendors
3.6 Policy RFC 1244 and cert@cert.org
5. ADDITIONAL SOURCES OF INFORMATION
There are several primary sources of information that you can tap into (and correspond with) to keep up to date with current happenings in the general network security and in specific the "firewall" community. I recommend subscribing to the following mailing lists: (a) cert-advisory-request@cert.org; (b) cert-tools- request@cert.org, and (c) firewalls@greatcircle.com. In addition to that read and participate in the following USENET newsgroups: (a) comp.security.announce (which echos the CERT advisory mailing list); (b) comp.security.misc; (c) alt.security (frequently dissolves into "flame wars"); (d) comp.risks; and (e) comp.virus (almost exclusively for discussing PC and MAC viruses). Also, you can copy files from the CERT USENET Clipping Archive via anonymous FTP from cert.org.
CERT Contact Information:
Emergencies: +1 412 268-7090
FAX: +1 412 268-6989
E-mail: cert@cert.org
U.S. Mail: CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213-3890, USA
USENIX Papers are available directly from USENIX:
The USENIX Association
2560 Ninth Street, Suite 215
Berkeley, CA 94710, USA
6. Acknowledgements
The author extends thanks to several of the authors of the tools discussed in this paper and others for providing feedback that effected several changes in the first couple drafts of this paper. This includes but, is not limited to the following: Ed DeHart (CERT), Jim Ellis (CERT), David and Michelle Koblas (SOCKS), Herve Schauer (Gatekeeper), Dan Farmer (COPS), D. Brent Chapman (firewalls@greatcircle.com), and Matt Bishop (Editor).
7. References
[1] S. Carl-Mitchell and John S. Quarterman, Building Internet
Firewalls. UnixWorld; February, 1992; pp 93-102.
[2] Wietse Venema. TCP Wrapper: Network Monitoring, Access
Control and Booby Traps. USENIX Proceedings, UNIX Security
Symposium III; September 1992.
[3] David and Michelle Koblas. SOCKS. USENIX Proceedings, UNIX
Security Symposium III; September 1992.
[4] William LeFebvre. Restricting Access to System Daemons Under
SunOS. USENIX Proceedings, UNIX Security Symposium III;
September 1992.
[5] D. Brent Chapman. Network (In)Security Through IP Packet
Filtering. USENIX Proceedings, UNIX Security Symposium III;
September 1992.
[6] Stephen E. Hansen and E. Todd Atkins. Centralized System
Monitoring with Swatch. USENIX Proceedings, UNIX Security
Symposium III; September 1992.
[7] J. David Thompson and Kate Arndt. A Secure Public Network
Access Mechanism. USENIX Proceedings, UNIX Security Symposium
III; September 1992.
[8] Herve Schauer. An Internet Gatekeeper. USENIX Proceedings,
UNIX Security Symposium III; September 1992.
[9] William Cheswick. The Design of a Secure Internet Gateway.
Murray Hill, NJ: AT&T Bell Laboratories.
[10] Garfinkel, Simson, and Gene Spafford. Firewall Machines.
Practical UNIX Security. Sabastopol, CA: O'Reilly and
Associates, Inc., 1991.
[11] Shabbir J. Safdar. Giving Customers the Tools to Protect
Themselves. USENIX Proceedings, UNIX Security Symposium III;
September 1992.
[12] John F. Haugh, II. Introduction to the Shadow Password Suite.
USENIX Proceedings, UNIX Security Symposium III; September
1992.
[13] Matt Bishop. Anatomy of a Proactive Password Checker. USENIX
Proceedings, UNIX Security Symposium III; September 1992.
[14] Bjorn Satdeva. Audit: A Policy Driven Security Checker for a
Heterogeneous Environment. USENIX Proceedings, UNIX Security
Symposium III; September 1992.
[15] Allan Heydon and J.D. Tygar. Specifying and Checking UNIX
Security Constraints. USENIX Proceedings, UNIX Security
Symposium III; September 1992.
[16] James M. Galvin and David M. Balenson. Security Aspects of a
UNIX PEM Implementation. USENIX Proceedings, UNIX Security
Symposium III; September 1992.
[17] Don Davis. Network Security Via Private-Key Certificates.
USENIX Proceedings, UNIX Security Symposium III; September
1992.
------------------------NOTICE---DISCLAIMER------------------------
The contents of this paper do not necessarily reflect the opinions of my employer or anyone else that I know. Nothing in this paper should be construed as a product endorsement. No warranty is expressed or implied. Any comments? Please send me e-mail. -------------------------------------------------------------------
------------------------NOTICE---COPYRIGHT-------------------------
(c) Copyright 1992,1993 Robert B. Reinhardt. This paper may be distributed freely as long as the paper is not modified in any way, includes this notice, and is provided without guarantee or warranty expressed or implied. E-mail comments to breinhar@access.digex.com -------------------------------------------------------------------
Reverse Engineering :Subscribe Now
Zts - ZTS
DISCLAIMER
and any such codes/snippets provided are to be executed on
your sole discretion. The author is not responsible for the codes.
Categories
- Amazing Links (2)
- Ebooks (2)
- Games (1)
- Hacking (49)
- Hardware (2)
- Networks-programs (12)
- virus (4)
- Web Info (4)
- Xp-Tricks (19)
Subscribe Now
Page Hits
| Provided by website design company directory. |
