Basic Unix security tutorial
I was going to put this into the tutorial section but since some of the post appears on main page and some not so I am putting it into the security section because it is also related to security of computers too.
This tutorial is for Unix newbies who want to learn about Unix security, and how to secure their computer.
First of all, I think that you are using Linux. Unix was first distributed freely and in open-source form.
First of all, you need to learn how the unix system works with different users. Here is a mini-tutorial that will explain what and how the Unix password file works.
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: I'll not tell how to crack the password file ]).
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.
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.
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.
Now I will tell 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.
man . "man" stands for manual. It 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.
Now before I go further more I will write a little bit about Linux runlevels.
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. 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.
Storage of password
The password file has some encrypted text within it. Let's talk about the encryption scheme first. 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 don't try it.
Now little about trojans
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 this is why you should beware of trojans. Be very careful with what you run.
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 search engines and searchifor 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,go to www.PGP.com
I am not advertising about them you can go to anyother (like I care) one if you will search you will find a lot of them.
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.
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.
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.
End of this chapter I will put another one about the Security web links about the unix. Awwh I am tired now.
Basic Unix security tutorial
I was going to put this into the tutorial section but since some of the post appears on main page and some not so I am putting it into the security section because it is also related to security of computers too.
This tutorial is for Unix newbies who want to learn about Unix security, and how to secure their computer.
First of all, I think that you are using Linux. Unix was first distributed freely and in open-source form.
First of all, you need to learn how the unix system works with different users. Here is a mini-tutorial that will explain what and how the Unix password file works.
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: I'll not tell how to crack the password file ]).
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.
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.
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.
Now I will tell 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.
man . "man" stands for manual. It 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.
Now before I go further more I will write a little bit about Linux runlevels.
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. 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.
Storage of password
The password file has some encrypted text within it. Let's talk about the encryption scheme first. 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 don't try it.
Now little about trojans
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 this is why you should beware of trojans. Be very careful with what you run.
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 search engines and searchifor 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,go to www.PGP.com
I am not advertising about them you can go to anyother (like I care) one if you will search you will find a lot of them.
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.
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.
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.
End of this chapter I will put another one about the Security web links about the unix. Awwh I am tired now.
