Notas rápidas del MCSA

Nerd
Bueno, después de más de cuatro meses asistiendo a clases para la certificación MCSA de Microsoft, he decidido compartir algunas anotaciones interesantes que se han visto durante el curso, aunque no entran en el temario del mismo. Así que prepararos para una entrada bastante técnica, pero muy útil (o eso espero) para la gente de sistemas:

  • Servidor de ficheros: una buena idea es tener discos “hot swap”, para poder reemplazarlos sin necesidad de parar el servicio, en caso de necesidad. Esto no nos sirve, si lo que falla es el disco donde tenemos el sistema operativo; para ello, usaremos 2 discos en espejo.
  • Discos duros: básicamente hablamos de discos SATA y discos SCSI (llamados SAS actualmente). Estos últimos son los recomendados siempre en entornos de empresa, puesto que el rendimiento es mucho mejor a pesar de que el pico de rendimiento puede ser mayor en discos SATA, aunque únicamente en picos puntuales.
  • DMZ: nunca se deberían facilitar accesos directos al exterior desde la red interna. Para ello, usaremos máquinas que harán de intermediarios para los servicios requeridos (como DNS, correo, web, etc.) que se ubicarán en esta DMZ. Estas máquinas perimetrales, no deberían ser miembros del dominio, por temas de seguridad.
  • Servidor Radius/IAS: Montaremos un servidor Radius cuando 1) queramos centralizar ahí las directivas de acceso remoto o 2) queramos autentificar equipos contra servidores que no estén en Directorio Activo
  • NAS vs SAN: entre otras, la diferencia principal es que NAS tiene un sistema operativo que hace toda la gestión, mientras que SAN únicamente comparte disco.
  • Siempre que podamos, intentaremos deshabilitar (no quitar) los componentes no estrictamente necesarios (USB, CD, ciertos tipos de archivo anexos en correos electrónicos, etc.)
  • NetBios: hoy en día, si podemos, deshabilitaremos Netbios en nuestra red. Con ello, deshabilitaremos también la función “Mis sitios de red”, ya que únicamente se verá nuestro propio equipo. Los usuarios, por tanto, tendrá que usar la búsqueda por Directorio Activo para encontrar recursos compartidos, impresoras, usuarios, etc. Esto lo haremos, puesto que si tenemos muchos equipos, NetBios puede llegar a colapsar la red.
  • Directorio Activo: agarraos …
    • No montaremos un árbol de dominios con más de 3 niveles de profundidad, puesto que más niveles hacen inviable su gestión.
    • Montaremos un mínimo de 2 Controladores de Dominio por dominio.
    • Antes de montar Directorio Activo, deberemos tener muy claro para qué lo queremos, y siempre, primero se hará la estructura sobre papel.
    • Las cuentas de los usuarios que dejan la empresa, no deberán borrarse en los siguientes 5 años, por temas legales.
    • Los permisos se darán siempre a nivel de grupo.
  • Alto rendimiento: para alto rendimiento, usaremos (si el bolsillo lo permite) una cabina de discos, y montaremos el RAID por hardware que nos permita la cabina.
  • Además, usaremos fibra para la conexión gigabyte, o en su defecto, iSCSI.
  • Auditoría: la auditoría ha de habilitarse para empezar a registrar eventos. Lo que se ha hecho antes de habilitar la auditoría no se podrá auditar. En cualquier caso, para auditar necesitaremos:
    • Directivas: habilitar la directiva de auditoría necesaria, y
    • Recurso: habilitar el recurso que quiero auditar e indicar qué se quiere auditar.
  • Clústers: siempre que podamos, montaremos Clústers con Windows 2008 en lugar de con Windows 2003, por temas de compatibilidad.
  • Tarjetas de red TEAM: este tipo de tarjetas que soportan TEAM, permiten funcionar juntas como una sola (una máquina puede tener por ejemplo 4 tarjetas TEAM a 1 GB cada una, funcionando como una única tarjeta). Ésto nos permitirá usar cada tarjeta para una comunicación. Así, si por ejemplo estamos trabajando con una única comunicación por ejemplo copiando una ISO de 8GB, únicamente estaremos usando una de las tarjetas (a 1GB máximo). Sacaremos provecho al TEAM cuando estemos usando varias comunicaciones de forma simultánea.

¡Espero que os sea de utilidad!

Flickr! Foto por elvissa

¡Argh! ¡No funciona Internet!

Fear ¿Qué pasa cuando llegas a la oficina y…? ¡argh! ¡No funciona Internet ! Muchas cosas se te pasan por la cabeza, pero cuando descubres que tampoco responde a ping el servidor dns interno… La cosa cambia.

Ya no es un problema de conectividad o de red, que puede ser debido al switch, firewall, router, cables, ISP, etc. La cosa se centra únicamente en el servidor dns. Ese es el momento de levantarse e ir a la sala de servidores a mirar qué pasa (recordemos que el servidor no responde, así que tampoco debería funcionar el control remoto: no hay más remedio que levantarse).

Una vez en el cpd, se agradece haber etiquetado todos los servidores, y más aún ver que el servidor dns no tiene la luz encendida… ¿¡está apagado!? Pues sí, ese es el problema.

Después de encenderlo y comprobar que todo vuelve a la normalidad, después de este acto casi heroico que ha requerido de esta infinidad de conocimientos técnicos (léase, apretar el botón de encendido), toca ver qué ha pasado.

En los logs de Windows del "Event Viewer " del servidor, dentro de "System Logs " se podrá observar cuándo se apagó y cuando ha vuelto a encenderse. Por ejemplo, el último evento registrado en los logs antes de apagarse, dice "The Event log service was stopped ". Mirando un poco antes, se observa como se van deteniendo algunos servicios hasta que se llega a una entrada que tiene como origen "Windows Update Agent ". Examinando dicha entrada, se aprecia la siguiente descripción:

Restart Required: To complete the installation of the following updates, the computer will be restarted within 5 minutes:
– Cumulative Security Update for Internet Explorer 6 Service Pack 1 (KB963027)
– Security Update for Windows 2000 (KB959426)
– Security Update for Windows 2000 (KB923561)
– Windows Malicious Software Removal Tool – April 2009 (KB890830)
– Security Update for Windows 2000 (KB960803)
– Security Update for Windows 2000 (KB952004)

¡Fantástico! Las actualizaciones de Windows, estaban configuradas como automáticas, con permisos de descarga e instalación gestionados por Windows Update… Así que con la última publicación de las actualizaciones de Windows, el servidor se ha descargado e instalado dichas actualizaciones, con el posterior reinicio. ¿Reinicio? ¿Por qué no se ha reiniciado el PC? ¿Porqué se ha apagado directamente?

Una vez detectada la causa (otra cosa es ver quien o qué ha cambiado esto), es turno de la solución. Simplemente se vuelven a dejar las actualizaciones de Windows con permisos de descarga pero no de instalación, o si se dispone de algún programa de gestión centralizada de parches, pues entonces ni eso.

Flickr! Foto por herby_fr

Recuperando passwords cifrados

Passwords El cifrado de datos se usa en múltiples ocasiones, pero siempre con el fin de asegurar una confidencialidad, de no permitir que alguien que acceda a los datos pueda leerlos, ya que únicamente tendrá acceso al cifrado de los mismos.

Por ejemplo, los ficheros de password de Windows suelen guardar estas contraseñas cifradas, como ya vimos , en LM o NTLM según estemos usando Windows Vista o una versión anterior.

Un algorismo de cifrado muy común, por ejemplo en algunas bases de datos, es el famoso md5 , que genera cifrados de 128 bits, o 32 carácteres hexadecimales. Este es un tipo de cifrado unidireccional, es decir, nunca se podrá "descifrar" un cifrado, sino que se suele usar para comparar los cifrados de password, y no los password originales.

Pues bien, ayer me topé con que existen múltiples webs del estilo "password recovery" que mantienen grandes bases de datos con la palabra y su cifrado, permitiéndo buscar por cifrado y devolviéndo la palabra que lo generó. Un ejemplo es passcracking.com .

También podemos descargárnos directamente las rainbow tables correspondientes al algorismo de cifrado, para posteriormente usar algún programa como Rainbow Crack que busque en cuestión de segundos la relación entre el cifrado y texto plano que queramos recuperar. Hay muchas rainbow tables cada una con toda la relación cifrado-texto plano para un número y tipo de carácteres concreto. Más información aquí .

Flickr! Foto por Richard Parmiter

Mi mailbox inundado de spam

SPAMHoy en día hay un problema en Internéeee : el spam. Un buen programa antispam como spamassassin acaba con la mayoría de él, pero últimamente estamos teniendo algunos ataques de spam que hasta ahora no habíamos visto: se trata de los ataques de spam NDR (Non-delivery report).

Básicamente, se inunda el mailbox de correo que has enviado y que se te ha devuelto porqué la dirección de destino no existe, porqué el mailbox destino está lleno, o por cualquier otra causa. La gracia del asunto, claro está, es que realmente tu no has enviado ninguno de esos correos, simplemente los spammers se hacen pasar por ti (ponen tu dirección de correo en el campo "From" del email) y envían mensajes con spam a direcciones no existentes, de tal forma que a nosotros nos llega un correo devuelto que es sumamente fácil confundir con los correos devueltos habituales (hasta que lo abres y ves el contenido, claro).

Esto está más controlado en las ultimísimas versiones de algunos antispams, como spamassassin, que en mi caso, me he encargado de actualizar de la versión 3.1 a la 3.2 de la siguiente manera :

  1. Añadimos el repositorio Debian Volatile, el cual provee paquetes más nuevos para ClamAV y spamassassin que el repositorio debian estándar.
    deb http://volatile.debian.org/debian-volatile etch/volatile main contrib non-free
  2. Instalamos spamassassin mediante apt-get y sobrescribimos el anterior archivo de configuración /etc/default/spamassassin durante la instalación
  3. Habilitamos de nuevo spamassassin modificando la siguiente línea en /etc/default/spamassassin
    ENABLED=1
  4. Reiniciamos spamassassin
    /etc/init.d/spamassassin restart
  5. En /etc/mail/spamassassin/v320.pre añadimos la siguiente línea, que en nuestro caso ya viene habilitada por defecto, para encargarse de este tipo de ataques:
    loadplugin Mail::SpamAssassin::Plugin::VBounce
  6. Lanzamos spamassassin –lint para comprobar errores o warnings en la configuración
  7. Editamos el archivo de configuración de /etc/mail/spamassassin/local.cf para eliminar todas las entradas correspondientes a las "Network Checks", ya que a partir de esta nueva versión, esto estará en forma de plugin y se gestionará desde /etc/mail/spamassassin/v320.pre tal y como hemos visto.
  8. Finalmente probamos con algún mail en formato .txt que anteriormente el spamassassin nos había dejado pasar y que se trataba de un spam NDR, para ver si esta vez lo catalogaría correctamente con:
    spamassassin -Lt < mailtest.txt

Entrando en Vista (desde dentro)

BeerVeo en menéame un interesante vídeo de como conseguir privilegios de administración en una máquina Windows Vista (de la cual, obviamente desconocemos el password), usando la conocida distro Backtrack.

Sin duda un video interesante, y a tener en cuenta si tu empresa usa Windows Vista y cuenta con algún empleado con ganas de marcha, aunque, si no recuerdo mal, alguna vez he usado Ophcrack, otro Live-CD de este tipo especializado en recuperar contraseñas locales de sistemas Windows (y funciona). Así que quizá no haga falta irse a modificar ficheros como nos propone el tutorial, si ya tenemos la posibilidad de estar físicamente delante de la máquina “víctima”.

Flickr! Foto por Kate Raynes-Goldie

Conoce la web

Command LineBuscando mis cosillas por Internet, he ido a parar con una página accesible desde la caché de google que explicaba algunos comandos de lo más basico a la vez que interesantes para usar en Internet, si quieres obtener información de un determinado host. Creo que es una buena idea recogerlos y tenerlos aquí ordenados (obviamente hay muchos y muchos y aún muchos más).

  • ping <host>: el rey por excelencia. Si te responde sabrás que actualmente tienes conexión con el host. Si no te responde indicará que o bien está apagado, o bien no responde a pings debido a sus protocolos de seguridad. No lo uses junto a un -f ya que podrías llegar a colapsar el host (metiéndote en problemas). Junto con -a obtendremos la resolución de nombres para una dirección IP.
  • whois <host>: nos debería devolver el resultado de la consulta a la base de datos whois, con información del propietario del dominio del host, el teléfono y mail de contacto, etc. Además, es posible que nos devuelva un listado de DNS que guardan más información respecto al whois del host.
  • finger <usuario@host>: este es el comando que menos conozco. De hecho creo que no lo he usado desde la facultad (y quizá ni eso). Parece ser que este comando nos lo van a rechazar en la mayoría de ocasiones que lo usemos debido a problemas de seguridad, pero nos servirá para obtener información detallada de un usuario de un host (por ejemplo sacado del whois anterior). Usando simplemente <@host> nos listará los usuarios actualmente conectados al sistema. En cualquier caso, no viene instalado por defecto en las versiones de ubuntu que he probado (de la 6.06 en adelante).
  • telnet <host> <puerto>: pensándolo un poco, quizá me he precipitado diciendo que el ping era el rey. Si no ponemos puerto intentará conectar con el 23/TCP por defecto, en caso contrario intentará conectar con el puerto indicado, para comprobar si existe un servicio corriendo y accesible en el host.

Aprovechando el hilo dejo un comando más que no citaba las fuentes originales pero que creo que es bastante útil:

  • nslookup <dominio> <servidorDNS>: este comando preguntará al servidor DNS si es capaz de resolver el dominio que le indicamos. Útil a la hora de configurar firewalls y/o programas que actualizen desde un determinado host, y nos queramos asegurar de que serán capaces de encontrarlo.

Se trata de comandos muy básicos y la mayoría de ellos se pueden encontrar implementados en forma de aplicaciones web para ejecutarlos directamente desde la web. Como siempre, la mejor ayuda es el “man” o en su defecto, google.

Flickr! Foto por Dick Mooran

Integrándonos con Active Directory

GPOHace unas semanas, realicé un pequeño curso de administración de Directorio Activo en Windows 2003 Server, de forma totalmente gratuita aunque incompleta, ya que se trataba de una formación de 12h, de las 24 totales que duraba el curso. En cualquier caso me sirvió para aprender los conceptos básicos de DA e ir un poco más allá.

La cuestión es que este curso ha despertado en mi, simpatía e interés por los programas que tienen algún tipo de integración con DA. Curiosamente, vengo de pasar unos días en Peterborough (un pueblecito muy al norte de Londres), dónde he asistido a unas jornadas técnicas de unos productos que comercializamos, y me ha sorprendido ver como uno de ellos tiene implementada una muy buena integración con DA. Se trata de un programa de control remoto, cuya integración con DA va más allá de permitir que un determinado grupo o unidad organizativa tenga permisos para iniciar conexiones remotas con determinados usuarios, y por tanto decidir qué usuarios de DA pueden usar control remoto. Concretamente, lo novedoso (para mi) es que permite importarse en el DA a través de unos templates (ADM) que describen las políticas de configuración del programa, para poderse administrar todo directamente desde el propio DA.

Esto sin duda, facilita la vida a los administradores de sistemas, que pueden escoger si prefieren integrar la herramienta con su DA, manteniendo así de forma centralizada la administración de la seguridad de la empresa, o si por el contrario estiman mejor usar la propia interfaz de configuración del programa. Se trata, a mi entender, de una opción muy interesante a tener en cuenta.

Contraseñas de Windows

Mirando los feeds de “una al día” de Hispasec, he ido a parar a un fantástico artículo sobre la seguridad en las contraseñas locales en sistemas Windows dividido en varias entradas. Concretamente está en los siguientes enlaces:

Básicamente comentan la existencia de un fichero donde se almacenan las contraseñas (SAM), que como ya sabemos únicamente se guardan cifradas. Así pues, siempre que se realiza una comprobación de contraseñas realmente se realiza una comprobación del cifrado de las mismas (esta es la razón por la cual en los sistemas “seguros” un administrador nunca podrá recordarte tu contraseña si la has perdido, únicamente podrá crearte una de nuevo, ya que no será capaz de recuperarla a partir del cifrado).

Security

Por lo que nos comentan los amigos de Hispasec, inicialmente Windows usaba el algoritmo LM para el cifrado de las contraseñas (permitiendo contraseñas de hasta 14 carácteres), que introducía numerosos fallos de diseño y facilitaba la vida a los atacantes que buscaban mediante programas de fuerza bruta crear una contraseña que generase el mismo cifrado. Posteriormente Windows sacó el nuevo algoritmo NTLM, mucho más robusto, pero que no añadía seguridad, debido a que hasta la aparición de Windows Vista, se almacenaban los resultados de aplicar ambos algoritmos (LM y NTLM) en el mismo fichero de passwords (SAM), con lo que un atacante únicamente tenía que ignorar la clave NTLM y centrarse, como hasta ahora en el LM.

Como punto a favor, diremos que se puede anular el almacenamiento en cifrado LM usando passwords de 15 o más caracteres, o incluso forzando al sistema a no usarlo

Como último apunte, me quedo con el intento de añadir seguridad por parte de Microsoft, añadiendo un cifrado del cifrado con el uso de Syskey, que da las opciones (que nadie, que conozca, usa o ha usado) de tener que introducir manualmente el cifrado al iniciar el PC, o mediante el uso de un disquette, imposibilitando así que un atacante pueda conseguir este segundo cifrado (ya que está en tu cabeza o en un medio físico externo).

Flickr! Foto por Brad & Sabrina

Admin$

Admin$ es un recurso de red que nos permite saber si podemos conseguir permisos de administrador local en una máquina remota. Por defecto se crean en todos los sistemas operativos basados en NT (NT/2000/XP/2003) que comparten, además, cada partición del disco duro (C$, D$, etc.). Fuente:Wikipedia

Por nuestra parte, entonces deberíamos poder acceder al PC remoto de cualquiera de las siguientes maneras:

  • \\ip_pc_remoto\Admin$
  • \\ nombre_pc_remoto\Admin$

Después de autenticarnos, tendremos acceso al directorio %SYSTEMROOT% del PC en cuestión.

Esta semana me he encontrado un cliente con Windows XP Profesional SP2, con estos recursos no disponibles (mostrando el típico mensaje de “No se puede encontrar la ruta de acceso a la red”). Para reproducir el problema hemos seguido estos pasos:

  • Hemos entrado en el registro de un PC de test con Admin$ habilitado, para comprobar que no tenía la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\LanManServer\Parameters\AutoShareWks.
  • Hemos creado esta clave AutoShareWks tipo DWORD dándole valor 0 (deshabilitado).
  • Una vez reiniciada la máquina hemos comprobado que efectivamente, hemos perdido la conectividad con Admin$.
  • Dejando el valor de AutoShareWks a 1 y reiniciando el PC de nuevo hemos vuelto al punto de partida.
  • Cómo inicialmente no contábamos con esta key, la hemos eliminado, reiniciado por tercera vez la máquina, y como era de suponer, sin perder el acceso a Admin$.

En caso de que la máquina hubiese sido un servidor, habríamos trabajado con la key AutoShareServer.

Por cierto, Google no permite realizar búsquedas usando el símbolo ‘$’ salvo alguna excepción (cómo $10), así que no ha sido fácil encontrar esta información. Espero que os sirva!

La importancia de los Backups

Backups¿Quién no ha perdido en alguna ocasión datos importantes, y no ha podido recuperarlos por no tener una copia de seguridad? Hace poco, una empresa cliente ha tenido que cambiar de firewall ya que el anterior les ha dejado de funcionar. Al nuevo firewall le han cargado la copia de seguridad de la configuración más reciente: una configuración de hace algo más de tres meses, que obviamente no contempla muchos de los cambios que se han venido haciendo desde entonces. Esto nos ha ocasionado mucho trabajo; trabajo que ya habíamos hecho, y por tanto, mucha pérdida de tiempo, y todo debido a que la empresa cliente no tenía una buena política de copias de seguridad.

Tan importante como tener una buena política de copias de seguridad, es cómo se realizan estas copias. Y no me refiero a la metodología (periodicidad, copias incrementales, etc.), sino a la seguridad de las mismas. En entornos empresariales pequeños, en los que las copias de seguridad corren en DVDs o en discos extraíbles, prima que no nos sea un problema el caso de pérdida o sustracción de alguna de estas copias de seguridad. Esto nos lleva a la inevitable y necesaria encriptación de los datos de que constan nuestras copias. Este punto es sumamente importante si, por ejemplo como en el caso de la empresa anterior, nuestro backup contiene la configuración del firewall de nuestra empresa. Obviamente no nos interesa que nadie pueda ver nuestras políticas de seguridad de red, ya que perderíamos gran parte de esa “seguridad”. Igualmente, al trabajar con datos de clientes, proveedores o empleados, típicos de las bases de datos sobre las que se realizan los backups empresariales, es aún más importante que el administrador de sistemas se asegure de que dichos datos no puedan caer en manos ajenas, y que en caso de que así sucediese, no puedan ser accesibles.

Todo esto está muy bien, pero algo que creo no se acostumbra a hacer, es comprobar si las copias de seguridad que tenemos contienen todos los datos que queremos que contengan, y nos permiten recuperarlos en el mínimo tiempo posible. Por ejemplo, supongo que no será extraño empezar a trabajar en una empresa, y encontrarte toda la política de copias de seguridad ya definida, pero no encontrar por ningún lado definida la política de restauración de estas copias de seguridad. Quizá sería una buena idea, establecer metodologías para la recuperación de los datos de las copias de seguridad, para que cualquier persona pueda recuperar los datos en el menor tiempo posible.

Flickr! Foto por godog