Bring in the new security guide.
Submitted by: jkb
This commit is contained in:
Jordan K. Hubbard
parent
d52a8a2a93
commit
7e6229e0d5
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=3942
3 changed files with 1044 additions and 330 deletions
|
|
@ -1,77 +1,95 @@
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
||||||
<!ENTITY base CDATA "..">
|
<!ENTITY base CDATA "..">
|
||||||
<!ENTITY date "$Date: 1998-12-13 23:19:25 $">
|
<!ENTITY date "$Date: 1998-12-19 09:55:30 $">
|
||||||
<!ENTITY title "FreeBSD Security Guide">
|
<!ENTITY title "FreeBSD Security Information">
|
||||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||||
]>
|
]>
|
||||||
<!-- $Id: advisories.xml,v 1.8 1998-12-13 23:19:25 steve Exp $ -->
|
<!-- $Id: advisories.xml,v 1.9 1998-12-19 09:55:30 jkh Exp $ -->
|
||||||
|
|
||||||
<html>
|
<html>
|
||||||
&header;
|
&header;
|
||||||
|
|
||||||
<P>This guide attempts to document some of the tips and tricks used by
|
<H2>Introduction</H2>
|
||||||
many FreeBSD security experts for securing systems and writing secure
|
|
||||||
code. It is designed to help you learn about the various ways of protecting
|
|
||||||
a FreeBSD system against outside attacks and how to recover from such attacks
|
|
||||||
if and when they should happen. It also lists the various ways in which
|
|
||||||
the systems programmer can become more security conscious so he will
|
|
||||||
less likely introduce security holes in the first place.</P>
|
|
||||||
|
|
||||||
<P>We welcome your comments on the contents and correctness of this page.
|
<P>This web page is designed to assist both new and experienced users
|
||||||
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
|
in the area of security for the FreeBSD Operating System. The FreeBSD
|
||||||
FreeBSD Security Officers</A> if you have changes you'd like to see here.</P>
|
Development team takes security very seriously and is constantly working
|
||||||
|
on making the OS as secure as possible.</P>
|
||||||
|
|
||||||
<H2>The FreeBSD security officer</H2>
|
<P>Here you will find additional information, or links to information,
|
||||||
|
on how to protect your system against various types of outside attack,
|
||||||
|
whom to contact if you find a security related bug, etc. There is
|
||||||
|
also a section on the various ways that the systems programmer can
|
||||||
|
become more security conscious so he or she is less likely to
|
||||||
|
introduce security holes in the first place.</P>
|
||||||
|
|
||||||
<P>FreeBSD takes security seriously, a dedicated team of security officers
|
<H2>Table Of Content</H2>
|
||||||
providing a focal point for security related communications. A security
|
<UL>
|
||||||
officers' main task is to send out advisories when there are known security
|
<LI><A HREF="#sec">Information about the FreeBSD Security Officer</A></LI>
|
||||||
holes and otherwise keep abreast of security issues. The security officers
|
<LI><A HREF="#adv">FreeBSD Security Advisories</A></LI>
|
||||||
also communicate with the various <A HREF="http://www.cert.org/">CERT</A>
|
<LI><A HREF="#ml">FreeBSD Security Mailing Lists Information</A></LI>
|
||||||
and <A HREF="http://www.first.org/">FIRST</A> teams around the world,
|
<LI><A HREF="#tat">FreeBSD Security Tips and Tricks</A></LI>
|
||||||
sharing information about vulnerabilities in FreeBSD or utilities commonly
|
<LI><A HREF="#spg">Secure Programing Guidelines</A></LI>
|
||||||
used by FreeBSD, and keeping up to date on security issues in the world at
|
<LI><A HREF="#misc">Other Related Security Information</A></LI>
|
||||||
large. The security officers are also active members of those
|
</UL>
|
||||||
organizations.</P>
|
|
||||||
|
|
||||||
<P>When you need to contact the security officers about a sensitive matter,
|
<A NAME=sec></A>
|
||||||
please use their
|
<H2>The FreeBSD Security Officer</H2>
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
|
|
||||||
to encrypt your message before sending it.</P>
|
|
||||||
|
|
||||||
<H2>FreeBSD security advisories:</H2>
|
<P>To better coordinate information exchange with others in the security
|
||||||
|
community, FreeBSD has a focal point for security related communications:
|
||||||
|
The FreeBSD <a href="mailto:security-officer@freebsd.org">security officer</a>.
|
||||||
|
The position is actually staffed by a team of dedicated security officers,
|
||||||
|
their main tasks being to send out advisories when there are known security
|
||||||
|
holes and to act on reports of possible security problems with FreeBSD.</P>
|
||||||
|
|
||||||
<P>The FreeBSD security officers provide security advisories for
|
<P>If you need to contact someone from the FreeBSD team about a
|
||||||
the following releases of FreeBSD:</P>
|
possible security bug, you should therefore please <A
|
||||||
|
HREF="mailto:security-officer@FreeBSD.org">send mail to the Security Officer</A>
|
||||||
|
with a description of what you've found and the type of vulnerability it
|
||||||
|
represents. The Security Officers also communicate with the various
|
||||||
|
<A HREF="http://www.cert.org">CERT </A>and <A
|
||||||
|
HREF="http://www.first.org/"> FIRST</A> teams around the world,
|
||||||
|
sharing information about possible vulnerabilities in FreeBSD or
|
||||||
|
utilities commonly used by FreeBSD. The Security Officers are also
|
||||||
|
active members of those organizations.</P>
|
||||||
|
|
||||||
|
<P>If you do need to contact the Security Officer about a particularly
|
||||||
|
sensitive matter, please use their <A
|
||||||
|
HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key
|
||||||
|
</A> to encrypt your message before sending it.</P>
|
||||||
|
|
||||||
|
<A NAME=adv></A>
|
||||||
|
<H2>FreeBSD Security Advisories</H2>
|
||||||
|
|
||||||
|
<P>The FreeBSD Security Officers provide security advisories for the
|
||||||
|
following releases of FreeBSD:</P>
|
||||||
|
|
||||||
<UL>
|
<UL>
|
||||||
<LI> the most recent official release of FreeBSD,
|
<LI> The most recent official release of FreeBSD.
|
||||||
<LI> FreeBSD-current,
|
<LI> FreeBSD-current.
|
||||||
<LI> FreeBSD-stable, when at least 2 releases are based on it.
|
<LI> FreeBSD-stable, when at least 2 releases are based on it.
|
||||||
<LI> the previous FreeBSD-stable when a "new stable" does not
|
<LI> The previous FreeBSD-stable when a "new stable" does not yet
|
||||||
yet have 2 releases based on it.
|
have 2 releases based on it.
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
At this time, security advisories are available for:
|
At this time, security advisories are available for:
|
||||||
<UL>
|
<UL>
|
||||||
<LI> FreeBSD 2.2.6
|
<LI> FreeBSD 2.2.7
|
||||||
|
<LI> FreeBSD 2.2.8
|
||||||
|
<LI> FreeBSD 3.0
|
||||||
<LI> FreeBSD-current
|
<LI> FreeBSD-current
|
||||||
<LI> FreeBSD-stable
|
<LI> FreeBSD-stable
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P>Older releases will not be actively maintained and users are strongly
|
<P>Older releases are not maintained and users are strongly encouraged
|
||||||
encouraged to upgrade to one of the supported releases.</P>
|
to upgrade to one of the supported releases mentioned above.</P>
|
||||||
|
|
||||||
<P>An advisory will be sent out when a security hole exists that is
|
|
||||||
either being actively abused (as indicated to us via reports from end
|
|
||||||
users or CERT like organizations), or when the security hole is public
|
|
||||||
knowledge (e.g. because a report has been posted to a public mailing
|
|
||||||
list).</P>
|
|
||||||
|
|
||||||
<P>Like all development efforts, security fixes are first brought into
|
<P>Like all development efforts, security fixes are first brought into
|
||||||
the <A HREF="../handbook/current.html">FreeBSD-current</A>
|
the <A HREF="../handbook/current.html">FreeBSD-current</A> branch.
|
||||||
branch. After a couple of days and some testing, the fix is retrofitted
|
After a couple of days and some testing, the fix is retrofitted into
|
||||||
into the supported FreeBSD-stable branch(es) and an advisory then sent out.</P>
|
the supported FreeBSD-stable branch(es) and an advisory then sent
|
||||||
|
out.</P>
|
||||||
|
|
||||||
<P>Advisories are sent to the following FreeBSD mailing lists:
|
<P>Advisories are sent to the following FreeBSD mailing lists:
|
||||||
<UL>
|
<UL>
|
||||||
|
|
@ -80,9 +98,10 @@ into the supported FreeBSD-stable branch(es) and an advisory then sent out.</P>
|
||||||
<LI>FreeBSD-announce@freebsd.org
|
<LI>FreeBSD-announce@freebsd.org
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P>Advisories are always signed using the FreeBSD security officer
|
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
|
<P>Advisories are always signed using the FreeBSD Security Officer
|
||||||
and are archived, along with their associated patches, at our
|
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc"> PGP key
|
||||||
|
</A> and are archived, along with their associated patches, at our
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
||||||
repository</A>. At the time of this writing, the following advisories are
|
repository</A>. At the time of this writing, the following advisories are
|
||||||
currently available:</P>
|
currently available:</P>
|
||||||
|
|
@ -117,98 +136,317 @@ currently available:</P>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
|
||||||
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:07.rst.asc">FreeBSD-SA-98:07.rst.asc</A></LI>
|
||||||
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:08.fragment.asc">FreeBSD-SA-98:08.fragment.asc</A></LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<H2>FreeBSD security related information</H2>
|
<A NAME=ml></A>
|
||||||
|
<H2>FreeBSD Security Mailing Lists Information</H2>
|
||||||
|
|
||||||
<P>If you want to stay up to date on FreeBSD security, you can subscribe
|
<P>If you are administering or using any number of FreeBSD systems, you
|
||||||
yorself to one of the following mailing lists:</P>
|
should probably be subscribed to one or more of the following lists:</P>
|
||||||
|
|
||||||
<PRE>
|
<PRE>
|
||||||
freebsd-security General security related discussion
|
freebsd-security General security related discussion
|
||||||
freebsd-security-notifications Security notifications (moderated mailing list)
|
freebsd-security-notification Security notifications (moderated mailing list)
|
||||||
</PRE>
|
</PRE>
|
||||||
|
|
||||||
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
|
Send mail to <A HREF="mailto:majordomo@freebsd.org">
|
||||||
with
|
majordomo@FreeBSD.ORG</A> with
|
||||||
<PRE>
|
<PRE>
|
||||||
subscribe <listname> [<optional address>]
|
subscribe <listname> [<optional address>]
|
||||||
</PRE>
|
</PRE>
|
||||||
in the body of the message in order to subscribe yourself.
|
in the body of the message in order to subscribe yourself.
|
||||||
|
For example:
|
||||||
|
<PRE>
|
||||||
|
% echo "subscribe freebsd-security" | mail majordomo@freebsd.org
|
||||||
|
</PRE>
|
||||||
|
and if you would like to unsubscribe from a mailing list:
|
||||||
|
<PRE>
|
||||||
|
% echo "unsubscribe freebsd-security" | mail majordomo@freebsd.org
|
||||||
|
</PRE>
|
||||||
|
|
||||||
<H2>What to do when you detect a security compromise:</H2>
|
<A NAME=spg></A>
|
||||||
|
<H2>Secure Programing Guidelines</H2>
|
||||||
|
<P><P><UL>
|
||||||
|
<LI>Never trust any source of input, i.e. command line arguments,
|
||||||
|
environment variables, configuration files, incoming TCP/UDP/ICMP packets,
|
||||||
|
hostname lookups, function arguments, etc. If the length of or contents of
|
||||||
|
the date received is at all subject to outside control, then the program or
|
||||||
|
function should watch for this when copying it around. Specific security
|
||||||
|
issues to watch for in this are are:
|
||||||
|
<P></P>
|
||||||
|
<UL>
|
||||||
|
|
||||||
<UL>
|
<LI>strcpy() and sprintf() calls from unbounded data. Use strncpy and
|
||||||
<LI><B>Determine the level of security breach:</B><BR>
|
snprintf() when the length is known (or implement some other form of
|
||||||
What privilege did the attack get? That of another user or more (up to
|
bounds-checking when the length is unknown). In fact, never ever use
|
||||||
root privileges)?</LI>
|
gets() or sprintf(), period. If you do - will send evil dwarfs after you.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
<LI><B>Determine those parts of the system which are not in their original state
|
<LI>If you have to check the user input so it does not contain bad
|
||||||
anymore:</B><BR>
|
characters of some sort, do NOT check for those bad characters. Instead
|
||||||
What software has been tampered with? You may decide to re-install the
|
simply verify that it consists ONLY of those characters that you do
|
||||||
operating system from a safe medium, or you might have MD5 checksums of
|
allow. In general concept is: disallow anything that is not
|
||||||
the original software with which you can check your system. The tripwire
|
explicitly allowed.
|
||||||
package also keeps MD5 checksums, though be aware that tripwire might
|
<P></P></LI>
|
||||||
be tampered with as well and be sure and use a known-good copy.</LI>
|
|
||||||
|
|
||||||
<LI><B>Find out how the breakin was done:</B><BR>
|
<LI>Read man pages for strncpy() and strncat() calls. Be sure to
|
||||||
Via a well-known security bug? A misconfiguration? If it's a new bug,
|
understand how they work!!! While strncpy() might not append a terminating
|
||||||
you should warn the <A HREF="mailto:security-officer@freebsd.org">
|
\0, strncat() on the other hand adds the \0.
|
||||||
FreeBSD Security Officer</A>.</LI>
|
<P></P></LI>
|
||||||
|
|
||||||
<LI><B>Fix the hole(s):</B><BR>
|
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||||
Install new software that fixes the problems. If you aren't able to get
|
the destination string wrong for, and getenv() can return strings much
|
||||||
a fix quickly, you should temporarily disable remote access to your system
|
longer then the program might expect. These two functions are one of the
|
||||||
until you have done so.</LI>
|
key ways an attack is often made on a program, causing it to overwrite stack
|
||||||
|
or variables by setting its environment variables to unexpected values. If
|
||||||
|
your program reads environment variables, be paranoid. Be very paranoid!
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Ever time you use open() or stat() call - ask yourself: "What if it
|
||||||
|
is a symbolic link?"
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Make sure to use mkstemp() instead of mktemp(), tempnam(), mkstemp() and
|
||||||
|
etc. Also make sure to look for races in /tmp in general, being aware that
|
||||||
|
there are very few things which can be atomic in /tmp:
|
||||||
|
<UL>
|
||||||
|
<LI>Creating a directory. This will either succeed or fail.</LI>
|
||||||
|
<LI>Opening a file O_CREAT | O_EXECL</LI>
|
||||||
|
</UL>
|
||||||
|
If you use mkstemp - above cases will be properly handled for you. Hence
|
||||||
|
all temp files should use mkstemp() to guarantee there is not race
|
||||||
|
condition and that the permissions are correct.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>If an attacker can force packets to go/come from another arbitrary
|
||||||
|
system then that attacker has complete control over the data that we get
|
||||||
|
and <B>NONE</B>of it should be trusted.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Never trust a configuration file is correctly formatted or that it was
|
||||||
|
generated by the appropriate utility. Don't trust user input such as
|
||||||
|
terminal names or language strings to be free of '/' or '../../../' if
|
||||||
|
there is any chance that they can be used in a path name. Don't trust
|
||||||
|
<B>ANY</B> paths supplied by the user when you are running setuid root.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Look for holes or weaknesses in how data is stored. All temp files
|
||||||
|
should have 600 permission in order to be protected from prying eyes.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Don't just grep for the usual suspects in programs which run with
|
||||||
|
elevated privileges. Look line by line for possible overflows in these
|
||||||
|
cases since there are a lot more ways to cause buffer overflows then
|
||||||
|
by abusing strcpy() and friends.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Just because you drop privileges somewhere, it does not mean that no
|
||||||
|
exploit is possible. The attacker may put the necessary code on the
|
||||||
|
stack to regain the privileges before executing /bin/sh.</LI></UL>
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Do uid management. Do drop privileges as soon as possible, and really
|
||||||
|
do drop them. Switching between euid and uid is NOT enough. Use setuid()
|
||||||
|
when you can.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Never display configuration file contents on errors. A line number and
|
||||||
|
perhaps position count is enough. This is true for all libs and for any
|
||||||
|
suid/sgid program.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Tips for those reviewing existing code for security problems:<P></P><UL>
|
||||||
|
|
||||||
|
<LI>If you are unsure of your security fixes, send them to a reviewer with
|
||||||
|
whom you have already arrangements for a second glance over your
|
||||||
|
code. Don't commit code you are not sure about since breaking something
|
||||||
|
in the name of security fix is rather embarrassing.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Those without CVS commit privileges should make sure that a reviewer
|
||||||
|
with such privileges is among the last to review the changes. That person
|
||||||
|
will both review and incorporate the final version you would like to have
|
||||||
|
go into the tree.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>When sending changes around for review, always use context or unidiff
|
||||||
|
format diffs - this way diffs can be easily fed to patch(1). Do not simply
|
||||||
|
send the whole files. Diffs are much easier to read and apply to local
|
||||||
|
sources (especially those in which multiple, simultaneous changes may be
|
||||||
|
taking place). All changed should be relative to the -current branch of
|
||||||
|
development.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Always directly test your changes (e.g. build and run the affected
|
||||||
|
sources) before sending them to a reviewer. Nobody likes being sent
|
||||||
|
obviously broken stuff for review, and it just makes it appear as though
|
||||||
|
the submitter didn't even really look at what he was (which is also hardly
|
||||||
|
confidence building). If you need accounts on a machine with a specific
|
||||||
|
version which you don't have available - just ask. The project has
|
||||||
|
resources available for exactly such purposes.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Note for committers: do not forget to retrofit -current patches into
|
||||||
|
the -stable branch as appropriate.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Do not needlessly rewrite code to suit your style/tastes - it only
|
||||||
|
makes the reviewer's job needlessly more difficult. Do so only if there
|
||||||
|
are clear reasons for it.</LI></UL
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Look out for programs doing complex things in with signal
|
||||||
|
handlers. Many routines in the various libraries are not sufficiently
|
||||||
|
reentrant to make this safe.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Pay special attention to realloc() usage - more often then not the
|
||||||
|
function is not used correctly.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>When using a fixed size buffers, use sizeof() to prevent lossage
|
||||||
|
when a buffer size is changed but the code which uses it isn't. For
|
||||||
|
example:
|
||||||
|
<LISTING>
|
||||||
|
char buf[1024];
|
||||||
|
struct foo { ... };
|
||||||
|
...
|
||||||
|
BAD:
|
||||||
|
xxx(buf, 1024)
|
||||||
|
xxx(yyy, sizeof(struct foo))
|
||||||
|
GOOD:
|
||||||
|
xxx(buf, sizeof(buf))
|
||||||
|
xxx(yyy, sizeof(yyy))
|
||||||
|
</LISTING>
|
||||||
|
Be careful though with sizeof of pointers when you really want the size
|
||||||
|
of where it points to!
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Every time you see "char foo[###]", check every usage of foo to make
|
||||||
|
sure that it can't be overflowed. If you can't avoid overflow (and cases
|
||||||
|
of this have been seen), then at least malloc the buffer so that one can't
|
||||||
|
walk on the stack.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Always close file descriptors as soon as you can - this makes it more
|
||||||
|
likely that the stdio buffer contents will be discarded. In library
|
||||||
|
routines, always set any file descriptors that you open to close-on-exec.
|
||||||
|
<P><P></LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P><B>Other questions you may ask yourself are:</B></P>
|
<A NAME=tat></A>
|
||||||
|
<H2>FreeBSD Security Tips and Tricks</H2>
|
||||||
|
<P>There are several steps one must take to secure a FreeBSD system, or
|
||||||
|
in fact any Unix system:
|
||||||
<UL>
|
<UL>
|
||||||
<LI>Who do I warn? You can contact the security officer, or even the
|
|
||||||
local authorities. The choice is up to you.</LI>
|
|
||||||
|
|
||||||
<LI>Do I want to trace the person responsible? By not fixing the hole
|
<LI>Disabling potentially dangerous software<BR><P></P>
|
||||||
right away, you have a chance to catch the cracker. Then again, you have
|
A lot of software has to be run as a special privileged user to make
|
||||||
the chance the cracker wipes your disk. The choice is up to you.</LI>
|
use of specific resources, by making the executable set-uid. An
|
||||||
|
example is UUCP or PPP software that makes use of a serial port, or
|
||||||
|
sendmail which has to write in the mail spool and bind to a privileged
|
||||||
|
network port. When you are not using UUCP, it is of little use to have
|
||||||
|
software on your system and it may be wise to disable it. Of course,
|
||||||
|
this requires good knowledge of what can be thrown away and what not,
|
||||||
|
as well as good indication whether or not you will want the functionality
|
||||||
|
in the future.<BR><P></P>
|
||||||
|
Also some utilities you may find not useful enough to have them
|
||||||
|
around and pose a possible security risk, like swapinfo. If you remove
|
||||||
|
the set-uid bit for the executable (via 'chmod ug-s filename' command)
|
||||||
|
you can always keep on using swapinfo when you're root. It is however
|
||||||
|
not a good idea stripping so many sbits you have to be root all
|
||||||
|
the time.<BR><P></P>
|
||||||
|
Not only remove programs that you don't use, also remove services you
|
||||||
|
don't want or need to provide. This can be done by editing the
|
||||||
|
<TT>/etc/inetd.conf</TT> and <TT>/etc/rc.conf</TT> files and turning
|
||||||
|
off all services you don't use.<P></P>
|
||||||
|
|
||||||
|
<LI>Fixing software which has security bugs (or how to stay one step ahead
|
||||||
|
of crackers)<BR><P></P>
|
||||||
|
Make sure you are subscribed to various <A HREF="#ml">FreeBSD Security
|
||||||
|
mailing lists</A> so you could get updates on security bugs and get
|
||||||
|
fixes. Apply the fixes immediately.<P></P>
|
||||||
|
|
||||||
|
<LI>Backups - repair your system if security breach does occur<BR><P></P>
|
||||||
|
Always have backups and a clean version of the operating system (e.g. on
|
||||||
|
CD-Rom). Make sure your backups don't contain corrupted or modified by
|
||||||
|
attackers data.<P></P>
|
||||||
|
|
||||||
|
<LI>Install software to watch the state of the system<BR><P></P>
|
||||||
|
Programs like the tcp wrappers and tripwire (both in packages/ports) can
|
||||||
|
help you to monitor activity on your system. This makes it easier
|
||||||
|
to detect break-ins. Also read outputs of the /etc/security scripts
|
||||||
|
which are run daily and mailed to the root account.<P></P>
|
||||||
|
|
||||||
|
<LI>Educating the people who work on the system<BR><P></P>
|
||||||
|
Users should know that they are doing. They should be told to never give
|
||||||
|
out their password to anyone and to also use hard to guess passwords.
|
||||||
|
Let them understand that the security of the system/network is partly
|
||||||
|
in their hands.<P></P>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<H2><A href="secure.html">How to secure a FreeBSD system</A></H2>
|
|
||||||
|
|
||||||
<P>There are several steps involved in securing a FreeBSD system, or in
|
<P>There is also a FreeBSD Security How-To available which provides some
|
||||||
fact, any UNIX system:</P>
|
advanced tips on how to improve security of your system. You can
|
||||||
|
find it at <A HREF="http://www.freebsd.org/~jkb/howto.html">
|
||||||
|
http://www.freebsd.org/~jkb/howto.html</A>.</P>
|
||||||
|
<P>Security is an ongoing process. Make sure you are following the latest
|
||||||
|
developments in the security arena.</P>
|
||||||
|
|
||||||
<H2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></H2>
|
<A NAME=misc></A>
|
||||||
|
<H2>What to do when you detect a security compromise</H2>
|
||||||
|
|
||||||
<H2>Other useful security information:</H2>
|
<UL>
|
||||||
|
<LI><B>Determine the level of the security breach</B><BR>
|
||||||
|
What privileges did the attacker get? Did the attacker managed to get
|
||||||
|
root access? Did the attacker only managed to get user level access?</LI>
|
||||||
|
|
||||||
|
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||||
|
tampered with</B><BR>
|
||||||
|
What software has been tampered with? Was new kernel installed? Were any
|
||||||
|
of the system binaries (such as telnetd, login, etc) modified? If you
|
||||||
|
believe an attacker could have done any tampering with an OS, you may want
|
||||||
|
to re-install the operating system from a safe medium.</LI>
|
||||||
|
|
||||||
|
<LI><B>Find out how the break-in was done</B><BR>
|
||||||
|
Did the breaking occur via a well know security bug? If that is the case,
|
||||||
|
make sure to install the correct patches. Was the breaking successful due
|
||||||
|
to a misconfiguration? Was the breakin result of a new bug? If you believe
|
||||||
|
the breakin occurred via a new bug, you should warn the
|
||||||
|
<A HREF="mailto:security-officer@freebsd.org"> FreeBSD Security
|
||||||
|
Officer</A>.</LI>
|
||||||
|
|
||||||
|
<LI><B>Fix the security hole</B><BR>
|
||||||
|
Install new software or apply patches to the old one in order to fix the
|
||||||
|
problems. Disable already compromised accounts.</LI>
|
||||||
|
|
||||||
|
<LI><B>Other resources</B><BR>
|
||||||
|
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||||
|
<A HREF="http://www.cert.org/nav/recovering.html">detailed information</A>
|
||||||
|
on what steps to take in case of a system compromise.</LI>
|
||||||
|
</UL>
|
||||||
|
|
||||||
|
<H2>Other Related Security Information</H2>
|
||||||
<UL>
|
<UL>
|
||||||
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
|
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
|
||||||
archive</A>
|
archive</A> contains a huge collection of security related materials.</LI>
|
||||||
Contains a huge collection of security related material.</LI>
|
|
||||||
|
|
||||||
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">
|
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">The COAST Security
|
||||||
The COAST Security hotlist</A>
|
Hotlist</A> is the place to start looking for security related materials.
|
||||||
This page is THE place to start looking for security related
|
It contains hundreds of useful security pointers. Everything you always
|
||||||
material. It contains hundreds of useful
|
wanted to know about security... and more.</LI>
|
||||||
security pointers. Everything you always wanted to know about
|
|
||||||
security...and more...</LI>
|
|
||||||
|
|
||||||
<LI>The various CERTs (e.g. <A href="http://www.cert.org/">www.cert.org</A> and
|
<LI>The various CERT teams such as <A href="http://www.cert.org">
|
||||||
<A href="http://www.auscert.org.au/">www.auscert.org.au</A>)</LI>
|
http://www.cert.org</A> and <A href="http://www.auscert.org.au">
|
||||||
|
http://www.auscert.org.au</A>.</LI>
|
||||||
<li><a href="http://SecurityPortal.com/">SecurityPortal.com</a>
|
|
||||||
is intended to be the comprehensive Web site for Internet
|
|
||||||
Security. It is dedicated to providing corporate security professionals
|
|
||||||
with the information and resources needed to protect their networks. We
|
|
||||||
summarize breaking security news and provide a jumping off point for
|
|
||||||
Security Alerts, Products, Tools, Tips & Tricks and other Resources.
|
|
||||||
</li>
|
|
||||||
|
|
||||||
<LI>Mailing lists: Bugtraq, BOS, etc.</LI>
|
|
||||||
|
|
||||||
|
<LI>Mailing lists such as <A HREF="http://www.geek-girl.com/bugtraq/">
|
||||||
|
Bugtraq</A> and <A HREF="http://www.nfr.net/forum/firewall-wizards.html">
|
||||||
|
Firewall Wizards</A>.</LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
&footer
|
&footer
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
|
|
@ -1,77 +1,95 @@
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
||||||
<!ENTITY base CDATA "..">
|
<!ENTITY base CDATA "..">
|
||||||
<!ENTITY date "$Date: 1998-12-13 23:19:25 $">
|
<!ENTITY date "$Date: 1998-12-19 09:55:30 $">
|
||||||
<!ENTITY title "FreeBSD Security Guide">
|
<!ENTITY title "FreeBSD Security Information">
|
||||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||||
]>
|
]>
|
||||||
<!-- $Id: security.sgml,v 1.8 1998-12-13 23:19:25 steve Exp $ -->
|
<!-- $Id: security.sgml,v 1.9 1998-12-19 09:55:30 jkh Exp $ -->
|
||||||
|
|
||||||
<html>
|
<html>
|
||||||
&header;
|
&header;
|
||||||
|
|
||||||
<P>This guide attempts to document some of the tips and tricks used by
|
<H2>Introduction</H2>
|
||||||
many FreeBSD security experts for securing systems and writing secure
|
|
||||||
code. It is designed to help you learn about the various ways of protecting
|
|
||||||
a FreeBSD system against outside attacks and how to recover from such attacks
|
|
||||||
if and when they should happen. It also lists the various ways in which
|
|
||||||
the systems programmer can become more security conscious so he will
|
|
||||||
less likely introduce security holes in the first place.</P>
|
|
||||||
|
|
||||||
<P>We welcome your comments on the contents and correctness of this page.
|
<P>This web page is designed to assist both new and experienced users
|
||||||
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
|
in the area of security for the FreeBSD Operating System. The FreeBSD
|
||||||
FreeBSD Security Officers</A> if you have changes you'd like to see here.</P>
|
Development team takes security very seriously and is constantly working
|
||||||
|
on making the OS as secure as possible.</P>
|
||||||
|
|
||||||
<H2>The FreeBSD security officer</H2>
|
<P>Here you will find additional information, or links to information,
|
||||||
|
on how to protect your system against various types of outside attack,
|
||||||
|
whom to contact if you find a security related bug, etc. There is
|
||||||
|
also a section on the various ways that the systems programmer can
|
||||||
|
become more security conscious so he or she is less likely to
|
||||||
|
introduce security holes in the first place.</P>
|
||||||
|
|
||||||
<P>FreeBSD takes security seriously, a dedicated team of security officers
|
<H2>Table Of Content</H2>
|
||||||
providing a focal point for security related communications. A security
|
<UL>
|
||||||
officers' main task is to send out advisories when there are known security
|
<LI><A HREF="#sec">Information about the FreeBSD Security Officer</A></LI>
|
||||||
holes and otherwise keep abreast of security issues. The security officers
|
<LI><A HREF="#adv">FreeBSD Security Advisories</A></LI>
|
||||||
also communicate with the various <A HREF="http://www.cert.org/">CERT</A>
|
<LI><A HREF="#ml">FreeBSD Security Mailing Lists Information</A></LI>
|
||||||
and <A HREF="http://www.first.org/">FIRST</A> teams around the world,
|
<LI><A HREF="#tat">FreeBSD Security Tips and Tricks</A></LI>
|
||||||
sharing information about vulnerabilities in FreeBSD or utilities commonly
|
<LI><A HREF="#spg">Secure Programing Guidelines</A></LI>
|
||||||
used by FreeBSD, and keeping up to date on security issues in the world at
|
<LI><A HREF="#misc">Other Related Security Information</A></LI>
|
||||||
large. The security officers are also active members of those
|
</UL>
|
||||||
organizations.</P>
|
|
||||||
|
|
||||||
<P>When you need to contact the security officers about a sensitive matter,
|
<A NAME=sec></A>
|
||||||
please use their
|
<H2>The FreeBSD Security Officer</H2>
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
|
|
||||||
to encrypt your message before sending it.</P>
|
|
||||||
|
|
||||||
<H2>FreeBSD security advisories:</H2>
|
<P>To better coordinate information exchange with others in the security
|
||||||
|
community, FreeBSD has a focal point for security related communications:
|
||||||
|
The FreeBSD <a href="mailto:security-officer@freebsd.org">security officer</a>.
|
||||||
|
The position is actually staffed by a team of dedicated security officers,
|
||||||
|
their main tasks being to send out advisories when there are known security
|
||||||
|
holes and to act on reports of possible security problems with FreeBSD.</P>
|
||||||
|
|
||||||
<P>The FreeBSD security officers provide security advisories for
|
<P>If you need to contact someone from the FreeBSD team about a
|
||||||
the following releases of FreeBSD:</P>
|
possible security bug, you should therefore please <A
|
||||||
|
HREF="mailto:security-officer@FreeBSD.org">send mail to the Security Officer</A>
|
||||||
|
with a description of what you've found and the type of vulnerability it
|
||||||
|
represents. The Security Officers also communicate with the various
|
||||||
|
<A HREF="http://www.cert.org">CERT </A>and <A
|
||||||
|
HREF="http://www.first.org/"> FIRST</A> teams around the world,
|
||||||
|
sharing information about possible vulnerabilities in FreeBSD or
|
||||||
|
utilities commonly used by FreeBSD. The Security Officers are also
|
||||||
|
active members of those organizations.</P>
|
||||||
|
|
||||||
|
<P>If you do need to contact the Security Officer about a particularly
|
||||||
|
sensitive matter, please use their <A
|
||||||
|
HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key
|
||||||
|
</A> to encrypt your message before sending it.</P>
|
||||||
|
|
||||||
|
<A NAME=adv></A>
|
||||||
|
<H2>FreeBSD Security Advisories</H2>
|
||||||
|
|
||||||
|
<P>The FreeBSD Security Officers provide security advisories for the
|
||||||
|
following releases of FreeBSD:</P>
|
||||||
|
|
||||||
<UL>
|
<UL>
|
||||||
<LI> the most recent official release of FreeBSD,
|
<LI> The most recent official release of FreeBSD.
|
||||||
<LI> FreeBSD-current,
|
<LI> FreeBSD-current.
|
||||||
<LI> FreeBSD-stable, when at least 2 releases are based on it.
|
<LI> FreeBSD-stable, when at least 2 releases are based on it.
|
||||||
<LI> the previous FreeBSD-stable when a "new stable" does not
|
<LI> The previous FreeBSD-stable when a "new stable" does not yet
|
||||||
yet have 2 releases based on it.
|
have 2 releases based on it.
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
At this time, security advisories are available for:
|
At this time, security advisories are available for:
|
||||||
<UL>
|
<UL>
|
||||||
<LI> FreeBSD 2.2.6
|
<LI> FreeBSD 2.2.7
|
||||||
|
<LI> FreeBSD 2.2.8
|
||||||
|
<LI> FreeBSD 3.0
|
||||||
<LI> FreeBSD-current
|
<LI> FreeBSD-current
|
||||||
<LI> FreeBSD-stable
|
<LI> FreeBSD-stable
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P>Older releases will not be actively maintained and users are strongly
|
<P>Older releases are not maintained and users are strongly encouraged
|
||||||
encouraged to upgrade to one of the supported releases.</P>
|
to upgrade to one of the supported releases mentioned above.</P>
|
||||||
|
|
||||||
<P>An advisory will be sent out when a security hole exists that is
|
|
||||||
either being actively abused (as indicated to us via reports from end
|
|
||||||
users or CERT like organizations), or when the security hole is public
|
|
||||||
knowledge (e.g. because a report has been posted to a public mailing
|
|
||||||
list).</P>
|
|
||||||
|
|
||||||
<P>Like all development efforts, security fixes are first brought into
|
<P>Like all development efforts, security fixes are first brought into
|
||||||
the <A HREF="../handbook/current.html">FreeBSD-current</A>
|
the <A HREF="../handbook/current.html">FreeBSD-current</A> branch.
|
||||||
branch. After a couple of days and some testing, the fix is retrofitted
|
After a couple of days and some testing, the fix is retrofitted into
|
||||||
into the supported FreeBSD-stable branch(es) and an advisory then sent out.</P>
|
the supported FreeBSD-stable branch(es) and an advisory then sent
|
||||||
|
out.</P>
|
||||||
|
|
||||||
<P>Advisories are sent to the following FreeBSD mailing lists:
|
<P>Advisories are sent to the following FreeBSD mailing lists:
|
||||||
<UL>
|
<UL>
|
||||||
|
|
@ -80,9 +98,10 @@ into the supported FreeBSD-stable branch(es) and an advisory then sent out.</P>
|
||||||
<LI>FreeBSD-announce@freebsd.org
|
<LI>FreeBSD-announce@freebsd.org
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P>Advisories are always signed using the FreeBSD security officer
|
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
|
<P>Advisories are always signed using the FreeBSD Security Officer
|
||||||
and are archived, along with their associated patches, at our
|
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc"> PGP key
|
||||||
|
</A> and are archived, along with their associated patches, at our
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
||||||
repository</A>. At the time of this writing, the following advisories are
|
repository</A>. At the time of this writing, the following advisories are
|
||||||
currently available:</P>
|
currently available:</P>
|
||||||
|
|
@ -117,98 +136,317 @@ currently available:</P>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
|
||||||
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:07.rst.asc">FreeBSD-SA-98:07.rst.asc</A></LI>
|
||||||
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:08.fragment.asc">FreeBSD-SA-98:08.fragment.asc</A></LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<H2>FreeBSD security related information</H2>
|
<A NAME=ml></A>
|
||||||
|
<H2>FreeBSD Security Mailing Lists Information</H2>
|
||||||
|
|
||||||
<P>If you want to stay up to date on FreeBSD security, you can subscribe
|
<P>If you are administering or using any number of FreeBSD systems, you
|
||||||
yorself to one of the following mailing lists:</P>
|
should probably be subscribed to one or more of the following lists:</P>
|
||||||
|
|
||||||
<PRE>
|
<PRE>
|
||||||
freebsd-security General security related discussion
|
freebsd-security General security related discussion
|
||||||
freebsd-security-notifications Security notifications (moderated mailing list)
|
freebsd-security-notification Security notifications (moderated mailing list)
|
||||||
</PRE>
|
</PRE>
|
||||||
|
|
||||||
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
|
Send mail to <A HREF="mailto:majordomo@freebsd.org">
|
||||||
with
|
majordomo@FreeBSD.ORG</A> with
|
||||||
<PRE>
|
<PRE>
|
||||||
subscribe <listname> [<optional address>]
|
subscribe <listname> [<optional address>]
|
||||||
</PRE>
|
</PRE>
|
||||||
in the body of the message in order to subscribe yourself.
|
in the body of the message in order to subscribe yourself.
|
||||||
|
For example:
|
||||||
|
<PRE>
|
||||||
|
% echo "subscribe freebsd-security" | mail majordomo@freebsd.org
|
||||||
|
</PRE>
|
||||||
|
and if you would like to unsubscribe from a mailing list:
|
||||||
|
<PRE>
|
||||||
|
% echo "unsubscribe freebsd-security" | mail majordomo@freebsd.org
|
||||||
|
</PRE>
|
||||||
|
|
||||||
<H2>What to do when you detect a security compromise:</H2>
|
<A NAME=spg></A>
|
||||||
|
<H2>Secure Programing Guidelines</H2>
|
||||||
|
<P><P><UL>
|
||||||
|
<LI>Never trust any source of input, i.e. command line arguments,
|
||||||
|
environment variables, configuration files, incoming TCP/UDP/ICMP packets,
|
||||||
|
hostname lookups, function arguments, etc. If the length of or contents of
|
||||||
|
the date received is at all subject to outside control, then the program or
|
||||||
|
function should watch for this when copying it around. Specific security
|
||||||
|
issues to watch for in this are are:
|
||||||
|
<P></P>
|
||||||
|
<UL>
|
||||||
|
|
||||||
<UL>
|
<LI>strcpy() and sprintf() calls from unbounded data. Use strncpy and
|
||||||
<LI><B>Determine the level of security breach:</B><BR>
|
snprintf() when the length is known (or implement some other form of
|
||||||
What privilege did the attack get? That of another user or more (up to
|
bounds-checking when the length is unknown). In fact, never ever use
|
||||||
root privileges)?</LI>
|
gets() or sprintf(), period. If you do - will send evil dwarfs after you.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
<LI><B>Determine those parts of the system which are not in their original state
|
<LI>If you have to check the user input so it does not contain bad
|
||||||
anymore:</B><BR>
|
characters of some sort, do NOT check for those bad characters. Instead
|
||||||
What software has been tampered with? You may decide to re-install the
|
simply verify that it consists ONLY of those characters that you do
|
||||||
operating system from a safe medium, or you might have MD5 checksums of
|
allow. In general concept is: disallow anything that is not
|
||||||
the original software with which you can check your system. The tripwire
|
explicitly allowed.
|
||||||
package also keeps MD5 checksums, though be aware that tripwire might
|
<P></P></LI>
|
||||||
be tampered with as well and be sure and use a known-good copy.</LI>
|
|
||||||
|
|
||||||
<LI><B>Find out how the breakin was done:</B><BR>
|
<LI>Read man pages for strncpy() and strncat() calls. Be sure to
|
||||||
Via a well-known security bug? A misconfiguration? If it's a new bug,
|
understand how they work!!! While strncpy() might not append a terminating
|
||||||
you should warn the <A HREF="mailto:security-officer@freebsd.org">
|
\0, strncat() on the other hand adds the \0.
|
||||||
FreeBSD Security Officer</A>.</LI>
|
<P></P></LI>
|
||||||
|
|
||||||
<LI><B>Fix the hole(s):</B><BR>
|
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||||
Install new software that fixes the problems. If you aren't able to get
|
the destination string wrong for, and getenv() can return strings much
|
||||||
a fix quickly, you should temporarily disable remote access to your system
|
longer then the program might expect. These two functions are one of the
|
||||||
until you have done so.</LI>
|
key ways an attack is often made on a program, causing it to overwrite stack
|
||||||
|
or variables by setting its environment variables to unexpected values. If
|
||||||
|
your program reads environment variables, be paranoid. Be very paranoid!
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Ever time you use open() or stat() call - ask yourself: "What if it
|
||||||
|
is a symbolic link?"
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Make sure to use mkstemp() instead of mktemp(), tempnam(), mkstemp() and
|
||||||
|
etc. Also make sure to look for races in /tmp in general, being aware that
|
||||||
|
there are very few things which can be atomic in /tmp:
|
||||||
|
<UL>
|
||||||
|
<LI>Creating a directory. This will either succeed or fail.</LI>
|
||||||
|
<LI>Opening a file O_CREAT | O_EXECL</LI>
|
||||||
|
</UL>
|
||||||
|
If you use mkstemp - above cases will be properly handled for you. Hence
|
||||||
|
all temp files should use mkstemp() to guarantee there is not race
|
||||||
|
condition and that the permissions are correct.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>If an attacker can force packets to go/come from another arbitrary
|
||||||
|
system then that attacker has complete control over the data that we get
|
||||||
|
and <B>NONE</B>of it should be trusted.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Never trust a configuration file is correctly formatted or that it was
|
||||||
|
generated by the appropriate utility. Don't trust user input such as
|
||||||
|
terminal names or language strings to be free of '/' or '../../../' if
|
||||||
|
there is any chance that they can be used in a path name. Don't trust
|
||||||
|
<B>ANY</B> paths supplied by the user when you are running setuid root.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Look for holes or weaknesses in how data is stored. All temp files
|
||||||
|
should have 600 permission in order to be protected from prying eyes.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Don't just grep for the usual suspects in programs which run with
|
||||||
|
elevated privileges. Look line by line for possible overflows in these
|
||||||
|
cases since there are a lot more ways to cause buffer overflows then
|
||||||
|
by abusing strcpy() and friends.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Just because you drop privileges somewhere, it does not mean that no
|
||||||
|
exploit is possible. The attacker may put the necessary code on the
|
||||||
|
stack to regain the privileges before executing /bin/sh.</LI></UL>
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Do uid management. Do drop privileges as soon as possible, and really
|
||||||
|
do drop them. Switching between euid and uid is NOT enough. Use setuid()
|
||||||
|
when you can.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Never display configuration file contents on errors. A line number and
|
||||||
|
perhaps position count is enough. This is true for all libs and for any
|
||||||
|
suid/sgid program.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Tips for those reviewing existing code for security problems:<P></P><UL>
|
||||||
|
|
||||||
|
<LI>If you are unsure of your security fixes, send them to a reviewer with
|
||||||
|
whom you have already arrangements for a second glance over your
|
||||||
|
code. Don't commit code you are not sure about since breaking something
|
||||||
|
in the name of security fix is rather embarrassing.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Those without CVS commit privileges should make sure that a reviewer
|
||||||
|
with such privileges is among the last to review the changes. That person
|
||||||
|
will both review and incorporate the final version you would like to have
|
||||||
|
go into the tree.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>When sending changes around for review, always use context or unidiff
|
||||||
|
format diffs - this way diffs can be easily fed to patch(1). Do not simply
|
||||||
|
send the whole files. Diffs are much easier to read and apply to local
|
||||||
|
sources (especially those in which multiple, simultaneous changes may be
|
||||||
|
taking place). All changed should be relative to the -current branch of
|
||||||
|
development.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Always directly test your changes (e.g. build and run the affected
|
||||||
|
sources) before sending them to a reviewer. Nobody likes being sent
|
||||||
|
obviously broken stuff for review, and it just makes it appear as though
|
||||||
|
the submitter didn't even really look at what he was (which is also hardly
|
||||||
|
confidence building). If you need accounts on a machine with a specific
|
||||||
|
version which you don't have available - just ask. The project has
|
||||||
|
resources available for exactly such purposes.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Note for committers: do not forget to retrofit -current patches into
|
||||||
|
the -stable branch as appropriate.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Do not needlessly rewrite code to suit your style/tastes - it only
|
||||||
|
makes the reviewer's job needlessly more difficult. Do so only if there
|
||||||
|
are clear reasons for it.</LI></UL
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Look out for programs doing complex things in with signal
|
||||||
|
handlers. Many routines in the various libraries are not sufficiently
|
||||||
|
reentrant to make this safe.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Pay special attention to realloc() usage - more often then not the
|
||||||
|
function is not used correctly.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>When using a fixed size buffers, use sizeof() to prevent lossage
|
||||||
|
when a buffer size is changed but the code which uses it isn't. For
|
||||||
|
example:
|
||||||
|
<LISTING>
|
||||||
|
char buf[1024];
|
||||||
|
struct foo { ... };
|
||||||
|
...
|
||||||
|
BAD:
|
||||||
|
xxx(buf, 1024)
|
||||||
|
xxx(yyy, sizeof(struct foo))
|
||||||
|
GOOD:
|
||||||
|
xxx(buf, sizeof(buf))
|
||||||
|
xxx(yyy, sizeof(yyy))
|
||||||
|
</LISTING>
|
||||||
|
Be careful though with sizeof of pointers when you really want the size
|
||||||
|
of where it points to!
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Every time you see "char foo[###]", check every usage of foo to make
|
||||||
|
sure that it can't be overflowed. If you can't avoid overflow (and cases
|
||||||
|
of this have been seen), then at least malloc the buffer so that one can't
|
||||||
|
walk on the stack.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Always close file descriptors as soon as you can - this makes it more
|
||||||
|
likely that the stdio buffer contents will be discarded. In library
|
||||||
|
routines, always set any file descriptors that you open to close-on-exec.
|
||||||
|
<P><P></LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P><B>Other questions you may ask yourself are:</B></P>
|
<A NAME=tat></A>
|
||||||
|
<H2>FreeBSD Security Tips and Tricks</H2>
|
||||||
|
<P>There are several steps one must take to secure a FreeBSD system, or
|
||||||
|
in fact any Unix system:
|
||||||
<UL>
|
<UL>
|
||||||
<LI>Who do I warn? You can contact the security officer, or even the
|
|
||||||
local authorities. The choice is up to you.</LI>
|
|
||||||
|
|
||||||
<LI>Do I want to trace the person responsible? By not fixing the hole
|
<LI>Disabling potentially dangerous software<BR><P></P>
|
||||||
right away, you have a chance to catch the cracker. Then again, you have
|
A lot of software has to be run as a special privileged user to make
|
||||||
the chance the cracker wipes your disk. The choice is up to you.</LI>
|
use of specific resources, by making the executable set-uid. An
|
||||||
|
example is UUCP or PPP software that makes use of a serial port, or
|
||||||
|
sendmail which has to write in the mail spool and bind to a privileged
|
||||||
|
network port. When you are not using UUCP, it is of little use to have
|
||||||
|
software on your system and it may be wise to disable it. Of course,
|
||||||
|
this requires good knowledge of what can be thrown away and what not,
|
||||||
|
as well as good indication whether or not you will want the functionality
|
||||||
|
in the future.<BR><P></P>
|
||||||
|
Also some utilities you may find not useful enough to have them
|
||||||
|
around and pose a possible security risk, like swapinfo. If you remove
|
||||||
|
the set-uid bit for the executable (via 'chmod ug-s filename' command)
|
||||||
|
you can always keep on using swapinfo when you're root. It is however
|
||||||
|
not a good idea stripping so many sbits you have to be root all
|
||||||
|
the time.<BR><P></P>
|
||||||
|
Not only remove programs that you don't use, also remove services you
|
||||||
|
don't want or need to provide. This can be done by editing the
|
||||||
|
<TT>/etc/inetd.conf</TT> and <TT>/etc/rc.conf</TT> files and turning
|
||||||
|
off all services you don't use.<P></P>
|
||||||
|
|
||||||
|
<LI>Fixing software which has security bugs (or how to stay one step ahead
|
||||||
|
of crackers)<BR><P></P>
|
||||||
|
Make sure you are subscribed to various <A HREF="#ml">FreeBSD Security
|
||||||
|
mailing lists</A> so you could get updates on security bugs and get
|
||||||
|
fixes. Apply the fixes immediately.<P></P>
|
||||||
|
|
||||||
|
<LI>Backups - repair your system if security breach does occur<BR><P></P>
|
||||||
|
Always have backups and a clean version of the operating system (e.g. on
|
||||||
|
CD-Rom). Make sure your backups don't contain corrupted or modified by
|
||||||
|
attackers data.<P></P>
|
||||||
|
|
||||||
|
<LI>Install software to watch the state of the system<BR><P></P>
|
||||||
|
Programs like the tcp wrappers and tripwire (both in packages/ports) can
|
||||||
|
help you to monitor activity on your system. This makes it easier
|
||||||
|
to detect break-ins. Also read outputs of the /etc/security scripts
|
||||||
|
which are run daily and mailed to the root account.<P></P>
|
||||||
|
|
||||||
|
<LI>Educating the people who work on the system<BR><P></P>
|
||||||
|
Users should know that they are doing. They should be told to never give
|
||||||
|
out their password to anyone and to also use hard to guess passwords.
|
||||||
|
Let them understand that the security of the system/network is partly
|
||||||
|
in their hands.<P></P>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<H2><A href="secure.html">How to secure a FreeBSD system</A></H2>
|
|
||||||
|
|
||||||
<P>There are several steps involved in securing a FreeBSD system, or in
|
<P>There is also a FreeBSD Security How-To available which provides some
|
||||||
fact, any UNIX system:</P>
|
advanced tips on how to improve security of your system. You can
|
||||||
|
find it at <A HREF="http://www.freebsd.org/~jkb/howto.html">
|
||||||
|
http://www.freebsd.org/~jkb/howto.html</A>.</P>
|
||||||
|
<P>Security is an ongoing process. Make sure you are following the latest
|
||||||
|
developments in the security arena.</P>
|
||||||
|
|
||||||
<H2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></H2>
|
<A NAME=misc></A>
|
||||||
|
<H2>What to do when you detect a security compromise</H2>
|
||||||
|
|
||||||
<H2>Other useful security information:</H2>
|
<UL>
|
||||||
|
<LI><B>Determine the level of the security breach</B><BR>
|
||||||
|
What privileges did the attacker get? Did the attacker managed to get
|
||||||
|
root access? Did the attacker only managed to get user level access?</LI>
|
||||||
|
|
||||||
|
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||||
|
tampered with</B><BR>
|
||||||
|
What software has been tampered with? Was new kernel installed? Were any
|
||||||
|
of the system binaries (such as telnetd, login, etc) modified? If you
|
||||||
|
believe an attacker could have done any tampering with an OS, you may want
|
||||||
|
to re-install the operating system from a safe medium.</LI>
|
||||||
|
|
||||||
|
<LI><B>Find out how the break-in was done</B><BR>
|
||||||
|
Did the breaking occur via a well know security bug? If that is the case,
|
||||||
|
make sure to install the correct patches. Was the breaking successful due
|
||||||
|
to a misconfiguration? Was the breakin result of a new bug? If you believe
|
||||||
|
the breakin occurred via a new bug, you should warn the
|
||||||
|
<A HREF="mailto:security-officer@freebsd.org"> FreeBSD Security
|
||||||
|
Officer</A>.</LI>
|
||||||
|
|
||||||
|
<LI><B>Fix the security hole</B><BR>
|
||||||
|
Install new software or apply patches to the old one in order to fix the
|
||||||
|
problems. Disable already compromised accounts.</LI>
|
||||||
|
|
||||||
|
<LI><B>Other resources</B><BR>
|
||||||
|
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||||
|
<A HREF="http://www.cert.org/nav/recovering.html">detailed information</A>
|
||||||
|
on what steps to take in case of a system compromise.</LI>
|
||||||
|
</UL>
|
||||||
|
|
||||||
|
<H2>Other Related Security Information</H2>
|
||||||
<UL>
|
<UL>
|
||||||
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
|
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
|
||||||
archive</A>
|
archive</A> contains a huge collection of security related materials.</LI>
|
||||||
Contains a huge collection of security related material.</LI>
|
|
||||||
|
|
||||||
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">
|
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">The COAST Security
|
||||||
The COAST Security hotlist</A>
|
Hotlist</A> is the place to start looking for security related materials.
|
||||||
This page is THE place to start looking for security related
|
It contains hundreds of useful security pointers. Everything you always
|
||||||
material. It contains hundreds of useful
|
wanted to know about security... and more.</LI>
|
||||||
security pointers. Everything you always wanted to know about
|
|
||||||
security...and more...</LI>
|
|
||||||
|
|
||||||
<LI>The various CERTs (e.g. <A href="http://www.cert.org/">www.cert.org</A> and
|
<LI>The various CERT teams such as <A href="http://www.cert.org">
|
||||||
<A href="http://www.auscert.org.au/">www.auscert.org.au</A>)</LI>
|
http://www.cert.org</A> and <A href="http://www.auscert.org.au">
|
||||||
|
http://www.auscert.org.au</A>.</LI>
|
||||||
<li><a href="http://SecurityPortal.com/">SecurityPortal.com</a>
|
|
||||||
is intended to be the comprehensive Web site for Internet
|
|
||||||
Security. It is dedicated to providing corporate security professionals
|
|
||||||
with the information and resources needed to protect their networks. We
|
|
||||||
summarize breaking security news and provide a jumping off point for
|
|
||||||
Security Alerts, Products, Tools, Tips & Tricks and other Resources.
|
|
||||||
</li>
|
|
||||||
|
|
||||||
<LI>Mailing lists: Bugtraq, BOS, etc.</LI>
|
|
||||||
|
|
||||||
|
<LI>Mailing lists such as <A HREF="http://www.geek-girl.com/bugtraq/">
|
||||||
|
Bugtraq</A> and <A HREF="http://www.nfr.net/forum/firewall-wizards.html">
|
||||||
|
Firewall Wizards</A>.</LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
&footer
|
&footer
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
|
|
@ -1,77 +1,95 @@
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
||||||
<!ENTITY base CDATA "..">
|
<!ENTITY base CDATA "..">
|
||||||
<!ENTITY date "$Date: 1998-12-13 23:19:25 $">
|
<!ENTITY date "$Date: 1998-12-19 09:55:30 $">
|
||||||
<!ENTITY title "FreeBSD Security Guide">
|
<!ENTITY title "FreeBSD Security Information">
|
||||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||||
]>
|
]>
|
||||||
<!-- $Id: advisories.xml,v 1.8 1998-12-13 23:19:25 steve Exp $ -->
|
<!-- $Id: advisories.xml,v 1.9 1998-12-19 09:55:30 jkh Exp $ -->
|
||||||
|
|
||||||
<html>
|
<html>
|
||||||
&header;
|
&header;
|
||||||
|
|
||||||
<P>This guide attempts to document some of the tips and tricks used by
|
<H2>Introduction</H2>
|
||||||
many FreeBSD security experts for securing systems and writing secure
|
|
||||||
code. It is designed to help you learn about the various ways of protecting
|
|
||||||
a FreeBSD system against outside attacks and how to recover from such attacks
|
|
||||||
if and when they should happen. It also lists the various ways in which
|
|
||||||
the systems programmer can become more security conscious so he will
|
|
||||||
less likely introduce security holes in the first place.</P>
|
|
||||||
|
|
||||||
<P>We welcome your comments on the contents and correctness of this page.
|
<P>This web page is designed to assist both new and experienced users
|
||||||
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
|
in the area of security for the FreeBSD Operating System. The FreeBSD
|
||||||
FreeBSD Security Officers</A> if you have changes you'd like to see here.</P>
|
Development team takes security very seriously and is constantly working
|
||||||
|
on making the OS as secure as possible.</P>
|
||||||
|
|
||||||
<H2>The FreeBSD security officer</H2>
|
<P>Here you will find additional information, or links to information,
|
||||||
|
on how to protect your system against various types of outside attack,
|
||||||
|
whom to contact if you find a security related bug, etc. There is
|
||||||
|
also a section on the various ways that the systems programmer can
|
||||||
|
become more security conscious so he or she is less likely to
|
||||||
|
introduce security holes in the first place.</P>
|
||||||
|
|
||||||
<P>FreeBSD takes security seriously, a dedicated team of security officers
|
<H2>Table Of Content</H2>
|
||||||
providing a focal point for security related communications. A security
|
<UL>
|
||||||
officers' main task is to send out advisories when there are known security
|
<LI><A HREF="#sec">Information about the FreeBSD Security Officer</A></LI>
|
||||||
holes and otherwise keep abreast of security issues. The security officers
|
<LI><A HREF="#adv">FreeBSD Security Advisories</A></LI>
|
||||||
also communicate with the various <A HREF="http://www.cert.org/">CERT</A>
|
<LI><A HREF="#ml">FreeBSD Security Mailing Lists Information</A></LI>
|
||||||
and <A HREF="http://www.first.org/">FIRST</A> teams around the world,
|
<LI><A HREF="#tat">FreeBSD Security Tips and Tricks</A></LI>
|
||||||
sharing information about vulnerabilities in FreeBSD or utilities commonly
|
<LI><A HREF="#spg">Secure Programing Guidelines</A></LI>
|
||||||
used by FreeBSD, and keeping up to date on security issues in the world at
|
<LI><A HREF="#misc">Other Related Security Information</A></LI>
|
||||||
large. The security officers are also active members of those
|
</UL>
|
||||||
organizations.</P>
|
|
||||||
|
|
||||||
<P>When you need to contact the security officers about a sensitive matter,
|
<A NAME=sec></A>
|
||||||
please use their
|
<H2>The FreeBSD Security Officer</H2>
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
|
|
||||||
to encrypt your message before sending it.</P>
|
|
||||||
|
|
||||||
<H2>FreeBSD security advisories:</H2>
|
<P>To better coordinate information exchange with others in the security
|
||||||
|
community, FreeBSD has a focal point for security related communications:
|
||||||
|
The FreeBSD <a href="mailto:security-officer@freebsd.org">security officer</a>.
|
||||||
|
The position is actually staffed by a team of dedicated security officers,
|
||||||
|
their main tasks being to send out advisories when there are known security
|
||||||
|
holes and to act on reports of possible security problems with FreeBSD.</P>
|
||||||
|
|
||||||
<P>The FreeBSD security officers provide security advisories for
|
<P>If you need to contact someone from the FreeBSD team about a
|
||||||
the following releases of FreeBSD:</P>
|
possible security bug, you should therefore please <A
|
||||||
|
HREF="mailto:security-officer@FreeBSD.org">send mail to the Security Officer</A>
|
||||||
|
with a description of what you've found and the type of vulnerability it
|
||||||
|
represents. The Security Officers also communicate with the various
|
||||||
|
<A HREF="http://www.cert.org">CERT </A>and <A
|
||||||
|
HREF="http://www.first.org/"> FIRST</A> teams around the world,
|
||||||
|
sharing information about possible vulnerabilities in FreeBSD or
|
||||||
|
utilities commonly used by FreeBSD. The Security Officers are also
|
||||||
|
active members of those organizations.</P>
|
||||||
|
|
||||||
|
<P>If you do need to contact the Security Officer about a particularly
|
||||||
|
sensitive matter, please use their <A
|
||||||
|
HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key
|
||||||
|
</A> to encrypt your message before sending it.</P>
|
||||||
|
|
||||||
|
<A NAME=adv></A>
|
||||||
|
<H2>FreeBSD Security Advisories</H2>
|
||||||
|
|
||||||
|
<P>The FreeBSD Security Officers provide security advisories for the
|
||||||
|
following releases of FreeBSD:</P>
|
||||||
|
|
||||||
<UL>
|
<UL>
|
||||||
<LI> the most recent official release of FreeBSD,
|
<LI> The most recent official release of FreeBSD.
|
||||||
<LI> FreeBSD-current,
|
<LI> FreeBSD-current.
|
||||||
<LI> FreeBSD-stable, when at least 2 releases are based on it.
|
<LI> FreeBSD-stable, when at least 2 releases are based on it.
|
||||||
<LI> the previous FreeBSD-stable when a "new stable" does not
|
<LI> The previous FreeBSD-stable when a "new stable" does not yet
|
||||||
yet have 2 releases based on it.
|
have 2 releases based on it.
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
At this time, security advisories are available for:
|
At this time, security advisories are available for:
|
||||||
<UL>
|
<UL>
|
||||||
<LI> FreeBSD 2.2.6
|
<LI> FreeBSD 2.2.7
|
||||||
|
<LI> FreeBSD 2.2.8
|
||||||
|
<LI> FreeBSD 3.0
|
||||||
<LI> FreeBSD-current
|
<LI> FreeBSD-current
|
||||||
<LI> FreeBSD-stable
|
<LI> FreeBSD-stable
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P>Older releases will not be actively maintained and users are strongly
|
<P>Older releases are not maintained and users are strongly encouraged
|
||||||
encouraged to upgrade to one of the supported releases.</P>
|
to upgrade to one of the supported releases mentioned above.</P>
|
||||||
|
|
||||||
<P>An advisory will be sent out when a security hole exists that is
|
|
||||||
either being actively abused (as indicated to us via reports from end
|
|
||||||
users or CERT like organizations), or when the security hole is public
|
|
||||||
knowledge (e.g. because a report has been posted to a public mailing
|
|
||||||
list).</P>
|
|
||||||
|
|
||||||
<P>Like all development efforts, security fixes are first brought into
|
<P>Like all development efforts, security fixes are first brought into
|
||||||
the <A HREF="../handbook/current.html">FreeBSD-current</A>
|
the <A HREF="../handbook/current.html">FreeBSD-current</A> branch.
|
||||||
branch. After a couple of days and some testing, the fix is retrofitted
|
After a couple of days and some testing, the fix is retrofitted into
|
||||||
into the supported FreeBSD-stable branch(es) and an advisory then sent out.</P>
|
the supported FreeBSD-stable branch(es) and an advisory then sent
|
||||||
|
out.</P>
|
||||||
|
|
||||||
<P>Advisories are sent to the following FreeBSD mailing lists:
|
<P>Advisories are sent to the following FreeBSD mailing lists:
|
||||||
<UL>
|
<UL>
|
||||||
|
|
@ -80,9 +98,10 @@ into the supported FreeBSD-stable branch(es) and an advisory then sent out.</P>
|
||||||
<LI>FreeBSD-announce@freebsd.org
|
<LI>FreeBSD-announce@freebsd.org
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P>Advisories are always signed using the FreeBSD security officer
|
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
|
<P>Advisories are always signed using the FreeBSD Security Officer
|
||||||
and are archived, along with their associated patches, at our
|
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc"> PGP key
|
||||||
|
</A> and are archived, along with their associated patches, at our
|
||||||
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT
|
||||||
repository</A>. At the time of this writing, the following advisories are
|
repository</A>. At the time of this writing, the following advisories are
|
||||||
currently available:</P>
|
currently available:</P>
|
||||||
|
|
@ -117,98 +136,317 @@ currently available:</P>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
|
||||||
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
|
||||||
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:07.rst.asc">FreeBSD-SA-98:07.rst.asc</A></LI>
|
||||||
|
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:08.fragment.asc">FreeBSD-SA-98:08.fragment.asc</A></LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<H2>FreeBSD security related information</H2>
|
<A NAME=ml></A>
|
||||||
|
<H2>FreeBSD Security Mailing Lists Information</H2>
|
||||||
|
|
||||||
<P>If you want to stay up to date on FreeBSD security, you can subscribe
|
<P>If you are administering or using any number of FreeBSD systems, you
|
||||||
yorself to one of the following mailing lists:</P>
|
should probably be subscribed to one or more of the following lists:</P>
|
||||||
|
|
||||||
<PRE>
|
<PRE>
|
||||||
freebsd-security General security related discussion
|
freebsd-security General security related discussion
|
||||||
freebsd-security-notifications Security notifications (moderated mailing list)
|
freebsd-security-notification Security notifications (moderated mailing list)
|
||||||
</PRE>
|
</PRE>
|
||||||
|
|
||||||
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
|
Send mail to <A HREF="mailto:majordomo@freebsd.org">
|
||||||
with
|
majordomo@FreeBSD.ORG</A> with
|
||||||
<PRE>
|
<PRE>
|
||||||
subscribe <listname> [<optional address>]
|
subscribe <listname> [<optional address>]
|
||||||
</PRE>
|
</PRE>
|
||||||
in the body of the message in order to subscribe yourself.
|
in the body of the message in order to subscribe yourself.
|
||||||
|
For example:
|
||||||
|
<PRE>
|
||||||
|
% echo "subscribe freebsd-security" | mail majordomo@freebsd.org
|
||||||
|
</PRE>
|
||||||
|
and if you would like to unsubscribe from a mailing list:
|
||||||
|
<PRE>
|
||||||
|
% echo "unsubscribe freebsd-security" | mail majordomo@freebsd.org
|
||||||
|
</PRE>
|
||||||
|
|
||||||
<H2>What to do when you detect a security compromise:</H2>
|
<A NAME=spg></A>
|
||||||
|
<H2>Secure Programing Guidelines</H2>
|
||||||
|
<P><P><UL>
|
||||||
|
<LI>Never trust any source of input, i.e. command line arguments,
|
||||||
|
environment variables, configuration files, incoming TCP/UDP/ICMP packets,
|
||||||
|
hostname lookups, function arguments, etc. If the length of or contents of
|
||||||
|
the date received is at all subject to outside control, then the program or
|
||||||
|
function should watch for this when copying it around. Specific security
|
||||||
|
issues to watch for in this are are:
|
||||||
|
<P></P>
|
||||||
|
<UL>
|
||||||
|
|
||||||
<UL>
|
<LI>strcpy() and sprintf() calls from unbounded data. Use strncpy and
|
||||||
<LI><B>Determine the level of security breach:</B><BR>
|
snprintf() when the length is known (or implement some other form of
|
||||||
What privilege did the attack get? That of another user or more (up to
|
bounds-checking when the length is unknown). In fact, never ever use
|
||||||
root privileges)?</LI>
|
gets() or sprintf(), period. If you do - will send evil dwarfs after you.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
<LI><B>Determine those parts of the system which are not in their original state
|
<LI>If you have to check the user input so it does not contain bad
|
||||||
anymore:</B><BR>
|
characters of some sort, do NOT check for those bad characters. Instead
|
||||||
What software has been tampered with? You may decide to re-install the
|
simply verify that it consists ONLY of those characters that you do
|
||||||
operating system from a safe medium, or you might have MD5 checksums of
|
allow. In general concept is: disallow anything that is not
|
||||||
the original software with which you can check your system. The tripwire
|
explicitly allowed.
|
||||||
package also keeps MD5 checksums, though be aware that tripwire might
|
<P></P></LI>
|
||||||
be tampered with as well and be sure and use a known-good copy.</LI>
|
|
||||||
|
|
||||||
<LI><B>Find out how the breakin was done:</B><BR>
|
<LI>Read man pages for strncpy() and strncat() calls. Be sure to
|
||||||
Via a well-known security bug? A misconfiguration? If it's a new bug,
|
understand how they work!!! While strncpy() might not append a terminating
|
||||||
you should warn the <A HREF="mailto:security-officer@freebsd.org">
|
\0, strncat() on the other hand adds the \0.
|
||||||
FreeBSD Security Officer</A>.</LI>
|
<P></P></LI>
|
||||||
|
|
||||||
<LI><B>Fix the hole(s):</B><BR>
|
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||||
Install new software that fixes the problems. If you aren't able to get
|
the destination string wrong for, and getenv() can return strings much
|
||||||
a fix quickly, you should temporarily disable remote access to your system
|
longer then the program might expect. These two functions are one of the
|
||||||
until you have done so.</LI>
|
key ways an attack is often made on a program, causing it to overwrite stack
|
||||||
|
or variables by setting its environment variables to unexpected values. If
|
||||||
|
your program reads environment variables, be paranoid. Be very paranoid!
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Ever time you use open() or stat() call - ask yourself: "What if it
|
||||||
|
is a symbolic link?"
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Make sure to use mkstemp() instead of mktemp(), tempnam(), mkstemp() and
|
||||||
|
etc. Also make sure to look for races in /tmp in general, being aware that
|
||||||
|
there are very few things which can be atomic in /tmp:
|
||||||
|
<UL>
|
||||||
|
<LI>Creating a directory. This will either succeed or fail.</LI>
|
||||||
|
<LI>Opening a file O_CREAT | O_EXECL</LI>
|
||||||
|
</UL>
|
||||||
|
If you use mkstemp - above cases will be properly handled for you. Hence
|
||||||
|
all temp files should use mkstemp() to guarantee there is not race
|
||||||
|
condition and that the permissions are correct.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>If an attacker can force packets to go/come from another arbitrary
|
||||||
|
system then that attacker has complete control over the data that we get
|
||||||
|
and <B>NONE</B>of it should be trusted.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Never trust a configuration file is correctly formatted or that it was
|
||||||
|
generated by the appropriate utility. Don't trust user input such as
|
||||||
|
terminal names or language strings to be free of '/' or '../../../' if
|
||||||
|
there is any chance that they can be used in a path name. Don't trust
|
||||||
|
<B>ANY</B> paths supplied by the user when you are running setuid root.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Look for holes or weaknesses in how data is stored. All temp files
|
||||||
|
should have 600 permission in order to be protected from prying eyes.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Don't just grep for the usual suspects in programs which run with
|
||||||
|
elevated privileges. Look line by line for possible overflows in these
|
||||||
|
cases since there are a lot more ways to cause buffer overflows then
|
||||||
|
by abusing strcpy() and friends.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Just because you drop privileges somewhere, it does not mean that no
|
||||||
|
exploit is possible. The attacker may put the necessary code on the
|
||||||
|
stack to regain the privileges before executing /bin/sh.</LI></UL>
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Do uid management. Do drop privileges as soon as possible, and really
|
||||||
|
do drop them. Switching between euid and uid is NOT enough. Use setuid()
|
||||||
|
when you can.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Never display configuration file contents on errors. A line number and
|
||||||
|
perhaps position count is enough. This is true for all libs and for any
|
||||||
|
suid/sgid program.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Tips for those reviewing existing code for security problems:<P></P><UL>
|
||||||
|
|
||||||
|
<LI>If you are unsure of your security fixes, send them to a reviewer with
|
||||||
|
whom you have already arrangements for a second glance over your
|
||||||
|
code. Don't commit code you are not sure about since breaking something
|
||||||
|
in the name of security fix is rather embarrassing.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Those without CVS commit privileges should make sure that a reviewer
|
||||||
|
with such privileges is among the last to review the changes. That person
|
||||||
|
will both review and incorporate the final version you would like to have
|
||||||
|
go into the tree.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>When sending changes around for review, always use context or unidiff
|
||||||
|
format diffs - this way diffs can be easily fed to patch(1). Do not simply
|
||||||
|
send the whole files. Diffs are much easier to read and apply to local
|
||||||
|
sources (especially those in which multiple, simultaneous changes may be
|
||||||
|
taking place). All changed should be relative to the -current branch of
|
||||||
|
development.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Always directly test your changes (e.g. build and run the affected
|
||||||
|
sources) before sending them to a reviewer. Nobody likes being sent
|
||||||
|
obviously broken stuff for review, and it just makes it appear as though
|
||||||
|
the submitter didn't even really look at what he was (which is also hardly
|
||||||
|
confidence building). If you need accounts on a machine with a specific
|
||||||
|
version which you don't have available - just ask. The project has
|
||||||
|
resources available for exactly such purposes.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Note for committers: do not forget to retrofit -current patches into
|
||||||
|
the -stable branch as appropriate.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Do not needlessly rewrite code to suit your style/tastes - it only
|
||||||
|
makes the reviewer's job needlessly more difficult. Do so only if there
|
||||||
|
are clear reasons for it.</LI></UL
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Look out for programs doing complex things in with signal
|
||||||
|
handlers. Many routines in the various libraries are not sufficiently
|
||||||
|
reentrant to make this safe.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Pay special attention to realloc() usage - more often then not the
|
||||||
|
function is not used correctly.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>When using a fixed size buffers, use sizeof() to prevent lossage
|
||||||
|
when a buffer size is changed but the code which uses it isn't. For
|
||||||
|
example:
|
||||||
|
<LISTING>
|
||||||
|
char buf[1024];
|
||||||
|
struct foo { ... };
|
||||||
|
...
|
||||||
|
BAD:
|
||||||
|
xxx(buf, 1024)
|
||||||
|
xxx(yyy, sizeof(struct foo))
|
||||||
|
GOOD:
|
||||||
|
xxx(buf, sizeof(buf))
|
||||||
|
xxx(yyy, sizeof(yyy))
|
||||||
|
</LISTING>
|
||||||
|
Be careful though with sizeof of pointers when you really want the size
|
||||||
|
of where it points to!
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Every time you see "char foo[###]", check every usage of foo to make
|
||||||
|
sure that it can't be overflowed. If you can't avoid overflow (and cases
|
||||||
|
of this have been seen), then at least malloc the buffer so that one can't
|
||||||
|
walk on the stack.
|
||||||
|
<P></P></LI>
|
||||||
|
|
||||||
|
<LI>Always close file descriptors as soon as you can - this makes it more
|
||||||
|
likely that the stdio buffer contents will be discarded. In library
|
||||||
|
routines, always set any file descriptors that you open to close-on-exec.
|
||||||
|
<P><P></LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<P><B>Other questions you may ask yourself are:</B></P>
|
<A NAME=tat></A>
|
||||||
|
<H2>FreeBSD Security Tips and Tricks</H2>
|
||||||
|
<P>There are several steps one must take to secure a FreeBSD system, or
|
||||||
|
in fact any Unix system:
|
||||||
<UL>
|
<UL>
|
||||||
<LI>Who do I warn? You can contact the security officer, or even the
|
|
||||||
local authorities. The choice is up to you.</LI>
|
|
||||||
|
|
||||||
<LI>Do I want to trace the person responsible? By not fixing the hole
|
<LI>Disabling potentially dangerous software<BR><P></P>
|
||||||
right away, you have a chance to catch the cracker. Then again, you have
|
A lot of software has to be run as a special privileged user to make
|
||||||
the chance the cracker wipes your disk. The choice is up to you.</LI>
|
use of specific resources, by making the executable set-uid. An
|
||||||
|
example is UUCP or PPP software that makes use of a serial port, or
|
||||||
|
sendmail which has to write in the mail spool and bind to a privileged
|
||||||
|
network port. When you are not using UUCP, it is of little use to have
|
||||||
|
software on your system and it may be wise to disable it. Of course,
|
||||||
|
this requires good knowledge of what can be thrown away and what not,
|
||||||
|
as well as good indication whether or not you will want the functionality
|
||||||
|
in the future.<BR><P></P>
|
||||||
|
Also some utilities you may find not useful enough to have them
|
||||||
|
around and pose a possible security risk, like swapinfo. If you remove
|
||||||
|
the set-uid bit for the executable (via 'chmod ug-s filename' command)
|
||||||
|
you can always keep on using swapinfo when you're root. It is however
|
||||||
|
not a good idea stripping so many sbits you have to be root all
|
||||||
|
the time.<BR><P></P>
|
||||||
|
Not only remove programs that you don't use, also remove services you
|
||||||
|
don't want or need to provide. This can be done by editing the
|
||||||
|
<TT>/etc/inetd.conf</TT> and <TT>/etc/rc.conf</TT> files and turning
|
||||||
|
off all services you don't use.<P></P>
|
||||||
|
|
||||||
|
<LI>Fixing software which has security bugs (or how to stay one step ahead
|
||||||
|
of crackers)<BR><P></P>
|
||||||
|
Make sure you are subscribed to various <A HREF="#ml">FreeBSD Security
|
||||||
|
mailing lists</A> so you could get updates on security bugs and get
|
||||||
|
fixes. Apply the fixes immediately.<P></P>
|
||||||
|
|
||||||
|
<LI>Backups - repair your system if security breach does occur<BR><P></P>
|
||||||
|
Always have backups and a clean version of the operating system (e.g. on
|
||||||
|
CD-Rom). Make sure your backups don't contain corrupted or modified by
|
||||||
|
attackers data.<P></P>
|
||||||
|
|
||||||
|
<LI>Install software to watch the state of the system<BR><P></P>
|
||||||
|
Programs like the tcp wrappers and tripwire (both in packages/ports) can
|
||||||
|
help you to monitor activity on your system. This makes it easier
|
||||||
|
to detect break-ins. Also read outputs of the /etc/security scripts
|
||||||
|
which are run daily and mailed to the root account.<P></P>
|
||||||
|
|
||||||
|
<LI>Educating the people who work on the system<BR><P></P>
|
||||||
|
Users should know that they are doing. They should be told to never give
|
||||||
|
out their password to anyone and to also use hard to guess passwords.
|
||||||
|
Let them understand that the security of the system/network is partly
|
||||||
|
in their hands.<P></P>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
<H2><A href="secure.html">How to secure a FreeBSD system</A></H2>
|
|
||||||
|
|
||||||
<P>There are several steps involved in securing a FreeBSD system, or in
|
<P>There is also a FreeBSD Security How-To available which provides some
|
||||||
fact, any UNIX system:</P>
|
advanced tips on how to improve security of your system. You can
|
||||||
|
find it at <A HREF="http://www.freebsd.org/~jkb/howto.html">
|
||||||
|
http://www.freebsd.org/~jkb/howto.html</A>.</P>
|
||||||
|
<P>Security is an ongoing process. Make sure you are following the latest
|
||||||
|
developments in the security arena.</P>
|
||||||
|
|
||||||
<H2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></H2>
|
<A NAME=misc></A>
|
||||||
|
<H2>What to do when you detect a security compromise</H2>
|
||||||
|
|
||||||
<H2>Other useful security information:</H2>
|
<UL>
|
||||||
|
<LI><B>Determine the level of the security breach</B><BR>
|
||||||
|
What privileges did the attacker get? Did the attacker managed to get
|
||||||
|
root access? Did the attacker only managed to get user level access?</LI>
|
||||||
|
|
||||||
|
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||||
|
tampered with</B><BR>
|
||||||
|
What software has been tampered with? Was new kernel installed? Were any
|
||||||
|
of the system binaries (such as telnetd, login, etc) modified? If you
|
||||||
|
believe an attacker could have done any tampering with an OS, you may want
|
||||||
|
to re-install the operating system from a safe medium.</LI>
|
||||||
|
|
||||||
|
<LI><B>Find out how the break-in was done</B><BR>
|
||||||
|
Did the breaking occur via a well know security bug? If that is the case,
|
||||||
|
make sure to install the correct patches. Was the breaking successful due
|
||||||
|
to a misconfiguration? Was the breakin result of a new bug? If you believe
|
||||||
|
the breakin occurred via a new bug, you should warn the
|
||||||
|
<A HREF="mailto:security-officer@freebsd.org"> FreeBSD Security
|
||||||
|
Officer</A>.</LI>
|
||||||
|
|
||||||
|
<LI><B>Fix the security hole</B><BR>
|
||||||
|
Install new software or apply patches to the old one in order to fix the
|
||||||
|
problems. Disable already compromised accounts.</LI>
|
||||||
|
|
||||||
|
<LI><B>Other resources</B><BR>
|
||||||
|
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||||
|
<A HREF="http://www.cert.org/nav/recovering.html">detailed information</A>
|
||||||
|
on what steps to take in case of a system compromise.</LI>
|
||||||
|
</UL>
|
||||||
|
|
||||||
|
<H2>Other Related Security Information</H2>
|
||||||
<UL>
|
<UL>
|
||||||
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
|
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
|
||||||
archive</A>
|
archive</A> contains a huge collection of security related materials.</LI>
|
||||||
Contains a huge collection of security related material.</LI>
|
|
||||||
|
|
||||||
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">
|
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">The COAST Security
|
||||||
The COAST Security hotlist</A>
|
Hotlist</A> is the place to start looking for security related materials.
|
||||||
This page is THE place to start looking for security related
|
It contains hundreds of useful security pointers. Everything you always
|
||||||
material. It contains hundreds of useful
|
wanted to know about security... and more.</LI>
|
||||||
security pointers. Everything you always wanted to know about
|
|
||||||
security...and more...</LI>
|
|
||||||
|
|
||||||
<LI>The various CERTs (e.g. <A href="http://www.cert.org/">www.cert.org</A> and
|
<LI>The various CERT teams such as <A href="http://www.cert.org">
|
||||||
<A href="http://www.auscert.org.au/">www.auscert.org.au</A>)</LI>
|
http://www.cert.org</A> and <A href="http://www.auscert.org.au">
|
||||||
|
http://www.auscert.org.au</A>.</LI>
|
||||||
<li><a href="http://SecurityPortal.com/">SecurityPortal.com</a>
|
|
||||||
is intended to be the comprehensive Web site for Internet
|
|
||||||
Security. It is dedicated to providing corporate security professionals
|
|
||||||
with the information and resources needed to protect their networks. We
|
|
||||||
summarize breaking security news and provide a jumping off point for
|
|
||||||
Security Alerts, Products, Tools, Tips & Tricks and other Resources.
|
|
||||||
</li>
|
|
||||||
|
|
||||||
<LI>Mailing lists: Bugtraq, BOS, etc.</LI>
|
|
||||||
|
|
||||||
|
<LI>Mailing lists such as <A HREF="http://www.geek-girl.com/bugtraq/">
|
||||||
|
Bugtraq</A> and <A HREF="http://www.nfr.net/forum/firewall-wizards.html">
|
||||||
|
Firewall Wizards</A>.</LI>
|
||||||
</UL>
|
</UL>
|
||||||
|
|
||||||
&footer
|
&footer
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue