viernes, 27 de abril de 2012

Wsus Actualizaciones automaticas para Windows

Hoy en día todos los sistemas operativos tienen fallos o digamos vulnerabilidades, que son usadas por personas para hacer daño a los sistemas o utilizarlos en forma masiva paar sus fines de lucro.




Un usuario casero que tiene en su poder un equipo con windows tiene habilitada la opcion de actualizar e instalar estos "parches" sin importar que es lo que tenga instalado.




Pero que pueden hacer las organizaciones grandes para actualizar controladamente sus equipos?




Microsoft piensa en todo y tiene herramientas que nos permiten descubrir las vulnerabilidades de nuestros equipos y el poder distribuir estas actulizaciones de seguridad.




Les voy a platicar de una de ellas que es WSUS.3.1


WSUS es una aplicación que puede ser instalada en nuestro entorno de red sobre un servidor con Windows 2008 R2 el cual ya tiene este rol listo para ser usado.


Como funciona: 
Nuestro servidor Wsus se comunicara con el sitio de Windows update de microsoft y de acuerdo a los sistemas operativos y aplicaciones microsoft que se configuren en la consola estará reportando las actualizaciones necesarias a distribuir


Si tenemos un entorno de red con un controlador de dominio gestionado por Active Directory domain services, podemos crear póliticas de grupo en la cual indicaremos que equipos se estarán reportando al Wsus. 


Este estara revisando que sistemas operativos y aplicaciones microsoft tengan instaladas y comparará unos archivos xml que tiene el control de que parches y actualizaciones ya cuentan los equipos y les notificara ( de acuerdo a la configuracion que hayamos hecho en la política de grupo ) que parches les falta y los aplicara exactamente igual que si lo hiciéramos desde windows update.


Esto en un entorno corporativo es genial ya que evitamos que los equipos de nuestro usuarios salgan a internet y consuman ancho de banda de nuestro enlace.


Se pueden instalar Wsus por localidades de acuerdo a su entorno de red para poder distribuir cargas y todos estos se pueden gestionar desde una sola consola de Wsus.


También existe una herramienta que nos ayuda a hacer un analisis de vulnerabilidades en entornos Windows, que es el Microsoft Baseline Security Analizer y ademas de decirnos que actualizaciones nos faltan ya sea a equipos clientes y servidores, nos ayudan a ver que posibles cambios de configuración tengan que realizarse en primer importancia a los servidores que dan servicios a nuestro usuarios.


Así que ha instalar estas herramientas y asegurar nuestra red, ahí les dejo unas ligas

http://technet.microsoft.com/en-us/windowsserver/bb332157

http://technet.microsoft.com/en-us/security/cc184924


Consultando la configuración DNS


Dig: consultando la configuración dns

Dig es una herramienta (linea de comandos) disponible en prácticamente cualquier distribución linux (aunque también hay alguna versión para windows) que te permite hacer consultas a un servidor dns. Dig precisa conocer la dirección IP de un servidor DNS al que consultar por defecto, dirección IP que toma del archivo resolv.conf, que en Windows puedes encontrar enc:\windows\system32\drivers\etc\resolv.conf, y en sistemas GNU/Linux en/etc/resolv.conf.
En esta página, y en diferente color, se incluyen los comandos a ejecutar desde la consola.

los 13 principales

Ejecuta en linea de comandos dig . ns y obtendrás la lista de los trece super servidores dns, que debe ser la misma que la que puedes obtener en ftp.internic.net
Si lo que quieres es conocer los servidores que manejan los dominios .com .net ..., prueba: dig com. NS o "dig net. NS"... Lo mismo para paises: prueba dig es. NS o dig ca. NS etc etc

Opciones dig

dig tu_dominio.com +trace
Similar al tracert TCP/IP, pero para dns
dig tu_dominio.com. NS
Te indica los servidores dns de tu_dominio:
;; ANSWER SECTION:
ignside.net.            132119  IN      NS      ns2.nexen.net.
ignside.net.            132119  IN      NS      ns1.nexen.net.
El primer número (132119) indica el TTL (tiempo de vida en cache) de la consulta
dig tu_dominio.com. MX
Te indica los servidores de correo (Mail e[X]change) que gestionan los mails dirigidos a loquesea@tudominio.com. Por ejemplo:
;; ANSWER SECTION:
ignside.net.            3600    IN      MX      10 pouilly.nexen.net.
ignside.net.            3600    IN      MX      20 champagne.nexen.net.
Estan listados por orden de precedencia, los números mas bajos (10, 20) primero.
dig tu_dominio.com
devuelve la IP del dominio
dig midominio.com. @dns1.nrc.ca
consulta los datos dns en un servidor @especifico.
La mayoría de los servidores DNS estan configurados para, si no conocen la respuesta al query, encargarse ellos mismos de reformular la pregunta a otro servidor distinto. Esto se llama configuración recurrente o amistosa (friendly, recursive).
dig -x numero_ip
DNS inverso

Descifrando las respuestas

Una orden como dig www.ignside.net genera el siguiente resultado:
C:\WINDOWS\system32\dns\bin>dig www.ignside.net

; <<>> DiG 9.4.0-(Hawk)-8.02 <<>> www.ignside.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1580
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.ignside.net.               IN      A

;; ANSWER SECTION:
www.ignside.net.        2886    IN      CNAME   irvnet.nexenservices.com.
irvnet.nexenservices.com. 6486  IN      CNAME   sauterne.nexen.net.
sauterne.nexen.net.     486     IN      A       217.174.203.10

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 28 22:33:36 2005
;; MSG SIZE  rcvd: 116


C:\WINDOWS\system32\dns\bin>
Veamos la respuesta linea por linea, teniendo en cuenta que aquellas que comienzan con ; son comentarios introducidos por dig, no vienen del servidor dns:
En las dos primeras líneas, dig se limita a informar de la versión del programa en ejecución y del dominio objeto de consulta. La línea ;; global options: printcmd se refiere a las opciones generales usadas en la consulta. Puedes evitar estas dos lineas utilizando la sintaxis de consulta dig +nocmd nombredominio.com
La siguiente seccion Got Answer nos ofrece detalles de la consulta recibida, entre ellos, el número de respuestas recibidas, y si nos la ha dado o no una "autoridad" en dns.
Las 'banderas' (flags) nos dan detalles de la consulta y respuesta: QR (Query/Response) sirve para diferenciar la consulta de la respuesta. RD (Recursion Desired), es una modalidad de la consulta, que es replicada en la respuesta con la bandera RA (Recursion Allowed), y significa que pedimos al server que si no puede resolver la respuesta por si mismo, consulte recursivamente a otro server. La aceptación de la petición por el server es opcional. AA significaría que la respuesta es de un serverautorizado. Otras flags son: TC (Truncated Response), que significa que la respuesta se ha fraccionado por ser de mayor tamaño del permitido, AD (Authentic Data) y CD (Checking Disabled).
La tercera sección nos da detalles de la consulta; además como es obvio del dominio consultado, nos informa que estamos consultando en los registros A. Como ya sabemos, si indicase MX en su lugar querria decir que estamos consultando una dirección de email. IN indica que la búsqueda se realiza en el ámbito de internet.
Las consultas posibles que podemos hacer, comenzando por las ya conocidas son:
  • dig midominio.com NS para los servidores dns (nombre)
  • dig midominio.com MX para los servidores de correo
  • dig midominio.com A para la ip del servidor que aloja al dominio
  • dig midominio.com ANY reune las anteriores
  • dig midominio.com AAAA nos indica el numero IP en ipv6 (si es que lo tiene, claro):
    C:\WINDOWS\system32\dns\bin>dig www.ipv6.org AAAA +short
    shake.stacken.kth.se.
    2001:6b0:1:ea:202:a5ff:fecd:13a6
    
En el ejemplo que hemos puesto mas arriba, la respuesta tiene varias lineas. La líneawww.ignside.net. 2886 IN CNAME irvnet.nexenservices.com. nos dice que el dominio por el que preguntamos es un alias (CNAME) de irvnet.nexenservices.com; La siguiente linea nos indica que irvnet.nexenservices.com es un alias de sauterne.nexen.net, y la tercera linea nos indica la IP de sauterne.nexen.net.
El porque tres respuestas ? porque www no es mas que un subdominio de ignside.net y este subdominio es un alias de irvnet.nexenservices.com (apunta a la misma IP) que a su vez es un alias del dominio del ISP (nexen), obteniendo finalmente la Ip de este.
El que ninguna de las respuestas que hemos obtenido sea AUTHORITY no dice nada sobre la fiabilidad de la respuesta, simplemente que el server que nos la ha dado no es responsable del dominio.
Finalmente podemos encontrarnos con una sección de respuestas adicionales, que típicamente nos informaría de las IPS de los nameserves devueltos en la sección AUTHORITY, si los hubiera.
La última sección nos explica el tiempo que ha tardado en resolverse la consulta, el número en bytes de la respuesta, la fecha y el servidor dns consultado.

Acotando las respuestas:

dig admite varias opciones que modalizan la cantidad de información obtenida. Todas las secciones de la respuesta pueden ser eliminadas con las opciones +nocmd, +[no]comments, +[no]question, +[no]answer, +[no]authority, +[no]additional y +[no]stats.
Existe una forma abreviada, que es la de excluir todo y indicar concretamente lo que quieres: dig midominio.com A +noall +answer.
Otra opción para limitar la información es short. Y si al contrario quieres mas detalles de los standard, prueba +multiline

TTL

La respuesta dns incluye un valor TTL expresado en segundos: por ejemplo, en esta linea, 2886 segundos: www.ignside.net. 2886 IN CNAME irvnet.nexenservices.com.
TTL, o Time To Live, es el tiempo máximo durante el cual un server almacenará en su cache una respuesta obtenida de un server con "autoridad". Mientras dure el TTL, el server en cuestión no volverá a realizar consultas dns sobre ese dominio, respondiendo con los datos guardados. Expirado el TTL, consultará de nuevo a la autoridad en la materia ...

Zonas DNS

Hemos venido hablando de respuestas autorizadas o no. El servidor DNS, al contestar las consultas, busca en primer lugar en los registros dns de su zona local (aquellos de los que el server es responsable). Si encuentra alli la respuesta, será una respuesta autorizada. Si no la encuentra, buscará en su cache de consultas anteriores. Si aquí se encuentra una coincidencia, el servidor responde con esta información. Esta respuesta ya no es autorizada. Finalmente si el servidor está configurado para la búsqueda recursiva, consultará -en nuestro nombre- a otro server dns.
Por ello el concepto de autoridad, en dns, es similar al de administración: la respuesta es autorizada si el dominio está en una zona administrada por ese server. La respuesta también es autorizada si nuestro server dns no tiene la respuesta en cache y hace una consulta recursiva. A partir de ese momento, y mientras conserve la respuesta en cache, no sera respuesta autorizada.

PTR

Pointer Record. Tambien llamado reverse record (registro inverso).
Un registro PTR asocia una dirección IP con su nombre de dominio real, debiendo apuntar a un nombre de dominio que se resuelva a esa IP. La IP se indica invirtiendo sus cuatro grupos de numeros y añadiendo IN-ADDR.ARPA.

SOA record

SOA son las iniciales de Start Of Authority. Un Registro SOA identifica la mejor fuente de información sobre un dominio dado, y solo puede haber un registro por dominio. La información que obtenemos con dig midominio.com SOA incluye:
  • Hostname.Domain.Name, que es el nombre del servidor primario para este dominio (donde reside la respuesta autorizada): por ejemplo, en el caso de google.com, es ns1.google.com..
  • Mailbox.Domain.Name es (teóricamente) el correo del responsable del DNS de este dominio; en el mismo ejemplo de google.com, dns-admin.google (sustituye el primer punto por @ para formar el email).
  • serno se refiere el numero de serie, que identifica cuando ha habido una actualización de la base de datos: por ejemplo numeros de serie válidos serian 1, 2, 3 etc .... Típicamente se usa como serial number la fecha inversa de la ultima actualización (año-mes-dia). Por ejemplo, 2005072601
  • Refresh indica al servidor secundario cada cuanto tiempo debe consultar al primario sobre actualizaciones
  • Retry indica el lapso que debe respetar el servidor secundario para tratar de reconectar con el primario, en el momento de Refresh
  • Expire es el numero de segundos durante los cuales el servidor secundario mantiene los datos, si no puede conectar con el primario
  • TTL es el tiempo de vida que los datos deben conservarse en cache al ser solicitados.

Enlaces relacionados

Para mas opciones puedes consultar los parámetros de un registro DNS. En esta pagina encontrarás listadas todas las querys posibles, opcodes, códigos de respuesta, etc.
Otro excelente recurso lo puedes encontrar en www.networksorcery.comMen&Mice tienen un excelente glosario, ambos links en inglés.
Men & Mice también ofrecen la posibilidad de usar dig online