::::::::: :::::::: ::::::::: ::::::::::
:+: :+: :+: :+: :+: :+: :+:
+:+ +:+ +:+ +:+ +:+ +:+
+#++:++#+ +#++:++#++ +#++:++#: :#::+::#
+#+ +#+ +#+ +#+ +#+ +#+
#+# #+# #+# #+# #+# #+# #+#
######### ######## ### ### ###
http://blacksun.box.sk
_____________________________
______________________I Topic: I_____________________
\ I I /
\ HTML by: I Basic Local/Remote Unix I Written by: /
> I Security for Unix Newbies I <
/ Martin L. I_____________________________I R a v e n \
/___________________________>version 1.2, 5/3/2000<________________________\
|
<--! Begin 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.
<--! End copyright bullshit !-->
<--! 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:
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).
<--! Begin 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.
<--! End copyright bullshit !-->