FreeBSD Bugzilla – Attachment 40486 Details for
Bug 63634
[patch] Add section to the Security chapter (Spanish handbook).
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[patch]
security2.diff
security2.diff (text/plain), 6.94 KB, created by
Jesus R.Camou
on 2004-03-02 09:20:05 UTC
(
hide
)
Description:
security2.diff
Filename:
MIME Type:
Creator:
Jesus R.Camou
Created:
2004-03-02 09:20:05 UTC
Size:
6.94 KB
patch
obsolete
>Index: chapter.sgml >=================================================================== >RCS file: /home/ncvs/doc/es_ES.ISO8859-1/books/handbook/security/chapter.sgml,v >retrieving revision 1.3 >diff -u -r1.3 chapter.sgml >--- chapter.sgml 1 Feb 2004 12:14:06 -0000 1.3 >+++ chapter.sgml 2 Mar 2004 09:04:21 -0000 >@@ -180,6 +180,124 @@ > detener, el cual puede desconectar el sistema de Internet. Pueden no > quebrar el sistema, pero saturaran la conexió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és de este documento usaremos el texto en <application> >+ negrita</application> para referirnos a un comando o aplicació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án los métodos para asegurar >+ su sistema FreeBSD que fueron mencionados en la <link linkend="security-intro"> >+ sección anterior</link> a este capí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é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ña <emphasis>siempre</emphasis> >+ comprometida. Esto no significa que tenga que remover la >+ contraseña. La contraseña es casi siempre necesaria >+ para el acceso a la consola de la computadora. Esto significa que >+ usted no debe permitir utilizar la contraseña fuera de la consola o >+ igualarla 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> via <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> esten deshabilitadas. >+ Es posible hacer esto editando el fichero <filename>/etc/ssh/sshd_config >+ </filename>, asegurando que <literal>PermitRootLogin</literal> este >+ fijado como <literal>NO</literal>. Considere cada método de >+ servicio tal como FTP que puede caer a menudo en cracks. Las >+ conexiones directas a <username>root</username> deben ser solamente >+ permitidas fisicamente en la consola de sistema.</para> >+ <indexterm> >+ <primary><groupname>wheel</groupname></primary> >+ </indexterm> >+ >+ <para>Por supuesto, como administrador de sistema usted debe poder >+ accesar <username>root</username>, nosotros tenemos algunas formas >+ de conseguirlo. Nos aseguraremos de que estas formas tengas >+ autenticació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 accesar <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é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én posible usar un método de >+ autentificació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ón puesto que el meanismo de <groupname>wheel</groupname> >+ todavía permite al intruso romper <username>root</username>, >+ si el intruso ha conseguido quebrar el archivo de contraseñas >+ y el grupo del staff. Mientrás que usar el mecanismo de >+ <groupname>wheel</groupname> es mejor que no tener nada en lo absoluto, >+ no es necesariamente la opció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étodo de acceso alternativo conocido como <quote>starring</quote>. >+ Este método marca las contraseñas cifradas con un solo >+ <quote><literal>*</literal></quote>. Este comando pondra al dia el >+ fichero de <filename>/etc/master.passwd</filename> y la base de datos >+ de usuario/contraseña para desabilitar los logins con >+ autentificación de contraseñ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 cambiado a:</para> >+ >+ <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh</programlisting> >+ >+ <para>Este cambio evitará que las conexiones normales ocurran, ya que >+ la contraseña cifrada nunca coincidirá con <quote><literal> >+ *</literal></quote>. Habiendo hecho esto, los miembros del staff deberán >+ usar otros métodos de autentificación como &man.kerberos.1; >+ o &man.ssh.1;, usando public/private keys. Al usar algo como Kereberos, >+ uno debe asegurar generalmente las máquinas que corran los >+ servidores Kereberos, asi como también su estación de trabajo. >+ Al usar public/private keys con ssh, uno debe asegurar generalmente la >+ máquina usada para hacer el login (generalmente una estación >+ de trabajo). Una capa adicional de protección se puede agregar >+ a los public/private keys protegiendo con contraseña al momento de >+ crearlo con &man.ssh-keygen.1;. Pudiendo <quote>marcar</quote> las >+ contraseñas de las cuentas del staff también garantiza >+ que los miembros del staff pueden solamente accesar el sistema por medio >+ de un método seguro. Esto forza a los miembros del staff a accesar >+ el sistema usando solamente formas seguras y conexiones cifradas para >+ todas sus sesiones, lo que cierra un hoyo importante usado por muchos >+ intrusos.</para> >+ >+ >+ > </chapter> > > <!--
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 63634
: 40486