荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: jjk (frozen), 信区: Linux
标 题: Securing Linux, Part 1(转寄)
发信站: 荔园晨风BBS站 (Sat Jan 5 20:17:42 2002), 转信
【 以下文字转载自 jjk 的信箱 】
【 原文由 jjk@bbs.zixia.net 所发表 】
发信人: zixia (知人者智/自知者明/胜人者力/自胜者强), 信区: ZixiaLinux
标 题: Securing Linux, Part 1(转寄)
发信站: BBS 大话西游站 (Fri Jan 4 00:04:15 2002)
Securing Linux, Part 1
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 two-part series on
Linux security. In this first installment, Michael H. Warfield gets you
started with elementary Linux
security. (5,500 words)
............................
By Michael H. Warfield
'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
two-part 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.
LIST_ITEM:
LIST_HEAD: Less is more
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Planning
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Installation
LIST_SUMMARY:
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.
LIST_BODY:
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!
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Secure services
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Up and running
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Password and authentication security
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Security and the privileged user
LIST_SUMMARY:
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.
LIST_BODY:
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
single 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 single 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 single 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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Cryptography and security
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Eternal vigilance
LIST_SUMMARY:
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.
LIST_BODY:
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.
:END_LIST_ITEM
LIST_ITEM:
LIST_HEAD: Stay informed
LIST_SUMMARY:
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.
LIST_BODY:
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!
Additional resources: Where they are, what they're for
Poke around the public databases. Internet Security Systems (where I work)
has several, and we also link to outside sites.
Get on some security mailing lists, such as Linux-security or BugTraq.
You can find the addresses and subscription information -- and recommended
sites for further reading -- in the Resources section.
:END_LIST_ITEM
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.
About the author
Mike Warfield is a senior security researcher on the Internet Security
Systems X-Force. He is also a member of the Samba Development Team, a
founding member of the Atlanta Linux Enthusiasts, and a long-standing guru
with the Atlanta Unix Users Group.
He has been involved in Unix systems for over 15 years and with computer
security for over 25 years.
Resources
Read Michael Warfield's previous On the Ramparts columns in the LinuxWorld
archives:
http://linuxworld.com/linuxworld/archive/columnsbydate.html#ramparts
Further reading and security resources
(Most of the sites listed below feature additional security resources and
links.)
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/securi
ty/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@securityfocus.com Linux-Security: linux-security@redhat.com
Linux Administrator's Security Guide (LASG): https://www.seifried.org/lasg/
--
______ _●_ _●_ _____
◢◤ ▊ ◥_◤ ▊ ▊ ▊
◢◤ _▊_ ◢ ◣ _▊_ ▊_▊_
￣￣￣
※ 来源:·BBS 大话西游站 bbs.zixia.net·[FROM: 166.111.11.85]
--
※ 转载:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 192.168.0.146]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店