Autor: jgarrido

Hola a tod@s!

En este artículo veremos las opciones que tenemos como usuarios de Internet a la hora de denunciar un caso de Phishing.

El Phishing como tal, no sólo ataca a Bancos, sino que abarca mucho más. Correo, banco, comunidades virtuales, etc.. No está de más decir que todos los añadidos en seguridad que se le puedan dar al usuario, nunca estarán de más.

Internet Explorer, entre otras cosas, tiene el añadido de poder poner en conocimiento un sitio Web malicioso al equipo encargado de mantener el filtro antiPhishing del navegador, todo ello a través de un simple cuestionario.

Este cuestionario, una vez realizado y enviado, será revisado por el equipo de desarrollo del filtro antiPhishing, y éstos determinarán si la Web mandada es maliciosa o no. Si ésta es una Web maligna, pasará a formar parte de las listas negras del filtro antiPhishing. Realizar esta tarea es tan simple como el ejemplo que os traigo:

Hace como un mes más o menos me mandaron un mail en el que se me solicitaba un cambio de clave en Ebay. Al pinchar en el enlace, esto es lo que conseguí:

Si revisáis la imagen, comprobaréis que es un claro intento de estafa. El link no coincide con la página en cuestión y la página no tiene certificado de seguridad, dos claros síntomas de que la página no es quien dice ser. En este caso podemos hacer dos cosas. La primera en cuestión es comprobar si este sitio realmente es quien dice ser o no, y la segunda opción es reportar un caso de phishing directamente. En este caso nos decantaríamos por la segunda opción, ya que tenemos elementos suficientes para decir sin género de dudas que se trata de un caso de robo de información. Para realizar el formulario, tan sólo tendremos que pulsar en Herramientas –> Filtro Phishing –> Reportar sitio.

Una vez que hayamos seleccionado la opción, se nos abrirá una nueva pestaña en nuestro IE, en la cual tendremos que informar sobre el idioma utilizado en la Web y una vez marcada esa opción, dar al botón de enviar, tal y como se muestra en la imagen:

Al cabo de unos días, y si realmente el sitio es un sitio Web de suplantación de identidad, habrá entrado en las listas negras, y el sitio debería verse tal que así:

Con esto conseguimos no sólo ayudarnos a nosotros mismos como usuarios. Una simple tarea sirve para ayudar a muchísimos usuarios que reciban este mismo link.

Y eso es todo chic@s. Hasta otra!

Información adicional:

FAQ sobre el filtro AntiPhishing de Microsoft

Todo lo que debe saber acerca del Phishing

Grupo de delitos telemáticos de la Guardia Civil (España)

Hola a tod@s!

Llevo unas semanas de curro impresionantes, y no tengo apenas tiempo físico para escribir un poquito, así que estoy «economizando» mis momentos para hacer varias tareas a la vez. Los hombres también podemos hacer más de dos cosas a la vez. ;-). Así que aquí estoy, en un bar irlandés, con una cervecita negra que no rubia, con el portátil encendido, y como no! los que me conozcáis deduciréis que me he sentado en un sitio estratégico… Pues sí herman@s. Estoy sentado frente a una morena… Y me está mirando! 🙂

En fin, siguiendo a otras cosas más divertidas, me di cuenta hace una semana más o menos de un comportamiento curioso en Windows Vista que no tienen sus hermanos pequeños, Windows XP/2K3, etc… El caso es el siguiente.

Cuando un malware infectaba un equipo, éste lo podía hacer de muchas maneras. Una de las más fáciles era nombrar el malware como un proceso crítico del sistema. Todos conoceréis o habréis tenido la ocasión de examinar un equipo que tenga un malware de estas características. Ejemplos los hay a miles:

http://web.alerta-antivirus.es/virus/detalle_virus.html?cod=6858 (Malware MumaWow) (Versión TrianaDirecto:Mumamón) 😉

http://www.alerta-antivirus.es/virus/detalle_virus.html?cod=3650 (Malwrare NetSky)

Son dos ejemplos más que ilustrativos. Uno se «camufla» bajo el sobrenombre de svchost, y NetSky utiliza el nombre de Winlogon.

Pongamos un ejemplo ilustrativo con el proceso Winlogon.

Winlogon es un proceso crítico del sistema operativo. Se encarga de muchísimas tareas en el sistema operativo tales como la secuencia de seguridad CTRL+ALT+SUP, responsable de la configuración de las políticas de grupo, cargar perfiles de usuario, da soporte a GINA, etc… 

Los creadores de malware saben esto, y piensan automáticamente que si vemos algún proceso con este nombre, nos lo pensaremos dos veces antes de pararlo. Si conseguimos parar este proceso, nuestra sesión se cierra automáticamente. Este comportamiento de Windows es así por diseño del sistema operativo (sólo hay un proceso winlogon corriendo en el sistema), para prevenir por ejemplo que una aplicación muestre un diálogo de inicio de sesión falso, y así conseguir suplantar la identidad de algún usuario.

Si aún sabiendo estos datos, nos diésemos cuenta de que tenemos más de un proceso winlogon en nuestro sistema, e intentásemos pararlo, esta es la respuesta que obtendríamos.

No lo puedo parar! Horror!! Qué pasa? Qué tipo de comportamiento es este? Si soy el administrador de mi equipo, como es que no puedo eliminar este proceso?

Son preguntas que nos hemos hecho todos alguna que otra vez. En versiones anteriores a Windows Vista, el administrador de tareas (y taskkill en línea de comandos) intentaba evitar mediante un algorítmo el hecho de que se pudiese eliminar un proceso crítico del sistema operativo. Pero hecha la ley, hecha la trampa. El algorítmo para decidir qué proceso era crítico o no, no era muy inteligente que digamos en Windows XP/2K3, etc.., y era fácil para un creador de malware simular un proceso crítico del sistema (simplemente cambiando el nombre) para que herramientas del sistema como el TaskManager o TaskKill no pudiesen eliminar.

Aunque bueno, miento un poco. La aplicación sí que se puede eliminar, pero desde herramientas de terceros, como puede ser perfectamente válida Process Explorer.

Para evitar este tipo de falsificaciones, el administrador de tareas de Windows Vista ya no «vigila» si un usuario quiere parar un proceso crítico del sistema operativo, ni intenta evitar el paro forzoso de un proceso, sea crítico o no. Nos da total libertad para hacer con los procesos que no sean de sistema lo que nos de la gana, asumiendo así toda la responsabilidad.

Para procesos iniciados desde la capa de usuario, iniciaremos acciones en el administrador de tareas tal y como aparece en la imagen de abajo:

Y para procesos críticos del sistema que estén iniciados desde la capa del sistema, iniciaremos acciones en el administrador de tareas previa aceptación de elevación de privilegios si UAC está habilitado (por defecto está habilitado):

Y eso es todo amig@s!

Sed buenos. Yo desconecto ya. Creo que he descubierto una brecha de seguridad en el perímetro en donde está sentada la morena y voy a aprovecharla!

Saludos a tod@s!!

Hola a tod@s!

Este post lo quiero dedicar a una característica de Internet Explorer que me ha llamado mucho la atención en Windows Vista. La capacidad para controlar los ActiveX en nuestra empresa.

Antiguamente no existían las amenazas que tenemos hoy en día, y los desktops en nuestra empresa podían trabajar sin la necesidad de una securización total. También es sabido que hoy en día casi toda la comunicación e iteración entre el usuario e Internet pasa por el navegador. Y todas las pistas nos llevan a deducir que esto irá a más.

Internet Explorer es el navegador por excelencia en el ámbito corporativo. Tiene multitud de funciones y características de seguridad que hacen a este navegador único en la empresa. Por un lado para estar totalmente integrado con la infraestructura de la empresa, y por otro lado, su capacidad para securizarlo y adaptarlo a las necesidades de la empresa, siempre y cuando no se navegue bajo una cuenta administrativa, y partiendo de la base de que el equipo cumple con el principio del mínimo privilegio.

En versiones Windows 2000 y Windows XP, lo teníamos todo, excepto la capacidad de controlar aquellos ActiveX que sí necesitamos en nuestra empresa.

Un control ActiveX no es más que código ejecutable empacado en un archivo (generalmente con extensión .cab) que el usuario puede invocar e instalar desde Internet Explorer. Es una gran característica que se inventó para hacernos la vida un poco más fácil, permitiendo a los desarrolladores poder distribuir más fácilmente sus herramientas, pero que ha terminado (en la mayoría de los casos), en volvernos locos a más de uno.

Os pongo un caso curioso y personal. No hace mucho me encomendaron la labor de migrar una plataforma de trabajo (poco menos de 1000 desktops), de sus privilegios actuales (la mayoría administradores), a una plataforma que cumpliese con el principio del mínimo privilegio.

La migración duró un tiempo, y salvo algún que otro problema (siempre los hay J), todo fue como la seda. Hasta que llegamos a los ActiveX.

Debido al gran auge de ataques bajo controles ActiveX, nos planteamos una seria duda. Un control ActiveX, en la mayoría de los casos (99%) ha de instalarse bajo una cuenta administrativa. Si estábamos realizando la labor de llevar a la empresa a cumplir con el principio del mínimo privilegio…. Qué hacer?

No todos los ActiveX son dañinos. Tenemos el ActiveX de Adobe, el de Windows Installer para las actualizaciones de Windows, y, a parte, la empresa disponía de un antivirus corporativo que era actualizable a través de la Intranet, pero para realizar este trabajo necesitaba la instalación en el cliente de un control ActiveX. También disponía de Terminal Services for Web, y éste también necesitaba controles ActiveX.

Así que dimos con una solución que, si bien no era la mejor, era la que más se adecuaba a las circunstancias. El departamento Help-Desk instalaba esos controles ActiveX cuando el equipo se montaba de 0, pero bajo ningún concepto se le daban permisos de Administrador al usuario (a no ser que fuese el jefe J).

Como podréis observar, a día de hoy necesitábamos una solución mejor para la distribución de Desktops corporativos, ya que algún día, vamos a necesitar que sea nuestro usuario el que pueda instalarse esos ActiveX sin necesidad de ser Administrador. Eso reduciría la carga administrativa, y a la vez dotaría de dinamismo la actividad laboral entre usuario y departamento Help-Desk. Hoy en día hay aplicaciones de Intranet que necesitan esos controles ActiveX, aparte de las aplicaciones mencionadas antes.

En Windows Vista han pensado en esto (y muchas otras cosas más) y han lanzado un servicio llamado AXIS (Servicio Instalador ActiveX), el cual no es más que un servicio a nivel de políticas de grupo, que habilita esta función precisamente. El tener una White List o lista blanca en donde podamos poner las direcciones Web en las que sabemos con certeza que sus ActiveX no contienen código dañino.

La política tiene un funcionamiento muy sencillo y práctico. Para activar la política, nos dirigiremos a Panel de Control à Programas à Activar o desactivar características de Windows.

Una vez aceptado el aviso de UAC, activaremos la opción Servicio de instalador de ActiveX, el cual preparará nuestro Vista para este tipo de acciones. Una vez activada la característica, procederemos a crear nuestra White List o lista blanca de aplicaciones Web que necesiten instalar ActiveX en nuestros Desktops corporativos.

El segundo paso a realizar, consiste en iniciar la herramienta de políticas de grupo gpedit.msc.

Una vez allí, procederemos a ir a la ruta siguiente:

Como podréis comprobar, la directiva aún no está aplicada, por lo que cualquier usuario con privilegios administrativos podría instalar cualquier ActiveX, venga firmado o no.

Una cosa que me gustaría remarcar, es que habilitando esta característica correctamente, habilitaremos a un usuario sin ningún tipo de privilegios, instalar controles ActiveX autorizados por nosotros, los administradores. Como podréis comprobar, la directiva se va a aplicar desde configuración de equipo, y no de usuario, así que será la cuenta de equipo quien instalará estos ActiveX permitidos.

 

• 
  
  TPSControlFirmado


• 
  
  Control Firmado


• 
  
  Control sin firmar


• 
  
  Política de Certificado

Gracias a esta nueva manera de instalación de controles ActiveX en Windows Vista, podemos mantener el mínimo privilegio posible en nuestros Desktops, sin despreciar para nada la potencia de un ActiveX.

Me dejo en el tintero la referencia a los logs que deja este tipo de configuraciones, pero lo dejo para un par de post que tengo en mente sobre Logs en Windows Vista, que sé que a los que le gustan los análisis forenses como a mí les va a resultar entretenido.  

Espero que os haya molado!

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:

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.

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

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

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!

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!

La tecnología avanza mucho. Los departamentos informáticos cada vez tienen más aplicaciones, y la línea de negocio avanza. Webs, aplicaciones corporativas, usuarios. Todos ellos (y hablando de una misma empresa), necesitan conectarse al mismo tiempo para cambiar, pedir y modificar datos. Por ello es que los departamentos de sistemas deben balancear esa carga con el mínimo costo posible para así obtener un beneficio. Si la red está mal diseñada, las aplicaciones de negocio que trabajen en tiempo real y no real, verán afectado su rendimiento por este diseño. Todo esto unido a la continua conexión de los empleados.

Hoy en día, una empresa, por pequeña que sea, necesita priorizar el tráfico de red en base a un servicio determinado. Una aplicación Web, una aplicación de gestión, un ERP, etc..

De esta problemática se puede decir que parte la idea del QoS (Calidad del servicio). Una tecnología que nos puede ayudar a administrar cómo (con qué calidad) vamos a transmitir esos datos (por ejemplo streaming), con el fin de poder asegurar que estos datos se transmitan en el momento adecuado y a una velocidad determinada.

Las versiones anteriores de Windows (XP, 2000, 2003) también tienen soporte para QoS en términos estándard (Generic Quality of Service), utilizando DiffServ (implementado en ISA 2006), IntServ y RSVP. Windows Vista extiende las funciones de QoS y aporta cambios para que nuestras redes sean mucho más precisas y confiables.

Con Windows Vista y Windows LongHorn, podremos controlar el coste de ancho de banda, podremos negociar una mayor calidad de los niveles de servicio con los proveedores de ancho de banda, o hacerlo a nivel empresarial. El ancho de banda de red de los equipos con Windows Server «Longhorn» o Windows Vista se puede administrar de forma central, independientemente de la aplicación en cuestión y en toda la infraestructura del servicio de Directorio Activo. Y como complemento añadido en la administración del tráfico de QoS basada en directivas , es que no tendremos que modificar ninguna aplicación de negocio, ya que ésta ocurre por debajo de la capa de aplicación.

Una configuración de QoS basada en directivas nos puede permitir priorizar o administrar la velocidad de envío del tráfico de red saliente en función de las condiciones siguientes:

•  Aplicación de envío


•  Direcciones IP versión 4 (IPv4) o 6 (IPv6), tanto de origen como destino


•  Por Protocolo (Protocolo de control de transmisión [TCP], Protocolo de datagramas de usuarios [UDP] o ambos)


•  Puertos de origen o destino (TCP o UDP)

En el siguiente artículo veremos los componentes que componen QoS basadas en directivas y su funcionamiento.

Hola a tod@s!

Vamos a terminar este pequeño repaso al firewall de Windows Vista repasando las opciones que nos quedaban por cubrir, las cuales son:

·         NAP (Network Access Protection)

·         Configuración básica

·         Creación y personalización de reglas

·         Administración a través de la Shell

·         Jugar un poco con él

Empezaremos hablando sobre Network Access Protection. NAP o protección de acceso a la red, no es más que una serie de políticas que nos van a ayudar a los administradores a garantizar que los equipos que se conecten a nuestra red, cumplen con una política de salud aceptable. Si para nosotros una buena política de salud es no tener un resfriado, hacer ejercicio de forma constante, etc.., para un equipo una buena política de salud sería tener el antivirus en pleno funcionamiento y con las firmas actualizadas, tener instaladas todas las actualizaciones de seguridad, etc.. Si nuestro equipo no cumpliese con la política de seguridad establecida por la empresa, podrían pasar dos cosas. La primera que no se pudiese conectar a nuestra red, y una segunda podría ser que sí nos pudiésemos conectar, pero en una red aislada de toda la corporación, con acceso sólo a algunos recursos, y a la espera de poder cumplir con los requisitos mínimos de salud.

Recordemos que esto es sólo una medida más de seguridad, al igual que los antivirus, las políticas, DEP, UAC, MIC, etc…

En el artículo anterior veíamos cómo estaba configurado el firewall por defecto, los diferentes perfiles a los que nos podemos enfrentar (dominio, público, privado) y el tipo de comportamiento que tendrá nuestro firewall cuando nos conectemos con un determinado perfil. Por defecto están los 3 configurados iguales:

·         Estado del Firewall : Habilitado

·         Conexiones entrantes: Bloquear

·         Conexiones salientes: Permitir

Por defecto el firewall está habilitado para todos los perfiles, las conexiones entrantes se bloquean si no cumplen con una determinada regla, pero las conexiones salientes no. Yo particularmente recomiendo que se habilite esta regla (Conexiones salientes: Bloquear), y así cubrimos dos campos, los cuales son  las conexiones entrantes, y las salientes. Si activamos esta opción, toda acción de salida que no cumpla con una determinada regla será bloqueada. Cualquier aplicación que necesite salir al exterior, tiene que tener una regla para salir, si no la tiene, no sale. Cabe decir que si aplicamos esta opción, tendremos que configurar a mano las aplicaciones que necesiten salir a Internet, como por ejemplo nuestro navegador.

 Esto lo vamos a ver muy bien con dos ejemplos de aplicaciones que necesiten salir al exterior.

Una vez que hayamos aplicado esta opción, nuestro PC estará automáticamente aislado de toda comunicación desde el interior al exterior, y desde el exterior al interior. Esto quiere decir que si iniciamos nuestro navegador para navegar por Internet, éste no podrá salir, al no tener una regla de salida asignada. Tampoco podremos hacer comprobaciones de conectividad, como por ejemplo ping, etc.… Así que vamos a crear una regla de salida, como por ejemplo nuestro navegador.

Crear una regla de salida en el Firewall es tan sencillo como picar en la opción Nueva regla, la cual la podemos encontrar en dos puntos de nuestra consola. En la parte superior derecha o pulsando con el botón derecho del ratón en las pestañas Reglas de entrada y Reglas de salida.

Al pulsar en Nueva Regla nos saldrá un asistente que nos guiará en todo momento a crear una nueva regla.

Como podréis observar, la regla no solo se limita al ámbito de una aplicación, sino que podremos crear reglas por número de puerto, servicios, reglas predefinidas, etc… Podremos personalizar las reglas a nuestro gusto.

Como en nuestro caso vamos a darle salida a nuestro navegador, elegiremos la opción Programa y pulsaremos Siguiente.

Aquí nos está pidiendo el asistente que le indiquemos la aplicación que va a coincidir con la regla de salida. Marcaremos la ruta de nuestro navegador y pulsaremos Siguiente.

Aquí nos pregunta por el tipo de conexión que vamos a permitir o denegar. Si os fijáis, el firewall, al estar integrado con IPSEC, nos da la opción de permitir sólo las conexiones seguras y autenticadas, en el caso de que nuestra red estuviese configurada con IPSEC. Marcamos Siguiente.

En esta parte de la regla, nos preguntará en qué ámbito se aplicará esta regla. Como mi PC sólo va a estar en casa, marcaré la opción Privado. Si fuésemos un administrador de sistemas y tuviésemos que configurar el Firewall para el portátil de un directivo podríamos marcar los 3 ámbitos, así nuestro directivo tendría conectividad tanto en el trabajo, como en su casa, pasando por una red pública, como podría ser un aeropuerto, etc…

La última regla es solo para poner un nombre y una descripción. Tendremos que ser consecuentes con el nombre que pongamos si queremos  llevar una monitorización óptima. Pulsamos Finalizar y listo! Tenemos nuestra primera regla de salida!

Un problema menos, podemos navegar por la Red. Pero al cabo de un rato me veo en la necesidad de hacer una prueba de conectividad entre varios equipos, y al intentar una prueba con el comando ping, veo que el Firewall me está denegando la salida.

Para cerciorarnos de que no es un error de conexión, podemos mirar el log de nuestro Firewall para ver qué registra, y esto es lo que nos encontraremos:

Como podéis comprobar, me está denegando toda salida ICMP. Lo único que nos queda por hacer es crearnos una nueva regla de salida, pero esta vez personalizada, que se aplique a todos los programas. Lo único que tenemos que cambiar es la configuración del protocolo. La regla sólo se aplicará al protocolo ICMP, tal y como aparece en la imagen:

Si os fijáis, el firewall de Windows también nos permite configurar el protocolo ICMP, lo cual nos viene de perlas, porque yo sólo quiero peticiones de eco para poder hacer pings, lo que nos quedaría:

Una vez configurada nuestra regla y habilitada, podremos comprobar que ya tenemos conectividad ping.

Y la administración bajo línea de comandos? Es posible? Claro que sí!

Muchos administradores se quejaban de que Windows era una gran plataforma en entorno gráfico, pero que la línea de comandos estaba bastante descuidada. Esto es y no es cierto. Me explico. Desde Windows 2000/XP ya se podía administrar en un 100% un equipo bajo línea de comandos, lo que no había en Internet eran manuales al respecto. Ahora con la nueva PowerShell de Windows la experiencia se multiplica de forma exponencial. Veamos cómo podemos administrar nuestro Firewall a través de la Shell.

Vamos a utilizar la herramienta nativa de Windows netsh. Netsh es una aplicación bajo línea de comandos que nos permite la administración de la configuración de red de un equipo. Este tipo de administración lo podemos hacer tanto de forma local como remota.

Este comando no sólo sirve para administrar el Firewall de Windows, sino que podremos administrar un 100% de nuestra configuración. Podremos administrar NAP, HTTP, RPC, configuraciones IP, etc…

El comando en cuestión es el siguiente:

Netsh advfirewall firewall

Imaginemos que tenemos una aplicación que se llama juanito.exe que necesita salir al exterior. Necesitamos crearle una regla de salida sólo para el perfil privado. Lo que nos deja el comando siguiente:

Netsh advfirewall firewall add rule name=” Permitir aplicación Juanito.exe” dir=out program=”C:Archivos de programaAplicación de Juanitojuanito.exe” profile=private action=allow

En donde el apartado dir refleja la naturaleza de la regla (si es de salida o de entrada), el apartado profile refleja el ámbito de la regla (perfil público, privado o dominio) y la acción que va a tomar esa regla (permitir o denegar).

Con la aplicación netsh podremos crear, eliminar, crear backups de las reglas, etc… Recomiendo echarle un vistazo, ya que es una herramienta muy potente que puede ayudar a muchos administradores.

Y para jugar un poco con él, vamos a intentar poner una Shell a la escucha con la aplicación netcat.

El comando que vamos a utilizar es el siguiente:

nc.exe –l –e “cmd.exe” –p 1234

Al pulsar Enter podremos ver como nuestro firewall se cosca de que hay una aplicación que quiere salir a escuchar, y que incluso si desbloqueamos esa aplicación, el control de cuentas de usuario nos pide aprobación para iniciar la consola de nuestro Firewall.

Hola a tod@s! 

Me llamo Juan Garrido, en la community me conocen por Juanillo y me pasaré de vez en cuando por este blog para dejar algún que otro articulillo. Hoy os vamos a hablar del nuevo Firewall de Windows Vista. 

El tiempo parece que avanza cada día más rápido, y junto a él, estamos nosotros. Nunca antes el mundo había sido tan pequeño. Y esto se lo debemos en gran parte a las comunicaciones. Mensajería corporativa, correo interno, streaming para reuniones que antes serían imposibles, VOIP, gente que viene de otras empresas, ejecutivos con sus portátiles que van de una oficina a otra, etc…

Todo esto sería maravilloso si pasase exactamente así. Pero la realidad no es siempre de color de rosas y una red, por pequeña que sea, se puede convertir en un campo de batalla, si no tomamos las debidas precauciones.

Vivimos en un tiempo en el que las redes corporativas y las no corporativas son cada día más complicadas de administrar. Comerciales que conectan sus PDA a los portátiles o equipos de sobremesa, conexión de dispositivos de almacenamiento externo, tener que realizar operaciones en distintas redes, como por ejemplo, aeropuertos, ejecutivos que van de oficina en oficina y necesitan conectarse a la Red, etc..

Desgraciadamente, junto a este tipo de comportamiento, pueden venir a veces acompañados de la mano ciertas amenazas de seguridad como pueden ser Malware, Exploits, Spyware, DOS, Script-Kiddies, etc..

Y aquí es donde entra en acción un Firewall. Algo que ayude a minimizar los riesgos, sin perder un ápice de experiencia.

Antiguamente (y no hablo de mucho tiempo atrás) poniendo firewalls en el perímetro, podíamos permitirnos el lujo de tener a nuestros clientes sin firewall, pero hoy en día, con las nuevas técnicas de ataque, es casi de obligado cumplimiento defender en profundidad tanto a nuestros servidores como a nuestros clientes. Al fin y al cabo ellos serán los que utilicen la tecnología que les podamos proporcionar. Y por qué no aportarles tecnología y seguridad?

Dicho esto, en esta ocasión vamos a hablaros del nuevo Firewall de Windows Vista.

El Firewall de Windows Vista ayudará a mitigar estos desafíos que hemos comentado en líneas anteriores. Y por qué decimos mitigar? Pues porque un Firewall no es una panacea. La seguridad al 100% nunca está, ni estará garantizada. Un Firewall podrá reducir la superficie de ataque a una computadora, pero nunca asegurarla al 100%.

Dicho esto y sin haberme cogido los dedos  J, vamos a ver las nuevas características o features del nuevo Firewall de Vista.

Por caminos que no quede…[;)]

Este es el nuevo aspecto de las consolas MMC 3.0. A los administradores les resultará más fácil adaptarse a este tipo de consolas, ya que por defecto se mantendrá el mismo diseño en otras aplicaciones, como las nuevas versiones de ISA Server y los nuevos productos de la familia Forefront por ejemplo, que traerán un aspecto parecido.

Por un lado vemos la parte derecha, que nos presenta varias opciones. Desde exportar/importar directivas, hasta establecer filtros en base al perfil, estado de conexión o por grupos.

En la parte izquierda tenemos las opciones de configuración y monitorización de reglas. Podremos configurar tanto las reglas de entrada como las de salida, y monitorizar el estado de conexiones y actividad del Firewall.

En la parte central podremos ver el estado en que se encuentra nuestro Firewall. Podremos ver los perfiles de conexión que trae por defecto Windows. Perfil de dominio, perfil privado y perfil público, accesos para crear reglas de entrada o salida y un apartado de recursos y documentación.

Para acceder a las propiedades del Firewall de Windows con seguridad avanzada, podremos hacerlo de dos formas.

Pinchar con el botón derecho del ratón en Firewall de Windows con seguridad avanzada, tal y como se muestra en la imagen: