Columbia CS HOWTO SECURE YOUR PC's NETWORK SERVICES
Quick Links
main page
CERT
PuTTY
Microsoft Security Alerts
Linux Security HOW-TO
Counterpane Newsletter
Password Storage
 
 
 
 


More Information :

This page provides interesting extra detail not presented on the main page. However, you may find this information useful if you have a strange use case, need more complete information, have trouble initially, or just want to learn more about the topic. The information includes:

  • descriptions of alternate technologies
  • extracts from and full man pages (where appropriate)
  • links to papers on the topic

Jump here for the topics covered in this set of pages.

TOPICS:

Each topic listed below has extra relevant information not found on the main page. It should assist you if something goes awry while following the directions on the main page. If it does not, it should still make an interesting read.

 


More Information on Passwords

Basic passwords are the essential basis of most security systems and software today. There are other stronger forms of authentication, and some alternative ways to store your many passwords so you do not forget them. Much research has shown how dangerous so-called 'weak' passwords are, and the remarkable number of weak passwords still chosen.

  • Stronger Authentication

    The authentication process is all about identifying a subject so you can trust them with certain privilages. So, alternate forms of authentication seek to identify a subject without using a traditional password. So-called "smart cards" extend the basic authentication process by adding something you have (the card) to who you are (username) and something you know (password). Other authentication methods involve biometric identification - fingerprints, voiceprints, face recognition. Bruce Schneier points out that biometric authentication schemes have a subtle flaw (besides including some amount of uncertainty) - if compromised, the authentication cannot be changed. This means that if someone stole your thumbprint (or thumb) thumbprint identification would no longer work for you, because it could not uniquely identify you. Finally, some encrypted challenge-response protocols attempt to authenticate both the client and server to each other (rather than the usual case of client to server).

  • Alternative Ways to Store Passwords (attempt at compromise)

    Users are often told to never write down their password, but to make it as convoluted as possible. It is next to impossible to immediately remember a good password. And usually, users become used to typing the password as a combination of keystrokes rather than any concious thought pattern to reproduce the password. Since good passwords are not easily remembered, it (contrary to popular advice) may be easy enough to write down your password and stick it in your wallet. You should definitly never stick it under the keyboard or on your monitor. The advantage of having it in your wallet is easily realized because wallets are seldom left unattended.

    A digital scheme similar to this "wallet-storage" method is to encrypt all your account names, passwords, and authentication tokens in some single database on your handheld device that can be examined with a single username and password pair. This is similar to the single sign on mechanism described below. Critics of this approach say that all your authentication mechanisms are then reduced to that single password. It's a tradeoff. Good luck choosing... (see http://www.zetetic.net/products.html for more information on such a system).

  • Single Sign On

    Since both research and practical experience indicate that having ordinary users remember many different account names and passwords interferes with their productivity, many organizations have gone through a major effort to implement single sign-on technology, whereby one system-wide username and password grant the user access to all the systems the user needs to access. Some application servers (e.g., Tomcat) also implement an optional single-sign on mechanism.

  • Research on Passwords

    Passwords are unequivocally the most pervasive authentication mechanism in use. The subject of password choosing and guessing has been the focus of a number of research projects. Most notably, in 1979, Morris and Thompson found that about 86% of the passwords they surveyed could be guessed in a week's worth of computer time. More recently, Klein (1990) found that 21% could be guessed in a week. Spafford (1992) found that the average length of a password was 6.8 characters and about 30% were all lowercase. These results indicate that passwords, as currently used, provide a very false sense of security. All an attacker needs is one account.

    The New Security Paradigms Workshop last year included several papers and studies that focused on current password trends and proposed new mechanisms for passwords. The website is here and you can find the papers in the conference journal at the ACM digital library (linked from this page).

 



SSH

SSH is a great tool and it is very easy to use. Many users are afraid that switching from telnet to SSH is a lengthy process involving creating cryptographic keys and requiring a lot of user input. It can be, but only if you want to get involved in that sort of thing. You can use SSH just like telnet (as described on the main page).

This is the start of the manual entry for the OpenSSH client on a RedHat 7.3 system:


NAME
     ssh - OpenSSH SSH client (remote login program)

SYNOPSIS
     ssh [-l login_name] hostname | user@hostname [command]

     ssh [-afgknqstvxACNPTX1246] [-b bind_address] [-c cipher_spec]
         [-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec]
         [-o option] [-p port] [-F configfile] [-L port:host:hostport] [-R
         port:host:hostport] [-D port] hostname | user@hostname [command]

DESCRIPTION
     ssh (SSH client) is a program for logging into a remote machine and for
     executing commands on a remote machine.  It is intended to replace rlogin
     and rsh, and provide secure encrypted communications between two
     untrusted hosts over an insecure network.  X11 connections and arbitrary
     TCP/IP ports can also be forwarded over the secure channel.

     ssh connects and logs into the specified hostname.  The user must prove
     his/her identity to the remote machine using one of several methods
     depending on the protocol version used... <snip/>


SFTP

The SFTP protocol and client are companion software to SSH. This is the start of the manual entry for the SFTP client on a RedHat 7.3 system:

NAME
     sftp - Secure file transfer program

SYNOPSIS
     sftp [-vC1] [-b batchfile] [-o ssh_option] [-s subsystem | sftp_server]
          [-B buffer_size] [-F ssh_config] [-P sftp_server path]
          [-R num_requests] [-S program] host
     sftp [[user@]host[:file [file]]]
     sftp [[user@]host[:dir[/]]]

DESCRIPTION
     sftp is an interactive file transfer program, similar to ftp(1), which
     performs all operations over an encrypted ssh(1) transport.  It may also
     use many features of ssh, such as public key authentication and compres-
     sion.  sftp connects and logs into the specified host, then enters an
     interactive command mode... <snip/>



E-mail Port Forwarding

As mentioned on the main page, this technique only encrypts the transfer of e-mail from your mail server to your client computer. It is mainly used to protect your password while talking to the mail server. But the cool thing about port forwarding is that it is useful for any number of applications, not just sending and receiving email.

A slightly shady use of port forwarding is to get traffic through an open hole in an organization's firewall. Depending on your intentions, this may be a good or bad thing.

Another use is to connect a web server like Apache with an application server like Tomcat. Apache and Tomcat communicate via 1 of 3 protocols (WARP, AJP12, AJP13/14). This means that you can have some Apache instances on a separate machine than your Tomcat instances and have them talk over the network, rather than local sockets on the machine. If you want to protect this channel, you can use port forwarding.



PGP

PGP is great for signing and encrypting email.



Webmail

Webmail is a nifty innovation when done right (encrypting traffic and passwords between the server and browser). However, as stated on the main page, there is nothing much you as a user can do to securely read your e-mail via webmail if the server is not set up for encryption. The easy alternative is to use port-forwarding as described on the main page.



Windows

Suggestions are welcome.



Linux

There are many things you can do to help make your default Linux distribution more secure. This advice is based on a RedHat Linux 7.3 system (kernel 2.4.18-4smp) system.

  • finding services

    You can find controls for services in two places. If you run a System V type init system, then

    	 /etc/rc.d/init.d/ 
    	 
    will hold a number of scripts that are run when the machine starts. Various directories hold links to the scripts in this directory that are executed (or not) based on what "run-level" the machine enters. The run-level directories are in
    	 /etc/rc.d/rcX.d
    	 
    where X represents the run-level number. The run-levels of primary concern are 3 and 5 (console mode and X11 mode). You can remove a link from these directories or execute based on your wishes. Remember that some services may depend on others. Know what you're doing before you fiddle here. There are many good references on this topic. Look at the documentation for your distribution.

    The other place to control services (most network services) is in

    	 /etc/xinetd.d/
    	 
    This directory has a number of configuration files for the xinetd wrappers that various network services run under. Configuration files are named after the service they wrap (e.g., the "finger" file is the configuration for the fingerd server. The finger file is shown here:
    # default: on
    # description: The finger server answers finger requests. Finger is \
    #       a protocol that allows remote users to see information such \
    #       as login name and last login time for local users.
    service finger
    {
            socket_type     = stream
            wait            = no
            user            = nobody
            server          = /usr/sbin/in.fingerd
            disable         = yes
    }
    	 

    To disable a service, simply add a line like the following to the configuration file:

    	 disable         = yes
    	 

    A third semi-obvious way of finding what services are actually running is to issue a

    	 ps -el | more 
    	 
    command to the shell. You could also pipe the output to grep to find if a certain service is running rather than viewing the whole list. The top command is another good way of examining resource usage per running process. In addition, the
    	netstat -an | more
    	
    command is the way to check what ports are open for business. Note that even if a port is bound by some service, your firewall may be dropping packets to or from it based on your configuration wishes. (This is not happening by default.)

  • what services to shut off

    ...is really up to you and your needs. You probably don't need fingerd, apache, NFS, portmapper, telnetd, or rpc running. Most people do not need sendmail running either :-).

  • how to shut them off

    The best way to shut off the service is to use the shutdown script that came with it. Alternatively, you can use the script in the /etc/rc.d/init.d/ directory with a "stop" argument:

    	/etc/rc.d/init.d/some_service stop
    	
    Finally, you can always send it the good old KILL signal:
    	kill -9 [service_pid]
    	
    ..but that's the least graceful way of doing things.

  • what to watch

    The short answer is:

    • resource usage (top)
    • network connections (netstat)
    • running processes (ps)

    The longer answer is everything - file integrity, filesystem integrity, system logs, application logs. Tripwire can help with this by managing a set of files that should not be modified.

  • setting up a packet filter (firewall)

    There have been a number of incarnations of packet filter functionality in the Linux kernel over the last few releases (iptables, ipchains, netfilter). You should set your filter up so it drops EVERYTHING that is not specifically permitted. Usually there is a nifty little graphical tool (if you are a fan of a graphical desktop) that helps you create packet filter rules. Check out netfilter.org for more information.

  • setting up tripwire

    Tripwire maintains a database of files that should not be changed and have very strict access rules. These files are usually very sensitive system files that an attacker would like to get their hands on. Check out the tripwire website.

  • running Squid

    Squid is a proxy server that is really only useful if you're running some sort of webserver. It's useful for both security and performance reasons (it separates a client from directly accessing your webserver [security] and maintains a cache of recently requested files [performance].) Here is the manual for setting Squid up.



Secure Web Browsing

You have to assess the risks to your privacy and balance them against your needs to enjoy the web, use it for work, use it for family, or use it for research.

 

contact: crf | columbia cs | author last updated on 26 September, 2002 10:43