BRS09. Config. sistemas informáticos.

 ARQUITECTURAS SEGURAS
o Servicios
 Telnet
 características
 TCP/23 - sin cifrar - vulnerable brute force
 interactuar con protocolo
 IMAP - POP3 - SMTP -HTTP
 FTP/TFTP caraterísticas
 modos reglas firewall
 activo - pasivo
 TCP/21 - FTP UDP/21 - TFTP
 vulnerable brute force
 sin cifrar
 SSH características
 cifrado - TCP/22
 puede ser vulnerable a brute force
 se puede aplicar configuración de seguridad
o procesos
 Perímetro - sitemas críticos
 Usuarios - Servidores - OT
 DMZ sevicios
 web seguridad
 proto.comunicación - auditorías
 actualización - mecanismos de acceso
 mec.de protección - mec.de autenticación
 navegación seguridad
 listas negras - listas blancas
o cloud CASB
 servicio:SaaS - VDI/VGI - PaaS - FaaS -IaaS
 dispositivos : BYOD - COBO -COPE
1.- Reducción del número de servicios, Telnet, RSSH, TFTP, entre otros.
1.1.- Telnet. 1.2.- TFTP/FTP. 1.3.- RSSH / SSH.
2.- Hardening de procesos (eliminación información de depuración en caso
de errores, aleatorización de la memoria virtual para evitar exploits, etc.).
3.- Eliminación de protocolos de red innecesarios (ICMP, entre otros).
4.- Securización de los sistemas de administración remota.
5.- Sistemas de prevención y protección frente a virus e intrusiones (antivirus, HIDS, etc.).
6.- Configuración de actualizaciones y parches automáticos.
7.- Sistemas de copias de seguridad.
8.- Shadow IT y políticas de seguridad en entornos SaaS.
8.1.- Shadow IT.
1.- Reducción del Nº de servicios, Telnet, RSSH, TFTP, entre otros.
Los protocolos no necesarios o presenten vulnerab, deben ser eliminados de los sistemas. Si prot vuln son
imprescindibles para operativa. Se debe tunelizar las comunic xa comunicación de manera más segura. Otro
mecanismo seg. es establecer reglas de comunicación en firewalls de red y firewalls locales del equipo del
servicio. Tb posible aislar servicio vuln. y acceder sólo desde máquina de salto que tenga prot. y medidas
seg. adecuadas, mitigando riesgo x acceso controlado.
Usar prot. Vuln. puede proporcionar un método de acceso inicial para
posteriormente exploits, shell control remoto, … toma de control del sistema
1.1.- Telnet.
Prot. que permite conectar con equipo y ejecutar comandos de manera remota
x puerto TCP 23. Los mensajes se envían en claro (sin cifrar), atacante podría
leer comandos ejecutados + otra info como nombres usuarios y contraseñas
intercambiadas. Hay prog como WinSCP, Putty + línea comandos en Windows y Linux Telnet nativo.
Con nmap, podemos hacer fingerprint del protocolo que está corriendo en remoto y saber versión serv
telnet, si tiene vuln.conocidas, … Tb hay herr. F.bruta xa adivinar usuario y contraseña (hydra, medusa).
Para bastionar prot. Telnet  sustituirlo por SSH (cifrado) pero si no posible x “sistema legacy” configurarlo
de manera segura + medidas refuerzo complementario (medidas compensatorias) como pueden ser:
 Aumentar vigilancia con monitorización.
 Diseño arquitectura basado en aislamiento servicio, o acceso con máquina de salto.
 Aumentar el control de acceso al servicio.
 Reforzar las medidas de seguridad del sistema operativo base que alberga el servicio.
Dentro de medidas generales de seguridad también se deben implementar en estos servicios:
 Actualizaciones del producto.
 Copias de seguridad de la configuración y de los datos.
 Establecer máquina de salto a servidor ssh para posteriormente acceder al servicio vulnerable.
Telnet es usado por atacantes para obtención de info. del sist a través del “Banner” servicio. (Fingerprint). Tb
se puede usar xa interactuar con prot SNMP (TCP/25), POP3 (TCP/110), IMAP (TCP/143), HTTP (TCP/80)
1.2.- TFTP/FTP.
Creado para transmisión remota de ficheros. Se crean 2 canales (transmitir datos y ejecutar comandos
remotos). 2 modos funcionam.:
 Activo: servidor crea canal de datos en Pto 20 TCP y cliente crea canal datos en puerto TCP
aleatorio >1024. Cliente envía Nº puerto al servidor para establecer conexión. El servidor no conoce
puerto del cliente  complica la definición de reglas de firewall.
 Pasivo: Servidor FTP abre puerto de datos TCP>1024y lo comunica al cliente FTP.
El canal por donde se transmiten los datos de control es hacia el puerto TCP 21.

El protocolo TFTP tb para transmisión ficheros es un prot no orientado a conexión (UDP) y además no
requiere autenticación (debe protegerse con reglas de Firewall). Se puede aprovechar por atacantes para
envio fichero con código y mas tarde ejecutarlo en servidor.
Se debe habilitar el serv FTP con contra eliminando el usuario anónimo x defecto. Hay programas xa
configurar el servicio. Si posible, implementar vers. Segura del prot (cifrada) FTPS/SFTP.
1.3.- RSSH / SSH.
RSSH es una versión reducida de SSH que sólo permite scp (security copy) y sftp (secure ftp). Permite
transmisión ficheros en común. cifrada entre cliente y servidor. Mediante esta conexión se establece común.
Xa gestión equipos. Algunas de las medidas de protección para el servicio ssh:
 Acceso a máquina con permisos mínimos y en 2ª etapa realizar elevación priv. Xa acciones
privilegiadas. Acceso inicial NO con privilegios de administración.
 Recomendable mec.autenticación robusto, ej.con certificados y/o integrar autenticación servicio con
autent.sistema.
 Limitar Nº intentos, para evitar ataque de fuerza bruta.
 T sesión e inactividad se deben limitar para que no quede abierta sesión.
 Establecer permisos de archivos en los que se guarden claves privadas/públicas autenticación.
 Utilizar versión del software y protocolo sin vulnerabilidades del protocolo. Como es la versión 1.
 Se eliminará el acceso al entorno gráfico del equipo que alberga el servicio
 Eliminar de acceso del usuario superadmin root.
 Establecer reglas de usuarios que pueden acceder servicio, y desde qué dispositivo pueden.
  No se permite el acceso de usuarios sin contraseña.
 Usuarios reciben mensaje con caract. del entorno que acceden y normas de uso (concienciación).
 Eliminar comando rsh a través de archivos rhost. del servicio, autenticación criptográfica basada en
host de SSH es + segura q autenticación .rhosts.
 Usuarios no puedan usar variables de entorno al demonio SSH.
 Utilizar algoritmo de cifrado robustos.
Xa configurar el acceso con claves criptográficas.
 Las claves públicas en el directorio home de cada usuarios ~/.ssh/id_rsa. El fichero debe establecer
permisos lectura y escritura para su propietario pero no para el resto de usuarios y grupos (600).
 El acceso por ssh con clave privada se realiza por ssh -i /ruta/clave/privada usuario@ip_dominio.com

2.- Hardening procesos (elimin info de depuración en caso de

errores, aleatorización memoria virtual para evitar exploits, etc.).
Se establecerán configuración segura para cada componentes instalados en equipos, tanto del SO como
cada programa específico de tareas asignadas del sistema. Dentro de elem.comunes config serán:
 Eliminación de usuarios por defecto
 Modificación de las contraseñas por defecto del Sistema.
 Activar el registro de eventos del sistema
 Se permite gestión usuarios con roles y grupos asignando a usuario privilegios mínimos xa su tarea.
 Se establecerán mensajes informativos respecto a resp.usuario a la utilización de los sistemas.
 Los equipos se bloquean después de un tiempo de inactividad.
 Solo abiertos puertos necesarios para desarrollo actividad. Bloqueándo con firewall local y de red.
 Tener herramientas de protección antimalware como antivirus. Y deberán estar actualizados.
 Todo el software debe estar actualizado a la última versión.
Para control ejecución de software hay herr.que permiten sólo ciertos programas. Xa Microsoft AppLocker.
Tb monitorizar ejecución nuevos programas con herr. como HIDS. Se deben aplicar medidas seg.relativas a:
 Protección en reposo mediante el cifrado de los datos
 Protección en tránsito mediante el cifrado de las comunicaciones
 Protección en uso que es la seguridad de los datos asociado a los procesos.
Microsoft tiene Anti-Malware Scan Interface (AMSI) xa detectar script cuando se ejecuta en memoria,
proporcionando a los AV una copia de lo que se está ejecutando.
Los procesos maliciosos realizan acciones anormales en sistema que impiden su detección  necesario
controlar cambios claves registro, jerarquía procesos que ejecutan, T ejecución procesos, … estas tareas se
realizan en las tareas de Threat hunting y que posteriormente son implementados como reglas de detección.
La info de logs es info sensible por dos motivos, permite conocer info relativa al sistema y son las evidencias
de sucesos en un incidente de seguridad. El acceso a los mismos regulado y protegido.
Hay herr. como ProcMon de sysinternals que permite tener info. procesos en ejecución en SO. Tb otra herr
de sysinternal para enviar info sobre procesos como puede ser sysmon.
Medidas para proteger la memoria de los sistemas Dirigidas a impedir ejec. instrucciones en ciertas
regiones de memoria como el stack y a proporcionar cierta aleatoriedad al espacio de direcciones del
proceso (heap, stack,librerías, etc) para hacer más complejo el uso de direcciones hardcodeadas o de
técnicas como ret-to-libc. Con uso direcciones predecibles (p.ej. librerías estáticas) y ROP el atacante,
podría eludir dichas restricciones de seguridad.
ASLR Evita explotación de vuln. sobre la corrupción de memoria. (atacante pueda saltar a una dir.de
memoria donde sabe que hay una función disponiendo de datos del proceso: ejecutable + datos en la pila).
DEP - "Prevención de ejecución de datos de Windows". El código
malicioso ejecuta código fuera de ubicaciones reservadas al SO
Windows y prog. autorizados. Este mecanismo protección nos asegurael
uso de la memoria de manera segura y si uso incorrecto el programa se
cierra y notifica. Usaremos siempre soft compatible con DEP.
Inicio --> Equipo --> Propiedades --> Configuración avanzada
Sistema --> Cambiar configuración avanzada del sistema -->
Opciones avanzadas --> Configuración --> Prevención de
ejecución de datos
3.- Eliminación de protocolos de red innecesarios (ICMP, entre otros).
El control comunic. requiere de gestión en todo ciclo vida sistemas.
Desde fases de diseño, con el diagrama de arquitectura del
sistema indicando flujos info entre componentes sistema y prot
utilizados. Para control comunic y puertos que deben estar
abiertos para permitir solo comunic.establecidas y por los equipos.
Esta gestión se actualiza ante cambios en arquitectura o
componentes sistema y estará complementada por mecan
monitoriz de elementos protectores como los firewalls y, si
comunicación/intento no controlado permita determinar motivo de
porqué se han realizado y reportar incidente o falso positivo por mal funcionam. equipo que originó alerta.
Los protocolos innecesarios deben ser eliminados a nivel de red y a nivel de SO (firewalls de red y del SO).
Un ejemplo es el prot IPv6 (apenas se usa y lo usan atacantes xq nivel conocimiento protocolo es bajo y por
defecto muchos Ss se levantan en él sin que admin. lo desactiven a pesar de no estar siendo utilizado).
Estamos usando masivamente prot NAT para extender uso IPv4 en vez de IPv6  servicio de NAT se
convierte en pto clave/crítico seguridad. El NAT no debería ser medida protección, xq no es más que un
mec. ocultación de la infraestructura, atacantes saben que está siendo utilizada usan otras técnicas para
acceder a descubrir la arquitectura.
4.- Securización de los sistemas de administración remota.
Los sist. admin remotos debe ser actualizados para no disponer de vuln. conocidas y los Ss deben estar
protegidos como elem. críticos del sist, xq permiten tomar control sist. y extraer info, elevar privilegios, …
Comunicaciones a través de prot cifrado seguro que impidan que se pueda visualizar info transmitida.
La autenticación deberá estar basada en usuario y contraseña, un 2º factor autenticación y adicionalmente:
 Bloqueo de usuario frente ataques de fuerza bruta.
 No mostrar info relevante que indique la existencia de los usuarios.
 Control del origen desde la que se hace la conexión remota.
 Análizar equipos origen: Actualizado, con antivirus, firewall habilitado
 Tener proc. operativos de recup. contraseñas y realizar bajas usuarios.
 Usar CAPTCHA para evitar la utilización de herramientas automáticas.
Los accesos deben haber sido aprobados por responsable sistema y cada
usuario con su nivel de acceso mínimo al sistema. Estos accesos se
recertificarán periódicamente xa control usuarios con acceso.
Se deberá contar con mecanismo monitoriz de logs de la aplicación control
remoto y detectar intentos no deseados de acceso.
Los accesos remotos deben estar controlados (y los mínimos indispensables). Mejor acceso al sistema x un
pto central con salto a los diferentes sist, y no múltiples sist control remoto y hacia múltiples equipos (+ difícil
administración y control accesos). El acceso remoto deberá estar alineado con procesos de alta,
modificación y baja usuarios en sistema con sist gestión de identidades(PIM) y sist.accesos privilegiados
(PAM). Todos estos procesos tb alineados con procesos operativos de seguridad, también llamados POS.
El nivel de acceso remoto para usuarios privilegiados debe reforzarse (x posible impacto en org).
Tb se debe tener cta si app acceso remoto tiene que exponerse al dom público de Internet  refuerzo
medidas seg (establecer localizaciones o dispositivos origen del acceso remoto). Siempre basados en una
defensa en profundidad, donde acceso a determ Ss desde disposit controlados y con mínimos seguridad.
5.- Sist.prev y prot frente a virus/intrusiones (antivirus, HIDS, etc.).
Existen varios sistemas que protejen contra soft maliciosos y virus. Los que se implementen deben ser
complementarios, proporcionar protección + info ante incidente y deseable que tenga mecanismo de
reacción automática (defensa activa) en caso de que sistema peligro. Tipos herramientas:
 Activas: Se realizan contramedidas protección contra código malicioso. Deben estar actualizadas xq
métodos de ataque también evolucionan en el tiempo.
 Pasivas. Sólo avisan.
Active response: Concepto de los HIDS (sist detec intrusos a nivel de Host) de cómo reaccionar ante
eventos sospechosos. Hay que particularizar reglas a entorno donde se implementan. Ej de libre distrib es
OSSEC o versión + reciente Wazuh.
Los mec. protección deben tener sist.actualizaciones x nuevas vuln, y ser parametrizables para entorno
concreto, pudiendo añadir excepciones que deberán ser documentadas y analizadas previa a su aplicación.
Se debe contar en la red con <> mec.detección de código malicioso ya que hay técnicas de evasión de
antivirus y tener <> antivirus en la red complica a atacante la evasión.
Hay que ponerse en la mente atacante xa buscar contramedida xa ciertas actividades (ej. ejercicio
simulación ataque al sistema sistema y utilizando herr.de prot. como un endpoint (EDR) o antivirus, para ver
si se detecta el ataque mientras tratamos de evadir nuestros sistemas de proteccion).
Los sist.detección de intrusos (IDS) a través del análisis de trazas de red, alertan en base a
reglas Acompañado a la alerta, procedimiento de gestión de la alerta xq sistema sólo genera alarmas, no
mecan. protección (sí lo hace el IPS). Existe muchas formas de determinar reglas xa IDS, las de Snort se
basan en firmas clasificadas por categorías. Las reglas de los IDS pueden estar basadas en:
 Comportamiento. Necesitamos conocer funcionam normal del sistema para detectar las anomalías.
 Firmas: Detectan el tráfico malicioso en base a reglas.
La monitorización del tráfico red para enviar a IDS, se hace a través de métodos de port-mirroring o con
disp. denominado tap (antiguos hub) que reenvían todos paquete a todos puertos por métodos de broadcast.
Debemos estar informados de parches seguridad y vuln publicadas x fabricantes en base a nuestro catálogo
de activos y software. Las actualizaciones se deben forzar según programación en los equipos (no como
tarea dependiente del usuario). Tras actualizar, reinicio de equipos xa actualización correcta.
También actualiza las herr.de detección de artefactos de seguridad como pueden ser:
 Antivirus - HIDS, NIDS… (dominios, hash, ips,…)
Para móviles tb necesario utilización MDM que permita la actualización de dispositivos y control
herramientas ejecutables en ellos. Siempre orientado a una red BYOD,
Lo que pierda soporte (no actualización)  sustituir x lo que si tenga.
Básicos en las actualizaciones
 Descarga de sitios oficiales
 Comprobación de la integridad de la descarga
 Pruebas en entornos de preproducción. Si se puede.
 Mejor hacerlo que esperar a tener la seguridad al 100%

6.- Configuración de actualizaciones y parches automáticos.

Actualizaciones y parches seguridad uno de los pilares fund. para mantener nivel seguridad de sistemas.
Teniendo en cuenta que software está instalado en sistemas con complejas relaciones entre ellos, un fallo
seguridad en uno de los componentes software puede dañar el sistema entero. La seguridad de un
sistema es la seguridad de su punto más débil.
Una vez que pdto ha sido actualizado  actualización por parte de los administradores del sistema.
Algunas Cias como Microsoft aglutinan actualizaciones una vez al mes (1º martes del mes), salvo alguna
especialmente crítica que denominan parches de seguridad de vulnerabilidades de día cero.
Debido al desconocimiento de nuevas vuln en soft equipos, es necesario disponer mecan de protección
frente ataques además de actualizar (mitigar las conocidas).
El software licenciado está apoyado por equipo de soporte que desarrolla soluciones y envían a sist con
licencia,. El software libre depende de agilidad de comunidad para buscar solución (si grande, mejor). En
soft libre se está incrementando impacto de seguridad cuando son ampliamente utilizados, como
recientemente el fallo de seguridad de log4j.
Normalmente arquitecturas para el servicio de actualización pueden ser dos:
 Arquitectura distribuida del sistema, cada equipos actualiza descargando independientemente los
parches. Ok para org. Pequeñas/casa donde infraestructura pequeña y no equipo TIC.
 Arquitectura centralizada de actualización, servidor interno de actualizaciones que descarga
actualizaciones, las distribuye a resto equipos. Para entornos empresariales, y admin sistema que
controla actualizaciones (libera las que mejoran seguridad y no impacto negativo en operatividad).
Herram. xa búsqueda vuln que complementa tareas de actualización. Búsca vuln no parcheadas y permite
control y estado de actualización del sistema, dos de las herramientas más conocidas son:
 Nessus - OpenVas (incluida en Kali Linux)
En ejecución escaneos se deben realizar con credenciales xq muchas vuln. solo descubiertas asi.
 Fáciles de programas y repetir. Es fácil saber nivel parcheo. Herr. suelen poder hacer informes.
 Se puede cruzar con el inventario de activos.
 Producen “mucho ruido” en la red y consumo de recursos.
 Herram tienen que cubrir >> cjto elementos. Las licencias de los productos completos son caras.
 Existen soluciones open-source pero que no tienen una inteligencia tan amplia.
7.- Sistemas de copias de seguridad.
Permiten recuperar el sist ante incidente grave seguridad que deje sist inoperativo y/o con pérdida de datos
(ej ransomware). El sistema copias seguridad y las propias copias seg deberán estas protegidas x ser pto
crítico para resolver estos incidentes (evitar que atacante tb destruya sistema de copia y/o las copias de seg
realizadas para que no puedan ser restauradas). El sist copias de seguridad debe ser tratado como un
sistema crítico (acceso y control privilegiados desde red con propósito específico). El impacto de un ataque
crece con el tiempo entre copias.
Como resumen pasamos a indicar una estrategia de copias de seguridad basado en la regla 3.2.1:
 Deberías al menos almacenar 3 copias actualizadas de tus datos
 Las copias deben ser almacenadas en 2 medios diferentes (y con control acceso y prot.físicas)
 Una de las copias deberá ser almacenada de manera off-line.
Complementario al plan de copias de seguridad, deberá existir un plan de recuperación ante desastres. Las
copias se han de priorizar en fn citicidad datos/sistema y además respaldar tb configuraciones equipos para
rápida recuperación tras desastre (hacer manuales xa recuperar sistema tras desastre y simulaciónes de
restauración de copias seguridad periódicamente, para comprobar que copia info y config sea suficiente).
8.- Shadow IT y políticas de seguridad en entornos SaaS.
Las polít. seguridad en entornos cloud (SaaS, PaaS, …) deben respaldarse con matriz de responsabilidades
(matriz RACI) entre prov y cliente que delimite tareas de cada uno conforme a políticas seguridad sistema.
En caso de servicio SaaS las copias seguridad son resp.proveedor, cliente deberá ser informado de
realización de éstas y tener evidencia de que se han realizado. Las cop.seg. deben cumplir mismas medidas
que las internas:
 Tiempo de retención - Cifrado de las copias
 Procedimiento en caso de recuperación - Realización de simulacros de recuperación
 Fiabilidad de copias con test de las realizadas. - Copias etiquetadas y fácilmente identificables.
Los sistemas proporcionados x prov externos deben cumplir con mismas medidas seguridad que las
implementadas en la org. Se deben delimitar las resp del servicio relativos a la seguridad, para que ningún
ámbito quede sin cubrir. Tras definir funciones tb se implementan los procesos que formen parte de la
seguridad (ej. comunicación de un incidente, brecha seguridad de datos, caída servicio, actualización de
componentes, medidas regulatorias adicionales que hay que implementar, la gestión de excepciones, la
formación de los técnicos que administran la plataforma desde el punto de vista de la seguridad,…)
8.1.- Shadow IT.
Las aplicaciones y sistemas olvidados (sin mantenimiento) constituyen elem vulnerable para la org desde
pto vista seguridad (dispositivos, software, servicios en la nube, servicios on-premise…), además muchos
depart. Eº sacan proyectos usando TIC y dejan de lado la seguridad. El control de activos constituye un
elem fundamental. Admins pueden usar herram para la detección de:
 Elementos de red a través de NAC
 Control de software instalados con agentes de control de inventario, HIDS,...
 Ss centralizados de control de configs como: SCCM (Microsoft), Ansible o Jenkins (Linux),... Muchas
de ellas pueden usarse con fines de seguridad en el mundo de las operaciones DevSecOps.
La org. debe contar con políticas que incluyan a los equipos de seguridad desde el diseño de programas que
usen tecnología (actualmente casi todos proyectos empresariales).
Tb hay malas prácticas por usuarios que usan softw personal o que + conocen en vez del que proporciona
Cia, medidas técnicas que impidan descarga e instalación software no aprobado y configurado x Cia.
Políticas de concienciación, muchos usuarios usan plataf. descarga gratuita (posible delito prop intelectual +
malware asociado casi seguro).
 No permitir descarga ficheros ejecutables, no permitiendo la navegación a páginas web de software.
 Controlar entrada ficheros ejecutable en email o en mecan. intercambio info. que Ea proporcione.
 Desinstalar los ficheros ejecutables no controlados.
 La búsqueda de ficheros ejecutables y maliciosos.
 Actualización de patrones de búsqueda en base a IOCs: hash. nombres de ficheros,...
El ciclo vida software debe finalizar con etapa desinstalación, borrado y actualiz. Mecan.seguridad:
 Eliminación de protocolos, puertos, reglas,...en los dispositivos de la red.
 Desinstalción de software, Eliminación de usuarios
 Baja de los procedimientos de copia y recuperación de desastres.
 Destrucción de los dispositivos que albergaban la información
 Desconexión de los elementos con los que se integraba y operaba.