|
Basic
Local/Remote Unix Security
<--! Begin disclaimer !-->
Yada yada yada... you know the drill. I did not write this
tutorial for people to learn "how to hack" and crack into and
possibly damage other machines. It is solely intended to teach the
reader a lesson about Unix security. Also, I am not responsible to
any damage caused by using any of the techniques explained in this
guide.
<--! End disclaimer !-->
Changes in version 1.2:
Added a new appendix called 'Non-Standard Loggers'.
Changes in version 1.1:
Added a new appendix called 'Security Checklists'.
Introduction
This guide is meant for Unix newbies who want to learn a
little about basic Unix security, and how to secure their box. Most
systems come very very insecure out-of-the-box. What is
out-of-the-box (let's call it OOTB from now on), you ask? An OOTB
system is a system which was just installed. All the default
configurations are turned on, which means zero personalization
(besides maybe a little personalization made during the installation
process) and quite a lot possible security problems. Also, there are
some very basic concepts that most newbie Unix users aren't familiar
with.
During this tutorial, I will teach you how to change
default configurations, basic packet filtering, how to secure your
system's networking services (or completely remove them or some of
them, in case you don't need them, in order to increate your
computer's security), how to use, how to avoid trojans, what are
sniffers, how to maintain local security between different users in
your system (if you're not the only one using this system, whether
it's locally or remotely), some stuff about SSH, how to protect
yourself against computer viruses under the Unix system, what are
security scanners and how to use them, why you should encrypt your
important data and how etc'.
Now, it is advised to go through Black Sun's previous
tutorials (see blacksun.box.sk) prior to reading this tutorial. They
contain some basic concepts and terminology which you need to know
and you're might not familiar with. Also, you should have some basic
Unix knowledge and experience. If you don't have that kind of
knowledge yet, we advise you to go to the local computer store and
buy a basic Unix book (it shouldn't cost too much), or, if you
really want to, order a specific one from the Internet (or even
better: go to blacksun.box.sk/books.html and order a book from
there. We get 15% of the money you pay... :-) This doesn't mean that
you pay more, though. We simply get 15% out of the money you pay).
Don't worry about online ordering, it's completely secure as long as
you order your books from Amazon.com (they're considered the most
secure E-Store on the planet, and I order lots of books from there).
Oh, one last note: this tutorial is in no way a complete
one (Duh! It's a BASIC tutorial, in case you havn't read the title).
I included everything I could possibly think of (that is notable for
a beginners guide in this field, of course). With time, I will add
more chapters, so make sure you have the latest version by visiting
blacksun.box.sk often or subscribing to Black Sun's mailing list
(info on how to subscribe at blacksun.box.sk also).
Okay, heads up! Here we go!
Setting The
Ground
First of all, I assume that you are using either RedHat
Linux or Mandrake Linux. Why is that? Because most Unix newbies use
either of these two distributions. Don't worry, it's no crime to use
them or something, and it's not "lame". Each distribution has it's
advantages. RedHat and Mandrake, for example, both have simple
installation and come with a lot of utilities built-in. That's okay,
although I like Slackware Linux and OpenBSD better (I'll explain why
in a second).
Now, some of you might be asking right now "but... but I
have a different distribution! Will this stuff work for me too?".
Before I answer this question (to the impatient ones of you, I can
already say "yes", but that's not the exact answer. Read on and
you'll understand), I want to explain what is a distribution
(otherwise known as a "distro" or a "flavor" of Unix), why there are
so many of them, where you could learn about all the different
distributions and how to choose the right distribution for you.
Unix was first distributed freely and in open-source form.
If you're not familiar with any programming language, then you're
not familiar with the term "source code". I'll explain.
The simplest way to show you what source code is is to send
you to a webpage. Take hackernews.com (a personal favorite) for
example. Every common browser has an option to view the page's
source from within the browser, but let's pretend you don't know how
to do this or you don't even have this option within your browser.
First, wait for the whole page to load. Then, save it to your hard
drive, a diskette or whatever. Then, open the HTML page you've just
saved with any text editor (Pico, KEdit, Emacs, Notepad, UltraEdit,
whatever).
Now what do you see? No more text and graphics and colors
and layout, but plain good instructions. These are HTML
instructions. HTML stands for Hyper Text Marquee Language, and it is
the language used to create HTML pages, which can be read by your
browser and used as instructions for how to build and display the
web page.
The same goes with programming. To create a program, you
need to know some sort fo a programming language (C, for example),
and then construct the program using commands which will later be
given to a compiler (which will turn the source code file into an
executable binary file, or in other words, a program which you can
run and play around with) or an interpreter (the program runs as
source code, and gets executed by a program called an interpreter,
which reads the instructions in the source code and performs them. A
popular interpreted programming language is Perl. Interpreted
programming languages usually run slower, but have their advantages.
We won't go into that now, though).
Okay, moving on. So now you know what source code is. As
I've already explained, Unix was initially distributed freely and in
source code form. This means that ANYONE with the right knowledge
and skills can create his own version of Unix, to meet his special
needs. A different version of Unix is called a distribution, a
"distro" or a "flavor".
Now go to www.linuxberg.com. Pick the closest mirror site
and then enter the distributions page. It will display a list of
Unix distributions, each one with it's own characteristics,
advantages and disadvantages. This is all nice, but what happens if
people start creating versions of Unix without paying attention to
compatibility issues? For example, if I would have created my own
version of Unix and called ls (the command that lists all files in
the current directory in console mode (text-based interface) or in a
virtual console (a console within a graphical window)) "list"
instead? This means that if someone would have made a program that
called the ls command for some purpose, it wouldn't work anymore
(unless I create a command called ls that calls my own command -
list. But in that case, I have to make sure that list has similar
rules to ls). See the problem?
Also, if I go to my friend's house, which could be using a
different distribution, how could I possibly use his computer if
everything is completely different?
This is why there are standards. Every Unix distribution
has to meet these standards so it will be compatible with other
versions. This is also why most (if not all) of the stuff I am about
to teach here will work in all distributions. If you have a certain
problem or question, ask in our message board (find it at
blacksun.box.sk).
Oh, almost forgot... in the beginning of this section, I
have clearly stated that I like Slackware Linux and OpenBSD more
than RedHat Linux and Mandrake Linux. Why is that? Simply because
they have some advantages, such as even mroe stability, security,
speed and encryption, and they top all the other distributions in
these fields. Of course, they are much harder to work with (have you
ever tried to install OpenBSD?! To a person who installed Mandrake
Linux, which is the easiest to install, and is almost as easy as
installing Windows 95, it would look like hell!!).
Okay, let's move on to the actual security information,
shall we?
First Thing's
First: Local Security
First of all, let's think: why would you want to improve
your computer's local security? Well, if you're the only one using
this computer, and you don't intend to let anyone into your computer
(at least not intentionally), then you should only read this chapter
for pure knowledge. But if you're running a multi-users system, you
definetly should improve your local security.
What is local security? Well, better local security means
that different users on this computer, whether they are local users
(they have local access to the computer. They use a keyboard, a
monitor and what-not that are directly connected to the actual box,
not through some sort of a local area network (LAN) or the Internet)
or remote users (users accessing your computer, whether legally or
not, using Telnet, SSH, RLogin etc' and through a local network or
the Internet), you need to increate your computer's local security.
Let's start with a basic lesson about file permissions.
Unix File
Permissions And The Password File
First of all, you need to learn about the way the system
works with different users. Here is a mini-tutorial out of the Byte
Me page at my website that will explain what and how the Unix
password file works, thus explain to you a little more about this
subject.
Password files == world readable + how do password files
look like?
First of all, a file that is world readable is a file that
can be read by ANYONE on the system, even the most inferior user. On
most systems today, the password file (usually /etc/passwd) is world
readable. Does this mean ANYONE can get the encrypted passwords and
decrypt them? Definetly not! A password file consists of several (or
one) lines, when each line represents a user.
The password file looks like this:
username:password:uid:gid:free text:home directory:shell
Username - the user's username.
Password - the user's password, encrypted using altered DES
encryption (can be cracked in a matter of time, though [note: we'll
get to cracking the password file later]). UID - User ID. If your
UID is 0, you have root priviledges (nothing can stop you, and you
can even type "su username" (without the quotes) to become a
different user. Type exit to return to your root shell after you're
done. Btw SU stands for Switch User). If two users have the same
UID, they'll have identical permissions.
GID - Group ID. The same as UID, with root being GID=0. GID
let's you set ownership patterns and access patterns for a group of
users (or a single user) who have different or identical UIDs but
have the same GID. Free text - some free text about the user. For
info on how to exploit this field in order to get private
information about people, read the Info Gathering tutorial here.
Home directory - where the user's private configurations files are
stored. Usually /root if you are root, or /usr/your-username or
/home/your-username if you're another user. Shell - the program that
gets executed once you log in. Usually a command interpreter (a
program that receives commands from you and executes them).
Now, most systems will make /etc/passwd world-readable, but
don't put the passwords in it. Instead, they will put a single
character, such as *. The passwords will be stored at the shadow
file, which is not world-readable, and is usually stored at
/etc/shadow. The shadow file is identical to the /etc/passwd file,
only it has the encrypted passwords. Some shadowing programs can
also improve the encryption schemes, but that's not important to us
right now.
The /etc/passwd has to be world readable if you want to:
Find out what's the username of a certain UID. Very useful
in some situations. For example: each file has an owner. The owner
can change access patterns for this file, or change it's ownership.
Root can own all files if he/she wants to. The owner's UID is
inserted into the file. Programs such as ls (ls stands for list. It
views the contents of a directory. For more info about it and it's
uses, type "man ls" without the quotes on a Unix system) can tell
you who owns a file. If they don't have access to the password file
(programs run with your priviledges, unless they are SUID, in which
case they run with the priviledges of the user who SUIDed them.
People try not to use SUID, because it poses lots of security
threats), they will only be able to present you with the UID of the
owner. But if they have access to the password file, they can find
the appropriate username for this UID.
Find out information about people (what's their home
directory, what's their shell, what's written in their free text
area etc').
Etc' etc' etc'... be creative!
EOF
In case you're wondering, EOF stands for End Of File. This
means that... well, duh! End of file! That's it, you've just
finished that nice little mini-tutorial. Now I assume you want to
learn how to change file permissions.
So, in order to change file permissions, you need to learn
how to use the chmod command. Now, I am about to guide you on the
process of finding information about Unix commands by yourself. It's
quite easy.
Okay, let's try man first. Man stands for manual. Man is a
command that displays a manual page for a specified command. The
syntax is: max command. For example: man ls, man cd, man more etc'.
So let's try to type man chmod. AHA! No man entry for chmod... :-/
(some systems might have a man page for chmod)
Let's try using info. We type info chmod. AHA! This time,
we're getting something. So let's see... it says a little about the
chmod command, but it doesn't explain how to use it! Oh, wait, look
at this - there are links within this guide. Simply position your
cursor within a word, a couple of words or a sentence that link
somewhere else (they always have a * in front of them) and hit
enter. Keep following links until you learn about chmod and about
file permissions.
unlevels
I have decided to quote a nice mini-tutorial from the Byte
Me page at my website instead of just writing about runlevels all
over again (I don't like doing things twice).
What are Linux runlevels? If you've been paying attention
to what your Linux box does during startup, you should have noticed
that it says: "Entering runlevel x" (where x is a number between 1
and 5) at one point of the bootup stage (after it mounts your root
filesystem (your "/" directory) into read-write mode, sets up sound,
finds your kernel's module dependencies (never mind that for now)
etc'). A runlevel is a bootup/shutdown sequence. It consists of a
list of commands to run on startup and a list of commands to run on
shutdown (or when switching to different runlevels).
Now, first of all, let's see how you can switch runlevels.
Bah, that's easy. Simply type init x, where x is a number between 0
and 6. Runlevel 0 is for "halt" (turning off your computer, if you
have APM -Advanced Power Management, and if you have APMD - APM
Daemon, installed. All modern CPUs have APM), runlevel 6 is for
reboot and the rest are various runlevels. 5 will bootup everything
- it will even automatically run X (by default, of course. You can
change this). Runlevel 1 is considered the single-mode runlevel. It
does the least possible (kinda like "safe mode" in Windows) and
doesn't even require you to enter a password (but only root can
switch runlevels, so you have to be either root or have physical
access to the computer during startup (we'll get to that later)).
Editing your runlevels list is different with every
different distribution. Usually it would go like this:
a) Go to /etc/rc.d/rcx.d/ (where x is the runlevel's
number) and play around within this directory. It contains symbolic
links (kinda like shortcuts in Windows. For more information about
symbolic links (otherwise known as "symlinks"), type man ln) to
programs (including their parameters) that will be executed, and
symbolic links to programs that will be killed on shutdown. Play
around to find out more (but ALWAYS make backups!!).
You can also try this:
b) (this should work on most Linux boxes) Switch to the
runlevel you want to edit. Then type setup. Go to system services,
and select/unselect the services u want to run on startup and kill
on shutdown).
Or this:
c) The easiest way - on some distributions, such as RedHat,
you will be able to type the command control-panel within an xterm
(a "virtual terminal" - a console window within X-Windows) and get a
nice little window thingi with lots of buttons and suchlikes. Find
the button that says "runlevel editor" when you put the mouse above
it for a second or two. Then click on this button and play around
with the programs. I'm sure you'll figure out how to use it
yourself. It's quite self-explanitory, and it contains help files
and documentation if you really need help.
Anyway, you can always try running the command:
find / -name *rc* -print
If none of the three specified methods didn't work, so you
could see where your runlevel directories are and apply method a on
them.
And now, for a nice little runlevels-related hack.
Now, if you're reading this document, you're probably a
Linux newbie, so you probably use Redhat Linux, Mandrake Linux etc'.
If so, you should have a prompt saying "boot:" or "LILO boot:" or
"LILO:" when you start your computer, and you could either type
Windows or Linux (you can change these names into, say, sucky-OS for
Windows and Stable_and_secure_OS for Linux, or anything else you
want. Use the linuxconf program to edit LILO's preferences, and use
your imagination... :-) ). Now, what happens if you type linux 5? Of
course! It boots up Linux in runlevel 5!! But wait! What happens if
you type linux 1 or linux single? It runs on runlevel 1 - single
user mode, which means... automatic root access! No password needed.
:-)
Of course, you can change runlevel 1 by going to
/etc/rc.d/rc1.d and then removing the contents of this directory and
copying everything from another runlevel (replace the number in
rc1.d to any other runlevel number). Please read cp's manual page
and make sure you're copying symbolic links as links and not as
files.
Of course, anyway, if you have local access to a Unix box
(or any other box that I know of, as a matter of fact), you can boot
from a floppy (unless, of course, the first boot device is a hard
drive and the bios is password-protected, but these can be hacked
too. Refer to this guide).
EOF
Now, imagine that some evil cracker (e.g. your grandma...
:-) ) reads this document and then locally roots your computer
somehow (the verb 'to root' means 'to get root access to a computer,
not necessarily one that runs Unix'). Scary, huh? That was as easy
as stealing a candy from a baby (not that I've ever done that... /me
looks away... :-) ).
Cracking The
Password File
As you should already know by now, the password file has
some encrypted text within it. Let's discuss about the encryption
scheme first, shall we?
Unix password file encryption is based on an altered
version of DES encryption. If you will try to decode an encrypted
Unix password (let's call it a hash from now on. That's the proper
name for it) using standard DES decoding, you will get a null
string. Nothing. Nada. Zero. No, not even zero. You simply won't get
anything.
So how do you open this door? With a key. :-) Key-based
encryption (e.g. PGP, which stands for Pretty Good Privacy, and has
very powerful encryption schemes) is an encryption scheme where you
need to have a key, which is a set of letters (lowercase or
uppercase), numbers, symbols etc' (it could be just numbers, symbols
and lowercase letters, all letters, etc').
So in Unix "crypt" (from now on, crypt means Unix password
file encryption), the key is actually the first eight characters of
the user's password (you can add extra characters to the key, which
can be generated randomly, for extra security. These are called
salts. I won't explain much about them here because I don't believe
I know enough about them to do so), so you need the user's password
to decode the hash (but if you have the user's password, why would
you want to decode his hash if you already have the password? :-) ).
So, crypted passwords cannot be cracked, right? WRONG! You
can use a password cracker such as John the Ripper or Cracker Jack
(there are both Unix versions and Windows versions. Sorry, I don't
have URLs to download them) to crack the hashes. But how do these
things work?
A password cracker generates random passwords and then
tries to break the hash by using this password as the key. If it
fails, it simply tries another password until it gets it right.
Password crackers can try thousands of passwords per second on
modern computers.
there are two methods of password cracking - brute-force
and dictionary attacks. In brute-force mode, your password cracker
guesses passwords systematically. You can set a minimum amount of
characters for the password, and tell your cracker what to create
the password out of (lowercase letters, uppercase letters, numbers,
symbols etc'). In dictionary attacks, your password cracker takes
words out of a simple text file called a 'dictionary file'. Each
line in this file represents a single word for the password cracker
to try.
Dictionary files usually have an advantage over brute-force
attacks, because if you know that the target's password has
something to do with dogs, you could download a dictionary file
about dogs. If you know it's the name of some philosopher, you could
download a dictionary file containing the names of all known
philosophers. You can also download all-purpose dictionaries that
contain various words (these usually have the greatest chance to
succeed). The best place to download wordlists from is theargon.com.
So, as you can see, if someone obtains your hashes somehow,
he could decode them and break into your computer. This is why all
users on your system should have a long password, and preferably not
a dictionary word.
If you need help with using a password cracker or have any
further questions, try asking them on the message board at
blacksun.box.sk (it's ours, btw... :-) ).
Trojans
Yes, trojans. Most people who read this might be thinking
about Netbus, Back Orifice, Sub7 and other Windows trojans. These
aren't trojans. Okay, I mean, they ARE trojans, but not this kind of
trojans. They are 'remote administration trojans'. First, let's
understand what this name means, and then you'll see what they have
to do with Unix in general and with local
security in particular (as well as remote security). Let's
start with the word trojan:
Trpjan - In the Greek mithology, There is a story about the
'trojan horse'. The Greek were trying to capture the city of Troy
for a reason which is beyond this guide (you should really read the
whole story or get the movie or something. It is quite good). They
were camping on the outsides of Troy for about ten years and they
still didn't manage to get in. Then, they came up with a brilliant
plan: the whole army pretended to be leaving the area, and they left
a giant wooden horse for the Trojans as some kind of a present (to
honor the Trojans for being so good). Within this horse sat a couple
of soldiers. When the Trojans found the giant horse, they carried it
inside and then, under the cover of night, the soldiers inside it
came out, opened the city's gates and let the entire Greek army get
in, which eventually lead to the fall of the city of Troy.
So, as you see, a trojan program is a program that does not
do what it proclaims to be doing. It could either be a harmless joke
(a joke program that pretends to delete your entire hard drive or
any other kinds of computer joke programs) or a malicious program
which could harm your system.
Remote administration - To remotely administer a system
means to be able to work on this system as if you had local
("physical") access to it. Being able to remotely access your system
(or "to remotely login to it") is useful for getting files off your
system, working on your system from a distant place etc'.
Remote administration trojan - A trojan program that let's
the author of the program, the person who sent you the program or
any other person in the world access your computer and remotely
administer it (this is why Remote Administration Trojans, or RATs,
are often called remote administration "backdoors" - they open a
"back door" for the attacker to get in). This is exactly like
depositing your entire system and evertyhing on it to the hands of
the attacker.
The most dangerous thing about RATs would probably be that
most of them (especially Netbus and Sub7) are extremely easy to use
and understand, and come with one or two pages of instructions (yes,
they're THAT simple), so any little kid can use them. Most of these
"kids" have no idea what this program or other programs that do most
of the work for them do, which lead to the nickname "script kiddies"
- "lamers" (a lamer is a person who acts immaturely or stupidly)
with programs that do all of the work for them. Technically, a
script kiddie can crack into the Pentagon if he is given a program
that does everything for him. But does he know how this whole thing
works? Will he know what to do once he's in? I doubt it.
Now, malicious trojan programs can do a lot more than that.
There are also trojans that allow the attacker to have local access
to any user who runs the program (if root runs it, the whole system
is doomed. This is one of the reasons why no sensible system
administrator would work as root all the time, and instead make
himself a less-priviledged account to work with). This is useful if
the attacker has an account on this system and wants to get access
to some other user's files (or even root access, which means access
to practically everything).
Also, if you gain write access to a commonly-used
application (such as su, which let's you run a sub-shell as another
user by simply giving his password instead of having to relogin. SU
stands for Switch User. Oh, by the way, root doesn't need to supply
a password to su if he wants to gain access to some other person's
account), you can trojan these applications. Let's take su for
example - if you manage to change su so it'll send you every
username and password which it received, you could eventually
capture your target's password or even root's password.
So, kids, this is why you should beware of trojans. Be very
careful with what you run. Also, there are programs called checksum
checkers. These programs perform periodical tests (once a day, once
an hour, once a week etc, depending on how you configure them) that
determine if the size of some applications (you can descelect
default applications to test or add new applications by yourself)
has changed. If someone has trojaned one of those applications, it's
size should change, but it is also possible (although much harder)
to trojan a program without affecting it's size, but that's out of
the topic of this guide.
Unix Viruses
The computer virus problem is much less harsh under the
Unix platform, but if you want to keep your data intact, you should
be aware of the problem, which still exists.
There is an incredibly small number of viruses in the wild
for the Unix operating system (a virus that is "in the wild" is a
virus that has gone through a network of any kind and started
infecting computers on this network, just like a biological virus,
when it escapes a restricted laboratory environment and goes into
"the wild" and starts infecting people). This is because virus
writers are less motivated to write viruses for Unix, because of the
following reasons:
A) Most people who use Unix are more mature than other
computer users. Virus creators who intend to infect other computers
are immature people.
B) Because of access restrictions in the Unix operating
system, if a user runs a file that is infected with a virus, the
virus can't go far, and it can only do what this user has
priviledges to do (although, if a root-priviledged user runs a
virus, it can infect the whole system and freely travel to other
systems). So, because there are files that some users can access and
some other users can't, Unix viruses can't spread far.
Still, the problem exists, and we want to protect our data,
right? This is why you should still get yourself a Unix virus
scanner. Because of the extreme lack of viruses in the Unix system,
there are no "big titles" of virus scanners. Try going to
altavista.com and searching for Unix virus scanners. Download some
different ones and compare the quality of their scans and the amount
of resources they consume.
Encryption
Encrypt your important files. Use PGP for better
encryption.
If someone penetrates your computer's security, it will be
much much harder for him to get your important data if you encrypt
it.
For more information about encryption, read Black Sun's
encryption tutorials at blacksun.box.sk (go to the tutorials page
and then find the encryption section. We have some guides for
beginners about PGP and encryption in general).
Remote
Security
Why would you want to improve your computer's remote
security? DUH! If you ever plan to hook your computer into a LAN,
the Internet or any other kind of network, you immediately increase
the chance of you getting hacked. You should definetly attend to
your remote security (unless you like getting your ass
rooted).
Also, you should read the local security part first, since
it contains a lot of information you need to know before you read
this, and also quite a few tricks that work for both local security
and remote security.
Remote Root
Logins
Before I explain to you what is the issue with remote root
logins and how to block them, I need to explain to you what a TTY is
first.
Unix is a multi-users system, right? And on multi-users
systems, many users, each one with his own monitor or any other type
of terminal, can work on the same computer, right?
Now, this computer is obviously running more than one
process (a process is a running program), since it has multiple
users on it. Each process receives some input and sends out some
output. Well, then, how will this computer know which input is
whom's and where to direct the output of each program? You wouldn't
want to receive the output of processes that other users are
running, right? (well, technically, if you're a malicious cracker,
you'd love to receive the output of other users' processes, but
we're getting off-topic now).
This is why each user has a TTY. TTY stands for Terminal
TYpe. Each user has it's own TTY, which can be composed of letters
and numbers. That way, the computer knows where the input comes from
(from which TTY) and where to direct the output to.
Okay, first, let's make an experiment. Run a text-based
console of an XTerm window (a console window from within X-Windows,
the popular Graphical User Interface, or GUI, of Unix systems) and
type the command who. This will show who is logged into the system
(his username), when he logged in and what is his TTY. By the way,
if you prefer a graphical version of the who command, try typing gw
within an XTerm or within a "run command" box in X. This program
should come with the gnome window manager.
Okay, let's move on. Now, that we know what TTYs are, let's
edit the file /etc/securetty with a simple text editor. Now, what do
we have here? We have a list of all TTYs that can log in as a
root-priviledged user. My /etc/securetty file looks like this:
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
Okay, let me explain myself. Your computer should have
eight virtual consoles. You can switch virtual consoles by pressing
ctrl+alt+F1 for console #1, ctrl+alt+F2 for console #2 etc'. You can
imagine how useful this could be.
Consoles #7 and #8 are usually reserved for graphical
displays, so if you run X, it should appear in #7, and if you run
another X process, it should appear in #8.
These eight local consoles have these TTYs: tty1 for #1,
tty2 for #2 etc'. Now, as you can see, my /etc/securetty file
contains only those local TTYs, so no remote user can login as a
root-priviledged user into my computer, even if he has all the
usernames and the passwords.
Now, of course, if someone has all the passwords, he could
log in as another user and then use su to switch to root. So the
/etc/securetty thing isn't exactly some fail-proof method, but it'll
block off some intruders.
Watching Your
Processes
If you intend to have several users logged into your
system, you should really watch for what they're running, and how
much system resources they're hogging.
Here are a few methods to watch your users:
Using PS
Type in the command ps -aux. Quite a list, huh? Now, if you
want it to be more readable, try doing ps -aux | more or directing
it's output into a file, like this: ps -aux > some-file-name. If you
want to look for specific entries within this list, try doing ps
-aux | grep some-text and it'll display lines within the output of
ps -aux that contain some-text (or whatever you type in).
Oh, by the way, as far as I know, PS stands for ProcesseS.
Using Top
Type the command top. Cool program, huh? Quite useful...
you should have a whole virtual console or a whole XTerm devoted
exclusively for it.
If you prefer a graphical display, try typing gtop (a
graphical version of top that comes with the gnome window manager)
or kpm (stands for KDE Process Manager. Comes with the KDE window
manager).
Eavasdropping
If you're a root-priviledged user and you want to see what
the other users on your system are typing, consider using a command
called TTY Watch. It will eavasdrop on the TTY of the user(s) you
choose to eavasdrop on, and let you know exactly what they're typing
and exactly what they see on their monitors.
Try searching for the latest version of ttywatch at Packet
Storm Security (packetstorm.securify.com), Security Focus
(securityfocus.com), Linux.Box (linux.box.sk), Astalavista
(astalavista.box.sk) etc'.
Playing With
INetD
First of all, you need to learn what network daemons are
and what INetD is.
A daemon is a program similar to TSR programs on Microsoft
platforms. TSR stands for Terminate and Stay Resident. TSRs locate
themselves on your computer's memory, and then stay silent and watch
everything. Once certain credentials are met, the program awakes and
does something. For example: when your free disk space reaches less
than, say, 200MBs, the program alerts you.
A daemon is the Unix equivelant of Microsoft's TSRs (well,
actually, Unix and it's daemons were around waaaaaaaaay before
Microsoft DOS and later Microsoft Windows started selling). So what
is a network daemon? Well, obviously, it's a daemon that watches for
certain credentials that have something to do with networks. Here
are several examples:
Example #1: The telnet daemon. Usually listens for incoming
connections on port 23, and then, once this credential is met, it
displays a login screen to the second party. Once the second party
enters the correct combination of a username and a password, it is
given a shell environment, where it can interact with your computer
and run commands on it.
Example #2: The FTP daemon. FTP stands for File Transfer
Protocol, and makes it easier for different computers to exchange
computer files. More info on my FTP security for extreme newbies
tutorial (blacksun.box.sk/ftp.txt).
Example #3: A firewall is also a network daemon. Firewalls
are programs that filter incoming and outgoing network packets. They
awake once a network event occurs, and decide whether to allow or
disallow it.
Now, let's think. Suppose you have twelve different network
daemons on your system. That would take up too much memory for us,
right? Then why not just have a single daemon to do all the ditry
work for us and consume less memory? This is where INetD comes into
the picture.
INetD stands for InterNet Daemon. You can configure inetd
by editing /etc/inetd.conf (conf stands for configurations). This
file should contain instructions on how to edit it.
Updating Your
Network Daemons
You've just got the latest version of your favorite Unix
distribution. It came with an FTP daemon, which you want to run on
your system so you could turn it into an FTP server. But then,
someone discovers a hole within this FTP daemon, and a new version
with a fix for this problem goes out. You don't wanna get caught
with your pants down, running an old and buggy FTP daemon, right?
Hell, you could get cracked by some script kiddie and lose your
entire hard drive! We don't want THAT to happen, now do we?
First of all, you need to know when a new hole is
discovered. You should watch packetstorm.securify.com on a daily
basic, and also subscribe to the BugTraq mailing list
(securityfocus.com). You should also look for mailing lists
concerning the network daemons (also referred to as network
services) you are using.
Then, once there are new versions of the network daemons
you use, you should download the latest version and update the files
on your system.
Network
Sniffers
For an excellent paper on network sniffers (what are they,
how can they risk your computer's security and how to fight against
them), read this excellent paper: blacksun.box.sk/sniffer.txt.
DO NOT Use
Telnetd!
DO NOT run the telnet daemon on your system! If you want
people to be able to remotely login to your system and run commands
on your system, DO NOT use telnet for this purpose.
Instead, you should use SSH (SSH stands for Secure SHell).
SSH encrypts your sessions, so it'll be harder for intruders to
eavasdrop you and/or capture any passwords you enter.
Of course, you have to use a special client for SSH, since
SSH is very different than telnet, because of the following reasons:
A) SSH encrypts your sessions. Telnet merely creates
plain-text TCP sessions. B) SSH runs on port 22 by default, while
telnet stays on port 23. Although almost every telnet application in
existence allows you to create telnet sessions with any remote host
and port specified, some telnet applications still use port 23.
Anyway, ALL telnet applications have port 23 as their default, so if
you type telnet some-host or telnet some-ip, it'll telnet to that
host/IP and into port 23.
Get sshd and ssh clients at packetstorm.securify.com,
securityfocus.com, linux.box.sk, astalavista.box.sk etc'.
Basic Packet
Filtering
First, find these two files: /etc/hosts.allow and
/etc/hosts.deny. These two files can be used to form a basic packet
filtering system. Let's start with /etc/hosts.deny first.
Each line in this file should look like this: host:service
Host - a hostname or an IP. You can also use wildcards. For
example: *.aol.com would stand for every host that has a hostname
that ends with aol.com.
Service - what network service(s) do you want to allow/deny
to this host? Services are defined by their port number. You can
also put ALL instead to block of EVERY well-known port to this host
(a well-known port is any port between 0 and 1024. These ports are
called well-known ports because each one has a default network
service associated with it. For example: port 23 is the default for
telnet, port 21 is the default for FTP, port 25 is the default for
Sendmail, port 110 is the default for POP3 etc').
Each line within this file represents a combination of a
host and a port(s) that you don't want this host to be able to
access. This is called basic packet filtering.
Now, the /etc/hosts.allow file works exactly like
hosts.deny, only it contains hosts that you want to allow access to.
Here are a few examples of why you would need such a thing:
Example #1: You want to block every well-known port to AOL
users besides port 21, so they could access your FTP server. To do
this, you put *.aol.com:all in your hosts.deny file and then
*.aol.com:21 in your hosts.allow file. As you can see, hosts.allow
has a higher priority than hosts.deny.
Example #2: You want to block off AOL users from your FTP
server on port 21, besides foobar.aol.com, which is actually quite
nice and always has something interesting to contribute to your FTP
collection. To do this, you put *.aol.com:21 in hosts.deny and
foobar.aol.com:21 in your hosts.allow file.
Advanced
Packet Filtering
Yup... firewalls.
Firewalls are programs that watch everything that comes in
and out of your network or personal computer, and decide what to
allow and what to block. Out of their nature, firewalls need
root-priviledges to run (or admin priviledges on NT networks).
Firewalls usually come with a set of premade rules files.
Rules files are files with rules on what to allow and what to deny.
These rules files can block DoS attacks and relatively popular
methods of hacking. Also, most firewalls come with a 'learning mode'
option, which is a way of defining your rules as you go on (whenever
something comes in or out, you are asked to either allow or deny it,
and the firewall adapts itselfs to your preferences).
One of the best firewalls for Unix (and one of the best
firewall in the world) is IP Chains. Search for the latest version
at packetstorm.securify.com (search for ipchains, not ip-chains or
ip chains or anything. Otherwise, you probably won't find anything),
securityfocus.com or linux.box.sk.
For help using ipchains (ipchains isn't exactly the most
user-friendly firewall in existence), get some ipchains howtos (a
howto is a document on how to do something or how to use something),
which probably come with the ipchains package anyway, together with
the executables, the configurations
files etc'. These howtos should help you a lot. You should
also get a front-end for ipchains if you're a first-time user.
Some people will argue and claim that other packet
filtering firewalls, such as BSD's ipfilter, are better than
ipchains. However, I still consider ipchains as my firewall of
choice.
DoS Attacks
DoS stands for Denial of Service. DoS attacks deny access
to a certain service for a certain person. DoS attacks can crash
your computer, disconnect you, crash your web server programs, SMTP
server programs, POP3 server programs etc', disallow you access to
your Email account (a mailbomb (flooding someone with enormous
amounts of Emails. Usually done with some sort of a program which
automates this progress) is also considered a DoS attack (although
somewhat privitive) because it fills up your mailbox and denies you
access to it), block certain remote services and in general anything
you can think of that will deny you access to something.
To protect yourself against DoS attacks, I recommend
either:
a) Getting a good firewall (see previous section).
b) Subscribing to security mailing lists and checking
online databases
frequently to get the latest versions of everything and all
the latest patches.
Security
Scanners
Security scanners automatically test the security of a
network by attempting to crack into it in different popular ways. It
is advised to run one on your network or home PC (unless you don't
run any services on your system, which makes your system much less
vulnerable, in which case there is no need to be
so paranoid. Just avoid default configurations and read all
the rest of the sections and you're pretty much safe) to test it's
security, although just running one isn't enough to secure oneself
(follow the rest of the instructions in this text and read some
other texts and books. This text is in no way complete (ahem... the
name is BASIC Local/Remote Unix Security). Try some of the stuff at
blacksun.box.sk's books page).
In the next part, I will review some of the best scanners
available at the time this tutorial was written, although not in
much depth and detail, since I am limited in size and time.
The Scanners
Remote security scanners test the security of a remote
network or computer over a LAN (Local Area Network), a WAN (Wide
Area Network, such as the Internet) or any other kind of network.
SATAN
Author: Dan Farmer and Weitse Venema.
Language written in: C and Perl.
Platform built on: some version of Unix.
Requirements: Unix, Perl 5.001+, C, IP header files and
root access on the system you intend to run Satan from.
Satan stands for Security Administrator's Tool for
Analyzing Networks). It is the first security scanner that is
actually user-friendly. It is built as a website, where you can
choose attacks using simple forms, pulldown boxes, radio boxes and
check boxes, and it displays all the output in an easily-readable
form, ready for printing.
Satan also includes a short and easy-to-understand tutorial
on each attack, which makes it an excellent source for security
study for beginners. If you're interested in network security, it is
advised to get Satan and try running it on your computer and
scanning your friends (DO NOT scan systems you are not allowed to
scan! It is illegal!).
If you prefer the command-line approach, Satan can also be
run using a simple command-line-based interface.
Satan can be obtained from the following URL:
http://www.trouble.org/~zen/satan/satan.html
As far as I know, there are no Windows NT and Macintosh
versions of Satan, but I havn't checked for a long time now. I
expect that there should be a Windows NT version soon, if there
isn't one already.
If you're using any version of Linux, you must make several
modifications to run Satan on your system (the next part has been
copied from some website. I forgot the website's URL, but I'm not
going to credit these folks anyway, since I am sure they have stolen
this from some book... forgot the book's name, though...):
a) The file tcp_scan makes incompatible select() calls. To
fix this problem,
Nessus
Author: Renaud Deraison.
Language written in: C.
Platform built on: Linux.
Requirements: Linux (most non-Linux distributions will also
run it, though, since they all can emulate each other's programs),
C, X-Windows and GTK (the version of GTK you will need depends on
the version of Nessus you intend to run).
Nessu is another excellent remote security scanner. Has a
user-friendly graphical user interface and relatively fast scans.
Get Nessus from the following URL: http://www.nessus.org
IdentTCPScan
Author: Dave Goldsmith.
Language written in: C.
Platform built on: Unix.
Requirements: Unix, C, IP header files.
IdentTCPScan has a very useful ability: what it does is
that it portscans it's target (determines which ports are open on
the target host), tells you what service is probably running on this
port and tells you which user is running it by his UID.
This can reveal some interesting holes. For example: if it
discovers that some network or computer is running their web server
as UID 0 (remember? UID 0 = root access), this is a serious security
hole! If some malicious attacker exploits a hole in, say, one of the
CGIs on this website, he could access ANY file on the system, since
the web server runs as root, hence is not limited with access. Web
servers should run on users that have limited access (in this case,
the web server should only have access to the files contained in the
website and to it's own files, of course).
Unfortunately, I don't have an up-to-date URL. Try
searching packetstorm.securify.com or securityfocus.com.
Appendix A:
Security Checklists
Here are some URLs for "security checklists" - papers that
explain about various actions that need to be taken in order to
increase your box'ssecurity.
Unix Computer Security Checklist
Author: AUCERT
URL:
http://www.bive.unit.liu.se/security/AUSCERT_checklist1.1html
Generic Password Security Checklist
Author: Lindsay Winsor
URL:
http://delphi.colorado.edu/~security/users/access/goodprac.htm
CERT Coordination
Center Generic Security Information Checklist
Author: CERT
URL: http://ird.security.mci.net/check/cert-sec.html
TCP/IP Security Checklist
Author: Dale Drew
URL: http://ird.security.mci.net/check.html
Security Policy Checklist*
Author: Barbara Guttman and Robert Bagwill
URL: http://csrc.nist.gov/isptg/html/ISPTG-Contents.html
* Why would you want to establish a written security
policy? Because if you're running an office network or some other
kind of widely-used network and you plan to sue anyone who would
hurt or try to hurt the integrity of your network than a written and
published security policy would be the first thing you'll need in
order to sue.
Appendix B:
Using Different Loggers
Suppose your network or home PC have been compromised and
broken into. What's next? Surely you would like to sue the bastard,
or at least find out how exactly they got in. Or perhaps someone is
inside your system right now and you want to look for anything
suspicious.
For any of the two, you will need the kind of evidence
found in log files. But what if the attacker has erased all forms of
evidence of his mischevious acts (which is very probable)? Most
attackers will do that using automated log cleaners, which will
delete their presense from the log files. But what if you're using
something the attacker nor the creator of the log cleaner hasn't
been expecting? I'm talking about another logger, which the
automated tool will not detect and mess with. If you are using
another logger or a modified logger, it is most likely that script
kiddies won't notice it, and only real crackers will notice it and
get read of their presense in your logs. This will increase the
chance that you will get to keep your logs.
--------------------------------------------------------------------------------
That's about all for this time, folks. As I have already
stated in the introduction (actually, the next part was copied and
pasted from the introduction chapter): "I included everything I
could possibly think of (that is notable for a beginners guide in
this field, of course). With time, I will add more chapters, so make
sure you have the latest version by visiting blacksun.box.sk often
or subscribing to Black Sun's mailing list (info on how to subscribe
at blacksun.box.sk also)."
Oh, by the way, some of you might have been expecting me to
mention the r* services (rcp, rlogin, rsh etc'), which don't exactly
have perfect security. Well, I was thinking of writing a tutorial
completely devoted to them. If you're interested, you could go to
blacksun.box.sk right now and see if it's already done (if it's not,
most chances are that because there are other tutorials scheduled
ahead of it).
copyright bullshit
All copyrights are reserved. You may distribute this
tutorial freely, as long as you keep our names and Black Sun
Research Facility's URL at the top of this tutorial.
I have written this tutorial for you, the readers. But I
also wish to remain the author of this guide, meaning I do not want
people to change a line or two and then claim that the whole guide
is theirs. If you wish to create an altered version of this
tutorial, please contact me by Email - barakirs@netvision.net.il.
Credits
version 1.2, 5/3/2000
written by R A V E N
|