|
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.
|
|