lunes, 8 de abril de 2019

Explorando la red con PowerShell: Escaneo de puertos TCP y barridos ping

A continuación comparto una recopilación de algunos comandos útiles a la hora de explorar la red utilizando PowerShell.

Barridos ping

Para descubrir todos los hosts activos de una red de forma rápida podemos realizar un barrido ping o ICMP. En este ejemplo se usa un operador de rango para hacer ping a todas las IP's de una red /24 y del resultado filtramos los que contienen la linea TTL, que son los que nos interesan (esto excluye las IP's que respondieron con tiempo de espera agotado)


PS C:\> 1..254 | % {echo "192.168.88.$_"; ping -n 1 -w 100 192.168.88.$_} | Select-String ttl

Respuesta desde 192.168.88.1: bytes=32 tiempo=2ms TTL=64
Respuesta desde 192.168.88.214: bytes=32 tiempo=2ms TTL=64
Respuesta desde 192.168.88.229: bytes=32 tiempo<1m TTL=128

PS C:\>

Escaneo de puertos TCP

Para probar si un puerto TCP está abierto, podemos usar el cmdlet Test-NetConnection

PS C:\> foreach ($ip in 1..254) {Test-NetConnection -Port 80 -InformationLevel "Detailed" 192.168.88.$ip}



ComputerName            : 192.168.88.1
RemoteAddress           : 192.168.88.1
RemotePort              : 80
NameResolutionResults   : 192.168.88.1
MatchingIPsecRules      :
NetworkIsolationContext : Private Network
InterfaceAlias          : vEthernet (Ether-wifi)
SourceAddress           : 192.168.88.229
NetRoute (NextHop)      : 0.0.0.0
TcpTestSucceeded        : True


ADVERTENCIA: TCP connect to (192.168.88.2 : 80) failed
ADVERTENCIA: Ping to 192.168.88.2 failed with status: TimedOut

ComputerName            : 192.168.88.2
RemoteAddress           : 192.168.88.2
RemotePort              : 80
NameResolutionResults   : 192.168.88.2
MatchingIPsecRules      :
NetworkIsolationContext : Private Network
InterfaceAlias          : vEthernet (Ether-wifi)
SourceAddress           : 192.168.88.229
NetRoute (NextHop)      : 0.0.0.0
PingSucceeded           : False
PingReplyDetails (RTT)  : 0 ms
TcpTestSucceeded        : False


El comando anterior arroja resultados muy verbose para mi gusto, la siguiente alternativa facilita probar un rango de puertos y da como resultado una salida mas limpia:

PS C:\> 1..1024 | % { echo ((new-object Net.Sockets.TcpClient).Connect("192.168.61.1",$_)) "$_ is open" } 2>$null
22 is open
80 is open
443 is open
PS C:\>

Eso es todo. En una próxima entrada analizaremos opciones para probar puertos UDP con PowerShell.

domingo, 7 de abril de 2019

Preparación para el examen AZ-500: Sesiones de Ignite

Recientemente se lanzó el examen beta AZ-500: Microsoft Azure Security Engineer, siendo el único necesario para obtener la certificación Microsoft Certified: Azure Security Engineer Associate. De momento no hay una guía de preparación oficial, por lo cual lo que voy a apoyarme exclusivamente en la documentación de Microsoft y en Sesiones de Ignite y Microsoft Mechanics.

Si quieres tomar este exámen beta, puedes conseguir un voucher con un 80% de descuento en este post de Microsoft Learning Blog.

A continuación, una lista de las sesiones de Ignite que estoy usando como preparación para este examen.

Azure Essentials: Defense in depth security



Azure Security Center | Azure Friday



Azure security & management - BRK2021



Azure Security fundamentals: Protecting infrastructure apps and data in the cloud - BRK2395



Built-in not bolted on - securing your Azure resources in practice - THR3064



Governing Azure subscriptions with auditing management groups and policies - BRK3268



Protect server workloads across datacenter and cloud with Azure Security Center and - BRK3235



Protect the keys to your kingdom with Privileged Identity Management - BRK3248



Securing your data with Azure SQL DB : Build 2018



Understanding how Microsoft Information Protection capabilities work together to - BRK3002



Accelerate deployment and adoption of Microsoft Information Protection solutions - BRK3009



Securing your hybrid cloud environments with Azure ATP and AAD Identity Protection - BRK3237



Securing web applications using Web Application Firewall



Securing Azure SQL Database Managed Instance: Overview and best practices - BRK3163



Secure customer identity and access management using Azure Active Directory B2C - BRK3240



Monitoring your networks in Azure - BRK3298



Monitor your infrastructure and analyze operational logs at scale with Azure Monitor - BRK3354



MNA 02/08/2019 - Azure DDoS



Common sense in the world of Azure governance - THR2102




Manage keys secrets and certificates for secure apps and data with Azure Key Vault - BRK3059



Lock down access to Azure using identity - BRK3383



Learn how to protect your data in Azure Storage with new features and capabilities - BRK3340



In the security trenches of Azure SQL Database and Azure SQL Data Warehouse - BRK3149



Identity and secure resource access in App Service and Azure Functions - Matthew Henderson



Granting partners and suppliers access to resources using Azure Active Directory B2B - BRK3249



From the trenches: Hardening your Azure Active Directory tenant - THR2214



Expose APIs with peace of mind when using Azure API Management - BRK2200



Enable Azure Active Directory Conditional Access to secure user access while - BRK3241



Deep dive into Implementing governance at scale through Azure Policy - BRK3085



CYA (covering your assets) with security and threat detection in Azure - BRK2421



Azure Update Inventory and Automation for Linux and Windows VM management - BRK3063



Azure Information Protection and Exchange Online - better together - THR3076



Azure Firewall and Best Practices in building an enterprise-grade DMZ in Azure - BRK4029



Azure Active Directory security insights with Conditional Access Identity Protection - BRK3401



Azure Active Directory best practices from around the world - BRK3408



Attack discovery and investigation with Azure Advanced Threat Protection - THR3037



AKS (Azure Kubernetes Service) Security & Identity updates | Best of Microsoft Ignite 2018



How to delegate administration in Azure AD - BRK3239



Early look at Microsoft Threat Protection





domingo, 24 de marzo de 2019

Transferir archivos con PowerShell usando WinRM

Mover archivos con PowerShell es sencillo siempre que tengamos acceso vía SMB al servidor remoto. Por ejemplo, para copiar la carpeta "C:\Tools" y todo su contenido (-Recurse) al servidor FILESERVER por SMB, basta con el siguiente comando:

Copy-Item -Path "C:\Tools" -Destination "\\FILESERVER\C$" -Recurse

El comando asume que las credenciales utilizándose son válidas en el equipo remoto. En caso de que el servidor no tenga habilitado el SMB, puede lograrse lo mismo mediante WinRM. Los requisitos son los siguientes:


  • PowerShell 5.0 en el equipo local y en el remoto
  • WinRM debe estar habilitado (Viene configurado por defecto desde Windows Server 2012 en adelante, en caso de que esté deshabilitado puede habilitarse con Enable-PSRemoting -Force)
  • Los puertos 5985 (HTTP) y 5986 (HTTPS) deben estar habilitados.
  • Ambos equipos deben estar en dominio. Si la estación de trabajo desde donde se está administrando el servidor está en un grupo de trabajo, seguir las siguientes instrucciones.

Primero, crear una sesión remota y guardarla dentro de una variable:

$FileSession = New-PSSession –ComputerName FILESERVER

El comando es muy similar al anterior, el único cambio es que en este caso utilizamos el parametro ToSession y le pasamos la variable de la sesión creada previamente:

Copy-Item –Path "C:\Tools" –Destination 'C:\' –ToSession $FileSession -Recurse

A pesar de ser similar al comando anterior, esta vez la transferencia se realizó vía WinRM. Una vez terminada la transferencia, es buena practica remover la sesión que creamos:

$FileSession | Remove-PSSession

sábado, 23 de marzo de 2019

Nuevos requisitos para la certificacion Azure Administrator Associate

La semana pasada pasé el examen AZ-100: Microsoft Azure Infrastructure and Deployment que en ese momento era uno de los dos examenes necesarios para obtener la certificación Microsoft Certified: Azure Administrator Associate. Habiendo ya agendado el siguiente exámen, el AZ-101: Microsoft Azure Integration and Security, se anuncia en el blog Born to Learn un camino simplificado para esta certificación en el cual solo se requiere pasar solo un examen para obtener esta certificación. Por fortuna, el equipo de Microsoft Learning tomó algunas decisiones para hacerse cargo de las inconveniencias que puedan tener las personas que ya estaban siguiendo este track:

  • Los que ya pasaron el examen AZ-100, obtendran automáticamente la certificación Microsoft Certified: Azure Administrator Associate a partir del 1 de mayo del 2019.
  • Los que ya tomaron el examen AZ-101, hayan pasado o no, recibiran un voucher para tomar cualquier examen de Microsoft que se imparta a traves de Pearson VUE.

Examinando la alineación de los tópicos de los examenes AZ-100 y AZ-101 con los del nuevo examen AZ-103, se observa que el nuevo examen ya no cubre Logic Apps, Azure Functions, App Service, Azure Site Recovery ni Azure Migrate. Presumo que esos tópicos se moverán a algún otro rol intermedio que se anuncie a futuro, o bien estarían incluidos únicamente en el path de Microsoft Certified Azure Solutions Architect Expert.

lunes, 11 de junio de 2018

Solución al error de autenticación en conexión a Escritorio remoto "Oracle/CredSSP"

Las actualizaciones de Mayo del 2018 trajeron sorpresas para los administradores de entornos donde las conexiones RDP dejaron de funcionar repentinamente. Microsoft publicó un articulo donde detalla el alcance de la vulnerabilidad de CredSSP cuyos parches trajeron consigo este inconveniente que se presenta principalmente en los casos donde el cliente ya tiene las actualizaciones de 05/2018 y el servidor aún no cuenta con las mismas.

El error que se presenta al intentar conectarse desde un cliente actualizado a un servidor sin el parche es el siguiente:

An authentication error occurred. The function requested is not supported.This could be due to CredSSP encryption oracle remediation
Error de autenticacion. No se permite la funcion solicitada.Puede deberse a una actualizacion de Oracle de cifrado CredSSP

Desde luego la solución mas recomendable es aplicar la actualización en clientes y servidores que se manejaran vía RDP, pero en casos donde es imperioso acceder a un servidor que aún no esta parchado es posible cambiar el comportamiento del cliente para que ignore la vulnerabilidad utilizando políticas de grupo o directamente modificando el registro, el cambio requiere un reinicio para tomar efecto.

Via gpedit.msc:





Vía regedit:



PS C:\Users\Administrator> reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2
The operation completed successfully.

PS C:\Users\Administrator>



Luego de parchear los servidores, lo recomendable es revertir el cambio para no dejar el sistema expuesto al robo de credenciales.

Paso a paso: Administración remota de Hyper-V en grupos de trabajo


Para administrar remotamente un servidor Hyper-V en casos donde la estación de trabajo o el servidor están en un grupo de trabajo, deben realizarse algunas configuraciones previas que detallo en esta entrada.


Configuración en el servidor Hyper-V


Habilitar la administración remota:

PS C:\Users\Administrator> Configure-SMRemoting.exe -Enable
Server Manager Remoting is now enabled: Enabled remote access.

PS C:\Users\Administrator>

Crear las reglas de firewall necesarias para la administración remota:

Set-NetFirewallRule -DisplayGroup 'Windows Management Instrumentation (WMI)' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Event Log Management' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru

Habilitar CredSSP en el servidor:

PS C:\Users\Administrator> Enable-WSManCredSSP -Role Server -Force


Configuración en el cliente


Habilitar el servicio winrm y añadir el host HYPER-V a los equipos de confianza del cliente:


PS C:\Windows\system32> winrm quickconfig
WinRM service is already running on this machine.
PS C:\Windows\system32> winrm set winrm/config/client '@{TrustedHosts="hyperv"}'
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = true [Source="GPO"]
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = true
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = hyperv

PS C:\Windows\system32>


Al igual que en el servidor, en el cliente necesitamos una regla de firewall para permitir la administración remota de volúmenes:

Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru


Agregar el hostname y dirección IP del servidor al archivo C:\Windows\System32\Drivers\etc\hosts



Modificar la política de seguridad local (gpedit.msc) para permitir delegación de credenciales (agregar wsman/* en la lista de servidores para poder administrar cualquier servidor remoto):





Configurar las opciones de seguridad COM con la utilidad ubicada en C:\Windows\System32\dcomcnfg.exe, aquí debemos permitir el acceso remoto para anonymous logon:





Comprobamos la conectividad al servidor Hyper-V remoto, en este caso utilizando credenciales alternativas:







domingo, 3 de junio de 2018

Virtualizacion anidada (nested virtualization) en Windows Server 2016

Una nueva característica de Hyper-V en Windows Server 2016 es la de virtualización anidada o nested virtualization, que nos permite ejecutar un hipervisor como ESX o KVM dentro de un guest de Hyper-V. Este feature muy útil para ambientes de laboratorio se habilita por máquina virtual con el  comando Set-VMProcessor sobre la VM apagada.


Para comprobar si la virtualización anidada ya esta habilitada en una VM utilizar Get-VMProcessor:


Como la mayoria de los features disponibles en Hyper-V corriendo sobre Windows Server 2016, la virtualización anidada también puede utilizarse en Windows 10 con Hyper-V. Esto requiere Windows 10 versión 1607 en adelante.