Fix the more blatant grammar violations. Some sections of this document
could do with a more thorough manhandling, however. :)
This commit is contained in:
Tim Vanderhoek
parent
c27349fb53
commit
19bc141e0a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=6307
3 changed files with 87 additions and 81 deletions
|
|
@ -1,10 +1,10 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
||||
<!ENTITY base CDATA "..">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.18 1999/11/09 13:05:25 kuriyama Exp $">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.19 1999/12/12 16:24:47 jhb Exp $">
|
||||
<!ENTITY title "FreeBSD Security Information">
|
||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||
]>
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.18 1999/11/09 13:05:25 kuriyama Exp $ -->
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.19 1999/12/12 16:24:47 jhb Exp $ -->
|
||||
|
||||
<html>
|
||||
&header;
|
||||
|
|
@ -203,7 +203,7 @@ understand how they work!!! While strncpy() might not append a terminating
|
|||
<P></P></LI>
|
||||
|
||||
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||
the destination string wrong for, and getenv() can return strings much
|
||||
the destination string wrong, and getenv() can return strings much
|
||||
longer then the program might expect. These two functions are one of the
|
||||
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
|
||||
|
|
@ -221,7 +221,7 @@ there are very few things which can be atomic in /tmp:
|
|||
<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
|
||||
If you use mkstemp() the 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>
|
||||
|
|
@ -242,9 +242,9 @@ there is any chance that they can be used in a path name. Don't trust
|
|||
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
|
||||
<LI>Do not 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
|
||||
cases since there are a lot more ways to cause buffer overflows than
|
||||
by abusing strcpy() and friends.
|
||||
<P></P></LI>
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ suid/sgid program.
|
|||
<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
|
||||
whom you already have arrangements for a second glance over your
|
||||
code. Don't commit code you are not sure about since breaking something
|
||||
in the name of a security fix is rather embarrassing.
|
||||
<P></P></LI>
|
||||
|
|
@ -281,14 +281,15 @@ go into the tree.
|
|||
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
|
||||
taking place). All changes 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
|
||||
the submitter didn't even really look at what he was submitting
|
||||
(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.
|
||||
|
|
@ -303,7 +304,7 @@ 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
|
||||
<LI>Look out for programs doing complex things with signal
|
||||
handlers. Many routines in the various libraries are not sufficiently
|
||||
reentrant to make this safe.
|
||||
<P></P></LI>
|
||||
|
|
@ -312,7 +313,7 @@ reentrant to make this safe.
|
|||
function is not used correctly.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>When using a fixed size buffers, use sizeof() to prevent lossage
|
||||
<LI>When using 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>
|
||||
|
|
@ -358,11 +359,11 @@ 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
|
||||
Also some utilities you may find not useful enough to have
|
||||
around 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
|
||||
not a good idea to strip so many sbits that 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
|
||||
|
|
@ -372,13 +373,14 @@ 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
|
||||
mailing lists</A> so you get updates on security bugs and
|
||||
fixes. Apply the fixes immediately.<P></P>
|
||||
|
||||
<LI>Backups - repair your system if security breach does occur<BR><P></P>
|
||||
<LI>Backups - repair your system if a 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>
|
||||
CD-Rom).
|
||||
Make sure your backups do not contain corrupted data or
|
||||
data modified by attackers.<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
|
||||
|
|
@ -387,8 +389,8 @@ 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.
|
||||
Users should know what 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>
|
||||
|
|
@ -406,8 +408,8 @@ developments in the security arena.</P>
|
|||
|
||||
<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>
|
||||
What privileges did the attacker get? Did the attacker manage to get
|
||||
root access? Did the attacker only manage to get user level access?</LI>
|
||||
|
||||
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||
tampered with</B><BR>
|
||||
|
|
@ -417,16 +419,16 @@ 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
|
||||
Did the break-in occur via a well-known security bug? If that is the case,
|
||||
make sure to install the correct patches. Was the break-in successful due
|
||||
to a misconfiguration? Was the break-in result of a new bug? If you believe
|
||||
the break-in 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>
|
||||
problems. Disable any compromised accounts.</LI>
|
||||
|
||||
<LI><B>Other resources</B><BR>
|
||||
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
||||
<!ENTITY base CDATA "..">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.18 1999/11/09 13:05:25 kuriyama Exp $">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.19 1999/12/12 16:24:47 jhb Exp $">
|
||||
<!ENTITY title "FreeBSD Security Information">
|
||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||
]>
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.18 1999/11/09 13:05:25 kuriyama Exp $ -->
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.19 1999/12/12 16:24:47 jhb Exp $ -->
|
||||
|
||||
<html>
|
||||
&header;
|
||||
|
|
@ -203,7 +203,7 @@ understand how they work!!! While strncpy() might not append a terminating
|
|||
<P></P></LI>
|
||||
|
||||
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||
the destination string wrong for, and getenv() can return strings much
|
||||
the destination string wrong, and getenv() can return strings much
|
||||
longer then the program might expect. These two functions are one of the
|
||||
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
|
||||
|
|
@ -221,7 +221,7 @@ there are very few things which can be atomic in /tmp:
|
|||
<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
|
||||
If you use mkstemp() the 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>
|
||||
|
|
@ -242,9 +242,9 @@ there is any chance that they can be used in a path name. Don't trust
|
|||
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
|
||||
<LI>Do not 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
|
||||
cases since there are a lot more ways to cause buffer overflows than
|
||||
by abusing strcpy() and friends.
|
||||
<P></P></LI>
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ suid/sgid program.
|
|||
<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
|
||||
whom you already have arrangements for a second glance over your
|
||||
code. Don't commit code you are not sure about since breaking something
|
||||
in the name of a security fix is rather embarrassing.
|
||||
<P></P></LI>
|
||||
|
|
@ -281,14 +281,15 @@ go into the tree.
|
|||
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
|
||||
taking place). All changes 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
|
||||
the submitter didn't even really look at what he was submitting
|
||||
(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.
|
||||
|
|
@ -303,7 +304,7 @@ 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
|
||||
<LI>Look out for programs doing complex things with signal
|
||||
handlers. Many routines in the various libraries are not sufficiently
|
||||
reentrant to make this safe.
|
||||
<P></P></LI>
|
||||
|
|
@ -312,7 +313,7 @@ reentrant to make this safe.
|
|||
function is not used correctly.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>When using a fixed size buffers, use sizeof() to prevent lossage
|
||||
<LI>When using 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>
|
||||
|
|
@ -358,11 +359,11 @@ 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
|
||||
Also some utilities you may find not useful enough to have
|
||||
around 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
|
||||
not a good idea to strip so many sbits that 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
|
||||
|
|
@ -372,13 +373,14 @@ 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
|
||||
mailing lists</A> so you get updates on security bugs and
|
||||
fixes. Apply the fixes immediately.<P></P>
|
||||
|
||||
<LI>Backups - repair your system if security breach does occur<BR><P></P>
|
||||
<LI>Backups - repair your system if a 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>
|
||||
CD-Rom).
|
||||
Make sure your backups do not contain corrupted data or
|
||||
data modified by attackers.<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
|
||||
|
|
@ -387,8 +389,8 @@ 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.
|
||||
Users should know what 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>
|
||||
|
|
@ -406,8 +408,8 @@ developments in the security arena.</P>
|
|||
|
||||
<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>
|
||||
What privileges did the attacker get? Did the attacker manage to get
|
||||
root access? Did the attacker only manage to get user level access?</LI>
|
||||
|
||||
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||
tampered with</B><BR>
|
||||
|
|
@ -417,16 +419,16 @@ 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
|
||||
Did the break-in occur via a well-known security bug? If that is the case,
|
||||
make sure to install the correct patches. Was the break-in successful due
|
||||
to a misconfiguration? Was the break-in result of a new bug? If you believe
|
||||
the break-in 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>
|
||||
problems. Disable any compromised accounts.</LI>
|
||||
|
||||
<LI><B>Other resources</B><BR>
|
||||
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
|
||||
<!ENTITY base CDATA "..">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.18 1999/11/09 13:05:25 kuriyama Exp $">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.19 1999/12/12 16:24:47 jhb Exp $">
|
||||
<!ENTITY title "FreeBSD Security Information">
|
||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||
]>
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.18 1999/11/09 13:05:25 kuriyama Exp $ -->
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.19 1999/12/12 16:24:47 jhb Exp $ -->
|
||||
|
||||
<html>
|
||||
&header;
|
||||
|
|
@ -203,7 +203,7 @@ understand how they work!!! While strncpy() might not append a terminating
|
|||
<P></P></LI>
|
||||
|
||||
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||
the destination string wrong for, and getenv() can return strings much
|
||||
the destination string wrong, and getenv() can return strings much
|
||||
longer then the program might expect. These two functions are one of the
|
||||
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
|
||||
|
|
@ -221,7 +221,7 @@ there are very few things which can be atomic in /tmp:
|
|||
<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
|
||||
If you use mkstemp() the 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>
|
||||
|
|
@ -242,9 +242,9 @@ there is any chance that they can be used in a path name. Don't trust
|
|||
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
|
||||
<LI>Do not 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
|
||||
cases since there are a lot more ways to cause buffer overflows than
|
||||
by abusing strcpy() and friends.
|
||||
<P></P></LI>
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ suid/sgid program.
|
|||
<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
|
||||
whom you already have arrangements for a second glance over your
|
||||
code. Don't commit code you are not sure about since breaking something
|
||||
in the name of a security fix is rather embarrassing.
|
||||
<P></P></LI>
|
||||
|
|
@ -281,14 +281,15 @@ go into the tree.
|
|||
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
|
||||
taking place). All changes 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
|
||||
the submitter didn't even really look at what he was submitting
|
||||
(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.
|
||||
|
|
@ -303,7 +304,7 @@ 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
|
||||
<LI>Look out for programs doing complex things with signal
|
||||
handlers. Many routines in the various libraries are not sufficiently
|
||||
reentrant to make this safe.
|
||||
<P></P></LI>
|
||||
|
|
@ -312,7 +313,7 @@ reentrant to make this safe.
|
|||
function is not used correctly.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>When using a fixed size buffers, use sizeof() to prevent lossage
|
||||
<LI>When using 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>
|
||||
|
|
@ -358,11 +359,11 @@ 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
|
||||
Also some utilities you may find not useful enough to have
|
||||
around 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
|
||||
not a good idea to strip so many sbits that 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
|
||||
|
|
@ -372,13 +373,14 @@ 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
|
||||
mailing lists</A> so you get updates on security bugs and
|
||||
fixes. Apply the fixes immediately.<P></P>
|
||||
|
||||
<LI>Backups - repair your system if security breach does occur<BR><P></P>
|
||||
<LI>Backups - repair your system if a 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>
|
||||
CD-Rom).
|
||||
Make sure your backups do not contain corrupted data or
|
||||
data modified by attackers.<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
|
||||
|
|
@ -387,8 +389,8 @@ 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.
|
||||
Users should know what 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>
|
||||
|
|
@ -406,8 +408,8 @@ developments in the security arena.</P>
|
|||
|
||||
<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>
|
||||
What privileges did the attacker get? Did the attacker manage to get
|
||||
root access? Did the attacker only manage to get user level access?</LI>
|
||||
|
||||
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||
tampered with</B><BR>
|
||||
|
|
@ -417,16 +419,16 @@ 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
|
||||
Did the break-in occur via a well-known security bug? If that is the case,
|
||||
make sure to install the correct patches. Was the break-in successful due
|
||||
to a misconfiguration? Was the break-in result of a new bug? If you believe
|
||||
the break-in 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>
|
||||
problems. Disable any compromised accounts.</LI>
|
||||
|
||||
<LI><B>Other resources</B><BR>
|
||||
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||
|
|
|
|||
Loading…
Reference in a new issue