os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add new content.

Browse source 
Submitted by: jcamou@cox.net
Minor fixes by: myself
PR: 63634
This commit is contained in:
Jesus Rodriguez Cuesta 2004-03-02 10:23:07 +00:00
parent 58f4a83e85
commit d067bc7bbb
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=20245
1 changed files with 154 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

177
es_ES.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -23,22 +23,24 @@
<title>Sin&oacute;psis</title>
<para>Este cap&iacute;tulo proveera una introducci&oacute;n b&aacute;sica
a los conceptos de seguridad de sistema y algunos temas avanzados en &os;.
Muchos de los temas se pueden aplicar a la seguridad del sistema asi como
tambi&eacute;n a la de Internet en general. El Internet ya no es un lugar
<quote>amistoso</quote> en el cual cada qui&eacute;n desea ser un buen
vecino. Asegurar su sistema es imprecindible para proteger sus datos,
caracter&iacute;stica intelectual, tiempo, y mucho mas de las manos de
hackers y similares.</para>
a los conceptos de seguridad de sistema y algunos temas avanzados en
&os;. Muchos de los temas se pueden aplicar a la seguridad del sistema
asi como tambi&eacute;n a la de Internet en general. Internet ya no es
un lugar <quote>amistoso</quote> en el cual cada qui&eacute;n desea ser
un buen vecino. Asegurar su sistema es imprecindible para proteger sus
datos, caracter&iacute;stica intelectual, tiempo, y mucho mas de las
manos de hackers y similares.</para>
<para>FreeBSD proporciona un arcenal de utilidades y mecanisimos para
asegurar la integridad y la seguridad de su sistema y red.</para>
<para>Despu&eacute;s de leer este cap&iacute;tulo, usted sabr&aacute;:</para>
<para>Despu&eacute;s de leer este cap&iacute;tulo, usted sabr&aacute;:
</para>
<itemizedlist>
<listitem>
<para>Conceptos b&aacute;sicos de seguridad, con respecto a &os;.</para>
<para>Conceptos b&aacute;sicos de seguridad, con respecto a &os;.
</para>
</listitem>
<listitem>
@ -71,8 +73,9 @@
</listitem>
<listitem>
<para>Como configurar y cargar los modulos de extensi&oacute;n de control
de acceso usando TrustedBSD <acronym>MAC</acronym> Framework.</para>
<para>Como configurar y cargar los modulos de extensi&oacute;n de
control de acceso usando TrustedBSD <acronym>MAC</acronym>
Framework.</para>
</listitem>
<listitem>
@ -167,18 +170,146 @@
</indexterm>
<indexterm><primary>Negaci&oacute;n de servicio (DoS)</primary></indexterm>
<para>Un ataque de negaci&oacute;n de servicio es una acci&oacute;n que priva
al sistema de los recursos requeridos. Generalmente, los ataques DoS son
mecanismos de fuerza bruta que intentan quebrar el sistema forzando sus
servidores. Algunos ataques DoS intentan aprovecharse de bugs en la red
para quebrar el sistema con un solo paquete. Esto puede ser solucionado
aplicando en el kernel una actualizaci&oacute;n que arregle el bug.
Los ataques en servidores muchas veces pueden ser solucionados aplicando
opciones apropiadas para limitar la carga del sistema en condiciones
adversas. Los ataques de fuerza bruta en redes son mas complicados.
Los ataques con paquetes enmascarados, por ejemplo, son casi imposible de
detener, el cual puede desconectar el sistema de Internet. Pueden no
quebrar el sistema, pero saturaran la conexi&oacute;n a Internet.</para>
<para>Un ataque de negaci&oacute;n de servicio es una acci&oacute;n que
priva al sistema de los recursos requeridos. Generalmente, los ataques
DoS son mecanismos de fuerza bruta que intentan quebrar el sistema
forzando sus servidores. Algunos ataques DoS intentan aprovecharse de
bugs en la red para quebrar el sistema con un solo paquete. Esto puede
ser solucionado aplicando en el kernel una actualizaci&oacute;n que
arregle el bug. Los ataques en servidores muchas veces pueden ser
solucionados aplicando opciones apropiadas para limitar la carga del
sistema en condiciones adversas. Los ataques de fuerza bruta en redes
son mas complicados. Los ataques con paquetes enmascarados, por
ejemplo, son casi imposible de detener, el cual puede desconectar el
sistema de Internet. Pueden no quebrar el sistema, pero saturaran la
conexi&oacute;n a Internet.</para>
</sect1>
<sect1 id="securing-freebsd">
<title>Asegurando FreeBSD</title>
<indexterm>
<primary>seguridad</primary>
<secondary>asegurando FreeBSD</secondary>
</indexterm>
<note>
<title>Comando vs. Protocolo</title>
<para>A trav&eacute;s de este documento usaremos el texto en
<application>negrita</application> para referirnos a un comando o
aplicaci&oacute;n. Esto se utiliza para casos tales como ssh, puesto
que es tanto un protocolo como un comando.</para>
</note>
<para>Las siguientes secciones cubrir&aacute;n los m&eacute;todos para
asegurar su sistema FreeBSD que fueron mencionados en la
<link linkend="security-intro"> secci&oacute;n anterior</link> a este
cap&iacute;tulo.</para>
<sect2 id="seuring-root-and-staff">
<title>Asegurando la cuenta <username>root</username> y las cuentas de
staff</title>
<indexterm>
<primary><command>su</command></primary>
</indexterm>
<para>Ant&eacute;s que nada, no se preocupe en asegurar las cuentas
del staff si aun no ha asegurado la cuenta <username>root</username>.
La mayor parte de los sistemas tienen asignada una clave de acceso
a la cuenta <username>root</username>. Lo primero que usted debe
asumir es que la contrase&ntilde;a <emphasis>siempre</emphasis>
est&aacute; comprometida. Esto no significa que tenga que
eliminar la contrase&ntilde;a. La contrase&ntilde;a es casi siempre
necesaria para el acceso a la c&oacute;nsola de la computadora. Esto
significa que usted no debe permitir utilizar la contrase&ntilde;a
fuera de la c&oacute;nsola o usarla posiblemente con el comando
&man.su.1;. Por ejemplo, cerciorese de que sus ptys sean
correctamente especificados como inseguros en el archivo
<filename>/etc/ttys</filename> para rechazar conexiones directas a
<username>root</username> v&iacute;a <command>telnet</command> o
<command>rlogin</command>. Si se usan otros servicios tales como
<application>sshd</application>, asegurese de que las conexiones
directas a <username>root</username> est&eacute;n deshabilitadas. Es
posible hacer esto editando el fichero
<filename>/etc/ssh/sshd_config</filename>, asegurando que
<literal>PermitRootLogin</literal> est&eacute; fijado como
<literal>NO</literal>. Considere cada m&eacute;todo de acceso
- Servicios como FTP puedes tener problemas de seguridad. Las
conexiones directas a <username>root</username> deben ser s&oacute;lo
permitidas f&iacute;sicamente en la c&oacute;nsola de sistema.</para>
<indexterm>
<primary><groupname>wheel</groupname></primary>
</indexterm>
<para>Por supuesto, como administrador de sistema usted debe poder
acceder como <username>root</username>, y nosotros tenemos algunas
formas de conseguirlo. Nos aseguraremos de que &eacute;stas formas
tengan autenticaci&oacute;n adicional. Una de las formas de hacer
<username>root</username> accesible es agregar cuentas apropiadas del
staff al grupo <groupname>wheel</groupname> (en
<filename>/etc/group</filename>). Se permite a los miembros del
staff puestos en el grupo <groupname>wheel</groupname> usar el
comando <command>su</command> para acceder <username>root</username>.
Nunca debe dar a miembros del staff acceso nativo a
<groupname>wheel</groupname> cuando se crea la cuenta. Las cuentas
del staff deben estar colocadas en grupos de
<groupname>staff</groupname>, para despu&eacute;s agregar a aquellos
deseados al grupo <groupname>wheel</groupname> en el fichero
<filename>/etc/group</filename>. Solamente a aquellos que realmente
se necesiten en este grupo deben ser agregados. Es tambi&eacute;n
posible usar un m&eacute;todo de autentificaci&oacute;n tal como
Kerberos, utilizar el fichero <filename>.k5login</filename> en la
cuenta <username>root</username> para permitir a &man.ksu.1; que
<username>root</username> no necesite a nadie en el grupo
<groupname>wheel</groupname>. Esta puede ser una mejor
soluci&oacute;n puesto que el mecanismo de
<groupname>wheel</groupname> todav&iacute;a permite al intruso romper
<username>root</username>, si el intruso ha conseguido quebrar el
archivo de contrase&ntilde;as y el grupo del staff. Mientr&aacute;s
que usar el mecanismo de <groupname>wheel</groupname> es mejor que no
tener nada en lo absoluto, no es necesariamente la opci&oacute;n mas
segura.</para>
<para>Una manera indirecta de asegurar las cuentas del staff y usar el
acceso a <username>root</username> de ultima instancia es usar un
m&eacute;todo de acceso alternativo conocido como
<quote>starring</quote>. Este m&eacute;todo marca las
contrase&ntilde;as cifradas con un solo
<quote><literal>*</literal></quote>. Este comando actualizar&aacute;
fichero de <filename>/etc/master.passwd</filename> y la base de datos
de usuario/contrase&ntilde;a para desabilitar los logins con
autentificaci&oacute;n de contrase&ntilde;a.</para>
<para>Una cuenta del staff como esta:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>Debe ser cambiada a:</para>
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh</programlisting>
<para>Este cambio evitar&aacute; que las conexiones normales ocurran,
ya que la contrase&ntilde;a cifrada nunca coincidir&aacute; con
<quote><literal>*</literal></quote>. Habiendo hecho esto, los
miembros del staff deber&aacute;n usar otros m&eacute;todos de
autentificaci&oacute;n como &man.kerberos.1; o &man.ssh.1;, usando
pares de claves p&uacute;blicas/privadas. Al usar algo como
Kereberos, uno debe asegurar generalmente las m&aacute;quinas que
corran los servidores Kereberos, asi como tambi&eacute;n su
estaci&oacute;n de trabajo. Al usar pares de claves
p&uacute;blicas/privadas con ssh, uno debe asegurar generalmente la
m&aacute;quina usada para hacer el login (generalmente una
estaci&oacute;n de trabajo). Una capa adicional de protecci&oacute;n
se puede agregar a los pares de claves
p&uacute;blicas/privadas protegiendolas con contrase&ntilde;a en el
momento de crearlas con &man.ssh-keygen.1;. Pudiendo
<quote>marcar</quote> las contrase&ntilde;as de las cuentas del staff
tambi&eacute;n garantiza que los miembros del staff solamente pueden
acceder al sistema por medio de un m&eacute;todo seguro. Esto fuerza
a los miembros del staff a acceder al sistema usando solamente formas
seguras y conexiones cifradas para todas sus sesiones, lo que
protege de una de las vulnerabilidades m&aacute;s usadas por
los intrusos.</para>
</chapter>