Computer/Network Security and how to approach it

From SusoSight

By Mark Krenz This was a document I wrote for a presentation on Computer and Network security for a Bloomington Linux Users Group meeting in January 2005. It was stored away in a file for years without much viewership. I wanted to go back and refer to it in 2013 so pulled it out and gave it its own page. According to my own header description. I wrote this all in one night and did a 2 hour presentation for 10 people at the BLUG meeting.

Keep in mind that this was written in 2005 and so the technical controls mentioned may be obsolete as well as some of the concepts, but I think that the ideas are still fairly solid. To give some context to this document, I had just finished a 7 year job at Kiva Networking, an ISP in Bloomington mostly doing system administration. I also had been running my web hosting company Suso for a while and had just turned it into a business.


Answer these questions:

  • Why is it so bad to use root as a normal account?
  • What does "smashing the stack mean"?
  • How do I setup a firewall?
  • How do hackers exploit security holes?
  • Why shouldn't I rely on DNS for authentication?

This is a presentation less about the details of securing a system and more about how to think about security. Think of it as the 40,000 foot overview of computer security.

  • I. What do we mean when we say "computer security" or "network security"?

In general computer security is meant to prevent three things: 

   - Data loss           |
   - Reputation loss     |   Each level affects the level below it.
   - Time loss          \|/

Data loss can be thought of as the unauthorized reading, writing, deleting or corrupting of any data whether it is on the disk, over the network or in volitile memory.

Reputation loss happens when perhaps a machine is broken into, but no data is affected. This is actually very rare as usually some data is affected when a breakin occurs. In any case, the reputation of the computer, services, administrator and company or network is affected.

At its most basic level, time loss happens during prevention as well as during recovery from an attack or disaster. Time loss can occur when the administrator needs to patch a piece of software to prevent security weaknesses up to losing time while needing to recover a machine from backup after it has been hacked and data was corrupted.

Each item implies that the item below it will or has happened.

So we must take efforts to reduce all three of these potential losses. Of course time loss happens during this process, but the amount of lost time in prevention is almost always less than that of recovery. 

 "An ounce of prevention is worth a pound of cure."

II. What tools do we have at our disposal on a computer to prevent data loss: Reading:

  • Social Engineering
  • Computer Hardware
  • Kernel controls
  • Filesystem
  • Permission scheme
  • Program access controls
  • Program code
  • Network firewall
  • Special network access controls or information
  • Encryption
  • Passwords

Writing: (includes deleting and corrupting)

  • Social Engineering
  • Computer Hardware
  • Kernel controls
  • Filesystem
  • Permission scheme
  • Program access controls
  • Program code
  • Network firewall
  • Special network access controls or information
  • Passwords
  • Backups

Again, these lists go in order of importance from top down. If any item fails, then all items below are at risk.

A. "Social Engineering" is the act of tricking someone into giving you access to something that you should not have access too. I can't emphasize this one enough, the security of a system is still only as strong as the will and intelligence of the people protecting and administrating it. How easy is it to get a key to your apartment, house or machine room? How easy is it to pretend that you are someone you are not? Such as a technician that needs to repair something.

B. The "Computer hardware" level refers to safeguards that computer automatically have built into them. This includes things like CPU protected memory and hard drive write lock or ECC RAM.

C. The "Kernel controls" level is just that. Any kind of control that the kernel has over what you as a user can do to the operating system. This includes such things as memory and device management and making sure that binary files are safe to execute and don't contain viruses.

The filesystem level is an extension of the kernel level. This is where you can be sure that data you write to disk is what you actually wrote and that when you read it back it is the same data. One pretection at this level is creating multiple superblocks and also keeping track of bad blocks on a hard disk. Software RAID is also at this level.

D. "Permission scheme" is part of the filesystem level but deserves special notice. Under Unix, the permission scheme of using users, groups and modes on files, directories and when programs run is a major part of the security of such a system.

E. "Program access controls" includes things such as Apache's allow and deny directives and a mail servers ability to stop open relaying of email. Some other examples:

  • Apache
    • allow/deny from X
    • DirectoryIndex ....
    • Options/AllowOverride
    • Limit GET POST OPTIONS PROPFIND
    • suexec
    • PHP safe_mode
  • Postfix (mail server)
    • seperate processes to deal with various stages of mail delivery.
    • mydestination
    • mynetworks
    • default_destination_concurrency_limit
    • message_size_limit
    • smtpd_recipient_restrictions
  • BIND (Dns server)
    • inet 127.0.0.1 allow { localhost; } keys { rndckey; };
    • allow-transfer (Not allowing zone transfers to the public)

F. "Program code" refers to the secureness of the program itself. Can it be easily tricked by passing extra parameters or bad data. Or can it cause problems by running it multiple times or too many times too quickly.

G. "Network firewall" is basically any method of using the kernel's networking stack to allow, foward, masquerade, log, deny or reject network connections either incoming or outgoing. This falls below "Program access controls" because all too often the firewall is either not loaded, misconfigured by default or too restrictive.

At this point we leave the group of controls that aren't based on a user having something to access a system. Unless you think of the last three items have owning an IP address or username, etc.

H. "Special network access controls or information" is called special because this is rather experimental. This includes stuff like "port knocking" and network access keys for Wifi, SSH keys, etc. THe information part of this represents things like reverse dns entries, identd lookup information, whois lookup information, PGP/GPG public keys.

I. "Encryption" - Strong encryption, while hard to break by brute force of weaknesses, still usually depends on something like a passphrase, password or certificate to gain access to the decryption methods. Weak encryption can simply be broken through brute force attacks.

J. "Passwords" - This level refers to any single signon access control that is used to access the system. Usually, this is the easiest way for a malicious person to access a system due to the simplicity and effectiveness of social engineering. Or the simplicity of people's passwords

K. "Backups" - Backups are usually thought of only as a way to archive or store information in case a disk fails. But they can be a very vulnerable and serious consideration of security. All someone needs is a tape drive. Most tape formats are unencrypted and as easy to read as installing a hard drive on your PC.

It is important to consider all of these levels when working towards a secure system.

III. Potential vulnerabilities and prevention

Now we will talk about the potential vulnerabilities of each item and how they can be prevented or reduced in risk.

A. "Social Engineering" - 99% of the time physical access to most machines means that someone can do anything they want to a machine: Turn it off, remove the hard drive and read it on another machine, etc. The only thing stopping most companies from losing everything to the vulnerabilities of social engineering is fear. Fear that the person that tries it is going to get caught. Its amazing that in a world of scam artists, its amazing it doesn't happen more often.

The best way to prevent this is to have a written, sensical and adhered to proceedure for physical access. For most people who have home computers, they will probably feel fine if their front door is locked when they leave. For more important systems such as a companies accounting system, using biometrics such as fingerprint or retinal scanners to access locked rooms is good security. I don't know how many companies have their billing department right up front in the lobby with all that is protecting them is a locked door or elevator.

What happens when someone leaves the elevator unlocked or tricks someone into access? "We're here to clean the building." claims someone in a uniform that was bought from Goodwill for $5. Yeah, clean the building all right.

B. "Computer Hardware" - If you have ever had bad ram cause compilation problems, you can get a taste of what hardware vulnerabilities are like. These can be the most visible or most invisible vulnerabilities you will find. When you visit a public computer lab, maybe the computer you are at has a keyboard logger hooked up to it. Usually there is nothing you can do about CPUs that don't handle memory allocation properly or make an incorrect calculation except avoid the computers that use them. Hard disks, magnetic tape and floppy disks can be erased when passed by a strong magnetic field. The so called "electro magnetic pulse" has the power to wipe out electrical security. It is usually quick expensive to prevent these types of vulnerabilities, but fortunately, they are rare enough that we can ignore them on most systems.

Physical access to the machine is also a major vulnerability at this level.

C. "Kernel controls" - The kernel's job in an OS is to manage hardware and software resources for the rest of the system. Whenever there is some flawed piece of logic in the kernel is exploited, it is possible to do nearly anything, circumventing every other access control you have on your system. Keeping up to date with the latest kernel upgrades and patches is the best thing you can do. Don't just blindly apply upgrades and patches either. If there is no immediate threat, read more about other people who have applied the upgrade to make sure there are no adverse effects. On systems with shared access such as a public accessable shell server, you can help limit the scope of vulnerabilities by compiling the kernel without module support. This prevents the potential for loadable malicious code from being used to change the way the kernel functions.

You should try to completely understand any kernel feature that you have not used before or doesn't make immediate sense to you. It is possible that some features that seem on the surface to be harmless can actually do strange damaging things. One such feature that bit me in the butt once was "TCP Explicit Congestion Notification". Enabling this "feature" was preventing my mail server from communicating with mail servers that were behind Cisco PIX firewalls.


D. "Permision scheme" - The vulnerabilities in this level are usually the pain of every Un*x newbie and the frustration of every system admin. Often times I see users who are trying to let PHP (which runs as user Apache) write files to their directory, simply change the directory to mode 777 (world writeable). While functional, this opens up a range of new possibilities for attacks. What if the user's home directory can be entered by other users?

However, usually the problem with vulnerabilities in the un*x permission scheme is not the permissions of the files and directories themselves, but in how programs such as servers are run and what they have access too. This is where we answer our first question: 

 "Why is it so bad to use root as a normal account?"

Since root pretty much has access to everything, you have more than enough rope to hang yourself. You are opening yourself up to vulnerabilities that normally would not be possible on a normal account.

Let's say that you login to IRC using the BitchX program as user root. After people on the channel warn you that you shouldn't use IRC as root, someone decides to prove it to you by exploiting a hole(example) in the BitchX program code that doesn't handle really long message lines correctly. Once they have exploited this code, they execute the code for a shell and gain a root account on your machine.

Now they can do anything since BitchX is running as root.

If you had been running as your normal non-privileged user, the worst this person could have done is wipe out everything in your home directory.

Imagine now running your web browser as root and some website takes advantage of a known or unknown security exploit in Firefox, which allows them to automatically run a program on your computer simply by accessing their website. Remember that piece of code that you can put on your website that will eject the CD-ROM drive when using Internet Explorer?

It is a good idea to try to run server daemons that are open to the public as a non root user. In fact, you should try to run them as their own individual user that is only used for that system. Daemons like Apache, Bind, Postfix, Qmail, Innd, ircd usually do this. In fact, they usually programatically prevent you from running the process as root.


E. "Program access controls" - A lot of times program access controls have vulnerabilities that are related to some plugin or module. Under Apache, modules like mod_access, mod_index or mod_auth have had vulnerabilities that allowed an anonymous user from anywhere on the internet to exploit the Apache server and write data to the document root on the filesystem. The best way to protect yourself from these types of problems is again to keep up with the announced security vulnerabilities. Someone I used to work with said that you should subscribe to the mailing list for each piece of software you use.


Some programs are capable of functioning in a chroot environment. This is where a program is run with its root directory changed from the normal / base directory to something like /var/lib/named. This way, if someone does exploit a vulnerability, the malicious user will not be able to do anything outside of the chroot directory.

F. "Program code" - In software that you have not written, this is where all the exploits happen. I put it here to cover cases where you have written custom code without much thought to the security of the code itself.

In C there is a term called "smashing the stack". Most vulnerabilities are exploited through this method. It happens when the program written in C is forced to write beyond the end of an array that is declared auto in a routine. Most commonly, this can be done by passing an argument that is longer than the array is allocated for. For instance, IIS has a vulnerability where writing more than X bytes of data in the request string with some executeable program code at the end will allow you to execute an arbitrary command. There are automated programs out there that search for vulnerable versions of IIS. 

   See "Smashing The Stack For Fun And Profit"
   http://www.cs.ucsb.edu/~jzhou/security/overflow.html

In your own code you need to take the proper care to ensure that the data that you are being passed is safe for you to use. In any language. Make sure that any argument that is passed to your program has key characters like quotes and backslashes escaped so that they lose their special meaning.

"Security by obscurity is not security." Its only a matter of time till someone figures out how to hack your software.

G. "Network firewall" -- Usually firewalls themselves are not vulnerable to attacks, but they can be. What I want to talk about instead in this section is how you have your firewall setup. 


   ........

H. "Special network access controls or information" -- The big vulnerability here is in trusting information from DNS servers, whois servers or the like. If the information did not come from one of your machines, you should be cautious about trusting it. DNS infomation can be spoofed.

I. "Encryption"

Imagine if you will a network. 10 machines hooked up to a hub. One machine is running a network sniffing program, while another user on a different machine simply tries to login to their ftp account.

For the purpose of this demonstration, I have set my password for user mark to f3lld0wn!

[play video]

Encryption on an open network is very important. At any point from A to B on the internet there could be someone listening to the network traffic.

J. "Passwords"

Use MD5 passwords for now. Eventually, you will want to use a stronger encryption. Run john the ripper on your shadow file every once in a while to check for easily cracked passwords.

K. "Backups" -- Store your backups in a fireproof safe and in multiple geographical locations if possible. Onsite and also in a back safety deposit box is good. Check the security of the bank. Some backs have really lax rules on access to safety deposit boxes (again, social engineering vulnerabilities are present).

Also, lay backup tapes so that the tape inside the cartridge is perpendicular to the ground. There has been some scientific studies to show that laying tapes like this will increase their expected lifetime because they will not be hanging all their weight on the spindle.

Retrieved from "http://suso.suso.org/x/index.php?title=Computer/Network_Security_and_how_to_approach_it&oldid=8560"