jueves, 19 de diciembre de 2013

Gestión de Memoria. Hyper-V & Vmware Parte I.

En esta seria serie de post voy a intentar aclarar las típicas dudas sobre la gestión de la memoria en plataformas de virtualización VMWare & Hyper-V.

Es un requisito saber como gestiona nuestro hypervisor la memoria física disponible y conocer todas las técnicas de supervisión y gestión.
Vamos a empezar con razonamientos razonables :-).


Imagina que eres el administrador de una empresa en la que existen 8 servidores de 2 gb Ram, sobre un servidor físico de 16gb. Vas a adquirir un almacenamiento compartido y un segundo servidor para proporcionar a tu organización redundancia a fallos. Tus requisitos de memoria Ram, a priori, son 16 gb Ram. Comprarías un segundo servidor de 16 Gb de Ram o bien para tener preparado para ante un fallo del primer servidor, poder migrar las máquinas, o bien migrarías la mitad de las máquinas y tener en cada servidor 8gb usados/16 gb disponibles. Cuando recuerdas que el pre-venta del proyecto de virtualización no paraba de decirte que el ahorro de costes eran brutal, no paras de pensar que tienes un segundo server, con el mismo rendimiento que tenías antes, y has multiplicado por dos la inversión en servidores de tu empresa+ el almacenamiento compartido. Todo esto por tener la garantía de la continuidad de negocio... Bien, si lo ves razonable, no serás de los que un día, en uno de esos 8gb usados/16gb disponibles creas un par de máquinas virtuales para pruebas, o para una pequeña aplicación...

Todo lo anteriormente dicho es discutible, pero lo que es innegable es que debemos controlar el consumo de recursos de nuestros sistemas ( físicos o virtuales) para hacer ahorrar dinero a la empresa !!!

La estimación de los informes suele indicar que en el mundo físico, la carga de los servidores suele estar en torno a un 35% de la memoria RAM  que tiene instalada. El mundo de la virtualización nos permite jugar con esos valores medios estimados, valores en una ventana de gran actividad y cruzarlos en el tiempo. Por ejemplo, si tenemos servidores que no necesitan estar por la noche encendidos porque tienen cero actividad de usuarios, pero tenemos una aplicación de backup, o un proceso OLAP que requiere de mucho calculo y que lanzamos por las noches, el sistema de virtualización bien configurado debería ser capaz de realizar lo que estáis pensando: Bajar los recursos asignados a las máquinas con poca actividad y dejar "rienda suelta" a la máquina virtual que alberga la aplicación que consume más recursos, y queremos que lo haga automático !!!

Una cosa curiosa en los sistemas Windows es la del consumo de memoria en su arranque. Los típicos 5 minutos una vez iniciado el sistema mientras que carga librerías y el malware que tengamos instalado :-) el consumo se dispara. Esto debemos tenerlo en cuenta en nuestras estrategías de gestión de la memoria.

Vas pensando en todo el juego que ofrece la gestión de la memoria de la virtualización verdad !! Vamos a por ello.

En los sistemas Hyper-V podemos configurar de la memoria virtual:


Ram de inicio sería la cantidad de memoria que indicamos para la máquina virtual. La máquina virtual tendrá esa reserva, y aunque necesite más recursos en momentos puntuales, seguirá en esos parámetros.

***Debemos tener en cuenta que para virtualizar una máquina, necesitamos tener al menos, en el equipo físico, 300 mb que consume Hyper-v en memoria, y el consumo de la máquina. A esto debemos sumarle el consumo de los servicios de integración con las herramientas que requiere  32mb por 1gb inicial de ram de la máquina virtual, y 8mb por cada 1g de ram adicional. Una máquina de 8 gb necesitaría:
300 mb Hyper-v
8 gb de la máquina
32+64mb
8gb de la máquina y medio giga (redondeando xD) para la gestión.***

Si usamos la tecnología de gestión dinámica de la memoria:

Memoria de inicio es la cantidad mínima de memoria con la que la máquina debe arrancar. Por ejemplo un servidor 2012 invitado, con menos de 512mb de RAM no arranca, aunque su consumo estable puede verse por debajo de ese valor.
Importante saber que el sistema operativo Windows Xp e inferiores no es capaz de gestionar esta memoria, por lo que si una máquina virtual corriendo Xp está configurada con memoria dinámica, su memoria RAM será siempre la que indiquemos para el momento de su arranque.
Debemos tener la memoria de inicio definida disponible al arrancar, sino no podremos.

La memoria máxima será la cantidad máxima disponible que podrá usar la máquina virtual en caso de necesidad. OJO con este caso. Una máquina Windows corriendo una base de datos SQL Server, en un momento dado de necesidad de recursos, por la ejecución de un trabajo, puede intentar consumir toda la memoria RAM que le vayamos pasando, pudiendo la máquina virtual colapsar al resto de máquinas.

Aquí podéis ver un caso en el que se establece la memoria dinamicamente, y la máquina está demandando un poco más aún, insaciable.


El buffer de memoria indica mediante % el valor estimado de sobrecarga (Respecto a la memoria inicial) que una máquina debe tener. Hyper-V intentará siempre reservar este espacio de memoria, pero en el caso de tener otra máquina virtual consumiendo recursos, puede que este buffer no esté garantizado. Por eso es dinámico y no un valor fijo. Una máquina con 8 GB de ram y un buffer de memoria del 50% intentará tener siempre 12 gb de ram disponible. En el caso de necesitar esos recursos, la máquina estaría consumiendo 12 gb pero como tiene un buffer del 50, intentará reservar 18gb de ram... si la máquina tiene carga, hasta el infinito...

La ponderación de memoria establece las prioridades de consumo entre distintas máquinas virtuales.

Imaginamos una situación en la que tenemos una máquina con 2gb asignados para el inicio, gestión de memoria dinámica configurada entre 1gb y 8gb. Una configuración típica para garantizar que la máquina arranca "bien", pero que podemos aprovechar momentos de poca actividad ( menos consumo de 2gb) mediante la memoria dinámica. Trabajando con nuestro sistema, esa máquina virtual se consolida en un 1gb de consumo. Tenemos más máquinas virtuales funcionando en el servidor que consumen el 100% de los recursos restantes. Si reiniciamos la máquina virtual, que estaba consumiendo 1gb, pero que necesita 2gb para arrancar, pero el servidor no tiene más memoria, que pasaría?. Hyper-V Smart Paging usará memoria en disco swap para ofrecer el 1gb necesario para el arranque de esa máquina. Esta será la UNICA vez que Hyper-V usará lo que se denomina OverCommit, manejar más memoria ram en las máquinas virtuales que la instalada físicamente. De esta manera reducimos el uso del Swap a mínimos.

Por hoy creo que es suficiente. En el siguiente episodio entraremos en detalle en estos mismos conceptos pero en el mundo Vmware.

Como siempre, espero que os guste y gracias por leerme !!!










miércoles, 18 de diciembre de 2013

Consejos no técnicos para seguridad en las compras navideñas.

En el post de hoy voy a dar una seria de consejos, los que le doy a todos mis allegados que no "dominan" el mundo de la seguridad, o incluso el mundo del PC.

No es un post técnico, simplemente unos consejos a seguir para cualquier persona que estas navidades quiera comprarme un regalo por Internet :-)


  • Usa un sistema actualizado. Si usas el Internet Explorer  o si usas otro de los navegadores más habituales, debes usar la última versión. Para comprobar si estas "en regla" puedes entrar aquí para comprobarlo.http://whatbrowser.org/. Las actualizaciones que aparecen una vez al mes en la parte inferior derecha, hay que aceptarlas para mantener el sistema actualizado.
    .
  • No uses la conexión Wi-Fi del vecino, la de la cafetería, transporte o cualquier otra ubicación "pública". Los "malos" no van con el portátil y con pinta de Matrix, con un móvil pueden analizar todo el tráfico de la red, incluida nuestra contraseña.
  • No te registres en servicios de páginas webs de ofertas, cupones, subastas y demás. En la época de compras de navidad las estafas aumentan y son muy realistas. Ofrecer rebajas y descuentos es una manera de engañar a los compradores estafados.
  • Contraseña fuerte. Toda la seguridad de tus datos reside en la complejidad de tu contraseña. Debes establecer un criterio para usar una contraseña fuerte, distinta del correo, redes sociales, etc y sobre todo, que puedas recordar !!! Debes crearte una regla, por ejemplo, a mi me gustaria usar kinomakino como contraseña en todos sitios. Podría usar para Facebook "kinofacebookmakino". Con esta regla, mi contraseña de hotmail sería "kinohotmailmakino". Con esto incrementas la seguridad de tu contraseña. Busca la solución para tu clave favorita!!!.
  • No accedas a tus sitios de compras desde enlaces. Si quieres comprar en AMAZON porque has visto un objeto que te interesa mediante un anuncio en Facebook o por correo, aunque sea de tu mejor amigo, no entres !!!. Si estás muy interesado en ver ese artículo entra en el navegador, en Internet. en la barra de direcciones, arriba, escribe manualmente la dirección del sitio que quieres visitar. Si no la conoces puedes usar el buscador. De esta manera aumentan las prababilidades de estar accediendo al sitio que quieres, y no una copia falsa para estafar.
Si sigues todos estos consejos, con suerte, estas navidades podrás comprarme ese regalo que sabes que tanta ilusión me hace. 

Espero que os gusten estos consejos, gracias por leerme !!!

lunes, 16 de diciembre de 2013

Tips & Tricks: Gestión del historial de comandos con Powershell.

En el post de hoy os voy a comentar un par de trucos para el manejo de Powerhsell.

Todos sabéis que podemos recuperar el historial de comandos introducidos en la interface de Powershell mediante las teclas arriba-abajo del cursor. Para hacerlo más cómodo podemos pulsar F7 y nos aparece una ventana emergente para seleccionar el comando (Solo nos recupera los últimos 49 registros).


Por defecto los nuevos 2012 traen un buffer o historial de 4096 comandos. Me parece mucha información disponible, e intentando minimizar siempre los vectores de ataque o de recopilación de información, creo conveniente hacer un $MaximumHistoryCount = 10 o un valor bajo. Lo necesario si estás trabajando con algún comando. Es curioso que si entramos con F7, seguimos teniendo los últimos 49 registros... Bug?

Para poder recuperar solo unos determinados registros del historial, podemos hacer algo así Get-History 32 -count 32 me tomará 32 registros a partir del 33.

Este comando Powershell no se puede ejecutar contra equipos remotos, por lo que solo es posible con acceso a la consola del servidor.

Seguro que todo esto es menos necesario si usas el ISE (Integrated Scripting Environment) para facilitarte un poco la programación de scripts bajo PowerShell. ( Usar el buscador de Windows) Instalado por defecto desde Windows 7 /2008r2.


Espero que os guste el truco, gracias por leerme.


viernes, 13 de diciembre de 2013

Honeypot, Firewall, IPS HomeMade con Powershell.

En el artículo de hoy vamos a trabajar con algunos conceptos básicos de Powershell.

El Script que os presento se basa en el registro del firewall de un equipo Windows 7 o superior.
Como vimos en esta entrada, es necesario configurar el detalle del log del servicio de firewall.

La idea del script es trabajar un poco con Powershell, y ya de paso, proporcionar un servicio a nuestra infraestructura.
Pido perdón de antemano a los expertos en Powershell o programación en general ya que soy de sistemas, y la programación para mi es un mundo desconocido.

El script nos pregunta por pantalla por un número de puerto. Con el número introducido levantamos un socket a la escucha para ese puerto. Esto actuaria como Honeypot, ya que es un puerto para un servicio que realmente no estamos ofreciendo. La idea es que en un ambiente de red local, dejar ese puerto a la escucha, por ejemplo un servidor SSH en el puerto 22, siempre y claro que no lo usemos legítimamente. Mediante el log del firewall de Windows voy a detectar intentos de conexión, que voy a permitir. Cada cierto tiempo incluiré una regla en el firewall denegando todas las conexiones entrantes para la ip que se ha intentado conectar al puerto emulado. Si publicamos ese honeypot hacia internet tendríamos protección ( ip baneada) solo para ese servidor. En el caso de tener varios servidores Windows ofreciendo servicios públicos, deberíamos añadir la capacidad de replicar esta regla al resto de servidores. También se me ocurre que mediante orquestación y automatización mediante SYSTEM CENTER 2012 Orchestrator podríamos lanzar un comando ssh hacia nuestro Firewall perimetral no-windows ( o cualquier sistema de comunicación que nos ofrezca el firewall) para banear la ip en todos los servicios expuestos, sean Windows o cualquier otro.

Este es el script primera versión, que aunque operativo, tiene mucho que mejorar.


[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing") 
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") 

$objForm = New-Object System.Windows.Forms.Form 
$objForm.Text = "Baneador IP.kinomakino"
$objForm.Size = New-Object System.Drawing.Size(300,200) 
$objForm.StartPosition = "CenterScreen"

$objForm.KeyPreview = $True
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Banear") 
    {$x=$objTextBox.Text;$objForm.Close()}})
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Cancelar") 
    {$objForm.Close()}})

$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Size(75,120)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.Add_Click({$x=$objTextBox.Text;$objForm.Close()})
$objForm.Controls.Add($OKButton)

$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Size(150,120)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancela"
$CancelButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($CancelButton)

$objLabel = New-Object System.Windows.Forms.Label
$objLabel.Location = New-Object System.Drawing.Size(10,20) 
$objLabel.Size = New-Object System.Drawing.Size(280,20) 
$objLabel.Text = "Introduce el puerto que quieres monitorizar:"
$objForm.Controls.Add($objLabel) 

$objTextBox = New-Object System.Windows.Forms.TextBox 
$objTextBox.Location = New-Object System.Drawing.Size(10,40) 
$objTextBox.Size = New-Object System.Drawing.Size(260,20) 
$objForm.Controls.Add($objTextBox) 

$objForm.Topmost = $True

$objForm.Add_Shown({$objForm.Activate()})
[void] $objForm.ShowDialog()

$x = $objTextBox.Text
#Toda la parte de arriba es para mostrar el textbox y almacenarlo en $x

$Honeypot = [System.Net.Sockets.TcpListener][int]$x;
$Honeypot.Start();
#Abre el socket con el puerto indicado en el Textbox
while($true)
{
sleep -s 300
#comprueba cada 5minutos si ha habido intento de conexión mediante el log del Firewall.

$logPath="C:\Windows\System32\LogFiles\Firewall\pfirewall.log"
$blackListPath= "C:\Windows\System32\LogFiles\Firewall\blacklist.txt"
$blacklist = Get-Content $blackListPath

$header=(Select-String -Path $logPath -Pattern "^#Fields").Line.Split(" ") | select -Skip 1
$ips=Get-Content $logPath | select -Skip 4 | 
ConvertFrom-Csv -Delimiter " " -Header $header |
where {$_."dst-port" -eq $x -and $_.path -eq "RECEIVE" -and $blacklist -notcontains $_."src-ip"} |
select -ExpandProperty "src-ip" 
$ips
$ips | Add-Content $blacklistPath
foreach ($ip in $ips){
  New-NetFirewallRule -DisplayName "Ip Bloqueada $ip" -Direction Inbound -Action Block -RemoteAddress $ip
   #si encuentra algún registro contra el puerto indicado, envia un correo.
                 $smtpserver = “smtp.gmail.com”
                 $msg = new-object Net.Mail.MailMessage
                 $smtp = new-object Net.Mail.SmtpClient($smtpServer )
                 $smtp.EnableSsl = $True
                 $smtp.Credentials = New-Object System.Net.NetworkCredential(“nick gmail sin @gmail, “clavegmail”); 
                 $msg.From = “correo origen
                 $msg.To.Add(”correo destino”)
                 $msg.Subject = “Ip baneada”
                 $msg.Body = “La ip $ip ha sido baneada por intento de conexión al honeypot”
                 $smtp.Send($msg)
                      }
                  
                        }
           
Para poder utilizarlo debes activar el detalle en el firewall de Windows así. En el mismo directorio debes crear un fichero vacio llamado blacklist.txt. Cambia los datos del correo y listo.

Una vez ejecutado comprobamos que el puerto introducido está a la escucha: netstat -ano


Ahora desde un equipo realizo un intento de conexión al puerto indicado, en este caso un scan completo.
Si todo ha ido bien, y esperando 5 minutos al menos, volvemos a realizar el scan y vemos que estamos baneados por el firewall.


En las reglas del Firewall de Windows compruebo que se ha creado la regla.


En unos segundos el sonido del correo en el móvil me indica que esto también ha ido bien.

En el fichero Blacklist almacenaremos las IP baneadas, que podemos usar como fuente de información en el supuesto de tener un firewall perimetral, por ejemplo pasándolo por ssh en un array de IP Baneadas.

Parsear el log para detectar el scan de puertos hubiera sido factible, pero si solo tengo publicado un servicio ( puerto) de este server no tendría ninguna manera, por eso lo del honeypot.

El lenguaje es bastante sencillo, y es muy fácil empezar a programar en Powershell. Este script lo he hecho mirando por la world wide web y con la ayuda de Dirk74 (technet forum).

Espero poder trabajar mas en esta idea, y añadir alguna mejora y capacidades nuevas, en próximas entregas de Inseguros lo intentaré.

Como siempre, espero que os guste, y gracias por leerme !!!

TrueCrypt Vs. EFS. Consumo de recursos CPU y velocidad de transferencia.

En el post de hoy vamos a hablar de cifrado de datos en disco. Para esta ocasión vamos a trabajar tanto con el sistema nativo de cifrado de Windows EFS, como con el sistema software libre TrueCrypt en su versión para Windows.


No voy a discutir sobre la fortaleza de los dos sistemas, ya que en ambos casos depende de la longitud de clave que empleemos en el cifrado.

Para empezar vamos a realizar una instalación limpia de True Crypt. El funcionamiento es muy sencillo. Instalamos TrueCrypt y creamos un volumen. Para realizar esta prueba indicaremos una carpeta en nuestro disco. TrueCrypt creará una especie de "disco duro virtual" con el tamaño que indiquemos, en donde almacenaremos los datos. Montaremos este disco duro. Si no ejecutamos TrueCrypt, o el disco duro cae en manos ajenas, solo será accesible el fichero de disco duro virtual, el cual no podremos abrir si no conocemos la clave de cifrado empleada.










Una vez tenemos la unidad de disco creada, vamos a realizar unas mediciones de rendimiento, al igual que hacíamos con otros post sobre Freenas. Vamos a medir el acceso a ese disco cifrado.



Ahora es el turno de EFS. Para poder cifrar una carpeta con EFS debemos crear un agente de recuperación. Este agente se define a nivel de GPO, para poder garantizar que en caso de baja del usuario que cifró el disco, poder recuperar el acceso con usuario/Certificado definido.


Ahora con el usuario que queremos sea el agente de recuperación, en este el caso el mismo de la prueba, genero un certificado personal con: cipher /r:nombredelcertificado

Una vez generado, creamos el agente.


El proceso de cifrado de una carpeta es muy sencillo, botón derecho...


Ya tenemos nuestra carpeta cifrada. Vamos a realizar la misma prueba contra el cifrado EFS.


Como podéis ver, el rendimiento es superior con EFS que con TrueCrypt.

TrueCrypt- EFS

TOTAL I/O Per Second. 8669.54 ----9878.05
Mb/S Per Second.          33.87 -----38.59
Cpu Utilization.               25.31% ----20.60%

Estos son los datos y la manera de configurar cada uno. Otro día podemos trabajar con Bitlocker...

Como siempre, espero que os guste y gracias por leerme.

jueves, 12 de diciembre de 2013

El camino del SysAdmin hacia el Chief Information Security Officer.

Siempre intento definirme como un administrador de sistemas concienciado en la seguridad, mas que como un experto en seguridad, pentester, investigador o similares.

También intento definirme como una persona guapa, apuesta, inteligente, simpática, pero no iba la cosa por ahí...
Propiedad de ECCOUNCIL...
El título de hoy es un poco para hacer la broma de la cantidad de siglas para puestos laborales que nos inundan y que debemos añadir a nuestra no pequeña lista de siglas, aunque van por ahí los términos.

Estoy colaborando con la empresa de un amigo en mejorar un poco su seguridad y de las necesidades identificadas he creado un pequeño Brainstorm de aspectos que yo considero interesantes.
He creído oportuno modificarlo y compartir con vosotros, gratis, esa lista de aspectos que considero que cualquier administrador de sistemas ( o si eres poseedor de siglas relacionadas) debería controlar en sus infraestructuras. Quizás algunos sean obvios para ti, o quizás alguno te sirva para mejorar en tu trabajo diario.


  • TECNICAS ANTI FINGERPRINTING.
    Del resultado de un pentest externo resulta interesante trabajar en la ocultación de toda la información que podamos de nuestros servicios expuestos. Por ejemplo, cambiar la carpeta de administración de nuestro CMS, cambiar el logotipo, cambiar el banner del servicio, recompilar el kernel para cambiar el comportamiento del Stack TCP xD etc.
  • FIREWALL Y MONITORIZACIÓN DE LOGS.
    Es importante contar con un sistema de Firewall para la red perimetral, pero es necesario ampliar la seguridad con firewall a nivel de servidor e incluso de estaciones. Tanto para la entrada como para la salida. La gestión de los logs y las decisiones en consecuencia de esta gestión son algo básico en las tareas diarias de un buen administrador. Por supuesto comprobar que todos los firewall se comportan como esperamos.
  • WEB APPLICATION FIREWALL.
    Las aplicaciones web debemos protegerlas al igual que el resto de servicios que ofrecemos en nuestra organización. Contar con un sistemas WAF nos puede ayudar con la mitigación de ataques 0Day que usan técnicas ya conocidas pero no subsanadas por el proveedor, o por nosotros mismos. También nos ayuda como técnica de anti-fingerprinting.
  • SISTEMA DE DETECCIÓN/PREVENCION DE INTRUSOS.
    Saber que estamos teniendo actividad sospechosa es el primer paso para parar esa actividad sospechosa. O bien manualmente, o bien dinámicamente, debemos actuar ante esa actividad registrada. Por ejemplo, un escaneo de puertos puede pasar desapercibido para un firewall si sobrepasamos el tiempo entre intentos de puertos, o lo mismo para un ataque de fuerza bruta. Mi experiencia es que al final el IDS te ayuda incluso para asuntos de rendimiento, por ejemplo cuando encuentra multidifusión sospechosa de algún dispositivo mal configurado.
  • HONEYPOTS.
    Trabajar con sistemas Honeypots es altamente recomendable, como hemos hablado largo y tendido en este blog. Tener sistemas de alerta asociados al Honeypot, o un sistemas de prevención IPS es estar un paso por delante en la prevención de un futuro ataque a un servicio real. No solo la parte científica o de investigación es importante en los sistemas Honeypots.
  • POLITICA DE ACTUALIZACION APLICACIONES WEB.
    Tener un sistemas para estar al tanto de las actualizaciones de los portales web es básico. Si usas un Wordpress como CMS deberías dejar la casilla de "Mantenerme informado" para estar al día de las actualizaciones. Cada proveedor tiene sus propios canales de información de seguridad. Debemos estar pendientes.
     
Otros elementos que considero relacionados con la seguridad a revisar:

  • INVENTARIO DE EQUIPOS.
    Tener un control de todo nuestro parque es indispensable para una buena gestión del servicio. Tener una lista con los PC´s hasta ahora era relativamente sencillo, pero con la virtualización, el número de equipos crece considerablemente. No solo es importante el inventario, sino el nivel de detalle que necesitamos para realizar nuestro trabajo.
  • POLITICA DE AUDITORIA INTERNA Y EXTERNA CONTINUA.
    Si tienes la suerte de poder contratar una auditoría de seguridad cada X meses eres afortunado, pero esto no es suficiente. Hay que establecer una política de auditoría continua, o lo más continuada posible.
  • INVENTARIO DE SOFTWARE Y VERSIONES.
    Saber que aplicaciones se ejecutan en la empresa y su versión actual es necesario. El típico ejemplo de un Adobe Pdf Reader no actualizado puede ser el punto de entrada a nuestra infraestructura. Tener todos los servicios que ofrecemos controlados, lo que llamarían CI (elemento de configuración) en el mundo ITIL. Por ejemplo, un servidor que ejecuta un proceso mediante el programador de tareas. Esto es un elemento que debemos supervisar, y no esperar el "madre mía" cuando ha fallado una ejecución, y ese mes no se mandan las nominas al banco !!!
  • POLITICA DE ACTUALIZACIÓN DE SISTEMAS OPERATIVOS.
     
    Tener un sistema centralizado de aprobación de actualizaciones para los sistemas operativos. No solo actualizar, sino tener un laboratorio para realizar las pruebas.
  • POLITICA DE ACTUALIZACIÓN DE SOFTWARE CONVENCIONAL (No actualizable mediante Windows Update por ejemplo).
    Como decía anteriormente debemos controlar las versiones que tenemos instaladas, pero sobre todo para poder actualizarlas. El caso del PDF Reader.
  • POLITICAS DE SEGURIDAD TECNICAS PARA NORMATIVA LOPD.
    Revisar el correcto funcionamiento de las típicas medidas de seguridad que nos exige la LOPD como el cambio de contraseñas, complejidad, longitud, bloqueo de sesiones, gestión de archivos temporales, etc.
  • LICENCIAS DE SOFTWARE.
    Tener controlado el inventario de licencias de nuestros sistemas operativos y aplicaciones es parte del trabajo del administrador de sistemas.
  • ESTRATEGIA PARA "BRING YOUR OWN DEVICE" Y DISPOSITIVOS MOVILES EN GENERAL.
    Establecer una estrategia que impida fugas de información en dispositivos móviles y garantizar el cumplimiento de las políticas de seguridad impuestas en la empresa. Por ejemplo, si se pierde el Iphone del jefe, o si se puede navegar por ciertas páginas web desde el portátil de empresa.
  • PROXY INTERNO PARA PROTECCIÓN WEB.
    Gestionar la navegación de los usuarios dentro de la red para proteger a los mismos de sitios maliciosos, o garantizar el cumplimiento de la política de seguridad de la empresa. No en todas las empresas se puede usar Facebook...
  • POLITICA EMPRESARIAL DE SEGURIDAD (Pruebas de identificación de phising y ejemplos para concienciación.)
    Tus usuarios son el último eslabón en la cadena de la seguridad. Trabajar en la concienciación de la cultura de la seguridad nos ahorrará muchos dolores de cabeza. Realizar demostraciones y pruebas.
Seguro que me dejo en el tintero mucho trabajo relacionado con la seguridad, pero espero que al menos estos términos os ayuden en vuestro trabajo diario como administradores de sistemas concienciados con la seguridad.

Como siempre, espero que os guste y gracias por leerme.

martes, 3 de diciembre de 2013

Windows Firewall Activación y Scripting.


Uno de los aspectos de la seguridad que suelo comentar con los colegas de profesión es la necesidad de saber que está pasando en nuestros sistemas. A menudo los administradores piensan que no hay ningún problema de seguridad, por una simple razón, no monitorizan nada. Esta técnica tiene la misma funcionalidad que tenía mi técnica cuando era joven con las reparaciones del coche. Si escuchaba algún ruido en el motor subía la radio...


Cuando hablamos de sistemas Microsoft tenemos un firewall integrado, que en las nuevas versiones, me permite bastante modularidad al más puro estilo Iptables. Podemos filtrar tráfico entrante y SALIENTE. A lo largo de mi carrera profesional he visto muy pocas veces el firewall de Windows bien configurado, por no decir que siempre lo suelo ver deshabilitado.

En el mejor de los casos, si eres un administrador de sistemas concienciado, intentarás trabajar con el firewall On. Bien, y ahora? Generalmente en las empresas nos pagan por trabajar, y parte de nuestro trabajo es monitorizar ese firewall instalado en los equipos.

Como todos sabéis, la mayoría de eventos del sistema se pueden revisar desde el cómodo Visor de Eventos. Tenemos registros de auditoría para inicios de sesión, registros de aplicaciones, incluso una rama para firewall. Bien, esta opción solo monitoriza los cambios en el firewall, cuando creamos reglas, cuando deshabilitamos pero no muestra el registro completo de peticiones aprobadas o denegadas.

En este episodio de Inseguros vamos a habilitar el registro completo del log del Firewall del un servidor Windows 2012.

Lo primero que haremos será habilitar el firewall y bloquear un puerto, en mi caso voy a bloquear el puerto 80 del servidor IIS. Comprobamos que no tenemos activada la opción de registrar paquetes descartados y correctos. Habilitamos este comportamiento para nuestro perfil de Firewall, ubicación del fichero, tamaño y listo !!.






Ya podemos ir al fichero de Logs y ver realmente qué esta pasando con nuestra regla de filtrado para el firewall.


Lo interesante de esto reside en poder automatizar la gestión de este log, enviando el fichero periódicamente a nuestro syslog o herramienta SIEM. Vamos a lanzar un comando que nos lea el fichero y nos muestre las ocurrencias que encuentre con la sentencia DROP TCP.

Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "drop tcp "


Podemos añadir una condición basada en regular expressión para filtrar los intentos a un determinado puerto.

Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -pattern '(DROP TCP.*80)'

Sin duda recomiendo establecer alguna estrategia de supervisión del fichero de logs del firewall, incluido el tamaño y la política de conservación del fichero.

Como siempre, espero que os guste y gracias por leerme !!!.


miércoles, 27 de noviembre de 2013

WebPlatform Installer, Web Application Firewall y técnicas anti-fingerprint del WAF.


En la aventura de hoy vamos a instalar un entorno de producción Web sencillo. Tan sencillo, que no me voy a preocupar por lo que debo instalar de software base, servidor Web, base de datos, php, extensiones, etc. Simplemente voy a pedir a los señores de Microsoft que quiere instalar un Joomla, y que "su informático" haga el resto.

Al más puro estilo WAMP (Windows Apache Mysql PHP) pero usando la potencia que nos ofrece IIS nativo.

Todo en el mundo de la informática parece que gira últimamente a la desaparición del informático en la empresa, por lo que nos debemos situar en el lado de los que preparamos los sistemas de automatización, y no en el lado de la "víctima" que se va a quedar sin empleo...En unos pocos años nadie va a instalar sistemas operativos en sus empresas, los alquilaran en la famosa nube, por lo que prefiero subirme a ella !!!.


Para eso nos ponen disponible Microsoft Web Platform Installer 4.6. El proceso es tan sencillo como seleccionar el entorno o producto que queremos instalar, descargar el instalador, y listo.






Una vez instalado Platform Installer podremos seleccionar posteriores añadidos de la lista disponible.



Una vez instalado, compruebo que la versión de Joomla que instala está algo caducada...

*** Web Platform Installer es mucho más que un gestor de descargas e instalación. Podemos crear nuestros propios empaquetados, para ofrecer a nuestros clientes todo el despliegue de un aplicativo, incluyendo la infraestructura base y la aplicación en si.
Otra opción muy interesante es la de conectar a nuestra nube pública en Azure con este servicio, y permitir a nuestros usuarios añadir estas aplicaciones a las máquinas virtuales existentes, y no como ahora que debíamos agregar una máquina virtual nueva previamente configurada.
Por último, junto a las capacidades de Virtual Machine Manager podemos usar opciones offline para distribuir nuestras aplicaciones a las nuevas máquinas virtuales.
Espero poder avanzar con estos aspectos en posteriores post.***

El siguiente paso que debemos ejecutar es instalar, mediante el role de Internet Information Services las extensiones y filtros ISAPI.


Ahora que tenemos nuestro portal Joomla preparado, vamos a probar varias URL´s con pinta maliciosa, como www.mihost.com/cmd.exe  /../ select * etc. Vemos que no disponemos de ningún sistema para protegernos contra este tipo de solicitudes. Aquí es donde entra el Web Application Firewall o WAF. Como su nombre indica, se trata de un firewall, un sistema de protección, que nos proteja de peticiones maliciosas.
Lo recomendable sería securizar la propia aplicación web, pero de esta manera evitamos en la medida de lo posible (según las reglas del WAF) ataques webs no comunes, o no identificados bajo nuestras plataformas CMS o similares. Otra cuestión es la disuasión. Si tenemos un ataque y nos presentamos con "un palo gordo" al estilo policía, seguramente el atacante desistirá a las primeras de cambio.

Para esta prueba vamos a usar un WAF para Windows software libre llamado AQTRONIX

La instalación es tan sencilla como bajarnos el paquete para nuestra versión de IIS y ejecutar el .msi o el fichero VBS de configuración.

Sin más pasos, podemos observar como en las mismas peticiones malintencionadas, obtenemos el mensaje del "policía con el palo" prohibiendonos el acceso.



Me gusta cambiarle el aspecto a las cosas, por lo que bajo C:\Program Files\AQTRONIX Webknight edito el fichero Denied.htm para cambiar el mensaje a uno un poco más del estilo de Inseguros.


Podemos redirigir al usuario a una web en concreto, interna o externa. Aquí es donde tendría gracia redirigir al atacante a una web por ejemplo Browser autoPwn con Metasploit, para atacar al atacante, pero sospecho que por motivos legales no podemos...

En el fichero de configuración podemos configurar exclusiones para directorios administrativos, ip´s, virtual host y demás configuraciones que imaginemos para poder "granular" el ámbito de aplicación "del palo".
Una interesante es bloquear permanente (durante las horas que hayamos definido) tras n intentos erróneos.


También podemos gestionar una lista estática de Ip´s introducida a mano.

Podemos configurar una ruta distinta para el fichero de log´s, o enviarlo a nuestra herramienta de SIEM o syslog.

Podemos definir una directiva para prohibir los ataques de fuerza bruta contra nuestro sistema de autenticación.

Hay un sinfín de opciones sencillas, desde longitudes de peticiones, navegadores, directorios, usuarios, extensiones de archivos, caracteres codificados y todo o casi todo lo que te imagines controlar sobre un aplicativo web.

La propia aplicación WAF nos acompaña de un gestor de logs para visualizar facilmente los accesos y acciones del sistema.


Vamos a ver como se ve desde fuera, la parte del atacante. Para ello voy a lanzar WAFW00F un script muy útil para identificar WAF.


Y por último voy a lanzar el script NSE de NMap para el mismo propósito.


Revisando el código del script podemos ver que respuestas está interpretando el script para determinar la presencia de nuestro WAF.

match = function(responses)
        for name, response in pairs(responses) do
            if response.header.server and string.find(response.header.server, 'WebKnight/') then -- 
                stdnse.print_debug("%s WebKnight detected through Server Header.", SCRIPT_NAME)
                webknight.version = string.sub(response.header.server, 11)
                webknight.detected = true
                return 
            end
            if response.status == 999 then
                if not webknight.detected then stdnse.print_debug("%s WebKnight detected through 999 response status code.", SCRIPT_NAME) end
                webknight.detected = true
            end
        end
    end,

Vamos a hacerle caso al script, y vamos a cambiar el código de respuesta http que muestra por defecto 999 para intentar evadir la detección.


Nmap deja de ser tan eficaz.


Sin embargo WAFW00F sigue detectando el sistema WAF.Pruebo a cambiar el Title Html del Denied.htm, algo muy básico, pero tampoco consigo borrar su huella ( al menos no lo pone en la pestaña del navegador). Vamos a modificar la respuesta, en vez de enviar directamente el contenido del fichero Denied,htm, hacemos una redirección.


BINGO, ya pasamos desapercibidos por las herramientas de detección más habituales ( Backtrack inside).


He probado con otro script de la gente de Insinuator TSAKWAF y detecta la presencia de un WAF, pero no consigue identificarlo.

Viendo las respuestas HTTP y la redirección del contenido se identifica claramente que el fichero de respuesta es Denied.htm, por lo que este análisis debería ser añadido al script NSE para detección. Nosotros que somos "ansin" podemos cambiar el fichero htm por defecto y usar otro, por si mejorar el script NSE :-)

Otra de las ventajas es la sencillez de actualización. Solo tenemos que cambiar los ficheros dll y sobreescribir el fichero Robots.xml con todos los datos públicos que se van actualizando, como blacklist, user-agent conocidos, técnicas de evasión etc.

Si queréis ampliar sobre los WAF, un punto de partida interesante es OWASP.

Otro documento muy interesante es un Paper sobre los criterios a tener en cuenta a la hora de elegir sobre nuestro sistema WAF. Muy importante el primer punto, la sencillez del despliegue.

Como habéis podido observar, instalar este sistema y configurar unos parámetros básicos nos ha tomado unos 5 minutos. Con el mismo Internet Information Services podríamos configurar muchos de los aspectos del WAF, pero el trabajo sería enorme, y muy dificilmente sostenible.

Como siempre, espero que os guste, sigo en el paro, y gracias por leerme !!!