Windows Server 2008 Parte II. Artículo Windows TI Magazine

Estándar

Segunda parte artículo Windows TI Magazine

Primera parte aquí 

Cada perfil es totalmente configurable, pudiendo desactivarlo o activarlo a nuestro gusto, creando archivos de log para cada uno de ellos, mostrando notificaciones de bloqueo, etc. lo cuál evidentemente facilita y mejora las posibilidades de administración asociadas.
Es interesante indicar en este momento que en función del ámbito de red que escojamos, las reglas configuradas por defecto serán más o menos estrictas. El perfil más restrictivo es el perfil público. Este debería ser el seleccionado si la instalación de nuestro servidor se va a realizar en áreas no controladas por nosotros al 100%, con una superficie de ataque amplia. Por el contrario, el perfil menos restrictivo es el de dominio. En este escenario la administración más centralizada y segura nos permite que las restricciones en función del perfil sean menores sin por ello menoscabar el nivel de seguridad deseado.
Adicionalmente, y como todo complemento de Windows, el Firewall es también  administrable 100% a través de la línea de comandos. Para ello disponemos de  la herramienta netsh. Esta es una aplicación  que opera bajo línea de comandos  y que nos permite administrar la configuración de red de un equipo. Este tipo de administración es posible realizarla tanto de forma local como remota.
No olvidemos sin embargo que Netsh no sólo sirve para administrar el Firewall de Windows, sino que no capacita también para la administración  al 100% de nuestra configuración de red. Pudiendo así, y a través de ella, administrar NAP, HTTP, RPC, configuraciones IP, solucionar problemas de WinSock, y otras funcionalidades y características propias del entorno de red, operando bien en remoto o local.
La sintaxis del comando en cuestión es la siguiente:
Netsh advfirewall firewall
Desarrollemos un ejemplo ilustrativo asociado. Ante la necesidad de tener que implantar una aplicación que cumpla las siguientes condiciones:
· Salida al exterior de la intranet corporativa.
· Regla sólo aplicable al perfil público.
· El Firewall debe permitir esta conexión, siendo transparente al resto de los perfiles.
La sintaxis completa del comando sería la siguiente:
Netsh advfirewall firewall add rule name=” Permitir aplicación Contabilidad” dir=out program=”C:\Archivos de programa\Aplicación de Contabilidad\Contabilidad.exe” profile=public action=allow
En donde, el apartado dir refleja la naturaleza de la regla (si es de entrada o de salida), el apartado profile refleja el ámbito de la regla (perfil público, privado o de dominio) y el apartado action refleja la acción del firewall (permitir o denegar).
Con netsh podremos crear y eliminar reglas, hacer backups de las mismas, etc…
Otra característica novedosa del Firewall Windows es que su total integración con el protocolo seguro IPSEC. Basándose, como ya indicábamos, toda la administración en una consola única.
En versiones anteriores de Windows, los administradores teníamos que lidiar con el firewall y las reglas de IPSEC en consolas diferentes. Recuerdo cuando a veces creaba reglas IPSEC que luego me bloqueaba el Firewall. Me volvía loco… Ya no sabía si era del Firewall, las reglas, el equipo, el cable, etc… La diversidad de las consolas de trabajo era sin lugar a dudas una posible interferencia en la operativa del administrador que ahora ha sido subsanada. 
La total integración del Firewall Windows con IPSEC en el nuevo sistema operativo no permite ver en una única consola como se están aplicando nuestras reglas, pudiendo ver con mayor detalle si ésta se está efectuando correctamente, y reducir así la superficie de error.
Nuevas características de seguridad en directorio activo: controladores de dominio de sólo lectura.
Me gustaría abordar en este punto otra cuestión que creo que puede tener intrigados a muchos técnicos, y que planteo desde una pregunta que me hicieron no hace mucho. La pregunta era “Un Controlador de Dominio  puede aumentar la seguridad de una corporación, si éste es administrado correctamente, pero ¿qué pasa con los controladores  a los que no podemos garantizar una seguridad física?.” La respuesta es evidente e incluso inquietante. Bastaría que un hacker comprometiese el controlador de dominio  para poder tener acceso a información sensible de toda la corporación.
LongHorn se ha pensado y diseñado para ser implementado en muchos entornos, entre ellos el mismo escenario que planteábamos en el párrafo anterior. Una corporación que necesita tener un DC (Domain Crontoler) replicando y situado en una ubicación de la que no podemos garantizar su seguridad ni física, ni lógica. Para atender a esta circunstancia nace  una nueva figura, el Controlador de Dominio de solo lectura (RODC Read Only Domain Controller) Este nos permite que podamos implementar un DC con una base de datos del dominio de solo lectura.

imagen-4.png

Un RODC mantiene los mismos atributos y objetos que un controlador de dominio de escritura, con la excepción de no poder hacer cambios en la base de datos. En su lugar, si alguna operación necesita escribir en la base de datos, ésta hace la replicación en un controlador de dominio de escritura que a su vez, replica en el RODC.
De este modo evitamos varios problemas, entre ellos dos importantes que anteriormente quedaban expuestos: La replicación indebida a nuestro bosque, y una posible exposición de ataque.
Adicionalmente reducimos la carga de replicación a otros servidores, ya que como en un RODC no es posible escribir en la base de datos, éste no puede replicar. Es decir, en un RODC la replicación siempre es única y exclusivamente unidireccional.
En la arquitectura de un RODC también se ha pensado en el almacenamiento de credenciales. Por defecto, en un sistema basado en Windows, se guardan los 10 últimos inicios de sesión. Se diseñó así para poder iniciar una sesión en un equipo miembro de un dominio, incluso si éste fallase por cualquier circunstancia. En escenarios donde no se puede garantizar una seguridad física ni lógica, esta cuestión puede representar un serio problema de seguridad. Aplicaciones como cachedump pueden ser utilizadas para recuperar las contraseñas almacenadas en la caché del sistema. La opción de caché del sistema se podía y se puede configurar de forma sencilla en cualquier Windows. Observando lo anterior un RODC no guarda credenciales de usuarios ni de equipos (establecido por defecto), salvo la de sus cuentas locales y la cuenta de sistema que se utiliza para la autenticación kerberos (krbtgt), buscando de este modo eliminar o al menos minimizar los riesgos expuestos.
Sin embargo en estas como en otras cuestiones no siempre llueve al gusto de todos y nos podemos encontrar con que esta limitación respecto de la caché no sea la más correcta en determinadas circunstancias. Es por ello que se ha pensado en la posibilidad de asignar caché para aquellas cuentas que precisemos oportunas. Si tenemos un RODC en una oficina externa, y ésta oficina tiene 20 usuarios, podremos asignar caché a esos 20 usuarios y denegar al resto. Si por alguna razón, el RODC es comprometido o robado físicamente, sólo tendremos que restablecer las contraseñas de estas cuentas. Al tener total seguridad de qué cuentas pueden ser comprometidas, reducimos el tiempo de acción de un administrador para solucionar la brecha de seguridad. Incluso podríamos permitirnos el lujo de asignar una cuenta administrativa sólo para manejar el RODC, pero sin acceso a los DC centrales con permiso de escritura.
Server Core. Windows también puede operar sin ventanas.
Pasamos en esta apartado a valorar otra novedad de LongHorn. El sistema nos aporta la posibilidad de llevar a efecto una instalación mínima de servidor, también conocida como Server Core. El proceso en este caso es sumamente sencillo. Tan sólo tendremos que seleccionar la opción de Server Core, y se instalará el sistema base sin entorno gráfico. Nada de instalaciones complicadas. Toda la instalación a sólo un clic de ratón.
Con Server Core podremos realizar la instalación mínima de un servidor, con sólo las funciones o roles necesarios que nos permitan desempeñar aquellas funcionalidades específicas para las que estemos generando el nuevo servidor. 
Evidentemente la metodología en esta ocasión es básica y se ocupa únicamente de atender los mínimos necesarios. La instalación es mínima, ocupándose exclusivamente del sistema base, y el rol o roles que necesitemos que adicionalmente desempeñe el equipo. Todo ello sin sistema gráfico, operando íntegramente través de la Shell. Nuestro sistema Windows se ha quedado en esta ocasión sin ventanas.
Supongamos, a modo de ejemplo, un escenario en el que necesitamos que un servidor adopte exclusivamente las funciones como DHCP  y DNS.  En una instalación Server Code,  ésta se limitará al sistema base y una Shell de comandos. Posteriormente, a través de ésta, completaremos la instalación con los servicios adicionales necesarios. Como ya indicábamos, un Windows sin Windows que sin embargo cubre las necesidades que se le demandan.
Una vez instalado el sistema base, nos encontramos con un entorno de trabajo básico. A muchos administradores puede parecerles incluso un tanto hostil, ya que carece de componentes gráficos. Como veremos a continuación, mantener y administrar un servidor de estas características no es, ni mucho menos, tan complejo como puede parecernos. A los más veteranos de la administración les resultará incluso familiar.

imagen-5.png

Abordemos un ejemplo práctico en mayor detalle para ilustrar este apartado. Una vez instalado el servidor en un modo Server Code, éste presenta una configuración básica no operativa y en nuestro ejemplo tendremos que desarrollar por lo tanto todos los procesos manualmente, sin apoyarnos en ningún asistente. De este modo modificaremos la password de administrador, cambiaremos  el nombre de equipo, configuraremos la red, activaremos Windows, pasando posteriormente a actualizarlo. Finalmente instalaremos un rol y un complemento. A los más antiguos del lugar les traerá recuerdos sin lugar a dudas.

imagen-6.png

Para cambiar la password de la cuenta Administrator, utilizaremos el comando:
Net user Administrator *
El comando nos solicitará que introduzcamos una password, y posteriormente nos la  volverá a pedir para su verificación. El asterisco se suele poner para no tipear la password en texto plano. Con esto evitamos a posibles “voyeur” que estén intentando visualizar lo que escribamos en pantalla.
Posteriormente pasamos a modificar el nombre de equipo de la máquina, ya que tal vez el nos haya asignado la instalación, no corresponda a la política corporativa de nomenclatura de máquinas. Cambiar el nombre de máquina es tan sencillo como formular adecuadamente el comando cuya sintaxis reflejamos a continuación:
Netdom renamecomputer <Nombre de máquina actual> /newname:<nombre de máquina nuevo>
Ejemplo:
Netdom renamecomputer QFGPH-345P /newname: Sevw2k3prb01
Una vez que la password se ha modificado y el nombre de equipo se encuentra dentro de la política de nomenclatura de la empresa, procederemos a comprobar si el cliente DHCP y el cliente DNS están en funcionamiento. Para ello bastará con teclear un query de servicios con el comando SC.
Sc query DHCP
Sc query DNS

Comprobado  que tenemos estos servicios iniciados y en funcionamiento, es hora de asignar una dirección IP a nuestro adaptador Ethernet. Para ello utilizaremos el comando netsh.
Primeramente tendremos que averiguar el nombre de nuestra interfaz. Para hacerlo teclearemos el  siguiente comando:
Netsh int show interface
Este comando nos devolverá el nombre de interface, información necesaria si  posteriormente tuviésemos que modificar su dirección IP.
Para establecer la dirección IP de un adaptador, existen dos posibilidades: direccionamiento dinámico (DHCP) o direccionamiento estático. La operativa para recibir la dirección IP desde un servidor DHCP es bien sencilla.  Simplemente  tendremos que teclear el comando siguiente:
Netsh int ip set address name=”Local Area Connection” source=dhcp
Para direccionamiento estático, imaginemos que necesitamos asignar la dirección IP 192.168.4.120/Clase C y la puerta de enlace 192.168.4.250  a nuestro servidor. El nombre de la interfaz es Local Area Connection.. El comando resultante sería el siguiente:
Netsh int ip set address name=”Local Area Connection” source=static address=192.168.4.120 mask=255.255.255.0 gateway=192.168.4.250 1 gwmetric=1
Una vez configurada la red, debemos realizar una comprobación de conectividad que verifique que el proceso de configuración se ha finalizado con éxito.

imagen-7.png

Una vez realizado el test de conectividad procederemos a activar Windows. Para realizarlo, utilizaremos el siguiente comando:
Slmgr.vbs –ato
Una vez activado Windows Server LongHorn, el sistema nos presenta una ventana informativa mostrándonos el estado de la actualización.

imagen-8.png

Avanzando en nuestro proceso de configuración, y antes de instalar cualquier rol, podemos actualizar nuestro Windows Server LongHorn con las últimas actualizaciones de seguridad. Para ello debemos de seguir una serie de pasos, que detallamos a continuación:
Lo primero que debemos hacer es configurar nuestro servidor para que se descargue actualizaciones cada cierto tiempo. En nuestro caso cada 3 horas. Estos términos podemos establecerlos con el comando siguiente:
Cscript C:\windows\system32\scregedit.wsf /AU /4
Una vez que hayamos configurado las actualizaciones, procederemos a parar y reiniciar el servicio de actualizaciones, para que éste recoja el cambio. Teclearemos los siguientes comandos:
Net stop Wuauserv
Net start Wuauserv

Existen multitud de comandos que podemos emplear a través de la Shell de Windows. Las posibilidades son amplias. Los límites son nuestra imaginación y conocimientos.
Instalar un componente o algún rol no es muy distinto de lo que ya hemos explicado. La operativa a través de la línea de comandos es la misma, siendo la única particularidad que tendremos que hacerlo a través de una aplicación denominada ocsetup.exe.

imagen9.png

Si por ejemplo necesitásemos instalar un servidor DHCP en nuestro Windows Server LongHorn, ejecutaríamos el siguiente comando:
Ocsetup.exe DHCPServerCore
Automáticamente el sistema instalaría un servidor DHCP en nuestro equipo. Actualmente la herramienta ocsetup es sensible a mayúsculas y minúsculas, con lo que tendríamos que escribir el comando exactamente como ha sido reflejado con anterioridad.

Saludos!

Anuncios

4 comentarios en “Windows Server 2008 Parte II. Artículo Windows TI Magazine

  1. Manu

    hola, muy muy interesante el articulo, cuanto mas post leo mas m gusta…por cierto una pregunta…donde puedo encontrar info sobre comandos avanzados (como netsh, control xxxx, etc.) aparte de en la ayuda (/?) hay algo asi como libros o algun site donde poder conseguirlo?

    Saludos y a seguir asi k voy a empezar a tirar para atras para ver k m hay en meses anteriores.

    Saludos,

  2. Sorcerer

    Wow la verdad es que esto suena muy bien hoy por cierto vere por primera vez el win08 server con el que vere que es lo que cambio del 2003 R2.

    Actualmente tenemos problemas sobre el DHCP ya que solo cuando estan las IP’s estaticas podemos tener el servicio sin problemas pero si las dejamos dinamicas no se conecta.

    Alguna idea??

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s