Qos (Quality of Service) III de III

Hola!


Terminando el artículo de QoS, os mostramos el funcionamiento interno de la calidad del servicio. Cómo realiza las peticiones y como agregar una regla en el Directorio Activo. Empecemos!


Funcionamiento de QoS (Quality of Service) basada en directivas


El proceso para aplicar QoS en nuestros equipos, es similar a la replicación de otras políticas en directorio activo.


1.       El motor de directiva de grupo recupera del Directorio Activo la configuración de directiva de grupo de usuario o equipo.


2.        El motor de directiva de grupo informa a la extensión de cliente de QoS que se produjeron cambios en las directivas de QoS.


3.       La extensión de cliente de QoS envía una notificación de evento de directiva de QoS al módulo de inspección de QoS.


4.        El módulo de inspección de QoS recupera las directivas de QoS de usuario o equipo y las almacena.


 


El proceso siguiente tiene lugar al crear un nuevo extremo Capa Transporte (conexión TCP o tráfico UDP)


 


1.       El componente Capa Transporte de la pila Next Generation TCP/IP informa al módulo de inspección de QoS.


2.        El módulo de inspección de QoS compara los parámetros del extremo Capa Transporte con las directivas de QoS almacenadas.


3.        Si se encuentra alguna coincidencia, el módulo de inspección de QoS se pone en contacto con Pacer.sys para crear un flujode datos que contendrá el valor DSCP y la configuración de limitación de tráfico de la directiva de QoS. Si existen varias directivas de QoS que coinciden con los parámetros del extremo Capa Transporte, se utilizará la directiva de QoS más específica.


4.        Pacer.sys almacena el flujo y devuelve un número de flujo correspondiente al flujo del módulo de inspección de QoS.


5.        El módulo de inspección de QoS devuelve el número de flujo a la capa Transporte.


6.        La capa Transporte almacena el número de flujo con el extremo Capa Transporte.


 


El proceso siguiente tiene lugar cuando se envía un paquete correspondiente a un extremo Capa Transporte marcado con un número de flujo


1.       La capa Transporte marca de forma interna el paquete con el número de flujo.


2.        La capa Red solicita a Pacer.sys el valor DSCP correspondiente al número de flujo del paquete.


3.        Pacer.sys devuelve el valor DSCP a la capa Red.


4.        La capa Red cambia el campo TOS de IPv4 o el campo de clase de tráfico de IPv6 por el valor DSCP especificado por Pacer.sys y, para los paquetes de IPv4, calcula la suma de comprobación final del encabezado de IPv4.


5.        La capa Red entrega el paquete a la capa Tramas.


6.        Debido a que el paquete está marcado con un número de flujo, la capa Tramas lo entrega a Pacer.sys a través de NDIS 6.0.


7.       Pacer.sys utiliza el número de flujo del paquete para determinar si éste necesita o no limitación, y en caso afirmativo, programa el envío del mismo.


 


8.        Pacer.sys entrega el paquete, bien inmediatamente (si no hay limitación de tráfico), o bien según lo programado (si la hay) a NDIS 6.0 para su transmisión a través del adaptador de red adecuado.


Y para terminar, la creación de una regla QoS en Windows Vista, es tan sencillo como realizar estos pasos:


1.       En el menú de Windows Vista, en la cajetilla Buscar, introduciremos el comando gpedit.msc


2.       Aceptamos el aviso de UAC dando conformidad al comando


3.       En el editor de objetos de directiva de grupo, nos dirigiremos a Configuración de equipo à Configuración de Windows àQoS basada en directivas de grupo


4.       Pulsando con el botón derecho del ratón sobre esta última pestaña (QoS basada en directivas de grupo) marcaremos la opción Crear nueva directiva


El proceso es muy sencillo. Comencemos:


 


Configuración QoS


 


La primera parte del asistente nos pregunta por el nombre de la aplicación, el valor DSCP que le queremos dar, y el valor (ya sea en Kbps o en Mbps) del acelerador.


Configuración QoS II


 


En la siguiente parte, nos preguntará si queremos establecer la directiva para todas las aplicaciones o sólo para alguna específica


 


Configuración QoS III


 


La siguiente pantalla del asistente nos preguntará por alguna dirección IP o rango entero. La misma pregunta se aplicará para confirmar el destino.


 


Configuración QoS IV


 


La última parte del asistente nos preguntará por el tipo de protocolo que utilizará la aplicación y el puerto. Al finalizar, nuestra nueva regla QoS se habrá aplicado.  


Como se puede ver, el diseño de los componentes de QoS basada en directivas conlleva las ventajas siguientes:


• La inspección del tráfico para determinar si una directiva de QoS se aplica o no se realiza por extremo Capa Transporte, y no por paquete.


• Al poder establecer reglas en base a una aplicación específica, el rendimiento del tráfico que no coincide con una directiva de QoS no se ve afectado.


• No es necesario modificar las aplicaciones para utilizar el servicio diferenciado basado en DSCP o la limitación del tráfico, ya que estas reglas se aplican por debajo de la capa de aplicación.


• Las directivas de QoS se pueden aplicar al tráfico protegido por seguridad de protocolo de Internet (IPsec).


Saludos!


 

PowerShell (II de V)

Comenzamos esta segunda entrega describiendo la base de la sintaxis en powershell. Lo primero que debemos conocer es que los comandos de PowerShell ahora se denominan cmdlets y comparten una sintaxis común.


 


Todos los cmdlets consisten de un verbo y un nombre, separados por un guión.


Esta estructura permite un aprendizaje más rápido y sobre todo relacionar fácilmente el verbo con lo que se quiere realizar, por ejemplo.


 


Algunos de los verbos admitidos en esta versión 1.0 de powershell son get, set, new, write, start, stop, remove, add, etc..Es relativamente sencillo suponer qué es lo que hace cada uno de los verbos. Si a continuación le agregamos el nombre, completamos el cmdlet, por ejemplo:


 



  • Get-help

  • Get-childitem

  • Get-service

  • Get-process

  • New-item

  • Set-acl

  • Set-alias

  • Set-date

 


Sin embargo muchos de estos cmdlets tienen su alias en versión UNIX y CMD.EXE para aquellos administradores que vengan desde estos entornos, por ejemplo:


 


Get-childitem nos sirve para listar los objetos dentro de una carpeta o disco y podemos utilizar el cmdlet nativo de Powershell o los ya conocidos ls y dir de UNIX y CMD.EXE respectivamente. Además, para no tener que escribir todo el cmdlet, también existe un alias reducido como gci en este caso.


 




Si no conocemos el nombre que debemos utilizar después de un verbo, PowerShell incluye una ayuda para autocompletar los cmdlets utilizando la tecla tabulación. Por ejemplo, si escribimos el verbo set- y queremos saber qué nombres están admitidos, solo vamos circulando por los nombres con TAB.


 



  • Set-acl -> TAB -> set-alias -> TAB -> set-authenticodeSignature -> TAB -> set-content -> TAB -> set-date -> TAB -> set-ExecutionPolicy ->  y así sucesivamente

 


Podemos también comenzar escribiendo las primeras letras del nombre y PowerShell completará los nombres que coincidan con estas primeras letras.


 


Windows PowerShell es una consola orientada a objetos, lo que quiere decir que todos los comandos de entrada y salida son en sí mismos objetos.  PowerShell se basa en el modelo de objetos de.Net.


 


.Net es una representación de objetos unificada que utilizan todos los equipos de desarrollo de Microsoft, por lo tanto desde PowerShell se pueden gestionar todos los componentes de Windows y de las aplicaciones basadas en .Net


 


Por ejemplo, si queremos conocer el día de la semana del 4 de enero de 1643 (nacimiento de Isaac Newton), solo tenemos que escribir lo siguiente:


 



  • (get-date “04/01/1643”).DayOfWeek

 


En este ejemplo, el cmdlet get-date devuelve el objeto .Net DateTime, que tiene una propiedad que calcula el día de la semana. Una aplicación más interesante para los administradores de sistemas es por ejemplo verificar si un archivo es más reciente que otro.


 



  • (get-childitem archivo1.txt).lastwritetime –gt (get-childitem archivo2.txt).lastwritetime

 


Si queremos conocer todos los detalles de cada cmdlet, Get-help nos muestra la ayuda completa. Su so es: get-help cmdlet, por ejemplo: get-help get-childitem.


 


La ayuda en PowerShell está muy cuidada y es muy extensa, de hecho podemos mostrar tres niveles de ayuda:


 



  • get-help get-childitem (Ayuda general y resumida)

  • get-help get-childitem –detailed (ayuda detallada)

  • get-help get-childitem –full (ayuda técnica completa)

 


Si la ayuda es extensa para visualizarla en pantalla, podemos exportar el contenido a un archivo de texto:


 



  • get-help get-childitem –full | out-file C:AyudaPowerShell.txt

 


Aunque si estáis acostumbrados a cmd.exe, podemos escribir lo siguiente para hacer lo mismo:


 



  • get-help dir –full > C:AyudaPowerShell.txt

 


 


Además, parte de la ayuda completa incluye numerosos ejemplos de aplicación de cada cmdlet.


 


Como habéis podido observar, en el anterior ejemplo hemos utilizado el símbolo | Una de las características más importantes de PowerShell es la capacidad de crear pipas (pipes), de tal forma que podemos pasar los resultados de un cmdlet hacia el siguiente. Esta funcionalidad ya la conocen muy bien los administradores que vienen del entorno UNIX ya que es una característica común desde hace mucho tiempo, y que sin embargo en Windows había sido una funcionalidad reducida a algunos comandos muy específicos, como por ejemplo > para exportar los resultados a un archivo de texto.


 


Cada cmdlet en un pipeline recibe un objeto del cmdlet previo, realiza una operación en él y después pasa el resultado al siguiente cmdlet en la pipa.


 



  • Get-childitem –recurse –filter *.exe | format-table name, lenght

 


En el ejemplo anterior, el cmdlet get-childitem recorre todas las carpetas por debajo de la ubicación actual en busca de archivos .exe y el resultado se pasa al cmdlet format-table para dar formato con el nombre y la longitud de los archivos encontrados.


 


Esta es una forma sencilla de hacer búsquedas y formatear la salida en pantalla. Otro ejemplo similar es el siguiente:


 



  • Get-childitem –recurse –path “C:windows” –filter *.dll | where {$_-name –match “system.*dll”}

 


Esta instrucción busca todos los archivos en la carpeta Windows que lleven la palabra system y con extensión dll.


 


Una característica destacable es la capacidad de ejecución en streaming de Powershell, es decir, no necesitamos esperar a que se procesen todos los resultados para verlos en pantalla, sino que a medida que se van encontrando valores coincidentes, se van presentando en pantalla.


 


En la mayoría de las consolas, el streaming se consigue ejecutando procesos separados para cada elemento en la pipa. PowerShell solo utiliza un proceso de ejecución y un único hilo. El streaming se logra particionando los cmdlets en tres cláusulas: inicio de proceso (begin-processing), objeto en proceso (process-object) y fin de proceso (end-processing).


 


Con esto llegamos al final de esta segunda entrega de PowerShell, seguiremos comentando más detalles de los cmdlets y su utilización por parte de los administradores de sistemas en el siguiente post.

Quality Of Service (QoS) II de III

Siguiendo la estela de artículos sobre Qos, aquí os hago llegar la segunda parte.  


Una política QoS puede ser aplicada a una cuenta de usuario o a un equipo, como parte de una GPO (Group Policy Object), la cual podemos linkar en un directorio activo que contenga un dominio. Al ser parte de una GPO, las políticas QoS en Windows Server 2008 y Windows Vista coexisten perfectamente en una infraestructura de Directorio Activo.


Para definir la prioridad del tráfico, podemos configurar una política QoS marcando el tráfico saliente con un valor específico DSCP (Punto de código de servicios diferenciados), tal y como lo define el RFC 2474.


El valor DSCP se almacena en el campo de tipo de servicio (TOS) del encabezado de IPv4 o en el campo de clase de tráfico del encabezado de IPv6. Los routers más modernos admiten la clasificación del tráfico en función del DSCP, aunque en muchos de ellos viene deshabilitado de fábrica. Si activamos esta función, los routers podrían leer el valor DSCP, y asignar el paquete a una cola específica.


Un router podría situar un paquete en función de su DSCP a una cola de “prioridad alta”, “mejor esfuerzo” o “inferior al menor esfuerzo”. Al configurar las colas de salida en función del DSCP, podríamos priorizar el tráfico en función de nuestras necesidades. Daríamos prioridad al tráfico en función de su necesidad.


Con QoS también podemos administrar el ancho de banda. Podemos configurar una directiva con una tasa de limitación para cuando salga el tráfico. Configurar esta limitación nos permite que QoS limite el tráfico de red saliente en función de la configuración de directiva que hayamos aplicado. Esta limitación la podemos expresar en Kbps o Mbps .


La arquitectura de QoS se basa en las siguientes características:


NPI de QoS o Interfaz de proveedor de red. Interfaz para controladores en modo núcleo que interactúa con el driver Pacer.sys.


Pacer.sys. Nuevo controlador de filtro ligero NDIS 6.0 que controla la programación de paquetes correspondiente a QoS basado en directivas y al tráfico de aplicaciones que utilizan las API genérica de QoS (GQoS) y de control de tráfico (TC). Pacer.sys sustituye a Psched.sys en Windows 2003 y Windows XP. Pacer.sys se instala con el componente Programador de paquetes de QoS desde las propiedades de conexión o adaptador de red.


NDIS 6.0.- Interfaz estándar entre los controladores de red en modo de núcleo y el SO Windows Server 2008 y Windows Vista. NDIS 6.0 admite los nuevos filtros ligeros. Estos son un modelo de controladores diseñado para controladores intermedios y de mini puerto NDIS, el cual nos aportará un mayor rendimiento.


Motor de directiva de grupo.- Durante el inicio de sesión recupera del directorio activo la configuración de directiva de usuario y equipo. También comprobará los cambios de directiva, y si detecta algún cambio, éste recuperará del directorio activo la nueva configuración. Este motor procesa los objetos GPO y sirve también para informar a la extensión de cliente de QoS de la actualización de las directivas.


Extensión de cliente de QoS.- Componente del servicio de cliente de directiva de grupo que únicamente espera e informa. Espera las indicaciones del motor de directiva de grupo por si se produce algún cambio, e informa al módulo de inspección de QoS.


Módulo de inspección de QoS.- Componente de la nueva pila TCP/IP que espera indicaciones de la extensión de cliente de QoS. Ésta recupera la configuración de la directiva de QoS e interactúa con la capa de Transporte y el driver Pacer.sys para marcar de forma interna el tráfico que coincide con las directivas de QoS.


Pila TCP/IP.- La nueva pila rediseñada para Windows Server 2008 y Windows Vista. Incluye compatibilidad integrada para IPV4 e IPV6 y admite la nueva plataforma Windows Filtering Platform.


Servicio de cliente de directiva de grupo.- Servicio de Windows que administra la configuración de directiva de grupo, tanto para usuario como para equipo.


En el siguiente artículo veremos cómo funciona internamente QoS hasta aplicar una directiva y crearemos una regla QoS.


Hasta entonces!

Windows Vista y Malware II

Tras haber analizado el intento de ejecución del Rootkit Hacker Defender con un usuario administrador y el UAC habilitado y haber sido infructuoso, vamos a proceder a realizar el ataque haciendo uso de los privilegios de Administrador.


Para realizar un rastreo al comportamiento del Rootkit evaluaremos 5 componentes básicos de este tipo de malware:


                – Ocultación de ficheros y carpetas.


                – Ocultación de procesos y servicios.


                – Ocultación de Puertos.


                – Ocultación de aplicaciones.


                – Componente troyano con tecnología de redirector.


Partimos de la base de que tenemos tanto el fichero de ejecución del rootkit como su fichero de configuración se encuentran en el escritorio de usuario y lo ejecutamos con privilegios de administrador.



Imagen 1- Ejecutando HXDEF100 y comprobando puertos


Inicialmente no detectamos ningún comportamiento anómalo típico, como la desaparición automática de los ficheros hxdef100, ¿ha fallado o es un comportamiento anómalo? Pasamos a realizar las comprobaciones de rigor: no aparece el proceso, ni el servicio, los puertos no han desaparecido aunque desde el fichero de configuración se solicitaba la ocultación de los puertos TCP 135 y 445, el troyano con tecnología de redirector no es funcional, pero ¡curiosamente aunque nuestra aplicación de referencia: la calculadora, se ejecuta sin problema, el icono ha desaparecido!



Imagen 2 – Comprobando proceso ocultacion de aplicaciones.


Bueno estos último nos deja una única funcionalidad: el rootkit se ha ejecutado con eficacia, aunque sus comportamientos para enlazar mediante Hooks las aplicaciones y procesos a engañar no han sido fructuosas, el tratamiento del modelo de UIPI y MIC ha funcionado correctamente.


Aún así  como no me deja tranquilo las pruebas, vamos a poner a Windows Vista en más aprietos. Como uno de los comportamientos a esperar es la ocultación de las carpetas, vamos a crear una carpeta con el mismo nombre el ejecutable (hxdef100) y movemos los ficheros hxdef100.exe y hxdef100.ini a la carpeta. ¡Oh sorpresa! Los ficheros desaparecen, pero no la carpeta. Pues vamos a comprobar el proceso y este aparece en el administrador de proceso, aunque no queda oculto, tampoco cambia el comportamiento con respecto a los puertos ni a la calculadora.


¿Porque se ha producido este comportamiento? Se ha producido una posible manipulación en la devolución de datos en el proceso explorer.exe, que se está ejecutando en la capa del administrador, aunque no se ha podido incidir sobre otros procesos restringidos, ni en el Kernell del sistema. Tal y como esperaba, el hecho de reiniciar el Sistema, lleva consigo que el servicio que controla y ejecuta el proceso HXDEF100, no puede levantarse puesto que no encuentra el fichero para la ejecución del servicio.



 


El resultado final de las pruebas realizadas nos devuelven los siguientes resultados:


          El comportamiento del Rootkit no ofrece la misma funcionalidad que en un Windows XP o en un Windows 2003.


          Hemos tenido que forzar por predicción de comportamiento la ejecución y el proceso de acción del Rootkit.


          Se revela bajo el procedimiento convencional que existe un proceso anómalo en ejecución.


          Las funcionalidades para la ocultación de aplicaciones y puertos no ha resultado efectiva.


          El comportamiento del troyano en tecnología de redirector ha fallado, no devolviendo ninguna Shell de ejecución.


Pues como este laboratorio no me ha dejado satisfecho, para el siguiente, un Rootkit un poco más puñetero. Seguiremos probando a Windows Vista…


Referencias Externas


 


 —————————————————————-


 


Rootkit 


 


UIPI y MIC

Políticas de Grupo en Windows Vista IV : Restriccion de hardware

Ya hemos comprobado las principales mejoras referentes al tratamiento de las políticas de grupo en Windows Vista. Podéis encontrar las referencias a continuación:

GPOs en Windows Vista 1


GPOs en Windows Vista 2


GPOs en Windows Vista 3



Solo nos queda echar un vistazo a las más de 800 nuevas políticas incorporadas para le gestión de este Sistema Operativo, por lo que en los próximos post iremos dando un repaso a aquellas políticas más destacadas. De momento podeis descargaros el listado completo de nuevas políticas en:


http://www.microsoft.com/downloads/details.aspx?familyid=41DC179B-3328-4350-ADE1-C0D9289F09EF&displaylang=en



A lo largo de este Blog algunos compañeros ya han hecho alguna referencia a ciertas políticas de grupo como aquellas para la gestión de UAC, Bitlocker o QoS por lo que no es necesario volver a ellas. En el presente post trataremos uno de los conjuntos de políticas más destacados: La Instalación de Dispositivos.



Hoy en día las memorias flash y otros dispositivos de almacenamiento USB están en manos de todos, ya sean PenDrives, MP3, tarjetas de memoria o discos duros externos, en las empresas de hoy en día donde el uso de disqueteras y los lectores de CD-DVD hace tiempo que está deshabilitados para prevenir posibles gusanos, ataques internos y robos de datos suponen un claro riesgo de seguridad, pese a que algunos de estos problemas los podamos paliar con otras herramientas como Rights Management Services (RMS) o las distintas soluciones antimalware, todos somos cocientes de la posibilidad de que alguien ajeno a un departamento pueda en un momento dado conectarse a un equipo y en menos de 5 minutos llevarse información confidencial de la empresa en un dispositivo USB o peor aun: que un empleado en su último día de trabajo conecte uno de estos dispositivos a un equipo y lo infecte de manera intencionada con un gusano o un rootkit. La mejor solución a este problema es a la vez la más sencilla e intuitiva: imposibilitar la instalación de dispositivos externos. Antes de Windows Vista teníamos que recurrir a soluciones de terceros para aplicar esta medida, pero gracias a las nuevas políticas incorporadas en este S.O. esta situación ha cambiado.



Las nuevas políticas de restricción e instalación de hardware las encontramos en “Configuración de equipo > Plantillas administrativas > Sistema”. Dentro de las posibilidades de restricción de hardware tenemos dos conjuntos principales de políticas: “Acceso de Almacenamiento Extraíble” donde podremos deshabilitar las capacidades de lectura o escritura de distintos dispositivos e “Instalación de dispositivos” donde tendremos la posibilidad de restringir la instalación de los controladores de aquellos dispositivos que indiquemos, siempre que sus drivers no se encuentren ya instalados en el equipo.


 



 


La configuración de las políticas de uno y otro grupo son muy sencillas de configurar, simplemente habitamos o deshabilitamos las políticas según el comportamiento que deseemos, así, por ejemplo, si habilitamos la política “CD y DVD: denegar acceso de lectura” veremos que al intentar acceder a un CD en el equipo nos aparece una advertencia indicando “Acceso Denegado”


 
Así mismo si configuramos la política “impedir instalación de dispositivos extraíbles” comprobamos que al conectar un dispositivo extraíble, como una llave USB, nos aparece un globo de información indicándonos que no ha sido posible instalar el dispositivo.


 
Ambos tipos de políticas, las de “Acceso de Almacenamiento Extraíble” y las de “Instalación de dispositivos” tienen la capacidad de aplicarse a tipos de dispositivos personalizados, usando para ello el GUID de dicho tipo de dispositivos, es decir que teneros la capacidad de impedir el uso o instalación de diferentes dispositivos según su GUID. La forma más sencilla de saber el GUID de un dispositivo es comprobarlo en el “administrador de dispositivos” en la pestaña detalles de las propiedades del dispositivo a comprobar.


 


Por ultimo, en el caso de las políticas del tipo de “Instalación de dispositivos” tenemos la posibilidad de escribir un texto personalizado para el globo de información que nos aparece al no poder instalar los controladores.


 
Como habéis podido comprobar en este post, Windows Vista ha mejorado sustancialmente sus capacidades de administración en sus nuevas políticas de grupo, capacidades que sin duda no tardaremos mucho en verlas funcionando en muchas empresas de nuestro alrededor. Por mi parte continuaré descomponiendo el entresijo de políticas de Windows Vista en sucesivos posts. Me despido hasta entonces.