Problemas de Seguridad Comunes en la UNAM · Demian García. Seguridad por capas Aplicación...

Problemas de Seguridad

Comunes en la UNAM

M.A. Manuel Quintero

Ing. Demian García

Seguridad por capas

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Información

POLÍTICAS

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Políticas

• ¿Cómo saber que se puede hacer o que no,

si no se plasma en ningún lugar?

• Siempre se requieren políticas

Políticas

Políticas como…

• Contraseñas.

– ¿Alguien permite cuentas sin contraseña?

• Respaldos.

– Y si se hacen… ¿quién verifica que funcionen?

• Uso de la red

– Puede ser mas efectivo que en algún lugar diga que no pueden usar Netflix, que bloquear el acceso.

• Uso aceptable de los equipos

Porque todos somos los

responsables de...

• Sistemas

• Seguridad

• Redes

• Aplicativos

• Administración

• Desarrollo

• Mantenimiento

• Atención a usuarios

• Configuración de teléfonos…etc.

Porque todos somos los

responsables de...

• Debe existir un responsable de la seguridad.

• No se puede ser juez y parte.

PERSONAS

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Personas

• Quienes realizan las operaciones en

cualquier equipo son las personas.

• Es eslabón más débil de la cadena.

• (TI: Enviar contraseñas en correos sin cifrar desde el principio de los tiempos)

• No basta con implementar políticas, ¡deben

ser accesibles y divulgadas por todos los

usuarios!

Personas (IT)

• ¿Quién es responsable de qué?

• ¿Saben quién tiene cuentas de administración en todos los equipos?

• Si hay un problema, ¿quién lo resuelve?

• Matrices RACI

• Capacitación.

• No implica comprar cursos, implica concientizar a las personas.

• Pero yo sé seguridad, a mi no me va a

pasar.

SEGURIDAD FÍSICA

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Seguridad física

• No existe un site.

• Instalaciones inadecuadas para los equipos

de cómputo/telecomunicaciones.

• ¿Quién tiene acceso físico a los servidores?

• Telaraña estructurada.

RED

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Red

• Seguridad perimetral.

• Es poca o nula.

• A veces se asume que un firewall es más que suficiente.

• Reglas de control de entrada restrictivas, pero permisivas de salida.

• Segmentación de la red.

• Los clientes y servidores están en el mismo segmento (público).

• Direcciones IP públicas.

Red

Dispositivos/elementos de red “maliciosos”.

Servicios usados para ataques de amplificación

DNS, NTP, CHARGEN, QOTD, SSDP, SNMP

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

NTP DNS SNMP SSDP

JUNIO 2016

Detecciones

0

10

20

30

40

50

CHARGEN QOTD

JUNIO 2016Detecciones

Red

DDoS

Red

• No existe control de acceso físico a la red.

• Y es más interesante cuando hay un DHCP.

• Para el acceso a los equipos, se encuentran

disponibles SSH/RDP en “servidores” con IP

pública.

• No se implementan VPN.

• Ausencia de administración de amenazas

(spam, malware, phishing).

Ransomware

SISTEMAS OPERATIVOS

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Mito: ‘Hay sistemas operativos que

ya son seguros’

Vulnerabilidades por SO, 2015

Con información de www.gfi.com

No es sólo el SO, sino lo que vive en

él

Con información de www.gfi.com

No es sólo el SO, sino lo que vive en

él

Con información de www.gfi.com

Sistemas operativos

• Los equipos no cuentan con actualizaciones

y antivirus.

• ‘Solo aplica a Windows’

• Instalaciones por defecto

• ¡Porque Linux/UNIX/OS X ya es seguro!

• Aun existen S.O. Legacy.

• Windows XP

• Debían 5

• Ubuntu 9.10

• Solaris 8

Sistemas operativos

• IPTables sin configurar

• O con una regla allow all.

• Contraseñas débiles

• Suelen tener duración 9999.

• admin/adminadmin/passwordpostgres/postgresSYSTEM/manager

• Sin hardening

• HIDS

APLICACIÓN

Aplicación

Sistemas Operativos

Red

Seguridad física

Personas

Políticas

Aplicación (Web)

• Lo más común, sin validación de entrada

(80%)

• SQL Injection

• XSS

• XSRF

• Contenido de prueba

• ‘It works’ en servidores de producción

• IndexOf

• Respaldos completos vía web con contraseñas en claro

Aplicación (Web)

• phpinfo() y phpmyadmin con permisos de

acceso.

• Accesos no restringidos.

• Cuentas de usuario para consultas.

• Usuarios administrativo para realizar

conexiones.

• Aplicaciones Web con conexiones a bases

de datos con root.

Pero hay luz al final del camino

• Definir políticas de seguridad

• Y que estén respaldadas.

• Hardening de equipos

• CIS benchmarks (https://www.cisecurity.org/)

• Aplicar mejores prácticas

• www.m3aawg.org

• Actualizar S.O. y antimalware

• En TODOS los sistemas operativos.

• Eliminar prejuicios y mitos.

Pero hay luz al final del camino

• Capacitar a los usuarios (y administradores)

• Asegurar la red

• Segmentar y proteger.

• VPN y no pones servicios innecesarios.

• Sanitizar entradas en servicios Web.

• Aplicar procesos de seguridad, no productos

de seguridad.

• Monitorear constatemente, sin asumir que si

todo funciona, es que todo esta bien.

Conclusiones

• La cuestión no es si serán vulnerados, sino

cuando.

• La seguridad es un proceso, no un producto.

• Divide y vencerás.

• Trabajo en equipo.

• La seguridad es tan buena como el eslabón

más débil.

• Apoyo de la Dirección.

¿Preguntas?

M.A. Manuel Quintero

Ing. Demian García

UNAM-CERT

manuel.quintero@cert.unam.mx

demian.garcia@cert.unam.mx

@unamcert

/unamcert

¡Gracias!