From sku@cox.net Tue Mar 2 01:10:47 2004 Return-Path: Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53F2D16A4CE for ; Tue, 2 Mar 2004 01:10:47 -0800 (PST) Received: from fed1mtao04.cox.net (fed1mtao04.cox.net [68.6.19.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36AD643D2D for ; Tue, 2 Mar 2004 01:10:47 -0800 (PST) (envelope-from sku@cox.net) Received: from nightfall.cox.net ([68.107.140.104]) by fed1mtao04.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040302091046.KTFE29098.fed1mtao04.cox.net@nightfall.cox.net> for ; Tue, 2 Mar 2004 04:10:46 -0500 Received: by nightfall.cox.net (Postfix, from userid 1000) id EAAC53138; Tue, 2 Mar 2004 01:10:46 -0700 (MST) Message-Id: <20040302081046.EAAC53138@nightfall.cox.net> Date: Tue, 2 Mar 2004 01:10:46 -0700 (MST) From: Jesus R.Camou Reply-To: Jesus R.Camou To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: [patch] Add section to the Security chapter (Spanish handbook). X-Send-Pr-Version: 3.113 X-GNATS-Notify: >Number: 63634 >Category: docs >Synopsis: [patch] Add section to the Security chapter (Spanish handbook). >Confidential: no >Severity: non-critical >Priority: medium >Responsible: jesusr >State: closed >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Tue Mar 02 01:20:05 PST 2004 >Closed-Date: Tue Mar 02 02:23:44 PST 2004 >Last-Modified: Tue Mar 02 02:23:44 PST 2004 >Originator: Jesus R. Camou >Release: FreeBSD 4.9-STABLE i386 >Organization: >Environment: System: FreeBSD nightfall.cox.net 4.9-STABLE FreeBSD 4.9-STABLE #8: Sat Feb 7 15:25:07 PST 2004 sku@nightfall.cox.net:/usr/obj/usr/src/sys/NIGHTFALL i386 >Description: Add a section to the security chapter of the Spanish handbook. Section id: securing-freebsd >How-To-Repeat: >Fix: --- security2.diff begins here --- 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. + + + + Asegurando FreeBSD + + seguridad + asegurando FreeBSD + + + + Comando vs. Protocolo + A través de este documento usaremos el texto en + negrita 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. + + + Las siguientes secciones cubrirán los métodos para asegurar + su sistema FreeBSD que fueron mencionados en la + sección anterior a este capítulo. + + + Asegurando la cuenta <username>root</username> y las cuentas de + staff + + su + + + Antés que nada, no se preocupe en asegurar las cuentas + del staff si aun no ha asegurado la cuenta root. + La mayor parte de los sistemas tienen asignada una clave de acceso + a la cuenta root. Lo primero que usted debe + asumir es que la contraseña siempre + 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 /etc/ttys para rechazar + conexiones directas a root via telnet + o rlogin. Si se usan otros servicios + tales como sshd, asegurese de que las + conexiones directas a root esten deshabilitadas. + Es posible hacer esto editando el fichero /etc/ssh/sshd_config + , asegurando que PermitRootLogin este + fijado como NO. Considere cada método de + servicio tal como FTP que puede caer a menudo en cracks. Las + conexiones directas a root deben ser solamente + permitidas fisicamente en la consola de sistema. + + wheel + + + Por supuesto, como administrador de sistema usted debe poder + accesar root, nosotros tenemos algunas formas + de conseguirlo. Nos aseguraremos de que estas formas tengas + autenticación adicional. Una de las formas de hacer + root accesible es agregar cuentas apropiadas del staff al + grupo wheel (en /etc/group). + Se permite a los miembros del staff puestos en el grupo wheel + usar el comando su para accesar + root. Nunca debe dar a miembros del staff acceso nativo a + wheel cuando se crea la cuenta. Las cuentas del + staff deben estar colocadas en grupos de staff, + para después agregar a aquellos deseados al grupo + wheel en el fichero /etc/group. + 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 + .k5login en la cuenta root para permitir + a &man.ksu.1; que root no necesite a nadie en el + grupo wheel. Esta puede ser una mejor + solución puesto que el meanismo de wheel + todavía permite al intruso romper root, + si el intruso ha conseguido quebrar el archivo de contraseñas + y el grupo del staff. Mientrás que usar el mecanismo de + wheel es mejor que no tener nada en lo absoluto, + no es necesariamente la opción mas segura. + + Una manera indirecta de asegurar las cuentas del staff y usar el + acceso a root de ultima instancia es usar un + método de acceso alternativo conocido como starring. + Este método marca las contraseñas cifradas con un solo + *. Este comando pondra al dia el + fichero de /etc/master.passwd y la base de datos + de usuario/contraseña para desabilitar los logins con + autentificación de contraseña. + + Una cuenta del staff como esta: + + foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + Debe ser cambiado a: + + foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh + + Este cambio evitará que las conexiones normales ocurran, ya que + la contraseña cifrada nunca coincidirá con + *. 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 marcar 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. + + +