| Home -> Library -> Hardening -> Unix Home | |
| Documents about Unix hardening |
|
| Basic Local/Remote Unix Security | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Changes in version 1.2: Changes in version 1.1:
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!
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.
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 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 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.
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.
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: 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. 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.
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).
And now, for a nice little runlevels-related hack. 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... :-) ).
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... :-) ).
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 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.
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 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.
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).
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 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.
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 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.
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:
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.
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).
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'.
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.
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.
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 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'.
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.
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 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 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 To protect yourself against DoS attacks, I recommend either: a) Getting a good firewall (see previous section).
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 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.
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.
Author: Dan Farmer and Weitse Venema. 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...):
Author: Renaud Deraison. 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
Author: Dave Goldsmith. 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.
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 Generic Password Security Checklist CERT Coordination Center Generic Security Information Checklist TCP/IP Security Checklist Security Policy Checklist* * 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.
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.
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
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| copyright bullshit | |
|
|
|
| Credits | |
| version 1.2, 5/3/2000 written by R A V E N |
|