🚀 go-pugleaf

a_ver_est wrote:

> wenas,

Hola Roger 8)


> Para mi desgracia me va a tocar securizar una instalaci�n de un w2k
> server como paso previo a la instalaci�n de un ISA server, � es
> posible securizar un w2k ?,

Buenas noticias: s� lo es. Y m�s de lo que la mayor�a de gente cree. 

Malas noticias: ISA es el peor proxy que se ha hecho jam�s.

 
> Bueno he hecho este mini documento a base de consejos recogidos de la
> web de microsof, lo comparto por si le es de utilidad a alguien y de
> paso si tiene mas ideas que puedan ser �tiles a�adirlas:
 
Te comento cada cosa que merezca alg�n comentario, pero lee
especialmente lo que pongo al final del post. En cualquier caso,
aunque esto pueda servir como base, la localizaci�n (configuraci�n de
un server en un escenario concreto) es lo que realmente determinar� el
grado de seguridad �ptimo. Sin saber si este server est� dentro de un
AD, de qu� tipo de dominio, el n�mero de clientes que lo usar�n,
etc�tera es muy dif�cil plantear una buena pol�tica de seguridad
acorde con el rendimiento.


> * verificar q la cuenta de administrador tiene un passwd fuerte

Debe especificarse como directiva.

 
> * desabilitar los servicios inecesarios

Esto es mucho m�s complicado de lo que parece. No es sencillo
determinar qu� servicios son innecesarios y hay muchos servicios que
siguen estando ah� una vez deshabilitados. En algunos casos, cabe
borrar el servicio, y no s�lo deshabilitarlo.

 
> * desabilitar o borrar las cuentas de usuarios inncesarias

Borrarlas, deshabilitarlas no es suficiente.

 
> * proteger ficheros y directorios ( por defecto ok, problemas si
> upgrade de NT 4.0)

Por defecto ok, no. Por comentar algunas cosas: Hay que usar una
pol�tica de ACLs adecuada mediante templates, hay que mover ciertos
ficheros (especialmente las herramientas de system32) a otro
directorio y quitarles permisos; restringir el uso de ficheros wsh,
vbs... hay que eliminar o renombrar algunos de ellos. Por no hablar de
habilitar WFP (restauraci�n de archivos) y EFS (encriptaci�n nativa de
windows 2000).

 
> * asegurarse que la cuenta de invitado esta desavilitada

Es preferible borrarla (existen m�todos, contrariamente a lo que dice
MS).
 

> * proteger el registro del acceso anonimo
>    1. Add the following key to the registry:

A Restrict 2 siempre, como dice Mike con RA 1 aun se puede enumerar.
Hay que hacerlo por las directivas, nunca por el registro.


> * aplicar ACLs al registro ->> ( por defecto ok, problemas si upgrade
> de NT 4.0)

Hay que aplicar ACLs. Por defecto da acceso a ciertos sitios, y hay
que controlar de forma especial (y establecer n accesos de solo
lectura) a ciertos hives.

 
> * Restringir acceso al LSA
> 	Hive

Hay que hacerlo por las directivas.

 
> * preparar cuenta administrador:
> 	* crear otra cuenta con el nombre administrador para logear los

No lo recomiendo. Esto crea una cuenta in�til, aunque tenga un
password de 30 caracteres y no tenga acceso a literalmente a nada, es
una tarea futil. S�lo genera trabajo para el administrador y un riesgo
innecesario.


> intentos de validacion
> 	* habilitar bloqueo de la cuenta despues de un numero n de riententos
> � realmente recomendable ?

Absolutamente imprescindible en las cuentas no administrativas. La
cuenta del administrador local no se puede bloquear, pero si la cuenta
del administrador en la red; hay que usar una herramienta espec�fica
para ello.


> * desabilitar administrador local.

????


> * eliminar todos los recursos compartidos inecesarios

Si, y eliminarlos bien. No vale con quitar el protocolo.


> SECURIZAR LA PILA TCP/IP

Hay que ir con cuidado con esto, seg�n qu� valores, especialmente en
un proxy, podr�an afectar negativamente al rendimiento.

Existen otras claves del registro que vale la pena modificar aparte de
las relativas a TCP/IP.


> CONTROL DE EVENTOS
> 
> * activar auditoria

Hay que determinar qu� pol�ticas de auditoria. Una mala configuraci�n
de pol�ticas puede generar muchos falsos positivos o errores
garrafales.


> � alguien llego hasta aqu� ? :)

Realmente faltan muchas cosas, algunas las considero
imprescindibles... Aunque una configuraci�n como la propuesta ya
dejar�a fuera de juego a la mayor�a de script kiddies.

Estoy haciendo un art�culo desde hace un tiempo sobre una
configuraci�n de 2000 Server en un entorno un tanto especial. Mi
escenario consistia en un router ADSL con una sola m�quina que hace
estacion y server a la vez, para un administrador ``cuando arriba a
casa''. Los servicios son: ftp, web y terminal server.

Me centro en una parte que no afecta a tu configuraci�n, y es el
peligro de que un server sea estaci�n de trabajo a la vez. Pero
podr�as usar mucho de mi art�culo para tu configuraci�n. Junto al
art�culo pensaba incluir una plantilla de pol�ticas, una plantilla de
IPSec (craso error no mentarlo en tu configuraci�n), algunos scripts,
etc. Aparte del documento en s�. De modo que configurarlo es tan
trivial como cargar las plantillas (todo explicado en el art�culo) y
luego hacer a mano, paso a paso, lo que no se puede automatizar
(��cre�as que s�lo te remitir�a a mamotretos te�ricos?? :). Cuando lo
termine te lo paso para que le eches un vistazo.

Tengo algunos links que te servir�n, cuando tenga un rato los miro y
te los mando al correo. En cuanto a lo que comenta Mike de los
documentos de la NSA, no me fio mucho de ellos, pero las plantillas de
base te ser�n �tiles, especialmente todo lo relativo a ISA Server.

Sea como fuere, el mayor peligro que veo en esa m�quina es el mero
hecho de usar ISA. C�ntrate en la seguridad de ISA aparte de lo b�sico
de la propia m�quina. Por otro lado, si la m�quina no est� en un CPD
(y existe acceso f�sico a la misma), la seguridad f�sica deber�a ser
tu mayor paranoia; es realmente trivial obtener acceso en ese caso.


> Saludos,
> Roger_J

Un abrazo,
- upierz