go to msn
Inbox
Compose
Addresses
Folders
Log Out

Features
Find, Buy, Sell...
  Classifieds
  Shopping
Subscriptions
  WebCourier
People Search
  White Pages
  Member Directory
Information
  News and Links
  Help Center
  Contact Us
 
Options
  Personal
  Password
  Signature
  POP Mail
  Filters
  Preferences
  Languages
[Log Out Instead of Timing Out]
Read Message
RELATED: Dictionary
Thesaurus
Inbox

From: IH <IH@flashmail.com>  Save Address Block Sender
To: Indian Hackers 022 <Beeblebrox@listbot.com>
Subject: Securing Linux
Date: Thu, 03 Jun 1999 01:22:13 +0530
Reply Reply All Forward Delete Previous Next Close
Thanks for using NetForward!
http://www.netforward.com
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v

Indian Hackers 022

 Securing Linux

Elementary security for your Linux box

 Summary
 Are strange people accessing the data on your Linux box? Are
they using
your machine to attack others? Unless
 you have a good grasp of basic Linux security, they could well
be doing
this -- if not today, then in the near future.
 If you didn't already know that every one of the major Linux
distributions does a poor job of ensuring security in
 its default installation, read this series on Linux security.
 By Michael H. Warfield



I 'll say at the outset that I feel that the title "Securing
Linux" is
somewhat misleading. It implies that one can somehow go
through a series of steps and emerge at the end with a secure
Linux
system or network. That isn't true. The real intent of this
series is to help you improve the security of your system and to
get you
to think securely. One without the other is
unlikely to succeed.

Security is a state of mind
Ultimately, security isn't something that is achieved as an end
goal; it
isn't a state. Rather, it's a way of setting up, maintaining,
and running an operating system, network, or environment.
Security is a
process and a mind-set as well as a condition. It
depends on the day-to-day actions of the system or network's
users and
system administrators. It also depends on the system
security not being so intrusive that it encourages users and
administrators alike to work around it.

But you have to start somewhere, and that somewhere is to
improve the
security of your system as much as possible while still
meeting your operational needs. A system that isn't connected to
any
network or phone lines and is kept in a locked room is
reasonably secure -- but it will meet few of your needs. From
there we
embark on a series of compromises between the best
possible security and the least inconvenience and difficulty
that will
serve our purposes.

Some of these tips are specific to Linux systems, but many are
very
general principles that apply to all systems and networks --
not just to Unix (or Unix-like) OSs.

1.Less is more

Applying the Principle of least privilege and the Principle of
minimum
access ensures that you open up your system
to the least amount of risk. Users are allowed only enough
privilege and
access to do their work, and no more.

2.Planning

Plan ahead and plan to distribute services. Even before you
begin an
installation (and, ideally, before you purchase
system software solutions), make a detailed plan of your
intended
security defenses. On paper.

3.Installation

A secure system starts with a secure install.

This is one area where the various Linux distributions fail to
do an
adequate job. All of the distributions are guilty of
making it too easy to set up insecure or misconfigured
installations.
Many of them enable services that the new user is
unlikely to be aware of, or enable services before they are
fully
configured.

4.Secure services

Internet and network services are among the most vulnerable
parts of
your system. Whether you're planning a new
installation or reviewing security on an existing system, your
file
servers, e-mail services, Web servers, FTP, and other
network services should be among the first things you check for
security
holes.

5.Up and running

Once your system is set up, be sure to keep track of the
services you're
running. Keep a close eye on services and
applications by monitoring your UDP and TCP ports.

6.Password and authentication security

Passwords can be the most underestimated security feature you
have. Make
sure that neither you nor your users are
using transparent (easily guessed) passwords, and make sure that
your
passwords are safe from unauthorized intruders.


7.Security and the privileged user

Never perform routine operations as root! Do your routine work
as a
nonprivileged user and step up to root only when
needed. This is a common mistake of most newbies to Linux (and
Unix in
general). When you (or a user or a program)
must run as root, take the proper security precautions.

8.Cryptography and security

Cryptography is a good thing. It can protect our files, our
e-mail, and
our communications. Widespread use of
cryptography will improve and change the security landscape.
Take
advantage of cryptography wherever its use is
appropriate.

9.Eternal vigilance

Once you've secured your installation and checked your basic
security
and services, your work isn't over. In fact, the job
of keeping your system secure is never over. Even if with
eternal
vigilance, some risk remains, and it may still be possible
for someone, sometime to get in. With or without the help of any
one of
a number of monitoring programs, you must
keep a watchful eye on what is going on in your system.

10.Stay informed

New security holes and bugs are discovered and exploited
constantly, and
new techniques, patches, and fixes are
created to counter the threat they present. The only way to
safeguard
the system you've worked so hard to secure is to
stay on top of new information as it becomes available.

The enemy within is ignorance
While advanced security can be difficult to implement, a great
deal can
be achieved by taking the simple steps of knowing what
you're running and disabling services you aren't sure about.
Even small
sites and single Linux systems can take steps to reduce
the risk and harden their security protection.

Not all of these ideas are ideal for all circumstances. You have
to
understand and balance your security needs, your network
design, your functionality needs, and your security policy (if
you have
one). In any case, knowledge is your best security tool
and ignorance is your worst enemy. Use our comprehensive list of
Resources for even more information, and to stay abreast of
developments.




Tip 1: Less is more


Applying the Principle of least privilege and the Principle of
minimum
access ensures that you open up your system to the
least amount of risk. Users are allowed only enough privilege
and access
to do their work, and no more.

Principle of least privilege
Users, applications, and even systems should be granted the
least amount
of privilege required to accomplish their respective
tasks. This approach reduces the opportunity for accidental
compromise
of the system. Ideally, security should not be a burden
on your users. It should not get in the way of their ability to
accomplish their tasks. Unfortunately, this isn't always the
case. You
must strike the right balance in terms of who is allowed to do
what, and
when.

Principle of minimum access

"That which is not explicitly permitted is denied."

This is one of the basic mantras of firewall design. It applies
equally
well to security in general. In a secure system, you grant
access by intent and deny everything else by default. Permission
takes
place by will or by action. This is a simple fail-safe
principle. If you "fail" to take action, you end up failing into
a
"safe" state (access denied).

Set up your basic security mechanisms to deny everything unless
you
explicitly configure it to be allowed. Set the
/etc/hosts.allow file to allow localhost only, and set the
/etc/hosts.deny file to deny everything else. With that as a
starting point, you can decide who and what will be granted
which
access, and everything else will be blocked. The default
should always be "No!"

Do the same thing with your firewall rules, whether you're using
a
standalone box or a networked system. Firewall code is a
useful feature, even if you aren't routing traffic between
systems. The
Linux kernel has firewall code built in. It just needs to be
enabled and configured -- which is well worth the effort.




Tip 2: Planning


Plan ahead and plan to distribute services. Even before you
begin an
installation (and, ideally, before you purchase system
software solutions), make a detailed plan of your intended
security
defenses. On paper.

Some basic steps along the road
Before you decide how to secure your systems, you must first
decide how
you intend for them to be used. Decide what services
each box will use on the network and what services each box you
administer will offer to the network. This helps form a
security policy. That policy or plan can be simple for simple
systems,
or it can be a large book for large sites and networks. In
either case, it helps to decide what you want to do before you
do it.
The creation of this policy is also the most frequently
overlooked step in developing a secure system.

Network layout and design considerations
If your site or networks permit it, compartmentalize functions.
While
this may be impractical for the home user with a single box,
one should put different functions on different systems whenever
possible. Your DNS, FTP, Web, mail, and firewall should not
all be on the same system. If they are, and one service is
compromised,
they all will be compromised. Placing functions on
separate systems limits the damage potential of a successful
attack.

If you have a limited number of systems and must therefore
combine
functionality, your security issues are more complicated.
You will have to depend on your authentication and authorization
systems
to provide the isolation that could have been provided
by separate boxes.




Tip 3: Installation

A secure system starts with a secure install.

This is one area where the various Linux distributions fail to
do an
adequate job. All of the distributions are guilty of making it
too easy to set up insecure or misconfigured installations. Many
of them
enable services that the new user is unlikely to be aware
of, or enable services before they are fully configured.

Some vendors and consultants are now complaining that Linux is
much too
easy to install, because it allows users to
unknowingly install poorly configured servers and shoot
themselves in
the foot. They are correct.

Security starts with the installation
Until the Linux distribution vendors wise up and start out with
a secure
configuration, it's up to the user to turn a basic installation
into one with a reasonable shot at being secure.

When you're installing your system, never install software
unless you
intend to use it! Resist the temptation to "just install
everything." Some of the things you so casually install could
come back
to haunt you during a system attack.

If your distribution permits it -- and not all do -- hold off on
enabling services until you're familiar with them and have
configured
them. Some distributions assume that if you're installing a
service, it
should be enabled. If you aren't sure, don't install it!



Tip 4: Secure services

Internet and network services are among the most vulnerable
parts of
your system. Whether you're planning a new installation
or reviewing security on an existing system, your file servers,
e-mail
services, Web servers, FTP, and other network services
should be among the first things you check for security holes.

Some services will obey the /etc/hosts.accept and
/etc/hosts.deny
configurations if they've been compiled with the
TCP Wrapper library, but not all will. Use the firewall code
along with
the TCP Wrapper configurations to secure your
services.

Secure file serving
If you're exporting any filesystems via NFS, SMB, Samba, or
anything
else, make sure your access permissions are carefully
checked.

Never run NFS, SMB, or NIS over the Internet. The risk is just
too
great. (NIS is jokingly referred to as "network intruder
service" and some have referred to NFS as "no file security.")
NFS in
particular uses UDP and depends on peer addresses for
authentication and authorization. But peer addresses are trivial
to
spoof for UDP!

E-mail security
If you're running POP or IMAP for remote downloading of e-mail,
switch
to an SSL-encrypted version. You can use stunnel or
edssl to set up SSL-enabled mail servers. Several e-mail clients
support
SSL POP and/or SSL IMAP, including Netscape and
Microsoft Outlook. SSL-enabled fetchmail is available from the
North
American Cryptographic Archives.

If you aren't intending to run POP or IMAP, make sure you really
aren't
running them. Some distributions enable these by
default. Some of the "bad guys" out on the Net are now engaged
in
massive parallel-port scanning for IMAP servers. If you
leave the backdoor open for one of them to get your number, the
next
time a major root compromise is discovered in IMAP
(for example) he or she could promptly come knocking. If you
don't know
you're running IMAP, you'll have no reason to know
when security patches or updates to it become available. Without
these
upgrades, an intruder could be root on your system
before you know what hit you.

Secure Web services
If you're running a Web server, check and recheck your CGI
scripts. Do
not allow other users to install arbitrary CGI scripts.
Do not use unrestricted server-side includes (SSIs).

IRC is one common example of a chat system -- many other chat
systems
also work with Web servers. If you have any kind of
chat server running on your system, make sure common users can't
insert
arbitrary HTML (hostile JavaScript anyone?) into
pages where your Web server can serve them up.

Securing FTP
If you're operating an anonymous FTP service, watch your
permissions
closely! Don't allow any directories to be both readable
and writable by anonymous users. If you want to permit anonymous
uploads
to your system, provide a write-only directory and
prohibit directory creation underneath it. If you permit a
location to
be both readable and writable, you not only allow your
system to be a "warez" (pirateware) repository, but you also
open up
your system to being used for "FTP bounce" attacks
against other systems.

If you're not running anonymous FTP -- make sure you're not. A
lot of
distributions enable anonymous FTP by default.

Disable telnet and finger
If you're running telnet, rlogin, or rsh to access your system
remotely
-- Why?!?!? These are seriously insecure and allow
passwords and userids to be "sniffed."

For remote access, use secure shell (ssh) connections and
disable all
nonencrypted remote access to the server. The ssh
package can be downloaded and installed very easily. ssh isn't
available
on any Linux distribution originating in the United
States due to US export restrictions on cryptography. Some
distributions
from outside of the US do include cryptography
modules and applications such as ssh and PGP in the base
distributions
and installations.

finger is often configured and available on default
installations.
Unless you have a specific need for this service, disable it or
restrict network access to it. finger provides far too much
information
about your users to would-be intruders. It is also
instrumental in certain advanced forms of denial-of-service
attacks such
as "nisnuke" on large networks.




Tip 5: Up and running


Once your system is set up, be sure to keep track of the
services you're
running. Keep a close eye on services and applications
by monitoring your UDP and TCP ports.

Tracking down services
Go through your system and make sure you're not running any
services you
don't intend to run, haven't configured, aren't using,
or don't understand. I helped a Web site clean out an intruder
who broke
in using innd, even though the site wasn't running a
news system. Installing services that users don't need or
understand is
a major strike against every Linux distribution -- and
most other OSs -- out there.

If you run it, they will come
Examine /etc/inetd.conf and disable any service you don't want
to be
running or don't understand. If you do this simply by
commenting out the services you don't want, you can easily
reenable a
service at a later date. But very few of us need echo,
chargen, or discard. If you don't need a service, don't use it.
And if
you don't know what it is, don't run it until you find out.
With a typical workstation configuration, it may be possible to
turn off
all services. For instance, if your machine isn't running any
inetd services, you don't need to run the inetd at all.

Find out who's listening to what
Run nstat -a and look for any unusual ports or services. If you
see a
TCP port in the state of LISTEN and you can't identify
the local port or service, track it down and decide if it's
something
you really want to be running.

Do the same for any UDP ports you find.

If it isn't something you specifically want, shut it down. If
it's
something you want locally but don't want outsiders to access,
use
the Linux firewall code to block outside access to it.

If you have trouble determining what application is listening on
a TCP
port or opening a UDP port, use the lsof package to
track it down.

Keep up with the times
Keep all software and distributions current with any updates
released by
the distributor. If the distributor doesn't have a
mechanism in place for announcing updates or alerts, consider
finding a
different distributor. Install updates as soon as they
become available. Far too many systems have been broken into
because of
out-of-date imapd servers, even when updates had
been available for months.

Tip 6: Password and authentication security
Passwords can be the most underestimated security feature you
have. Make
sure that neither you nor your users are using
transparent (easily guessed) passwords, and make sure that your
passwords are safe from unauthorized intruders.

Good passwords
It is frankly stupefying to discover how lax some administrators
are
about secure passwords. Passwords should be at least five
characters long, should mix letters with numbers or other
atypical
characters, and should be changed several times a year, at the
least. Your users should know that password sharing isn't
allowed, and
former users should be deleted from systems after a
reasonable amount of time has passed (i.e., former users should
be
allowed time to alert all correspondents of their new e-mail
address). Ex-user accounts can usually be password-disabled
immediately
upon the employee's departure. Be aware that more
attacks come from disgruntled employees than from any other
source. If
users are in the habit of sharing passwords, a
disgruntled attacker could have access to your system even if
you have
disabled his or her account.

Proceed with caution before implementing this next bit of
advice:

To ensure that you're not using transparent passwords, you can
run the
program crack on your own password system. Running
crack on your personal system or any system on which you're the
administrator is fine. But do not run this program on a
system for which you do not have administrative privileges
without the
consent of the system's management!

Warning! Some companies and ISPs take offense at users having
"cracker
tools" such as crack, or any of a variety of sniffing
and scanning tools (described in the section called "Eternal
Vigilance")
on their systems. If you aren't an administrator on a
system, make sure you have permission to possess these items and
that
the administrator is aware of them. Some people
consider the possession of lockpicks to be no different than the
possession of burglar tools. If you have tools for cracking
passwords or breaking into systems, you may be setting yourself
up to
answer some very intense questions. Some ISPs don't
even ask questions first. Providers have been known to cancel
accounts
merely for the possession of cracking tools. Don't take
the chance. Don't even download these tools if you don't have
your
administrator's permission!

Password handling
Not only should you never share passwords or give your passwords
out to
anyone, you should never leave passwords written
down where they can be read. Intruders known as dumpster divers
periodically go through the trash looking for scraps of paper
with passwords on them. Destroy all security information before
discarding.

Additional password security
If you aren't running a distribution that supports PAM
(Pluggable
Authentication Modules), then get one. PAM makes it
relatively simple to enable advanced password checking,
encryption, and
longer passwords. When you have it, enable it and
use it.

If you aren't in a network requiring single sign-on
authentication (NIS,
NIS+, Kerberos, etc.), enable shadow passwords and
MD5 (Message Digest algorithm) hashing. This enables long
passwords and
makes them much tougher to crack with brute
force, and much tougher to steal if you aren't the superuser.




Tip 7: Security and the privileged user

Never perform routine operations as root! Do your routine work
as a
nonprivileged user and step up to root only when needed.
This is a common mistake of most newbies to Linux (and Unix in
general).
When you (or a user or a program) must run as root,
take the proper security precautions.

Don't run as root
A couple of years ago we had a Linux "virus" running around.
Actually,
while some were sure "Bliss" was a virus, others thought
it was merely a worm or a trojan. In hindsight, it's probably
safe to
say that it was something of a hybrid -- mixing a little bit of
each. But the important thing is that it only propagated because
people
were running as root, allowing it to modify system
binaries. This is very bad practice. This rule can't possibly be
understated! If you routinely run as the root user, you might as
well be running DOS -- you have just about that much security!

By not running routinely as root, you also reduce the likelihood
of
"accidents." My son discovered that, if he was running as
root, any changes he saved to his desktop were saved to the
systemwide
configurations. He found out what a bad idea this can
be when he got part of the configuration wrong and was then
unable to
get any account to work right! This kind of accident
could lead to unforeseen side-effects and security compromises.

Never use a browser or chat program when running as root! While
the
chance of a hostile applet --- written in Java, ActiveX,
or some other language -- is remote, it isn't worth the risk.
The
destructive capability of such applets is magnified manyfold if
you're running as root.

What you can do with sudo
The program sudo is a useful tool to allow trusted users to
perform
certain functions as though they were root -- while at the
same time limiting their ability to really function as the
superuser. It
also provides convenient access to those utilities that require
root permission to run. By using sudo you avoid the overuse of
suid.

As with any security tool, sudo should be used with caution.
While
running a command under sudo, the user's permissions are
elevated to root. This makes any potential bugs or security
holes in the
command or program you're running under sudo more
serious than they would be if you were running them as a normal
user.
For instance, a shell escape out of a sudo-run command
is a potential root backdoor.

Even some programs that expect to be run only as root can become
a
security hole under sudo. If the program assumes that
only root can run it, and if that program then permits the
execution of
external commands, there is the potential for the user
calling sudo to execute arbitrary commands as root. For this
reason,
sudo should only be used by trusted users, and with great
caution.

Beware of software bearing trojans
Watch out for trojans! There is a reason why root shouldn't
normally
have dots (.) anywhere in his or her path. This helps avoid
the danger of having a trojan program like ls sitting in a
directory
waiting for the superuser to come looking to see what's there.
Some distributions still allow dots in the superuser path. Some
distributions have different paths for when you log in as root
and
when you su to superuser. If a dot is in the path for either
root login
or for su to superuser, it should be removed. While its
removal isn't a foolproof preventative against trojans, it does
help
reduce that danger.

Trojans are also a serious concern for normal users when it
comes to any
application that prompts for a password, such as su
(since ordinary users can su to any other username to which they
have
access). Programs that prompt for a password should
only be executed as an absolute path to the binary. One way to
encourage
this is to insert alias su /bin/su into the files
/etc/profile and /etc/bashrc so that bash users will
automatically use
the absolute path.

Use the groups, Luke
Often, jobs that need root access could be done just as well and
more
securely through the proper use of group ownerships and
secondary group membership. It takes more time to set this up
properly,
but once it's done right, it more effectively protects
system security while granting the access required by normal
users.

It's very easy and convenient when there are only one or two
users on a
system to simply perform all maintenance tasks by
stepping up to root. But once you have a lot of users and wish
to
delegate the authority for various tasks to different users, it
becomes impractical and dangerous to allow superuser access to
everyone
performing maintenance. It's well worth the effort to
implement an effective group membership configuration when the
system is
simple, before you really need it -- or before it's too
late.




Tip 8: Cryptography and security


Cryptography is a good thing. It can protect our files, our
e-mail, and
our communications. Widespread use of cryptography
will improve and change the security landscape. Take advantage
of
cryptography wherever its use is appropriate.

With any cryptographic system, the key is the key. The security
of your
cryptography depends on the security of your key.
That can be a private key stored on a system, or a password, or
a smart
card key. If you decide on a crypto system to guard
your security, your problems aren't solved, they've merely
changed. Now,
instead of guarding your front door, you must guard
the keys to the lock on the door.

Encrypted communications
SSL began its career securing Web servers for e-commerce, and
has since
been applied to FTP and telnet, as well as to
POP and IMAP e-mail services. In addition to simple remote
shells and
secure copying, ssh is capable of forwarding many
services and even tunneling PPP to provide a form of VPN
service.
Several remote services, such as cvs, rsync, and rdist,
can take advantage of ssh to secure their underlying
communications.

If you want to protect your e-mail, your open source choices are
PGP and
S/MIME (there are, additionally, several proprietary
schemes). Both PGP and S/MIME have advantages and disadvantages,
and
both have interoperability problems and usability
problems. When was the last time you checked the validity of a
PGP
signature? The "web of trust" model of PGP distributes
well, but transitive trust (I trust Sue and Sue trusts Adam but
do I
trust Adam?) doesn't scale well. The "authority" model of
S/MIME has its own scaling problems. Additionally, S/MIME has an
annoying infrastructure (and some would say, tax)
associated with it.

Encrypted files
If you want to protect the files on your system, there are
several
cryptographic filesystems available for Linux, including Matt
Blaze's CFS (Crytographic File System). These help secure your
files.
But on a multiuser system, you still must watch out for
trojan password traps and sniffers. Your filesystem encryption
is only
as secure as the passwords you use to access it.

FreeS/WAN
The FreeS/WAN project is developing IPSec for Linux. This is now
available for both 2.0 kernels and 2.2 kernels, and it
interoperates with many other IPSec implementations. For
encrypting VPNs
and private connections, this is the way to go. To
connect gateways between two or more widely dispersed networks,
this is
the tool to use. Running host to host, however, it is
very cumbersome and it will not operate over IP masquerading
firewalls
or gateways. Further, it isn't trivial to install, and you
must guard your keys religiously.

Don't be lulled into a false sense of (encrypted) security
The tools mentioned here enhance the security of communications,
but may
or may not improve overall system security. If
someone cracks a password by brute force, they're just as free
to use
the secure channels of access as are authorized users. A
recently well-publicized break-in at RootShell was done through
ssh. The
problem wasn't a vulnerability of ssh -- the attackers
had obtained the root password through other means and had
simply
connected in as if they belonged there.

For these reasons, even IPSec isn't the end-all, be-all of
security on
the Internet. It may eliminate spoofing or certain types of
passive sniffing attacks, but it won't stop brute force attacks
or
protocol attacks. Your e-mail may not be sniffable any longer,
but it can still be read if someone compromises and gains access
to your
system. Your credit card number won't necessarily be
sniffed while it's traveling along the wire on its way to an
insecure
Web server -- but most credit card theft is the result of
intruder access to the insecure server itself, not sniffing.




Tip 9: Eternal vigilance


Once you've secured your installation and checked your basic
security
and services, your work isn't over. In fact, the job of
keeping your system secure is never over. Even if with eternal
vigilance, someone, sometime, is likely to get in. With or
without
the help of any one of a number of monitoring programs, you must
keep a
watchful eye on what is going on in your system.

If you can't block 'em, catch 'em!
Enable the firewalling code, even on single systems, and block
everything that you don't understand or specifically want on
your system. This can put a serious crimp in some rootkit
backdoors.

Watch out for unusual suid programs. find can be used to locate
all of
the suid binaries, which can then be tracked for changes
or additions.

Scan that system!
Run a network security scanner on your system! SATAN is one such
scanner. Nessus is an excellent open source scanner, as is
Trinux. Trinux is a tiny distribution that can boot from floppy
disks
and scan your network. Internet Security Systems also
produces a commercial security scanner. Internet Scanner is free
to
download and run against your local host. Even if you don't
intend to purchase Internet Scanner, or can't afford it (it can
be a bit
expensive), I would encourage you to get the local host
evaluation copy and run it on your system (it's fully
functional).

Burglar alarms
Install an intrusion-detection system. These vary greatly from
package
to package, and there are commercial and open source
versions of most types. Some are host-based systems, monitoring
for
unauthorized changes to files; others monitor the network
or network interfaces for suspicious activities.

Check out Tripwire. Tripwire can alert you to modified binaries
and
permissions. There are commercial variations of this
application, including a commercially marketed and supported
version of
Tripwire itself. Some of the other systems are more
extensive than Tripwire, some are not.

There are log-monitoring packages available from several of the
security
sites listed in the Resources section at the end of this
article. Log monitors trigger on suspicious activity, such as
repeated
failed login attempts in security logs. The application can
send e-mail to the system administrator or even activate a pager
to
inform the administrator of an attack in progress. Some are
capable of performing even more drastic action, as we'll see in
Part 2
of this series.




Tip 10: Stay informed


New security holes and bugs are discovered and exploited
constantly, and
new techniques, patches, and fixes are created to
counter the threat they present. The only way to safeguard the
system
you've worked so hard to secure is to stay on top of new
information as it becomes available.

Stay on top of software updates
Subscribe to the mailing lists provided by the Linux
distribution
vendors to provide announcements of updates or alerts. Monitor
the vendor Web sites for errata and updates.

Know thine enemy
Browse through the various "white hat hacker" sites and get a
feel for
some of the recent danger points. RootShell and L0pht
(both listed in the Resources section) are good places to start.
There
are also some Linux security sites out there.

Warning! Some companies and ISPs take offense at users having
"cracker
tools" such as crack, or any of a variety of sniffing
and scanning tools (available from the various white hat hacker
sites,
among others) on their systems. These tools can be useful
if you run them against your own system to find security holes
before a
potential intruder does. But f you aren't an administrator
on a system, make sure you have permission to possess these
items and
that the administrator is aware of them. Some people
consider the possession of lockpicks to be no different than the
possession of burglar tools. If you have tools for cracking
passwords or breaking into systems, you may be setting yourself
up to
answer some very intense questions. Some ISPs don't
even ask questions first. Providers have been known to cancel
accounts
merely for the possession of cracking tools. Don't take
the chance. Don't even download these tools if you don't have
your
administrator's permission!
Get on some security mailing lists, such as Linux-security or
BugTraq.

The enemy within is ignorance
While advanced security can be difficult to implement, a great
deal can
be achieved by taking the simple steps of knowing what
you're running and disabling services you aren't sure about.
Even small
sites and single Linux systems can take steps to reduce
the risk and harden their security protection. Not all of these
ideas
are ideal for all circumstances. You have to understand and
balance your security needs, your network design, your
functionality
needs, and your security policy (if you have one). In any
case, knowledge is your best security tool and ignorance is your
worst
enemy


Security resources

 North American Cryptographic Archives:
 http://www.cryptography.org/
 Trinux:
 http://www.trinux.org/
 Nessus:
 http://www.nessus.org/
 Psionic Software / Abacus Sentry:
 http://www.psionic.com/
 RootShell:
 http://www.rootshell.com/
 L0pht Heavy Industries:
 http://www.l0pht.com/
 Deception Toolkit:
 http://all.net/dtk/dtk.html
 "Securing Your Linux Box," Peter Vertes (Linux Gazette, Issue
34,
November 1998):
 http://www.linuxgazette.com/issue34/vertes.html
 Wietse Venema's collected tools and papers:
 ftp://ftp.porcupine.org/pub/security/index.html
 Solar Designer's Secure-Linux Patch:
 http://freshmeat.net/appindex/1998/06/14/897822718.html
 StackGuard:
 http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
 Internet Security Systems:
 http://www.iss.net/
 CERT Security Improvement modules:
 http://www.cert.org/security-improvement/
 CIAC (Computer Incident Advisory Capability):
 http://ciac.llnl.gov/ciac/
 BugTraq: bugtraq@netspace.org
 Linux-Security: linux-security@redhat.com
 Linux Administrator's Security Guide (LASG):
 https://www.seifried.org/lasg/


______________________________________________________________________
To unsubscribe, write to Beeblebrox-unsubscribe@listbot.com
Start Your Own FREE Email List at http://www.listbot.com/
Reply Reply All Forward Delete Previous Next Close


Travel Agent | Buy Music | Downloads | Movie Times | Free Games | Yellow Pages
Headlines | Sporting Goods | Buy Videos | Weather | Buy books | More cool stuff...
search the web: 
 
[Log Out Instead of Timing Out]


© 1999 Microsoft Corporation. All rights reserved. Terms of service [Contact Us | Help]