Curso de Linux Seguridades

2013

Este documento fue elaborado para ser utilizado exclusivamente en los cursos de entrenamiento Linux
ofrecidos por Palosanto Solutions
Solution
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

ÍNDICE GENERAL

Capítulo 1 [INFORMACIÓN GENERAL SOBRE SEGURIDAD]

1.1 Introducción a la seguridad...................................... 2
1.1.1 Qué es la seguridad informática?............................... 2
1.1.1.1 Cómo ocurrió la seguridad informática?...................... 2
1.1.1.2 Estandarización de la seguridad............................ 3
1.1.2 SELinux................................................ 4
1.1.3 Controles de seguridad..................................... 4
1.1.3.1 Controles físicos...................................... 4
1.1.3.2 Controles técnicos..................................... 5
1.1.3.3 Controles administrativos................................ 5
1.1.4 Conclusión............................................. 5
1.2 Evaluación de vulnerabilidades................................... 6
1.2.1 Pensar como el enemigo.................................... 6
1.2.2 Definir evaluación y pruebas.................................. 7
1.2.2.1 Establecer una metodología.............................. 8
1.2.3 Evaluar las herramientas.................................... 9
1.2.3.1 Nmap............................................. 10
1.2.3.2 Nessus............................................. 10
1.2.3.3 Nikto.............................................. 10
1.2.3.4 Anticipar sus necesidades futuras........................... 11
1.3 Atacantes y vulnerabilidades..................................... 11
1.3.1 Breve historia de los hackers................................. 11
1.3.1.1 Tipos de hackers...................................... 12
1.3.2 Amenazas a la seguridad de la red.............................. 13
1.3.2.1 Arquitecturas inseguras................................. 13
1.3.2.2 Redes broadcast...................................... 13
1.3.2.3 Servidores centralizados................................. 13
1.3.3 Amenazas a la seguridad de un servidor.......................... 14
1.3.3.1 Servicios no utilizados y puertos abiertos...................... 14
1.3.3.2 Servicios sin parchar................................... 14
1.3.3.3 Administración desatenta................................ 15
1.3.3.4 Servicios inherentemente inseguros......................... 15
1.4 Ataques y agresiones comunes................................... 16
1.5 Actualizaciones de seguridad..................................... 19

Capítulo 2 [ASEGURAR SU SISTEMA LINUX]

2.1 Evaluar la seguridad del sistema................................... 21
2.2 Seguridad en el BIOS.......................................... 21
2.3 Seguridad del gestor de arranque.................................. 22
2.4 Banners de advertencia........................................ 22
2.4.1 Configurar un banner de inicio de sesión del sistema................. 22
2.4.2 Configurar un mensaje del día (motd)........................... 23
2.5 Seguridad en las contraseñas..................................... 24
INDICE | i
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

2.5.1 Crear contraseñas seguras................................... 24

2.5.2 Crear contraseñas dentro de una organización...................... 26
2.5.3 Forzar contraseñas seguras.................................. 26
2.5.3.1 John The Ripper...................................... 27
2.5.4 Caducidad de contraseñas................................... 27
2.6 Control de la cuenta root....................................... 27
2.6.1 Deshabilitar el acceso como root............................... 28
2.6.2 El comando su........................................... 29
2.6.3 Verificación del UID 0 en el archivo /etc/passwd.................... 29
2.7 Servicios de red existentes...................................... 30
2.7.1 Riesgos de los servicios..................................... 30
2.7.2 Servicios inseguros........................................ 31
2.7.3 Uso de la utilidad ntsysv.................................... 31
2.7.3.1 Habilitar y deshabilitar un servicio.......................... 32
2.7.3.2 Seleccionar runlevels................................... 32
2.7.4 Uso de la utilidad chkconfig.................................. 33
2.7.4.1 Listar los servicios..................................... 33
2.7.4.2 Habilitar un servicio.................................... 34
2.7.4.3 Deshabilitar un servicio................................. 34
Laboratorio 1.................................................. 36
Laboratorio 2.................................................. 37
Laboratorio 3.................................................. 38
Laboratorio 4.................................................. 40
Laboratorio 5.................................................. 42
Laboratorio 6.................................................. 43

Capítulo 3 [SSH: SECURE SHELL]

3.1 Introducción................................................ 46
3.2 Protocolo SSH............................................... 46
3.3 Cómo funciona SSH?.......................................... 47
3.4 Establecimiento de un canal seguro................................ 47
3.5 Autenticación............................................... 48
3.6 OpenSSH.................................................. 48
3.7 Asegurar SSH en el sistema...................................... 49
3.7.1 Usar contraseñas seguras.................................... 49
3.7.2 Deshabilitar el acceso como root............................... 50
3.7.3 Deshabilitar el protocolo 1................................... 50
3.7.4 Usar un puerto no estándar.................................. 50
3.7.5 Filtrar SSH en el firewall..................................... 51
3.7.6 Usar llaves públicas y privadas para la autenticación.................. 51
3.7.7 Configurar un banner...................................... 52
3.7.8 Redireccionamiento de puertos............................... 52
Laboratorio 7.................................................. 54
Laboratorio 8.................................................. 55
Laboratorio 9.................................................. 57

ii | INDICE
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Capítulo 4 [VPN: VIRTUAL PRIVATE NETWORK]

4.1 Introducción................................................ 59
4.2 Tipos de VPN............................................... 60
4.2.1 VPN de acceso remoto..................................... 60
4.2.2 VPN punto a punto........................................ 60
4.2.3 VPN local.............................................. 60
4.3 Protocolos................................................. 61
4.3.1 Implementaciones de capa 2 (Enlace)........................... 61
4.3.2 Implementaciones de capa 3 (Red)............................. 61
4.3.3 Implementaciones de capa 7 (Aplicación)......................... 62
4.4 Configuración de un servidor VPN.................................. 62
4.4.1 OpenVPN.............................................. 62
4.4.1.1 Cómo funciona OpenVPN?............................... 63
4.4.1.2 Ventajas de OpenVPN.................................. 63
4.4.1.3 Desventajas de OpenVPN................................ 64
4.4.2 Archivos de configuración................................... 64
4.4.3 Iniciar y detener el servicio .................................. 65
4.4.4 Cliente OpenVPN......................................... 62
Laboratorio10.................................................. 66
Laboratorio 11................................................. 73

Capítulo 5 [FIREWALL]
5.1 Introducción................................................ 77
5.2 Firewall................................................... 77
5.2.1 Tipos de firewall......................................... 78
5.2.2 Firewall de filtrado de paquetes............................... 78
5.3 Conceptos de firewall.......................................... 79
5.3.1 Enrutamiento de paquetes.................................. 79
5.3.2 Filtrado de paquetes...................................... 80
5.3.3 Network Address Translation (NAT)............................. 80
5.3.4 Reenvío de puertos....................................... 81
5.4 Netfilter................................................... 82
5.4.1 Operación............................................. 82
5.4.2 Estructura............................................. 83
5.4.2.1 Tablas de procesamiento de IPTables........................ 84
5.4.2.2 Comandos de IPTables.................................. 84
5.4.2.3 Filtros o criterios de coincidencia de IPTables................... 85
5.4.2.4 Acción o destino de procesamiento de las reglas de IPTables........ 86
5.4.3 Guardar las reglas de IPTables................................ 87
5.4.4 Iniciar y detener el servicio de IPTables.......................... 88
5.4.5 Verificar el estado de IPTables................................ 88
5.4.6 Cargar módulos de kernel requeridos por IPTables................... 89
Laboratorio 12................................................. 90

INDICE | iii
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Capítulo 6 [PROXY HTTP]

6.1 Qué es un proxy?............................................. 95
6.2 Proxy HTTP................................................. 95
6.2.1 Funcionamiento......................................... 95
6.2.2 Ventajas............................................... 96
6.2.3 Desventajas............................................ 96
6.2.4 Proxy HTTP abierto....................................... 97
6.2.5 Proxy transparente....................................... 97
6.3 Configuración de un servidor proxy HTTP............................. 97
6.3.1 Squid................................................. 97
6.3.2 Control de acceso........................................ 98
6.3.3 ACLs................................................. 98
6.3.4 Reglas de acceso......................................... 100
6.3.5 Archivo de configuración.................................... 101
6.3.6 Iniciar y detener el servicio.................................. 101
6.3.7 Configuración del cliente.................................... 102
Laboratorio 13................................................. 103
Laboratorio 14................................................. 109

iv | INDICE
 Capítulo 1
[INFORMACIÓN GENERAL
SOBRE SEGURIDAD]

CONTENIDO
1.1 Introducción a la seguridad
1.2 Evaluación de vulnerabilidades
1.3 Atacantes y vulnerabilidades
1.4 Ataques y agresiones comunes
1.5 Actualizaciones de seguridad
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

1.1 Introducción a la seguridad

Debido a la creciente dependencia actual en los sistemas y equipos conectados a
la red, que permiten a las empresas y negocios funcionar y llevar registro de
nuestra información personal, industrias enteras se han formado en torno a la
práctica de la seguridad informática.

Dado que la mayoría de las organizaciones son cada vez más dinámicas, sus
trabajadores están accediendo a recursos críticos de manera local y remota, de
ahí que la necesidad de entornos informáticos seguros se ha pronunciado cada
vez más.

Desafortunadamente, muchas organizaciones (así como usuarios particulares)

consideran la seguridad como algo de última instancia. La aplicación de adecuadas
políticas de seguridad es a menudo realizada postmortem, es decir, después de
que un acceso no autorizado ha ocurrido. Tomar las medidas correctas antes de
conectar nuestra organización a una red insegura, como Internet, es un medio
eficaz para frustrar intentos de intrusión y posibles ataques informáticos.

1.1.1 Qué es la seguridad informática?

La seguridad informática es un término general que cubre una amplia área de la
computación y el procesamiento de información. Las organizaciones que
dependen de los sistemas informáticos y las redes de comunicación para llevar a
cabo sus transacciones comerciales del día a día y que acceden a información
crítica, consideran los datos como una parte importante de sus activos fijos.
Muchos términos y medidas se han incorporado a nuestro vocabulario diario de
negocios, tales como el costo total de propiedad (TCO), el retorno de la inversión
(ROI), y la calidad de servicio (QoS). Con el uso de estos parámetros, las
organizaciones pueden calcular aspectos tales como la integridad de los datos y la
alta disponibilidad como parte de su planificación y de gestión de procesos. En
algunos sectores, como el comercio electrónico, la disponibilidad y confiabilidad
de los datos puede significar la diferencia entre el éxito y el fracaso.

1.1.1.1 Cómo ocurrió la seguridad informática?

La seguridad de la información ha evolucionado a lo largo de los años debido a la
creciente dependencia de las redes públicas, como Internet, de no divulgar
información personal, financiera y que sea restringida. Hay numerosos casos que
llevaron a las organizaciones de todos los sectores a volver a pensar la forma en
que manejan la información, incluyendo su transmisión y divulgación. La
popularidad de la Internet ha sido uno de los acontecimientos más importantes
que llevaron a intensificar los esfuerzos en materia de seguridad de datos.

2 | INFORMACIÓN GENERAL SOBRE SEGURIDAD

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Un número cada vez mayor de personas están utilizando sus computadores

personales para poder acceder a los recursos que Internet tiene para ofrecer.
Internet ha sido considerado como uno de los acontecimientos más importantes
del siglo 20.

Internet y sus primeros protocolos, sin embargo, se han desarrollado como un

sistema basado en la confianza. Es decir, el Protocolo de Internet (IP) no fue
diseñado para ser seguro en sí mismo. No existen estándares de seguridad
incorporados en la pila de comunicaciones TCP/IP, dejándolo abierto a usuarios y
procesos potencialmente maliciosos a través de la red. Avances y desarrollos
modernos han hecho de la comunicación en Internet más segura, pero todavía
hay varios incidentes y que nos alertan sobre el hecho de que nada es
completamente seguro.

1.1.1.2 Estandarización de la seguridad

Empresas de todos los sectores confían en los reglamentos y normas que se
establecen por organismos como la Asociación Médica Americana (AMA) o el
Instituto de Ingenieros Eléctricos y Electrónicos (IEEE). Los mismos principios son
válidos para la seguridad de la información. Muchos consultores y fabricantes de
la industria de la seguridad informática están de acuerdo en el modelo estándar
de seguridad conocido como CIA (Confidentiality, Integrity, and Availabilty o
Confidencialidad, Integridad y Disponibilidad). Este modelo de tres niveles es un
componente generalmente aceptado para la evaluación de riesgos de información
confidencial y el establecimiento de políticas de seguridad. A continuación se
describe el modelo CIA en mayor detalle:

• Confidencialidad. La información confidencial debe estar disponible sólo

a un conjunto de individuos predefinido. La transmisión no autorizada y el
uso de la información deben restringirse. Por ejemplo, la confidencialidad
de la información asegura que la información personal o financiera de un
cliente no se obtiene por una persona no autorizada para fines maliciosos
como el robo de identidad o fraude de crédito.
• Integridad. La información no debe ser alterada en formas que la hagan
incompleta o incorrecta. Usuarios no autorizados deben ser restringidos
de modificar o destruir información sensible.
• Disponibilidad. La información debe ser accesible a los usuarios
autorizados en cualquier momento que se necesite. La disponibilidad es
una garantía de que la información se puede obtener con una acordada
frecuencia y puntualidad. Esto, a menudo se mide en términos de
porcentajes y se acuerdos formales en los Acuerdos de Nivel de Servicio
(SLAs) usados por los proveedores de servicios de red y sus clientes
empresariales.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 3

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

1.1.2 SELinux
Las distribuciones basadas en Red Hat Enterprise Linux, como CentOS Linux,
incluyen una mejora al kernel llamada SELinux, que proporciona una arquitectura
de acceso obligatorio o MAC (Mandatory Access Control) que proporciona un gran
nivel de control sobre los archivos, procesos, usuarios y aplicaciones en el sistema.
Una revisión detallada de SELinux está más allá del alcance de este documento,
sin embargo para más información sobre SELinux y su uso en Red Hat Enterprise
Linux y sus derivados, consulte la guía detallada en el siguiente link:

https://access.redhat.com/site/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/Security-
Enhanced_Linux/index.html

1.1.3 Controles de seguridad

La seguridad informática a menudo se divide en tres categorías principales,
comúnmente conocidas como controles:

• Físico
• Técnico
• Administrativo

Estas categorías definen los objetivos principales de una correcta implementación

de seguridad. Dentro de estos controles hay sub-categorías que detallan aún más
como poner en práctica estos controles de seguridad.

1.1.3.1 Controles físicos

El control físico es la implementación de medidas de seguridad en una estructura
definida utilizados para disuadir o impedir el acceso no autorizado a material
sensible. Ejemplos de controles físicos son:

• Cámaras de vigilancia de circuito cerrado

• Sistemas de alarmas de movimiento o térmicas
• Guardias de seguridad
• Identificaciones de seguridad con foto
• Puertas aseguradas
• Biometría (incluye huellas digitales, voz, cara, iris, escritura a mano, y
otros métodos automáticos para el reconocimiento de las personas)

4 | INFORMACIÓN GENERAL SOBRE SEGURIDAD

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

1.1.3.2 Controles técnicos

Los controles técnicos usan la tecnología como una base para controlar el acceso
y el uso de los datos confidenciales a través de una estructura física y sobre una
red.

Los controles técnicos abarcan tecnologías tales como:

• Encriptación
• Tarjetas inteligentes
• Autenticación de red
• Listas de control de acceso (ACL)
• Software de auditoría de integridad de archivos

1.1.3.3 Controles administrativos

Los controles administrativos definen los factores humanos de la seguridad.
Involucran a todos los niveles del personal dentro de una organización y
determinan qué usuarios tienen acceso a qué recursos e información por medios
tales como:

• Formación y sensibilización
• Preparación para desastres y planes de recuperación
• Contratación de personal y estrategias de separación
• Registro de personal

1.1.4 Conclusión
Ahora que ha aprendido acerca de los orígenes, motivos y aspectos de seguridad
informática, le resultará más fácil determinar el curso de acción apropiado en
relación con su sistema Linux. Es importante saber cuáles son los factores y
condiciones que conforman la seguridad con el fin de planificar e implementar
una estrategia adecuada. Con esta información en mente, el proceso de
implementación de una política de seguridad en su organización se puede
formalizar y el camino se vuelve más claro a medida que profundiza en los
detalles del proceso de seguridad.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 5

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

1.2 Evaluación de vulnerabilidades

Con tiempo, recursos y motivación, un atacante puede violar casi cualquier
sistema. Todos los procedimientos y tecnologías de seguridad disponibles en la
actualidad no pueden garantizar que los sistemas estén completamente a salvo de
intrusos. Los routers ayudan a asegurar la salida a Internet. Los firewalls ayudan a
asegurar el perímetro de una red. Las redes privadas virtuales transfieren de
forma segura los datos en un flujo encriptado. Los sistemas de detección de
intrusos pueden advertirle de actividades maliciosas.

Sin embargo, el éxito de cada una de estas tecnologías depende de una serie de
variables, incluyendo:

• La experiencia del personal responsable de la configuración, la supervisión

y el mantenimiento de las tecnologías.
• La habilidad de parchar y actualizar servicios y kernels rápida y
eficientemente.
• La capacidad de los responsables de mantener una vigilancia constante
sobre la red.

Dado el estado dinámico de los sistemas y tecnologías de información, asegurar

los recursos corporativos puede ser bastante complejo. Debido a esta
complejidad, a menudo es difícil encontrar recursos expertos y capacitados para
todos sus sistemas. Esto es principalmente porque cada materia de seguridad de
la información requiere constante atención y concentración. La seguridad de la
información no se detiene.

1.2.1 Pensar como el enemigo

Supongamos que usted administra una red empresarial. Tales redes están
compuestas por sistemas operativos, aplicaciones, servidores, monitores de red,
firewalls, sistemas de detección de intrusos, etc. Ahora imagínese tratando de
mantenerse al día con cada uno de ellos. Dada la complejidad del software y
entornos de red actuales, los exploits y bugs son una certeza. Mantenerse al día
con los parches y actualizaciones para toda la red puede llegar a ser una tarea de
enormes proporciones en una gran organización con sistemas heterogéneos.

Combine los requerimientos de experiencia con la tarea de mantenerse al día, y es

inevitable que ocurran incidentes adversos, entonces, los sistemas son
vulnerados, los datos se corrompen y el servicio se interrumpe.

Para incrementar tecnologías de seguridad y ayudar a proteger los sistemas, redes

y datos, usted debe pensar como un cracker (una persona que irrumpe en un
sistema informático) y evaluar la seguridad de sus sistemas revisando sus
debilidades. Las evaluaciones de vulnerabilidades preventivas contra sus propios

6 | INFORMACIÓN GENERAL SOBRE SEGURIDAD

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

sistemas y recursos de red pueden revelar posibles problemas que se pueden

solucionar antes de que un atacante se aproveche de una debilidad.

Una evaluación de vulnerabilidades es una auditoría interna de la seguridad de la

red y sus sistemas, cuyos resultados indican la confidencialidad, integridad y
disponibilidad de la red (como se explica en la sección 1.1.1.2). Por lo general, una
evaluación de vulnerabilidad comienza con una fase de reconocimiento, durante
el cual se recopilan datos importantes con respecto a los sistemas y recursos
destino. Esta etapa lleva a la fase de preparación del sistema, donde el objetivo es
fundamentalmente revisado para todas las vulnerabilidades conocidas. La fase de
preparación culmina en la fase de información, donde los resultados se clasifican
en categorías de alto, medio y bajo riesgo; y métodos para mejorar la seguridad (o
mitigar el riesgo de la vulnerabilidad) del objetivo se discuten a fin de
implementar una posible solución.

Si realizara una evaluación de vulnerabilidades de su casa, usted probablemente

verificará cada puerta de su casa para ver si están cerradas y aseguradas. Quizás
también verificará cada ventana, asegurándose de que estén cerradas y con
seguro. Este mismo concepto se aplica a los sistemas, redes y datos electrónicos.
Los usuarios maliciosos son los ladrones y vándalos de sus datos. Enfóquese en las
herramientas que utilizarían, mentalidad y motivaciones, y podrá responder
rápidamente a sus acciones.

1.2.2 Definir evaluación y pruebas

Las evaluaciones de vulnerabilidades pueden ser divididas en dos tipos o
perspectivas: externa e interna.

Al realizar una evaluación de vulnerabilidades externa, usted intenta

comprometer sus sistemas desde el exterior. El ser externo a la empresa, le
muestra el punto de vista del cracker. Usted ve lo que un cracker ve, como
direcciones IP públicas, interfaces externas de su firewall, sistemas en su DMZ,
etc. DMZ (demilitarized zone o zona desmilitarizada) corresponde a un
computador o una pequeña subred que se encuentra entre una red interna de
confianza, tal como una LAN corporativa privada, y una red externa no confiable,
como Internet. Normalmente, la DMZ contiene equipos accesibles desde Internet,
como servidores Web (HTTP), servidores FTP, servidores SMTP (correo
electrónico) y servidores DNS.

Cuando se realiza una evaluación de vulnerabilidades interna, tiene una ventaja

puesto que ya está dentro y que su estado es de confianza. Este es el punto de
vista que usted y sus compañeros de trabajo tienen una vez que haya iniciado
sesión en sus sistemas. Usted ve los servidores de impresión, servidores de
archivos, bases de datos y otros recursos.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 7

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Hay diferencias notables entre estos dos tipos de evaluaciones de

vulnerabilidades. Ser interno de su empresa le da privilegios elevados más que
cualquier externo. Aún hoy en día, en la mayoría de las organizaciones, la
seguridad está configurada de una manera tal como para mantener fuera a los
intrusos o atacantes. Muy poco se hace para asegurar la parte interna de la
organización (tales como firewalls departamentales, controles de acceso a nivel
de usuario, procedimientos de autenticación para recursos internos, y más).
Típicamente, hay muchos más recursos cuando se observa desde el interior, ya
que la mayoría de los sistemas son internos a una empresa. Los sistemas y los
recursos disponibles para el exterior suelen ser muy limitados.

Tenga en cuenta la diferencia entre las evaluaciones de vulnerabilidades y las

pruebas de penetración. Piense en una evaluación de vulnerabilidades como el
primer paso para una prueba de penetración. La información obtenida de la
evaluación se utiliza para la prueba. Mientras la evaluación se lleva a cabo para
comprobar si hay potenciales agujeros y vulnerabilidades, las pruebas de
penetración tratan de explotar los resultados.

Los administradores de la seguridad informática son tan buenos como las

herramientas que utilicen y el conocimiento que posean. Utilice cualquier
herramienta de evaluación disponible, ejecútela contra el sistema, y es casi una
garantía de que habrá algunos falsos positivos. Ya sea por error del programa o
del usuario, el resultado es el mismo. La herramienta puede encontrar
vulnerabilidades que en realidad no existen (falsos positivos), o, peor aún, la
herramienta no puede encontrar vulnerabilidades que en realidad sí existen
(falsos negativos).

Ahora que la diferencia entre la evaluación de la vulnerabilidad y una prueba de

penetración está definida, tome los resultados de la evaluación de
vulnerabilidades y revíselos cuidadosamente antes de realizar una prueba de
penetración.

ADVERTENCIA: Intentar explotar vulnerabilidades de los recursos o equipos en

producción puede tener efectos adversos para la productividad y la eficiencia de
sus sistemas y redes de comunicación.

1.2.2.1 Establecer una metodología

Para ayudar en la selección de herramientas para una evaluación de
vulnerabilidades, es útil establecer una metodología de evaluación.
Desafortunadamente, no existe una metodología predefinida u homologada por la
industria en este momento, sin embargo, el sentido común y las buenas prácticas
pueden servir de guía suficiente.

8 | INFORMACIÓN GENERAL SOBRE SEGURIDAD

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

¿Cuál es el objetivo? ¿Estamos viendo un servidor, o estamos viendo toda nuestra

red y todo dentro de la red? ¿Estamos accediendo externa o internamente a la
empresa? Las respuestas a estas preguntas son importantes ya que ayudan a
determinar no solamente cuáles herramientas seleccionar sino también la forma
en que se utilizan.

Para obtener más información sobre el establecimiento de metodologías,

consulte los siguientes sitios Web:

• The Open Source Security Testing Methodology Manual (OSSTMM)

http://www.isecom.org/research/osstmm.html

• The Open Web Application Security Project

http://www.owasp.org/

1.2.3 Evaluar las herramientas

Una evaluación puede comenzar usando alguna herramienta de recopilación de
información. Al evaluar toda la red, primero haga un diagrama de todos los hosts
que se están ejecutando. Una vez localizados, examine cada host individualmente.
Saber qué herramientas utilizar puede ser el paso más importante en la búsqueda
de vulnerabilidades.

Al igual que en cualquier aspecto de la vida cotidiana, hay muchas herramientas

diferentes que realizan el mismo trabajo. Este concepto se aplica también para la
realización de evaluaciones de vulnerabilidad. Existen herramientas específicas
para los sistemas operativos, aplicaciones y hasta redes (basadas en los
protocolos utilizados). Algunas herramientas son gratuitas, mientras que otras no
lo son. Algunas herramientas son intuitivas y fáciles de usar, mientras que otras
son enigmáticas y muy mal documentadas pero tienen características que las
otras no.

Encontrar la herramienta adecuada puede ser una tarea de enormes proporciones

y, al final, la experiencia cuenta. Si es posible, establezca un laboratorio de
pruebas y pruebe tantas herramientas como pueda, anotando las fortalezas y
debilidades de cada una. Revise el archivo README o la página de manual de la
herramienta. Además, busque en Internet más información, como artículos, guías
paso a paso, o incluso listas de correo específicas a la herramienta.

Las herramientas que se mencionan a continuación son sólo una pequeña

muestra de las herramientas disponibles.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 9

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

1.2.3.1 Nmap
Nmap es una popular herramienta que se puede utilizar para determinar el diseño
de una red. Nmap ha estado disponible durante muchos años y es probablemente
la herramienta que se utiliza con mayor frecuencia para recopilar información de
una red. Una página de manual se incluye y ofrece una descripción detallada de
sus opciones y su uso. Los administradores pueden usar Nmap en una red para
encontrar hosts y puertos abiertos en esos sistemas.

Nmap es el primer paso en una evaluación de vulnerabilidades. Se pueden

mapear todos los hosts dentro de una red y hasta se puede pasar una opción que
le permite a Nmap intentar identificar el sistema operativo que se ejecuta en un
host en particular. Nmap es un buen fundamento para establecer una política de
uso de servicios seguros y la restricción de los servicios que no son utilizados.

1.2.3.2 Nessus
Nessus es un escáner de seguridad de servicios muy completo. La arquitectura
plugin de Nessus le permite a los usuarios personalizarlo para sus sistemas y
redes. Al igual que con cualquier escáner, Nessus es sólo tan bueno como la base
de datos de firmas de la que depende. Afortunadamente, Nessus es actualizado
con frecuencia y ofrece un informe completo, exploración de hosts y búsquedas
de vulnerabilidades en tiempo real. Recuerde que puede haber falsos positivos y
falsos negativos, incluso en una herramienta tan poderosa y tan actualizada como
Nessus.

Nota: El software cliente y servidor de Nessus requiere una suscripción para

utilizarlo. Así también, existe un proyecto de software derivado de Nessus
llamado OpenVAS (Open Vulnerability Assessment Software), el cual es de código
abierto, cumple con la misma función y no requiere de suscripción. Ambos, se han
incluido en este documento como una referencia a los usuarios que puedan estar
interesados en usar estas aplicaciones. Para más información visitar los sitios
Web:

• Nessus
http://www.nessus.org/

• OpenVAS (Open Vulnerability Assessment Software)

http://www.openvas.org/

1.2.3.3 Nikto
Nikto es un excelente escáner de scripts CGI (Common Gateway Interface). Nikto
no sólo comprueba las vulnerabilidades CGI, sino que lo hace de una manera

10 | INFORMACIÓN GENERAL SOBRE SEGURIDAD

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

evasiva, con el fin de eludir los sistemas de detección de intrusos. Viene con una
documentación muy completa que debe ser revisada cuidadosamente antes de
ejecutar el programa. Si dispone de servidores Web que están sirviendo scripts
CGI, Nikto puede ser un excelente recurso para el control de la seguridad de estos
servidores.

Más información sobre Nikto se puede encontrar en el siguiente sitio Web:

http://cirt.net/nikto2

1.2.3.4 Anticipar sus necesidades futuras

Dependiendo de su objetivo y de los recursos a evaluar, hay muchas herramientas
disponibles. Hay herramientas para redes inalámbricas, redes Novell, sistemas
Windows, Linux, y más. Otra parte esencial de la realización de evaluaciones
puede incluir la revisión de la seguridad física, selección de personal, o la
evaluación de la red de voz/PBX. Nuevos conceptos, tales como war walking y
wardriving, que implican la exploración del perímetro de la estructura física de su
empresa para detectar vulnerabilidades de su red inalámbrica, son algunos de los
conceptos que debe investigar y, de ser necesario, incorporar en sus evaluaciones.
La imaginación y la exposición a posibles ataques son los únicos límites de la
planificación y la realización de evaluaciones de vulnerabilidad.

1.3 Atacantes y vulnerabilidades

Para planificar y ejecutar una buena estrategia de seguridad, en primer lugar
tenga en cuenta las motivaciones que determinaron a los atacantes a explotar y
comprometer sistemas. Sin embargo, antes de detallar estos problemas, hay que
definir la terminología utilizada en la identificación de un atacante.

1.3.1 Breve historia de los hackers

El significado moderno del término hacker tiene sus orígenes en la década de
1960 y el Tech Model Railroad Club del MIT (Massachusetts Institute of
Technology) que diseñaba juegos de trenes de gran escala y detalle intrincado.
Hacker fue el nombre utilizado para los miembros del club que descubrían un
truco inteligente o una solución para un problema.

El término hacker ha llegado desde entonces a describir todo desde aficionados a

la informática a programadores talentosos. Un rasgo común entre la mayoría de
los hackers es la voluntad de explorar en detalle cómo los sistemas informáticos y

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 11

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

las redes funcionan con poca o ninguna motivación externa. Los desarrolladores
de software de código abierto a menudo se consideran a sí mismos y a sus colegas
el ser hackers, y el uso de la palabra como un término de respeto.

Por lo general, los hackers siguen una forma de la ética hacker que dicta que la
búsqueda de información y experiencia es esencial y que compartir este
conocimiento es el deber de la comunidad de hackers. Durante esta búsqueda de
conocimiento, algunos hackers disfrutan los retos académicos de burlar los
controles de seguridad en los sistemas informáticos. Por esta razón, la prensa a
menudo utiliza el término hacker para describir a aquellos que acceden
ilegalmente a sistemas y redes con intención inescrupulosa, maliciosa o criminal.
El término más adecuado para este tipo de hacker es cracker -un término creado
por los hackers a mediados de la década de 1980 para diferenciar las dos
comunidades.

1.3.1.1 Tipos de hackers

Dentro de la comunidad de personas que encuentran y explotan vulnerabilidades
en los sistemas y redes, existen varios grupos distintos. Estos grupos se describen
por el tono del sombrero que "visten" al realizar sus investigaciones de seguridad
y este tono es indicativo de su intención.

• El hacker de sombrero blanco es aquel que prueba sistemas y redes para

examinar su rendimiento y determinar lo vulnerables que son a la
intrusión. Por lo general, los hackers de sombrero blanco tratan de violar
sus propios sistemas o los sistemas de un cliente que los ha empleado
específicamente para los fines de una auditoría de seguridad. Los
investigadores académicos y consultores de seguridad profesional son dos
ejemplos de hackers de sombrero blanco.
• Un hacker de sombrero negro es sinónimo de un cracker. En general, los
crackers están menos enfocados en la programación y la parte académica
de irrumpir en los sistemas. Con frecuencia, los crackers utilizan
programas disponibles y explotan vulnerabilidades conocidas en sistemas
para descubrir información confidencial para beneficio personal o para
causar daño en el sistema destino o la red.
• El hacker de sombrero gris, por otro lado, tiene las habilidades e
intenciones de un hacker de sombrero blanco en la mayoría de
situaciones, pero utiliza su conocimiento para propósitos menos nobles
de vez en cuando. Un hacker de sombrero gris puede ser visto como un
hacker de sombrero blanco que lleva un sombrero negro, a veces para
llevar a cabo su propia agenda. Los hackers de sombrero gris usualmente
se suscriben a otra forma de la ética hacker, que dice que es aceptable
entrar en un sistema, siempre y cuando el hacker no cometa robo o viole
la confidencialidad. Algunos podrían argumentar, sin embargo, que el
hecho de violar un sistema es de por sí inmoral.
12 | INFORMACIÓN GENERAL SOBRE SEGURIDAD
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Independientemente de la intención del intruso, es importante conocer las

debilidades que un cracker intentará explotar. El resto del capítulo se centra en
estas cuestiones.

1.3.2 Amenazas a la seguridad de la red

Malas prácticas al configurar los siguientes aspectos de una red pueden aumentar
el riesgo de un ataque.

1.3.2.1 Arquitecturas inseguras

Una red mal configurada es un punto de entrada para usuarios no autorizados.
Dejar una red local abierta, vulnerable a la altamente insegura Internet, es como
dejar una puerta abierta en un vecindario con alta criminalidad -nada puede
suceder por un tiempo, pero eventualmente alguien aprovechará la oportunidad.

1.3.2.2 Redes broadcast

Los administradores de sistemas a menudo no se dan cuenta de la importancia del
hardware de red en sus sistemas de seguridad. Hardware muy simple como hubs
y routers se basan en el principio de broadcast o no-conmutación, es decir, cada
vez que un nodo transmite datos a través de la red a un nodo receptor, el hub o
router envía un broadcast de los paquetes de datos hasta que el nodo destino
recibe y procesa los datos. Este método es el más vulnerable al spoofing o
falsificación de direcciones ARP o MAC, tanto por intrusos externos como por
usuarios locales no autorizados.

1.3.2.3 Servidores centralizados

Otra falla potencial en las redes es el uso de sistemas centralizados. Una medida
de reducción de costos común para muchas empresas es consolidar todos los
servicios en una sola máquina de poderosas características. Esto puede ser
conveniente, ya que es más fácil de manejar y cuesta considerablemente menos
que las configuraciones de varios servidores. Sin embargo, un servidor
centralizado introduce un punto único de fallo en la red. Si el servidor central se
ve comprometido, puede hacer que la red sea completamente inútil o peor aún,
propensa a la manipulación o robo de datos. En estas situaciones, un servidor
central se convierte en una puerta abierta que permite el acceso a toda la red.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 13

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

1.3.3 Amenazas a la seguridad de un servidor

La seguridad de un servidor es tan importante como la seguridad de la red, ya que
a menudo estos equipos tienen gran cantidad de información vital de una
organización. Si un servidor está comprometido, todo su contenido podría estar
disponible para que un cracker pueda robarlo o manipularlo a su antojo. Las
siguientes secciones detallan algunos de los principales problemas.

1.3.3.1 Servicios no utilizados y puertos abiertos

Una instalación completa de CentOS Linux 6 incluye más de 1000 paquetes de
aplicaciones y librerías. Sin embargo, la mayoría de los administradores optan por
no instalar todos los paquetes de la distribución, prefiriendo en su lugar, instalar
una base de paquetes, incluyendo varias aplicaciones de servidor.

Es muy común entre los administradores de sistemas instalar el sistema operativo

sin prestar atención a los programas que realmente se están instalando. Esto
puede ser problemático porque servicios que no son necesarios se pueden
instalar, configurados por defecto, y posiblemente encendidos a tiempo de
arranque del servidor. Esto puede causar que servicios no deseados, tales como
Telnet, DHCP o DNS, se ejecuten en un servidor o estación de trabajo sin que el
administrador se dé cuenta, lo que a su vez puede causar tráfico indeseado al
servidor, o incluso, una posible entrada en el sistema para los atacantes.

1.3.3.2 Servicios sin parchar

La mayoría de las aplicaciones de servidor que se incluyen en una instalación por
defecto son componentes probados de software. Después de haber estado en uso
en entornos de producción durante muchos años, su código ha sido refinado y
muchos de los errores han sido encontrados y corregidos.

Sin embargo, no hay tal cosa como el software perfecto y siempre hay espacio
para un mayor refinamiento. Además, hay software nuevo que a menudo no es
tan rigurosamente probado como uno esperaría, debido a su reciente llegada a
entornos de producción o porque tal vez no sea tan popular como otros software
de servidor.

A menudo, los desarrolladores y administradores de sistemas encuentran errores

explotables en las aplicaciones de servidor y publican la información en sitios Web
de seguimiento de fallos y relacionados con la seguridad, tales como la lista de
correo Bugtraq (http://www.securityfocus.com) o el sitio del Equipo de
Respuesta ante Emergencias Informáticas CERT (http://www.cert.org).
Aunque estos mecanismos son una forma efectiva de alertar a la comunidad
acerca de las vulnerabilidades de seguridad, les corresponde a los
14 | INFORMACIÓN GENERAL SOBRE SEGURIDAD
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

administradores de sistemas parchar sus sistemas rápidamente, porque los

crackers tienen acceso a estos mismos servicios de seguimiento de la
vulnerabilidad y usarán la información para violar sistemas no actualizados cada
vez que pueden. Una buena administración de sistemas requiere vigilancia,
seguimiento constante de errores y el mantenimiento adecuado del sistema para
asegurar un entorno informático más seguro.

1.3.3.3 Administración desatendida

Los administradores que no pueden parchar o arreglar sus sistemas son una de las
mayores amenazas para la seguridad de un servidor. Según el SANS (SysAdmin,
Audit, Network, Security Institute), la principal causa de vulnerabilidad de la
seguridad informática es "asignar personas no capacitadas para mantener la
seguridad y no proporcionar ni el entrenamiento ni el tiempo necesarios para que
sea posible hacer su trabajo". Esto se aplica tanto a los administradores sin
experiencia como a los administradores muy confiados.

Algunos administradores fallan al tratar de parchar o arreglar sus servidores y

estaciones de trabajo, mientras que otros no pueden ver los mensajes de registro
del kernel del sistema o el tráfico de red. Otro error común es cuando las
contraseñas o llaves para acceder a un servicio se mantienen sin cambio alguno.
Por ejemplo, algunas bases de datos tienen contraseñas administrativas por
defecto porque los desarrolladores asumen que el administrador del sistema
cambia estas contraseñas inmediatamente después de la instalación. Si un
administrador de base de datos no cambia la contraseña, incluso un cracker sin
experiencia puede utilizar una contraseña conocida para ganar privilegios de
administrador en la base de datos. Estos son sólo algunos ejemplos de cómo la
administración desatenta puede llevar a comprometer un servidor.

1.3.3.4 Servicios inherentemente inseguros

Incluso la organización más atenta y vigilante puede ser víctima de una
vulnerabilidad si los servicios de red que elijan son inherentemente inseguros. Por
ejemplo, hay muchos servicios desarrollados bajo el supuesto de que se utilicen a
través de redes de confianza, sin embargo, este supuesto falla en cuanto el
servicio esté disponible a través de Internet, que en sí misma es insegura.

Una categoría de servicios de red inseguros son aquellos que requieren los
nombres de usuario y contraseñas sin cifrar. Telnet y FTP son dos de estos
servicios. Si algún software de sniffing de paquetes está monitoreando el tráfico
entre el usuario remoto y tal servicio, los nombres de usuario y contraseñas
pueden ser fácilmente interceptados.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 15

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Inherentemente, estos servicios también pueden ser presa fácil de lo que en

términos de seguridad se conoce como el ataque man-in-the-middle. En este tipo
de ataque, un cracker redirige el tráfico de la red engañando a un servidor de
nombres comprometido en la red para apuntar a su máquina en lugar del servidor
destino. Una vez que alguien abre una sesión remota con el servidor, la máquina
del atacante actúa como un conducto invisible, sentado en silencio entre el
servicio remoto y el usuario desprevenido, capturando la información. De esta
manera, un cracker puede reunir contraseñas administrativas y datos sin que el
servidor o el usuario se den cuenta.

Otra categoría de servicios inseguros incluyen los sistemas de archivos de red y

servicios de información tales como NFS o NIS, que son desarrollados
específicamente para usuarios de una LAN pero, por desgracia, son usados para
incluir usuarios remotos a través de conexiones WAN.

Por defecto, CentOS Linux se instala con todos estos servicios desactivados. Sin
embargo, dado que los administradores a menudo se ven obligados a utilizar
estos servicios, una configuración cuidadosa es crítica.

1.4 Ataques y agresiones comunes

La siguiente tabla muestra algunos de los ataques más comunes y puntos de
acceso utilizados por intrusos para acceder a los recursos de red de una
organización:

Exploit Descripción Notas

Contraseñas en Dejar las contraseñas administrativas Comúnmente asociado con
blanco o por en blanco o utilizar una contraseña por hardware de red, tales como
defecto defecto fijada por el fabricante del routers, firewalls, VPNs y
producto. Esto es más común en aparatos de almacenamiento
hardware como routers y firewalls, conectado a red (NAS).
aunque algunos de los servicios que se
ejecutan en Linux pueden contener Común en muchos sistemas
contraseñas administrativas por operativos que traen los
defecto (aunque CentOS Linux no se servicios en paquete (como
distribuye con ellos). UNIX y Windows).

Los administradores a veces

crean cuentas de usuarios
privilegiados en un apuro y
dejan la contraseña, creando un
punto de entrada perfecto para
usuarios malintencionados que
descubren la cuenta.
IP Spoofing Una máquina remota actúa como un Spoofing es bastante difícil, ya
nodo en la red local, encuentra que implica que el atacante
vulnerabilidades en sus servidores e prediga los números de

16 | INFORMACIÓN GENERAL SOBRE SEGURIDAD

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

instala un programa de puerta trasera o secuencia de TCP/IP para

caballo de troya para ganar control coordinar una conexión a los
sobre sus recursos de red. sistemas de destino, pero hay
varias herramientas disponibles
para ayudar a los cracker en la
realización de tal vulnerabilidad.

Depende de los servicios que se

estén ejecutando en el sistema
destino (por ejemplo, rsh,
Telnet, FTP y otros) que utilizan
técnicas de autenticación que no
son recomendadas en
comparación con otras formas
de autenticación encriptada
usadas en SSH o SSL/TLS.
Espionaje Es la recopilación de datos que pasan Este tipo de ataque funciona
entre dos nodos activos en una red, principalmente con protocolos
espiando en la conexión entre los dos de transmisión en texto simple,
nodos. tales como Telnet, FTP y
transferencias HTTP.

El atacante remoto debe tener

acceso a un sistema
comprometido en una LAN para
poder realizar este tipo de
ataque, por lo general el
atacante usó un ataque activo
(tal como IP spoofing o man-in-
the-middle) para comprometer
un sistema en la LAN.

Las medidas preventivas

incluyen servicios con
intercambio criptográfico de
clave, contraseñas de un solo
uso, o autenticación encriptada
para impedir la obtención de la
contraseña, también se aconseja
usar encriptación durante la
transmisión de datos.
Vulnerabilidades Un atacante encuentra una falla o Servicios basados en HTTP tales
de servicio hueco en un servicio que se ejecuta como CGI, son vulnerables a la
sobre Internet, a través de esta ejecución remota de comandos
vulnerabilidad, el atacante pone en e incluso al acceso a un shell
peligro todo el sistema y todos los interactivo. Inclusive si el
datos que pueda mantener, y podría servicio HTTP se ejecuta como
comprometer otros sistemas en la red. un usuario sin privilegios, tales
como nobody, la información
como los archivos de
configuración y los recursos de
INFORMACIÓN GENERAL SOBRE SEGURIDAD| 17
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

la red se pueden leer, o el

atacante puede comenzar un
ataque de denegación de
servicio que consume los
recursos del sistema o los hace
disponibles para otros usuarios.

Los servicios a veces pueden

tener vulnerabilidades que
pasan desapercibidas durante su
periodo de desarrollo y pruebas;
estas vulnerabilidades (como
buffer overflows, donde los
atacantes matan un servicio
utilizando valores arbitrarios
que llenan el buffer de memoria
de una aplicación) pueden dar
un control completo a un
atacante.

Los administradores deben

asegurarse de que los servicios
no se ejecuten como el usuario
root, y deben vigilar los parches
y actualizaciones de los
fabricantes u organizaciones
como CERT.
Vulnerabilidades Los atacantes encuentran fallas en las Las estaciones de trabajo y
de aplicación aplicaciones de escritorio y estaciones escritorio son más propensas a
de trabajo (por ejemplo, clientes de la explotación, ya que los
correo electrónico) y ejecutan código usuarios no tienen los
arbitrario, implantan troyanos o dañan conocimientos o la experiencia
sistemas. Pueden ocurrir otros tipos de necesaria para evitar o detectar
agresiones si la estación de trabajo anomalías. Es imprescindible
vulnerada posee privilegios de informar a las personas de los
administrador en el resto de la red. riesgos que corren al instalar
software no autorizado o abrir
adjuntos de mensajes de correo
electrónico no solicitados.

Varios programas pueden

implementarse, de tal manera
que el software de cliente de
correo electrónico no abra o
ejecute automáticamente
archivos adjuntos.
Ataques de Un atacante o grupo de atacantes se El caso DoS más informado en
denegación de coordinan en contra de los recursos de los EE.UU. se produjo en el año
servicio (DoS) red o servidores de una organización 2000. Varios sitios de tipo
mediante el envío de paquetes no comercial y gubernamental de
autorizados al host destino (servidor, alto tráfico quedaron
router o estación de trabajo). Esto incapacitados por un ataque
18 | INFORMACIÓN GENERAL SOBRE SEGURIDAD
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

obliga a que el recurso deje de estar coordinado de inundación de

disponible para los usuarios legítimos. ping (ping flood) utilizando
varios sistemas comprometidos
con conexiones de banda ancha
que actúan como zombies.

Los paquetes de origen son

falsificados (así como
reenviados), haciendo difícil la
investigación en cuanto al
verdadero origen del ataque.

Los avances en la penetración

de filtrado (IETF rfc2267) con
software como Iptables y
sistemas de detección de
intrusos como Snort ayudan a
los administradores a rastrear y
prevenir ataques de denegación
de servicio distribuidos.

1.5 Actualizaciones de seguridad

A medida que se descubren vulnerabilidades de seguridad, el software afectado
debe actualizarse a fin de limitar los riesgos de seguridad potenciales. Por
ejemplo, si el software es parte de un paquete dentro de una distribución Red Hat
Enterprise Linux soportada actualmente, Red Hat se compromete a producir los
paquetes actualizados que corrigen la vulnerabilidad tan pronto como sea posible.

Al actualizar el software en un sistema, es importante descargar la actualización

desde una fuente confiable. Un intruso puede fácilmente reconstruir un paquete
con el mismo número de versión que la que se supone sirve para solucionar el
problema y distribuirlo a través de Internet. Por lo tanto, es muy importante que
solamente descargue RPMs desde fuentes confiables y verificar la firma del
paquete para comprobar su integridad.

INFORMACIÓN GENERAL SOBRE SEGURIDAD| 19

 Capítulo 2
[ASEGURAR SU SISTEMA
LINUX]

CONTENIDO
2.1 Evaluar la seguridad del sistema
2.2 Seguridad del BIOS
2.3 Seguridad del gestor de arranque
2.4 Banners de advertencia
2.5 Seguridad en las contraseñas
2.6 Control de la cuenta root
2.7 Servicios de red existentes
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

2.1 Evaluar la seguridad del sistema

Al evaluar la seguridad de un sistema Linux, tenga en cuenta lo siguiente:

• BIOS y del gestor de arranque. ¿Puede un usuario no autorizado acceder

físicamente a la máquina y arrancar en modo monousuario o de rescate
sin una contraseña?
• Seguridad de la contraseña. ¿Qué tan seguras son las contraseñas de
cuenta de usuario en la máquina?
• Controles administrativos. ¿Quién tiene una cuenta en el sistema y cuánto
control administrativo tienen?
• Servicios de red disponibles. ¿Qué servicios están escuchando peticiones
de la red y todos ellos deberían estar ejecutándose?
• Firewalls. ¿Qué tipo de firewall, de ser el caso, es necesario?
• Seguridad mejorada de las herramientas de comunicación. ¿Qué
herramientas se deben utilizar para la comunicación entre hosts y cuáles
se deben evitar?

2.2 Seguridad en el BIOS

El BIOS (Basic Input/Output System) es el nivel más bajo de software que
configura o manipula su hardware. El gestor de arranque GRUB accede al BIOS
para determinar cómo arrancar su equipo Linux. Puede utilizar el BIOS para evitar
que los atacantes puedan reiniciar su equipo y manipular su sistema Linux.

Muchos BIOS de PC permiten establecer una contraseña de arranque. Esto no

proporciona mucha seguridad (el BIOS se puede resetear o incluso ser removido si
alguien pudiera conseguir acceso físico), pero puede ser un antídoto eficaz (es
decir, que tomará tiempo y deja huellas de manipulación).

Otro de los riesgos de confiar en las contraseñas de BIOS para garantizar su

sistema es el problema de la contraseña por defecto. La mayoría de fabricantes de
BIOS no espera que la gente abra su equipo y desconecte las baterías si se les
olvida su contraseña y equiparon a sus BIOS con contraseñas por defecto.

Muchos BIOS también permiten especificar otras buenas configuraciones de

seguridad. Revise su manual de BIOS o revíselo la próxima vez que arranque su
equipo.

Nota: Si usted tiene una máquina como servidor, y configura una contraseña de
arranque en el BIOS, el equipo no se iniciará sin atención. Tenga en cuenta que
tendrá que ir y proveer la contraseña en caso de una falla eléctrica, por ejemplo.

ASEGURAR SU SISTEMA LINUX| 21

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

2.3 Seguridad del gestor de arranque

Las razones principales para la protección por contraseña para un gestor de
arranque en Linux son las siguientes:

• Evitar el acceso a modo monousuario. Si los atacantes pueden arrancar el

sistema en modo monousuario, ingresarán automáticamente como root
sin que se le pida la contraseña de root.
• Evitar el acceso a la consola de GRUB. Si la máquina utiliza GRUB como su
gestor de arranque, un atacante puede utilizar la interfaz del editor de
GRUB para cambiar su configuración.
• Evitar el acceso a sistemas operativos inseguros. Si se trata de un sistema
de arranque dual, un atacante puede seleccionar un sistema operativo
durante el arranque (por ejemplo, DOS), que hace caso omiso de los
controles de acceso y permisos de archivos.

CentOS Linux incluye el gestor de arranque GRUB (GRand Unified Bootloader).

2.4 Banners de advertencia

Cada sistema debe exponer la menor información sobre sí mismo como sea
posible. Los banners del sistema, que se muestran por lo general justo antes de un
indicador de inicio de sesión (login prompt), dan información sobre el servicio o el
sistema operativo del anfitrión. Esto podría incluir el nombre de la distribución y
la versión del kernel del sistema, y la versión en particular de un servicio de red.
Esta información puede ayudar a los intrusos en la obtención de acceso al
sistema, ya que puede revelar si el sistema está ejecutando algún software
vulnerable. La mayoría de los servicios de red pueden ser configurados para
limitar la información que se muestra.

Muchas organizaciones implementan políticas de seguridad que requieren de un

banner del sistema para dar un aviso acerca de la propiedad del sistema,
proporcionar una advertencia a los usuarios no autorizados, y recordar a los
usuarios autorizados de su consentimiento a ser supervisados.

2.4.1 Configurar un banner de inicio de sesión del sistema

El contenido del archivo /etc/issue es mostrado en la pantalla justo antes del
indicador de inicio de sesión para los usuarios que ingresan directo desde la
terminal. Programas de acceso remoto como SSH o FTP también pueden ser
configurados para mostrar el contenido de /etc/issue.

22 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Por defecto, el sistema mostrará la versión del sistema operativo, la versión del
kernel y el nombre del sistema o hostname.

El archivo /etc/issue es un archivo de texto plano que también acepta ciertas

secuencias de escape para insertar información acerca del sistema. También
existe el archivo /etc/issue.net que puede ser utilizado cuando se inicia
sesión de manera remota.

En CentOS Linux, el contenido del archivo /etc/issue es el siguiente:

CentOS release 6.3 (Final)

Kernel \r on an \m

Usted puede configurar este archivo como crea conveniente, tratando en lo

posible de mostrar la menor cantidad de información posible.

A continuación se detalla un listado de las posibles secuencias de escape que

pueden ser utilizadas en el archivo /etc/issue:

Secuencia de escape Descripción

Introduce la velocidad de transmisión (baudrate) de la línea
\b
actual
\d Introduce la fecha actual
\s Introduce el nombre del sistema operativo
\l Introduce el nombre de la línea tty actual
Introduce el identificador de la arquitectura de la máquina, por
\m
ejemplo: i686, x86_64, etc.
\n Introduce el nombre de la máquina o hostname
\o Introduce el nombre de dominio de la máquina
\r Introduce la versión del kernel, por ejemplo: 2.6.11.12
\t Introduce la hora actual
\u Introduce el nombre de usuarios conectados actualmente
Introduce la versión del sistema operativo, por ejemplo: la
\v
fecha de creación, etc.

2.4.2 Configurar un mensaje del día (motd)

El contenido del archivo /etc/motd es mostrado en la pantalla después de que
un usuario inicia sesión exitosamente en el sistema. Este banner es conocido
como mensaje del día (message of the day), y generalmente es usado para enviar
un mensaje común a todos los usuarios del sistema. Este archivo está compuesto
de texto simple y por defecto está vacío.

ASEGURAR SU SISTEMA LINUX| 23

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

2.5 Seguridad en las contraseñas

Las contraseñas son el método principal que Linux utiliza para verificar la
identidad de un usuario. Esta es la razón por la cual la seguridad en las
contraseñas es tan importante para la protección del usuario, sus equipos, y la
red.

Por motivos de seguridad, el programa de instalación de CentOS Linux configura el

sistema para que utilice el algoritmo de encriptación SHA512 (Secure Hash
Algorithm 512) y contraseñas ocultas. Es altamente recomendable que no se
alteren estos valores.

Por defecto, los usuarios se almacenan en el archivo /etc/passwd y las

contraseñas en un archivo aparte /etc/shadow, el cual es legible solo por el
usuario root.

Esto obliga a un potencial atacante intentar descifrar contraseñas de forma

remota, mediante el acceso a un servicio de red en la máquina, tales como SSH o
FTP. Este tipo de ataque por fuerza bruta es mucho más lento y deja un rastro
evidente a medida de que existen intentos de conexión fallidos y que se escriben
en los archivos del sistema. Por supuesto, si el cracker comienza un ataque en
medio de la noche en un sistema con contraseñas débiles, quizás puede haber
tenido acceso antes del amanecer y editar los archivos de registro para cubrir sus
huellas.

Además del formato y de las consideraciones de almacenamiento es la cuestión

de contenido. Lo más importante que un usuario puede hacer para proteger su
cuenta contra un ataque de robo de contraseñas es crear una contraseña segura.

2.5.1 Crear contraseñas seguras

Al crear contraseñas seguras, sería bueno tener en cuenta lo siguiente:

• No utilice solamente palabras o números. Nunca usar solamente números

o palabras en una contraseña. Son ejemplos inseguros:
o 8675309
o juan
o hackme
• No utilice palabras obvias. Por ejemplo, nombres propios, palabras de
diccionario, o incluso términos de televisión, etc. Son ejemplos inseguros:
o pedro1
o pass123
o r2d2

24 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

• No utilice palabras en idiomas extranjeros. Los programas que descifran

contraseñas a menudo comprueban con listas de palabras que abarcan
diccionarios de muchos idiomas. Basarse en lenguas extranjeras para las
contraseñas seguras no es seguro. Algunos ejemplos inseguros incluyen
los siguientes:
o welcome1
o 1dumbKopf
o passe789
• No utilice terminología de hackers. Si piensa que pertenece a una élite
porque utiliza terminología hacker -también llamado L337 (LEET)- en su
contraseña, piénselo de nuevo. Muchas listas de palabras incluyen
lenguaje LEET. Algunos ejemplos inseguros incluyen los siguiente:
o H4X0R
o 1337
o B1ff
• No use información personal. Evite usar cualquier tipo de información
personal en sus contraseñas. Si el atacante conoce su identidad, entonces
el trabajo de deducir su contraseña será más fácil. Algunos ejemplos
inseguros incluyen:
o Su nombre
o El nombre de mascotas
o El nombre de familiares
o Cualquier fecha de nacimiento
o Su número telefónico o código postal
• No escriba su contraseña. Nunca guarde su contraseña en un papel. Es
mucho más seguro memorizarla.
• No utilice la misma contraseña para todos sus equipos. Es importante
hacer contraseñas separadas para cada equipo. De esta manera, si un
sistema está comprometido, todos sus equipos no están en riesgo
inmediato.

Las siguientes pautas le ayudarán a crear una contraseña segura:

• Crear una contraseña de al menos ocho caracteres. Mientras más larga la

contraseña mejor.
• Mezcle letras mayúsculas y minúsculas. Linux es sensible a mayúsculas y
minúsculas, por lo que al mezclarlas puede aumentar la seguridad de su
contraseña.
• Mezcle letras y números. Agregar números a las contraseñas,
especialmente cuando se añaden en la mitad (y no sólo al principio o al
final), puede mejorar la seguridad de la contraseña.
• Incluir caracteres no alfanuméricos. Los caracteres especiales como &, $,
etc. Pueden mejorar considerablemente la fuerza de su contraseña.
• Elija una contraseña que pueda recordar. La mejor contraseña del mundo
poco sirve sino la recuerda.

ASEGURAR SU SISTEMA LINUX| 25

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

2.5.2 Crear contraseñas dentro de una organización

Si una organización tiene un gran número de usuarios, los administradores de
sistemas tienen dos opciones básicas disponibles para forzar el uso de buenas
contraseñas. Pueden crear las contraseñas para el usuario, o pueden permitir a los
usuarios crear sus propias contraseñas, verificando que las contraseñas sean de
calidad aceptable.

La creación de las contraseñas de los usuarios asegura que las contraseñas son
buenas, pero se convierte en una tarea de enormes proporciones si la
organización crece. También aumenta el riesgo de que los usuarios escriban sus
contraseñas en papel.

Por estas razones, la mayoría de los administradores de sistemas prefieren que los
usuarios creen sus propias contraseñas, pero verificando activamente que las
contraseñas sean buenas y, en algunos casos, obligar a los usuarios a cambiar sus
contraseñas periódicamente a través de periodos de vigencia para dichas
contraseñas.

2.5.3 Forzar contraseñas seguras

Para proteger la red de intrusos, es una buena idea para los administradores de
sistemas verificar que las contraseñas utilizadas dentro de una organización son lo
suficientemente fuertes. Cuando a los usuarios se les pide crear o cambiar sus
contraseñas, pueden usar el comando passwd, el cual se valida contra PAM
(Pluggable Authentication Manager) para verificar si la contraseña es demasiado
corta o fácil de descifrar. Esta comprobación se realiza utilizando el módulo
pam_cracklib.so.

La comprobación de la contraseña que se realiza en el momento de su creación no

descubre malas contraseñas tan eficazmente como lo sería ejecutar un programa
de descifrado de contraseñas o password cracking.

Muchos programas de descifrado de contraseñas están disponibles y se ejecutan

en Linux, aunque no se incluyen con el sistema operativo. Analizaremos la
herramienta John The Ripper.

Nota: Siempre obtenga una autorización por escrito antes de intentar descifrar las
contraseñas dentro de una organización.

26 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

2.5.3.1 John The Ripper

John The Ripper es un programa de descifrado de contraseñas rápido y flexible.
Permite el uso de múltiples listas de palabras y es capaz de generar ataques de
fuera bruta para obtener las contraseñas.

Está disponible en el sitio:

http://www.openwall.com/john

2.5.4 Caducidad de contraseñas

La caducidad de contraseñas es una técnica utilizada por los administradores de
sistemas para defenderse de malas contraseñas dentro de una organización.
Caducidad de una contraseña significa que después de un período determinado
(generalmente 90 días), se pide al usuario crear una nueva contraseña. La teoría
detrás de esto es que si un usuario se ve obligado a cambiar su contraseña
periódicamente, una contraseña comprometida sólo es útil para un intruso por
una cantidad limitada de tiempo. La desventaja de esta técnica, sin embargo, es
que los usuarios son más propensos a anotar sus contraseñas para poder
recordarlas.

Existen dos programas primarios usados para especificar la caducidad de

contraseñas en CentOS Linux: el comando chage o la aplicación gráfica de
Administración de Usuarios (system-config-users).

2.6 Control de la cuenta root

Si los usuarios dentro de una organización son de confianza y poseen
conocimientos informáticos, entonces permitirles acceso de root no sería un
problema. Permitir el acceso root a los usuarios significa que actividades menores,
como añadir dispositivos o configurar interfaces de red, pueden ser realizadas por
los mismos usuarios, dejando a los administradores de sistemas libres para
manejar la seguridad de la red y otros temas importantes.

Por otro lado, dar acceso root a usuarios individuales puede conducir a lo
siguiente:

• Mala configuración de la máquina. Los usuarios con acceso root pueden

desconfigurar sus máquinas y requerir asistencia para resolver los
problemas. Peor aún, podrían abrir agujeros de seguridad sin saberlo.

ASEGURAR SU SISTEMA LINUX| 27

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

• Ejecutar servicios inseguros. Los usuarios con acceso root puede ejecutar
servicios inseguros en sus máquinas, tales como FTP o Telnet, colocando
los nombres de usuario y contraseñas en riesgo potencial. Estos servicios
transmiten la información a través de la red en texto simple.
• Ejecutar adjuntos de correo electrónico como root. Aunque son raros, los
virus de correo electrónico que afectan a Linux existen. El único momento
en que son una amenaza, es cuando son ejecutados por el usuario root.

2.6.1 Deshabilitar el acceso como root

Si un administrador se siente incómodo permitiendo que los usuarios inicien
sesión como root, la contraseña de root debería mantenerse en secreto, y el
acceso al runlevel uno (monousuario o modo de rescate) debe ser deshabilitado
configurando una contraseña en el gestor de arranque.

En la siguiente tabla se describen las formas en que un administrador puede

asegurarse de que las conexiones como root no están permitidas:

Método Descripción
Cambiar el shell de root Edite el archivo /etc/passwd y cambie el
shell de /bin/bash a /sbin/nologin.

Esto previene acceso a la cuenta root desde

comandos que requieren un shell, como su y
ssh
Deshabilitar el acceso de root mediante Un archivo /etc/securetty vacío
cualquier dispositivo de consola (tty) previene acceso de root desde cualquier
dispositivo conectado al equipo. Este archivo
lista todos los dispositivos desde los cuales el
usuario root puede iniciar sesión.

Si este archivo no existe en absoluto, el

usuario root puede conectarse a través de
cualquier dispositivo de comunicación en el
sistema, ya sea a través de la consola o una
interfaz de red. Esto es peligroso, porque un
usuario puede conectarse a este equipo como
root vía Telnet, que transmite las contraseñas
en texto plano a través de la red.

En CentOS Linux, por defecto este archivo

solo permite el inicio de sesión de root desde
una consola conectada directamente al
sistema.
Deshabilitar el inicio de sesión de root en Edite el archivo /etc/ssh/sshd_config
SSH y configure la directiva PermitRootLogin
con el valor No

28 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Utilice PAM para limitar el acceso de root Edite los archivos correspondientes a los
servicios en el directorio /etc/pam.d

2.6.2 El comando su
Cuando un usuario ejecuta el comando su, se le solicita la contraseña de root y,
después de la autenticación, se le da un intérprete de comandos o shell de root.

Una vez conectado con el comando su, el usuario ahora es el usuario root y tiene
acceso administrativo absoluto al sistema. Además, una vez que un usuario se ha
convertido en root, es posible que utilice el comando su para cambiarse a
cualquier otro usuario en el sistema sin que se le pida una contraseña.

Debido a que este programa es tan poderoso, los administradores dentro de una
organización podrían desear limitar quién tiene acceso al comando. Una de las
formas más sencillas de hacer esto es añadir usuarios al grupo administrativo
especial llamado wheel. El usuario root es parte del grupo wheel por defecto.

2.6.3 Verificación del UID 0 en el archivo /etc/passwd

En general, la mejor solución práctica para auditar el uso de la cuenta de root es
restringir quien debe tener acceso al uso de los comandos su o sudo. Algunos
administradores escogen tener creada más de una cuenta en el sistema con UID 0
con el fin de diferenciar entre los administradores, pero esta práctica puede tener
efectos secundarios inesperados, y por lo tanto no es recomendado.

El siguiente comando le mostrará todas las cuentas de usuario con UID 0 en el

sistema:

~]# awk -F: '($3 == "0") {print}' /etc/passwd

root:x:0:0:root:/root:/bin/bash

Esto debería mostrar una sola línea, para el usuario root. Si alguna otra línea
aparece, asegúrese de que estas otras cuentas con UID 0 son autorizadas, y si hay
alguna buena razón por las que existen; caso contrario, pudiera ser que su sistema
esté comprometido y que un intruso esté haciendo uso de esta cuenta con UID 0
para acceder a su sistema sin que usted lo sepa.

ASEGURAR SU SISTEMA LINUX| 29

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

2.7 Servicios de red existentes

Si bien controlar el acceso del usuario root y el establecimiento de políticas para
contraseñas son temas importantes para los administradores de sistemas dentro
de una organización, el seguimiento de los servicios de red que están activos y
ejecutándose es de suma importancia para cualquier persona que administra y
opera un sistema Linux.

Muchos servicios en Linux son servicios de red. Si un servicio de red se ejecuta en

un equipo, una aplicación de servidor (llamada daemon o demonio), está
escuchando por conexiones en uno o más puertos de red. Cada uno de estos
servicios debería ser tratado como una potencial vía de ataque.

2.7.1 Riesgos de los servicios

Los servicios de red pueden implicar muchos riesgos para los sistemas Linux. A
continuación se muestra una lista de algunos de los principales problemas:

• Ataques de Denegación de Servicio (DoS). A través de la inundación de un

servicio con peticiones, un ataque de denegación de servicio puede
inutilizar un sistema, ya que el servidor trata de registrar y responder a
cada petición recibida.
• Ataque de Denegación de Servicio Distribuido (DDoS). Un tipo de ataque
DoS que utiliza varias máquinas comprometidas (a menudo en el orden de
los miles o más) para dirigir un ataque coordinado a un servicio,
inundándolo con peticiones y volviéndolo inutilizable.
• Ataques de vulnerabilidad de scripts. Si un servidor está usando scripts
para ejecutar acciones del lado del servidor, como normalmente lo hacen
los servidores Web, un cracker puede atacar scripts escritos
incorrectamente. Estos ataques de vulnerabilidad de script pueden
conducir a un desbordamiento de búfer y permitir al atacante alterar
archivos en el sistema.
• Ataques de desbordamiento de buffer. Los servicios que se conectan a los
puertos del 0 al 1023 deben ejecutarse como un usuario administrativo. Si
la aplicación tiene un desbordamiento de búfer explotable, un atacante
podría obtener acceso al sistema a través del usuario que ejecuta el
demonio de dicha aplicación. Debido a que existen estos
desbordamientos explotables, los crackers utilizan herramientas
automatizadas para identificar sistemas con vulnerabilidades, y una vez
que han obtenido acceso, usan rootkits automatizados para mantener su
acceso al sistema. Un rootkit es un tipo sigiloso de software, a menudo
malicioso, diseñado para ocultar la existencia de ciertos procesos o
programas de los métodos normales de detección y permitir un acceso
privilegiado continuo en un equipo o sistema.

30 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

2.7.2 Servicios inseguros

Potencialmente, cualquier servicio de red es inseguro. Para limitar la exposición a
posibles ataques de red, todos los servicios no utilizados deben estar apagados.
Exploits, bugs o posibles errores en los servicios son continuamente revelados y
parchados, por lo cual es muy importante actualizar regularmente los paquetes de
software asociados con cualquier servicio de red.

Algunos protocolos de red son inherentemente más inseguros que otros. Estos
incluyen cualquier servicio que:

• Transmita nombres de usuario y contraseñas sobre la red sin encriptar.

Muchos protocolos más antiguos, como Telnet y FTP, no encriptan la
sesión de autenticación y deben evitarse siempre que sea posible.
• Transmita datos confidenciales a través de una red sin encriptar. Muchos
protocolos transmiten datos a través de la red sin cifrar. Estos protocolos
incluyen Telnet, FTP, HTTP y SMTP. Muchos de los sistemas de archivos de
red, tales como NFS y SMB, también transmiten información a través de la
red sin cifrar. Es responsabilidad del usuario cuando se utilizan estos
protocolos limitar qué tipo de datos se transmite.

Una herramienta que permite verificar que servicios se están ejecutando en un

sistema es Nmap, la cual es muy utilizada para realizar evaluaciones de
vulnerabilidades.

2.7.3 Uso de la utilidad ntsysv

La utilidad ntsysv es una aplicación de línea de comandos con una interfaz de
usuario de texto simple que permite configurar qué servicios serán iniciados en
los runlevels seleccionados. Para iniciar la utilidad, como usuario root, escriba
ntsysv en una terminal de comandos y se mostrará una pantalla, así:

ASEGURAR SU SISTEMA LINUX| 31

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

La utilidad muestra el listado de los servicios disponibles (los servicios que están
en el directorio /etc/rc.d/init.d) a lado de su estado actual y una
descripción que se obtiene presionando la tecla F1. Si hay un asterisco a lado del
servicio significa que está habilitado para iniciarse, caso contrario está
deshabilitado.

2.7.3.1 Habilitar y deshabilitar un servicio

Para habilitar un servicio, use las teclas direccionales y selecciónelo con la barra
espaciadora. Un asterisco (*) aparece entre los corchetes.

Para deshabilitar un servicio, use las teclas direccionales y selecciónelo con la

barra espaciadora. El asterisco (*) desaparece de los corchetes.

Una vez que haya terminado, use la tecla Tab para navegar al botón Ok, y
confirmar los cambios presionando la tecla Enter. Tenga en cuenta que ntsysv
no inicia o detiene un servicio.

2.7.3.2 Seleccionar runlevels

Por defecto, la utilidad ntsysv solo afecta el runlevel actual. Para habilitar o
deshabilitar servicios para otros runlevels, como root, ejecute el comando con la
opción --level seguido de los números 0 al 6 que representan a cada runlevel.

Por ejemplo, para configurar los runlevels 3 y 5, ejecute el comando:

~]# ntsysv –-level 35

32 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

2.7.4 Uso de la utilidad chkconfig

La utilidad chkconfig es una herramienta de la línea de comandos que le
permite definir en qué runlevel se va a ejecutar un determinado servicio, así como
también listar todos los servicios conjuntamente con su configuración actual. Este
comando debe ser ejecutado como usuario root.

2.7.4.1 Listar los servicios

Para mostrar una lista de los servicios del sistema (los que están dentro del
directorio /etc/rc.d/init.d) escriba el comando chkconfig --list, o
utilice chkconfig sin ningún argumento. Se mostrará una pantalla como la
siguiente:

~]# chkconfig
NetworkManager 0:desactivado 1:desactivado 2:activo 3:activo
4:activo 5:activo 6:desactivado

auditd 0:desactivado 1:desactivado 2:activo 3:activo

4:activo 5:activo 6:desactivado

avahi-daemon 0:desactivado 1:desactivado 2:desactivado 3:activo

4:activo 5:activo 6:desactivado

bluetooth 0:desactivado 1:desactivado 2:desactivado 3:activo

4:activo 5:activo 6:desactivado

cgconfig 0:desactivado 1:desactivado 2:desactivado

3:desactivado 4:desactivado 5:desactivado 6:desactivado

cgred 0:desactivado 1:desactivado 2:desactivado

3:desactivado 4:desactivado 5:desactivado 6:desactivado

crond 0:desactivado 1:desactivado 2:activo 3:activo

4:activo 5:activo 6:desactivado

cups 0:desactivado 1:desactivado 2:activo 3:activo

4:activo 5:activo 6:desactivado

dhcpd 0:desactivado 1:desactivado 2:desactivado

3:desactivado 4:desactivado 5:desactivado 6:desactivado

Cada línea consiste del nombre del servicio seguido por su estado (activo o
desactivado) para cada uno de los siete runlevels.

Para mostrar el estado actual de un servicio determinado, use el siguiente

comando:

chkconfig --list [servicio]

Donde [servicio] es el nombre del servicio a conocer su estado.

ASEGURAR SU SISTEMA LINUX| 33

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Por ejemplo, para mostrar el estado actual del servicio sshd, ejecute:

~]# chkconfig --list sshd

sshd 0:desactivado 1:desactivado 2:activo 3:activo
4:activo 5:activo 6:desactivado

2.7.4.2 Habilitar un servicio

Para habilitar un servicio en los runlevels 2, 3, 4 y 5, ejecute el comando siguiente
como usuario root:

chkconfig [servicio] on

Donde [servicio] es el nombre del servicio a habilitar en los runlevels

mencionados.

Por ejemplo, para habilitar el servicio httpd, ejecute:

~]# chkconfig httpd on

Para habilitar un servicio en determinados runlevels solamente, agregue la opción

--level seguido de los números 0 al 6 que representan a cada runlevel en que
quiere iniciar un servicio:

chkconfig [servicio] on --level [runlevels]

Donde [servicio] es el nombre del servicio a habilitar en los [runlevels]

seleccionados.

Por ejemplo, para habilitar el servicio vsftpd en los runlevels 3 y 5, ejecute:

~]# chkconfig vsftpd on --level 35

2.7.4.3 Deshabilitar un servicio

Para deshabilitar un servicio en los runlevels 2, 3, 4 y 5, ejecute el comando
siguiente como usuario root:

chkconfig [servicio] off

Donde [servicio] es el nombre del servicio a habilitar en los runlevels

mencionados.

Por ejemplo, para deshabilitar el servicio httpd, ejecute:

~]# chkconfig httpd off

34 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Para deshabilitar un servicio en determinados runlevels solamente, agregue la

opción --level seguido de los números 0 al 6 que representan a cada runlevel
en que no quiere iniciar un servicio:

chkconfig [servicio] off --level [runlevels]

Donde [servicio] es el nombre del servicio a deshabilitar en los

[runlevels] seleccionados.

Por ejemplo, para deshabilitar el servicio vsftpd en los runlevels 3 y 5, ejecute:

~]# chkconfig vsftpd off --level 35

ASEGURAR SU SISTEMA LINUX| 35

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 1
Protección de GRUB con contraseña
1. Piense en una contraseña segura a configurar en el gestor de arranque GRUB. Para
este laboratorio, la contraseña a configurar será palosanto. Ejecute el siguiente
comando en la consola:

~]# grub-md5-crypt
Password:
Retype password:
$1$d3Vel/$CHUr5/baO2v.y7QW4HBTu1

Cuando se lo solicite, ingrese la contraseña para GRUB y presione Enter. Esto devuelve
un hash MD5 de la contraseña.

2. A continuación, edite el archivo /boot/grub/grub.conf, ubíquese en la línea

timeout y justo debajo de ella agregue la siguiente línea:

password –-md5 <password-hash>

Donde <password-hash> es el valor obtenido en el punto anterior de este

laboratorio.

La próxima vez que se arranque el sistema, el menú de GRUB impide el acceso al editor
o interfaz de comandos sin la contraseña indicada.

3. Reinicie su equipo y verifique la aplicación correcta de la clave de GRUB.

36 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 2
Configuración de banners de advertencia y mensajes del día
1. Vamos a configurar un banner de advertencia que se mostrará antes de que el usuario
inicie sesión. En la medida de lo posible hay que tratar de no utilizar información
referente al sistema o kernel que se está ejecutando. Con su editor de texto preferido,
abra el archivo /etc/issue e ingrese un texto como el siguiente (usted está en la
libertad de configurar lo que sea más conveniente para sus necesidades):

ALERT! You are entering into a secured area! Your IP, login time and
username has been noted and has been sent to the server administrator!
This service is restricted to authorized users only. All activities on
this system are logged. Unauthorized access will be fully investigated
and reported to the appropriate law enforcement agencies.

Este mensaje solo se mostrará al acceder a través de una consola conectada

directamente al sistema. Para que sea visible al acceder remotamente, copie el
contenido en el archivo /etc/issue.net

2. Para configurar un mensaje del día y que se mostrará justo después de que un usuario
inicie sesión en el sistema, con su editor de texto preferido, abra el archivo
/etc/motd e ingrese un texto como el siguiente (usted está en la libertad de
configurar lo que sea más conveniente a sus necesidades):

Welcome to srv1.example.com
All connections are monitored and recorded
Disconnect IMMEDIATELY if you are not an authorized user!

3. Una vez creados los banners, ingrese a otra consola del sistema (ALT + CTRL + F2, por
ejemplo). Debería ver el banner de advertencia. Luego inicie sesión con un usuario
válido y debería ver el banner de mensaje del día.

ASEGURAR SU SISTEMA LINUX| 37

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 3
Verificación de contraseñas seguras con John The Ripper
1. Instalar el paquete de software llamado john (el cual será provisto por el instructor)
con el comando:

~]# rpm –ivh john-1.7.9-1.el6.rf.x86_64.rpm

2. Con nuestro editor de texto preferido, abrimos el archivo de configuración principal de

John The Ripper ubicado en /etc/john.conf y nos ubicamos al final del archivo en
la línea que se muestra a continuación:

.include <dynamic.conf>

Comentamos la línea, la cual no tomará efecto y debería quedar de la siguiente

manera:

#.include <dynamic.conf>

El archivo de configuración de la instalación de John The Ripper que hemos realizado

con el paquete RPM dado en el punto anterior, incluye la posibilidad de agregar scripts
de código dinámico ubicados en archivos externos, lo que mejora la funcionalidad de
John, de ahí que la línea anterior existe en el archivo de configuración. En nuestro caso
no utilizaremos dicha característica, de ahí que se comenta esta línea. En otras
instalaciones de John The Ripper puede no ser necesario ejecutar este paso.

3. Procedemos a crear un usuario local en el sistema y asignarle una contraseña, por

ejemplo el usuario juan con una contraseña 12345. Ejecutamos los comandos:

~]# useradd juan

~]# passwd juan

4. Ahora, vamos a unir el contenido de los ficheros /etc/passwd y /etc/shadow en

un solo archivo de texto a manera de que John The Ripper pueda deducir las
contraseñas. Ejecutamos lo siguiente:

~]# unshadow /etc/passwd /etc/shadow > passwords.txt

Donde passwords.txt es un archivo de texto que contiene la información conjunta

de ambos archivos para ser analizado por el software John The Ripper.

5. Ahora vamos a dejar que John The Ripper haga su trabajo, para esto ejecutamos lo
siguiente:

~]# john passwords.txt

Mientras más usuarios existan, más tiempo le tomará a John hacer su trabajo. La
ejecución de este proceso podría tomar algún tiempo.

38 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Mientras John se ejecuta, la salida en pantalla sería algo similar a esto:

~]# john passwords.txt

Loaded 5 password hashes with 5 different salts (generic crypt(3)
[?/32])
12345 (juan)
guesses: 1 time: 0:00:03:41 0.46% (2) (ETA: Thu May 2 20:14:46 2013)
c/s: 47.18 trying: meggie - seattle
guesses: 1 time: 0:00:14:08 6.44% (2) (ETA: Thu May 2 10:33:30 2013)
c/s: 49.99 trying: janines - ducks
guesses: 1 time: 0:00:14:49 6.70% (2) (ETA: Thu May 2 10:35:11 2013)
c/s: 50.06 trying: effies – lotuses
...

Se puede presionar cualquier tecla en cualquier momento para ver el estado de la

ejecución de John The Ripper.

6. Finalmente, para ver el resultado de las contraseñas encontradas por John,

ejecutamos:

~]# john --show passwords.txt

juan:12345:505:505::/home/juan:/bin/bash
1 password hash cracked

De esta manera podremos ver si las contraseñas creadas son débiles y fáciles de
deducir.

Nota: Es muy recomendable que obtenga una lista de palabras más larga que el
archivo por defecto de John, en nuestro caso, ubicado en la ruta
/usr/share/john/password.lst. Edite la directiva Wordlist en el archivo
de configuración de John antes de ejecutarlo.

Algunas listas de palabras pueden ser encontradas en el sitio:

http://www.openwall.com/wordlists/

ASEGURAR SU SISTEMA LINUX| 39

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 4
Configuración de caducidad de contraseñas
1. Cree el usuario test1 y asígnele una contraseña, así:

~]# useradd test1

~]# passwd test1

2. Ejecute el comando chage para modificar en forma interactiva varios detalles de la

cuenta y la caducidad de la contraseña. Así:

~]# chage test1

Changing the aging information for test1
Enter the new value, or press ENTER for the default

Minimum Password Age [0]: 10

Maximum Password Age [99999]: 90
Last Password Change (YYYY-MM-DD) [2013-05-02]:
Password Expiration Warning [7]:
Password Inactive [-1]:
Account Expiration Date (YYYY-MM-DD) [1969-12-31]: 2013-06-02

Donde:

• Minimum Password Age. Es el mínimo número de días entre cambios de

contraseña. El valor 0 indica que el usuario puede cambiar su contraseña en
cualquier momento. En este laboratorio, se ha configurado un valor de 10 lo
que significa que luego de 10 días el usuario podrá cambiar su contraseña.
• Maximum Password Age. Es el máximo número de días durante los cuales
una contraseña es válida. En este laboratorio, se ha configurado un valor de 90
lo que indica que la contraseña durará 90 días, luego de esto el usuario deberá
cambiar su contraseña para poder utilizar su cuenta.
• Last Password Change. Es el día cuando la contraseña fue cambiada por
última vez, usado para empezar el control de los días en el valor definido en la
directiva Minimum Password Age. En este laboratorio, se ha configurado
el valor de la fecha actual.
• Password Expiration Warning. Es el número de días antes del
vencimiento de la contraseña en que el usuario será advertido de que su
contraseña está a punto de expirar. En este laboratorio, el sistema nos
recomienda un valor de 7, el cual depende de la directiva Minimum
Password Age.
• Password Inactive. Se utiliza para establecer el número de días de
inactividad después de que una contraseña ha caducado antes de que la
cuenta sea bloqueada. Un valor de -1 desactiva esta función. Un usuario cuya
cuenta está bloqueado debe ponerse en contacto con el administrador del
sistema antes de ser capaz de iniciar sesión en el sistema nuevamente. En este
laboratorio, esta función está deshabilitada.

40 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

• Account Expiration Date. Se utiliza para configurar una fecha en la

cual la cuenta del usuario ya no estará disponible. Un usuario cuya cuenta está
bloqueada debe ponerse en contacto con el administrador del sistema antes
de ser capaz de iniciar sesión en el sistema nuevamente. En este laboratorio, la
cuenta caducará el 2 de Junio de 2013.

3. Un usuario por sí mismo no puede modificar estos valores, solo root puede hacerlo.
Para verificarlo, inicie sesión en otra consola (ALT + CTRL + F2, por ejemplo) e inicie
sesión con el usuario test1 y ejecute el comando chage para tratar de modificar sus
valores:

[test1@srv1 ~]$ chage test1

chage: Permission denied.

4. Finalmente, si el usuario test1 quisiera ver los valores de contraseña configurados

para su cuenta, puede ejecutar lo siguiente:

[test1@srv1 ~]$ chage --list test1

Last password change : May 02, 2013
Password expires : Jul 31, 2013
Password inactive : never
Account expires : Jun 02, 2013
Minimum number of days between password change : 10
Maximum number of days between password change : 90
Number of days of warning before password expires : 7

El usuario root puede ver los valores definidos para todos los usuarios del sistema.

ASEGURAR SU SISTEMA LINUX| 41

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 5
Limitar el acceso de root con el comando su y PAM
1. Crear los siguientes usuarios en el sistema y asignarles una contraseña:
• user1
• user2

2. Ahora, asignaremos solamente autorización al usuario user1 para que pueda

convertirse en root con la utilidad su. Para esto, ejecutamos el siguiente comando:

~]# usermod –G wheel user1

Para asignar al usuario user1 al grupo wheel, el cual es un grupo administrativo

especial que tiene privilegios de root.

3. A continuación, con su editor de texto preferido, abra el archivo /etc/pam.d/su,

ubíquese y quite el comentario (#) a la siguiente línea:

auth required pam_wheel.so use_uid

Este cambio hace que solo los miembros del grupo administrativo especial wheel
puedan hacer uso del comando su.

4. Ahora, inicie sesión en una consola aparte (ALT + CTRL + F2, por ejemplo) con el
usuario user1, ejecute el comando su e ingrese la contraseña de root, así:

[user1@srv1 ~]$ su -
Contraseña:
[root@srv1 ~]#

5. Haga lo mismo con user2 (el cual no ha sido agregado al grupo wheel) y se dará
cuenta que para este usuario ya no es posible convertirse en root:

[user2@srv1 ~]$ su -
Contraseña:
su: contraseña incorrecta

42 | ASEGURAR SU SISTEMA LINUX

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 6
Verificar servicios abiertos con el escáner de puertos Nmap
1. Verificar que se encuentre instalado la utilidad Nmap, así:

~]# rpm -q nmap

nmap-5.51-2.el6.x86_64

2. Caso contrario procedemos a instalar Nmap con el siguiente comando:

~]# yum install nmap

3. Ahora, procedemos a escanear el servidor del instructor (consulte a su instructor la

dirección IP del equipo a él asignado). Asumiendo que la dirección IP del servidor del
instructor es 192.168.0.1, entonces el comando a ejecutar sería:

~]# nmap 192.168.0.1

Starting Nmap 5.51 ( http://nmap.org/ ) at 2013-05-02 12:22 ECT

Nmap scan report for 192.168.0.1
Host is up (0.00019s latency).
Not shown: 1675 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
443/tcp open https
MAC Address: 00:12:79:D8:FA:C8 (Hewlett Packard)

Nmap done: 1 IP address (1 host up) scanned in 0.385 seconds

Como se puede observar, la salida del programa tras realizar el escaneo es bastante
simple y se entiende perfectamente. En este caso, nos dice que la dirección IP
192.168.0.1 tiene los puertos 22, 25, 53, 80, 111 y 443 abiertos y el servicio al cual
pertenecen.

Esto es un escaneo básico, se pueden introducir más opciones. Para mayor

información revise la página de manual del comando nmap.

4. Si queremos detectar el sistema operativo del equipo destino, en nuestro caso el

equipo del instructor, ejecutamos el comando nmap seguido de la opción –O, como se
muestra a continuación:

ASEGURAR SU SISTEMA LINUX| 43

www.palosanto.com [CURSO DE LINUX SEGURIDADES]

~]# nmap –O 192.168.0.1

Starting Nmap 5.51 ( http://nmap.org/ ) at 2013-05-02 12:25 ECT

Nmap scan report for 192.168.0.1
Host is up (0.00018s latency).
Not shown: 1675 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
443/tcp open https
MAC Address: 00:12:79:D8:FA:C8 (Hewlett Packard)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.9 - 2.6.30
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at

http://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 2.22 seconds

44 | ASEGURAR SU SISTEMA LINUX

 Capítulo 3
[SSH: SECURE SHELL]

CONTENIDO
3.1 Introducción
3.2 Protocolo SSH
3.3 Cómo funciona SSH
3.4 Establecimiento de un canal seguro
3.5 Autenticación
3.6 OpenSSH
3.7 Asegurando SSH en el sistema
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

3.1 Introducción
Internet hace posible realizar una gran variedad de operaciones de manera
remota, en especial, administrar un servidor y transferir archivos. El protocolo
Telnet que permite que los usuarios realicen estas tareas, tienen la gran
desventaja de transmitir el intercambio de información en texto plano en la red,
en particular, el nombre de usuario y la contraseña. Tal es así que un cracker que
se encuentre ubicado en una red entre el usuario y un equipo remoto puede
controlar el tráfico, es decir, utilizar una herramienta llamada sniffer o rastreador
que puede capturar paquetes que circulan en la red y obtener el nombre de
usuario y la contraseña para acceder al equipo remoto.

Si la información intercambiada no tiene un alto nivel de seguridad, el atacante

puede obtener incluso acceso a una cuenta en el equipo remoto y aumentar sus
privilegios en este equipo para obtener acceso como administrador.

Ya que es imposible controlar todas las infraestructuras físicas ubicadas entre el

usuario y el equipo remoto (al ser Internet una red abierta por definición), la única
solución es confiar en la seguridad a un nivel lógico (al nivel de los datos).

El protocolo SSH (Secure Shell) es la respuesta a este problema ya que posibilita a

sus usuarios (o servicios TCP/IP) acceder a un equipo a través de una
comunicación cifrada, también llamada túnel.

Para más información acerca de SSH, visitar los sitios Web:

http://www.ssh.com/

http://www.openssh.com/

3.2 Protocolo SSH

El protocolo SSH se desarrolló en 1995 por el finlandés Tatu Ylönen.

Es un protocolo que hace posible que un cliente (un usuario o incluso un equipo)
abra una sesión interactiva en una máquina remota (servidor) para enviar
comandos o archivos a través de un canal seguro.

• Los datos que circulan entre el cliente y el servidor están cifrados y esto
garantiza su confidencialidad (nadie más que el servidor y el cliente pueden
leer la información que se envía a través de la red). Como resultado, no es
posible controlar la red con un sniffer.
• El cliente y el servidor se autentifican uno a otro para asegurarse que las dos
máquinas que se comunican son, de hecho, aquellas que las partes creen que
son. El atacante ya no puede adoptar la identidad del cliente o de su servidor
(falsificación).

46 | SSH: SECURE SHELL

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

El objetivo de la versión 1 del protocolo (SSH1), propuesta en 1995, ofrecía una

alternativa a las sesiones interactivas tales como telnet, rsh, rlogin y rexec. Sin
embargo, este protocolo tenía un punto débil que permitía a los crackers
introducir datos en los flujos cifrados. Por este motivo, en 1997 se propuso la
versión 2 del protocolo (SSH2) como un anteproyecto del IETF.

SSH2 también incluye un protocolo SFTP (Secure File Transfer Protocol o Protocolo
Seguro de Transferencia de Archivos).

SSH es un protocolo, es decir, un método estándar que permite a los equipos

establecer una conexión segura. Como tal, existe una variedad de
implementaciones de clientes y servidores SSH. Algunas requieren el pago de una
cuota, en tanto que otras son gratuitas o de código abierto.

En Linux, el software cliente y servidor está dado por el programa OpenSSH. En

Windows se usa clientes SSH para conectarse a servidores Linux, un programa que
nos permite hacer esto es llamado PuTTy.

3.3 Cómo funciona SSH?

Una conexión SSH se establece en varias fases:

• En primera instancia, se determina la identidad entre el servidor y el

cliente para establecer un canal seguro (capa segura de transporte).
• En segunda instancia, el cliente inicia sesión en el servidor.

3.4 Establecimiento de un canal seguro

El establecimiento de una capa segura de transporte comienza con la fase de
negociación entre el cliente y el servidor para ponerse de acuerdo en los métodos
de cifrado que quieren utilizar. El protocolo SSH está diseñado para trabajar con
un gran número de algoritmos de cifrado, por esto, tanto el cliente como el
servidor deben intercambiar primero los algoritmos que admiten.

Después, para establecer una conexión segura, el servidor envía al cliente su clave
de host. El cliente genera una clave de sesión de 256 bits que cifra con la clave
pública del servidor y luego la envía al servidor junto con el algoritmo utilizado. El
servidor descifra la clave de sesión con su clave privada y envía al cliente un
mensaje de confirmación cifrado con la clave se sesión. Después de esto, las
comunicaciones restantes se cifran gracias a un algoritmo de cifrado simétrico,
mediante la clave de sesión compartida entre el cliente y el servidor.

La seguridad de la transacción se basa en la confianza del cliente y el servidor en

que las claves de host de cada una de las partes son válidas. Así, cuando se
conecta por primera vez con el servidor, el cliente muestra generalmente un

SSH: SECURE SHELL | 47

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

mensaje en el que le pide que acepte la comunicación (y posiblemente le presenta

un hash de la clave de host del servidor):

The authenticity of host 'srv1.example.com (192.168.0.1)'

can't be established.
RSA key fingerprint is
34:03:0f:f1:b9:cb:39:3d:35:85:60:43:24:1a:48:54.
Are you sure you want to continue connecting (yes/no)?

Para obtener una sesión segura propiamente dicha, es mejor pedirle

directamente al administrador del servidor que valide la clave pública presentada.
Si el usuario valida la conexión, el cliente guarda la clave de host del servidor para
evitar tener que repetir esta fase en futuras conexiones.

Por el contrario, dependiendo de su configuración, el servidor puede, a veces,

verificar que el cliente es quien dice ser. Si el servidor tiene un lista de hosts
autorizados para la conexión, cifrará el mensaje utilizando la clave pública del
cliente (que se encuentra en la base de datos de claves del host) para verificar si el
cliente es capaz de descifrarla con su clave privada (esto se llama challenge).

3.5 Autenticación
Una vez que se ha establecido la conexión segura entre el cliente y el servidor, el
cliente debe conectarse al servidor para obtener un derecho de acceso. Existen
diversos métodos:

• El método más conocido es la contraseña tradicional. El cliente envía un

nombre de usuario y una contraseña al servidor a través de la conexión
segura y el servidor verifica que el usuario en cuestión tiene acceso al
equipo y que la contraseña suministrada es válida.
• Un método menos conocido, pero más flexible, es el uso de claves públicas.
Si el cliente elige la clave de autentificación, el servidor creará un challenge
y le dará acceso al cliente si éste es capaz de descifrar el challenge con su
clave privada.

3.6 OpenSSH
OpenSSH es una versión libre del paquete de herramientas de comunicación
segura del protocolo SSH para redes, una solución de seguridad que está ganando
la confianza de un número cada vez mayor de usuarios de Internet.

Es un proyecto desarrollado principalmente por el proyecto OpenBSD, y su

primera integración en un sistema operativo fue en OpenBSD 2.6. Estos
programas se desarrollan fuera de los EE.UU., usando código desarrollado en unos
10 países distintos. Este código es de libre utilización bajo la licencia BSD.

48 | SSH: SECURE SHELL

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

El paquete de software a instalar en nuestro servidor Linux para poder ejecutar un

servidor SSH tiene el nombre openssh-server. Los archivos más importantes
a considerar serían:

Item Descripción
/etc/rc.d/init.d/sshd Script de inicialización del demónico de ssh
/etc/ssh/sshd_config Archivo de configuración del demónico
/etc/ssh/ssh_host_dsa_key La clave privada DSA usada por el demónico
de SSH
/etc/ssh/ssh_host_dsa_key.pub La clave publica DSA usada por el demónico
de SSH
/etc/ssh/ssh_host_rsa_key La clave privada RSA usada por el demónico
de SSH en su versión 2
/etc/ssh/ssh_host_rsa_key.pub La clave publica RSA usada por el demónico
de SSH en su versión 2

En una instalación de Linux típica se incluye por defecto el software OpenSSH, el

mismo que se inicia a tiempo de arranque del servidor.

3.7 Asegurar SSH en el sistema

Una instalación por defecto de SSH no es perfecta, y cuando ejecutamos un
servidor SSH hay algunos pasos simples que pueden fortalecer dramáticamente
una instalación.

3.7.1 Usar contraseñas seguras

Si está ejecutando SSH y se encuentra expuesto al mundo exterior, una de las
primeras cosas que podrá notar serán los intentos de los atacantes tratando de
acceder y adivinando su nombre de usuario y contraseña. Típicamente un
atacante escaneará el puerto TCP 22 (el puerto por defecto por el cual SSH
escucha por conexiones) para encontrar sistemas que estén ejecutando SSH, y
entonces intentará un ataque de fuerza bruta en contra de estos. Con contraseñas
seguras, felizmente cualquier ataque será registrado y notificado antes de que el
atacante pueda tener éxito.

Para visualizar los últimos inicios de sesión en el sistema, ejecute el comando

last.

Afortunadamente usted ya está usando una contraseña fuerte, de lo contrario

revise la sección 2.5.1 Crear contraseñas seguras.

SSH: SECURE SHELL | 49

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

3.7.2 Deshabilitar el acceso como root

La configuración del servidor SSH se encuentra almacenada en el archivo
/etc/ssh/sshd_config. Para deshabilitar el acceso de root, asegúrese de
tener configurada la siguiente directiva:

PermitRootLogin no

Y de reiniciar el servicio sshd una vez hecho este cambio:

~]# service sshd restart

Si usted necesita acceder como root al sistema, hágalo como un usuario normal y
luego utilice el comando su para convertirse en root, así por ejemplo si el usuario
user1 quisiera convertirse en root ya habiendo accedido al sistema, ejecutaría:

[user1@srv1 ~]$ su -
Contraseña:
[root@srv1 ~]#

3.7.3 Deshabilitar el protocolo 1

SSH posee dos versiones de protocolos que se pueden usar, protocolo 1 y
protocolo 2. El ya antiguo protocolo 1 es menos seguro y debe estar
deshabilitado, a menos que usted lo requiera para algo muy específico. En el
archivo /etc/ssh/sshd_config, busque la siguiente línea, quítele el
comentario y modifíquela como sigue:

# Protocol 2,1
Protocol 2

Y reinicie el servicio sshd.

3.7.4 Usar un puerto no estándar

Por defecto, SSH escucha las conexiones entrantes en el puerto TCP 22. Para que
un atacante determine si SSH se está ejecutando en su sistema, lo más probable
es que escanee el puerto TCP 22. Un método efectivo es ejecutar SSH en un
puerto no estándar. Cualquier puerto sin usar funcionará, pero es preferible usar
uno por encima del 1024.

Muchas personas escogen el TCP 2222 como un puerto alternativo (porque es

fácil de recordar), de la misma forma que el puerto TCP 8080 es conocido, a
menudo, como un puerto HTTP alternativo. Por esta razón, probablemente esta
no es la mejor opción.

50 | SSH: SECURE SHELL

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

De la misma forma que cualquier hacker escaneará el puerto TCP 22,

seguramente también escaneará el puerto TCP 2222 solo como buena medida. Es
mejor escoger cualquier puerto alto al azar que no sea usado por ningún servicio
conocido.

Para cambiar el puerto por el que su servicio SSH va a escuchar por conexiones,
modifique el archivo /etc/ssh/sshd_config, y ubique la siguiente línea:

Port 22

Cámbiela por un puerto alto, por ejemplo 3951, de esta manera:

Port 3951

Guarde los cambios y reinicie el servicio sshd.

3.7.5 Filtrar SSH en el firewall

Si usted solamente necesita tener acceso a SSH desde una dirección IP (digamos
desde el trabajo al servidor en casa), entonces considere la posibilidad de
adicionar una regla en el firewall de su router o en el de su sistema Linux conocido
como IPTables, para limitar el acceso al puerto TCP 22 a una dirección IP
específica.

Por ejemplo, en el caso de IPTables, esto podría realizarse con la siguiente regla:

~]# iptables -A INPUT -p tcp -s 192.168.0.1 --dport 22 -j ACCEPT

Donde 192.168.0.1 es la dirección IP desde donde se van a conectar a su servidor

SSH. Se asume que todo el tráfico restante es bloqueado por su firewall.

3.7.6 Usar llaves públicas y privadas para la autenticación

Usar llaves encriptadas para la autenticación ofrece dos beneficios principales.
Primero, es conveniente, porque ya no necesitará ingresar una contraseña (a
menos que encripte sus llaves con una contraseña de protección) si usa llaves
públicas y privadas. Segundo, una vez que un par de llaves públicas y privadas se
han creado en el servidor, podrá deshabilitar completamente la autenticación con
contraseña. Esto significa que sin una llave autorizada no puede ganar acceso,
entonces no más intentos de romper contraseñas.

Crear un par de llaves pública y privada e instalarlas para su uso en un servidor

SSH, es un proceso relativamente simple.

SSH: SECURE SHELL | 51

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Luego cuando acceda al servidor, ya no verá el login prompt preguntando por la

contraseña (a menos que cuando haya creado el par de llaves le haya puesto
contraseña). Por defecto, SSH tratará de autenticarse usando llaves. Si no se
encuentra ninguna llave y la autenticación falla, entonces SSH caerá en la
autenticación convencional por contraseña.

Una vez que haya verificado que puede acceder de forma exitosa al servidor
usando su par de llaves pública y privada, usted puede deshabilitar
completamente la autenticación por contraseñas añadiendo la siguiente
configuración al fichero /etc/ssh/sshd_config:

PasswordAuthentication no

No olvide reiniciar el servicio sshd.

3.7.7 Configurar un banner

El banner se usa para enviar un mensaje de advertencia y puede ser relevante
para mostrar información legal o simplemente para dar información a los
usuarios. El contenido del archivo especificado se envía al usuario remoto antes
de permitir la autenticación. Esta opción solo está disponible para la versión 2 del
protocolo. Por defecto, no se muestra ningún banner.

3.7.8 Redireccionamiento de puertos

SSH puede asegurar los protocolos TCP/IP a través del redireccionamiento de
puertos. Cuando se utiliza esta técnica, el servidor SSH se convierte en un
conducto encriptado entre el cliente y el servidor SSH.

El reenvío de puertos funciona mediante el mapeado de un puerto local en el

cliente a un puerto remoto en el servidor. SSH le permite mapear cualquier
puerto desde el servidor a cualquier puerto en el cliente; los números de puerto
no necesitan coincidir para que esta técnica funcione.

Para crear un canal de redireccionamiento de puertos, ejecutamos el comando

con la siguiente sintaxis:

~]# ssh –L [lport]:[lip]:[rport] [rip] –l [user]

Donde:

• lport. Es el puerto de red en la máquina local a donde se mapeará el

puerto de red de la máquina remota.
• lip. Es la dirección IP de la máquina local, desde donde se está
ejecutando el comando ssh.

52 | SSH: SECURE SHELL

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

• rport. Es el puerto de red de la máquina remota al cual queremos

acceder de manera segura a través de SSH.
• rip. Es la dirección IP de la máquina remota, donde está levantado el
servicio al cual queremos acceder de manera segura.
• user. Es el usuario con el que nos vamos a conectar a la máquina
remota para establecer el canal seguro.

Por ejemplo, con el siguiente comando:

~]# ssh –L 22443:192.168.0.10:443 192.168.0.1 –l root

El usuario podrá acceder de manera encriptada al servicio HTTPS (TCP 443)

ubicado en la máquina 192.168.0.1 a través del puerto TCP 22443 en la máquina
local. La conexión se realizará con el usuario root. Es decir, si se desea acceder al
servicio HTTPS ubicado en la IP 192.168.0.1 de manera segura, con el uso de un
navegador se ingresaría la siguiente URL:

https://192.168.0.10:22443/

SSH: SECURE SHELL | 53

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 7
Configuración de un banner para SSH
1. Vamos a configurar un banner de advertencia que se mostrará antes de que el usuario
inicie sesión. En la medida de lo posible hay que tratar de no utilizar información
referente al sistema o kernel que se está ejecutando. Hay que crear un archivo de
texto simple donde va a ir el contenido del banner, así que como usuario root vamos a
crear un archivo en blanco dentro del mismo directorio de instalación de SSH, con el
siguiente comando:

~]# touch /etc/ssh/sshd_banner

Con su editor de texto preferido, abra el archivo creado e ingrese un texto como el
siguiente (usted está en la libertad de configurar lo que sea más conveniente para sus
necesidades):

Welcome to srv1.example.com
All connections are monitored and recorded
Disconnect IMMEDIATELY if you are not an authorized user

2. Abra el archivo de configuración principal del servicio SSH, el cual es

/etc/ssh/sshd_config, busque la línea y modifíquela como se muestra a
continuación:

Banner /etc/ssh/sshd_banner

3. Guarde el archivo y reinicie el archivo, así:

~]# service sshd restart

4. Finalmente, verifique que su banner está funcionando, conectándose a través de SSH a

su servidor, así:

~]# ssh 192.168.0.1 –l root

Reemplaze el comando anterior con la dirección IP de la máquina asignada a usted.

54 | SSH: SECURE SHELL

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 8
Creación de llaves públicas y privadas para autenticación
SSH
1. Procedemos a crear un par de llaves pública y privada en el cliente que utilizará para
conectarse al servidor remoto. El equipo cliente será su máquina y el servidor remoto
será la máquina del instructor. Hay que hacer este procedimiento en cada máquina
que desee conectarse al servidor remoto, en nuestro caso lo haremos como usuario
root:

~]# ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
6e:41:e6:be:e1:71:b8:d4:ff:94:06:50:87:3c:b2:63 [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
| .... |
| ..+. |
| o .o . |
| + E. |
| S. .. |
| o + . . |
| O o + |
| + * . o |
| + ... |
+-----------------+

Este procedimiento, por defecto, creará dos archivos en el directorio de tipo oculto
llamado .ssh y que está localizado dentro del directorio home del usuario que
ejecutó el comando. En nuestro caso, al ejecutarlo como root, la ruta específica sería
/root/.ssh (tal como se ve en la ejecución del comando). Los archivos creados son
la llave privada y pública respectivamente:
• id_rsa
• id_rsa.pub

Al generar las llaves pública y privada, éstas también pueden ser protegidas por
contraseña. Si usted no desea que cada vez que se conecte al servidor remoto, el
sistema le pregunte la contraseña, solo presione Enter cuando se le pregunte por
una contraseña cuando esté creando el par de llaves. Cuando esté creando las llaves,
es su responsabilidad decidir si protege o no sus llaves con contraseña. Si no encripta
sus llaves con contraseña, entonces cualquiera que gane acceso a su máquina local
tendrá acceso SSH automáticamente al servidor remoto.

SSH: SECURE SHELL | 55

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

2. Ahora hay que copiar la llave pública (id_rsa.pub) al servidor remoto para
agregarla al archivo /root/.ssh/authorized_keys de ese servidor, que es
donde se almacenan las claves para los clientes autorizados. Esto lo puede hacer
conectándose al servidor vía consola o con algún software SSH o SFTP. En nuestro caso
lo haremos con el protocolo SCP (Secure copy) el cual usa el mismo protocolo SSH para
copiar archivos entre dos hosts de una red en forma segura. Para esto, ejecutamos
este comando en el equipo cliente, es decir, en su máquina del curso:

~]# scp /root/.ssh/id_rsa.pub [email protected]:/root/.ssh

[email protected]'s password:
id_rsa.pub 100% 416 0.4KB/s 00:00

Donde 192.168.0.1 es la dirección IP del servidor remoto, en este caso, la máquina del
instructor. La contraseña del servidor remoto es palosanto.

3. Una vez copiada la llave en el sistema remoto, nos conectamos por medio de SSH al
servidor remoto (la máquina del instructor) con el siguiente comando:

~]# ssh 192.168.0.1 –l root

Y estando ahí ejecutamos lo siguiente:

~]# cd /root/.ssh
~]# cat id_rsa.pub >> authorized_keys

4. Finalmente, salimos de la sesión en el servidor remoto y verificamos que ahora

podemos entrar sin clave, ya que la autenticación se realizará con las llaves pública y
privada. Ejecutamos nuevamente:

~]# ssh 192.168.0.1 –l root

Y esta vez no debería solicitarnos contraseña de acceso.

56 | SSH: SECURE SHELL

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 9
Redireccionamiento de puertos con SSH
En este laboratorio vamos a conectarnos de manera segura y encriptada al servicio HTTP que
se está ejecutando en el puerto TCP 80 de la máquina remota 192.168.0.1 (asumiendo que es
la dirección IP de la máquina del instructor) y lo vamos a redireccionar al puerto 2280 en la
máquina local 192.168.0.10 (asumiendo que es la dirección IP de su máquina).

1. Con el comando ssh, nos conectamos a la máquina remota para proceder a

redireccionar los puertos, así:

~]# ssh –L 2280:192.168.0.10:80 192.168.0.1 –l root

De ser necesario ingresamos la contraseña de SSH, caso contrario validará las llaves
pública y privada. La sesión de esta conexión SSH debe permanecer activa el tiempo
que deseemos acceder al servicio de manera segura, caso contrario cerramos la sesión
SSH.

2. Ahora, en otra consola, vamos a verificar que el puerto 2280 en nuestra máquina local
esté levantado, así:

~]# netstat -anp | grep 2280

tcp 0 0 127.0.0.1:2280 0.0.0.0:* LISTEN 29989/ssh

3. Finalmente abrimos un navegador Web y nos conectamos mediante el siguiente URL:

http://localhost:2280/

Y deberíamos ver el contenido del servidor remoto ya mapeado a nuestro puerto de

red local.

SSH: SECURE SHELL | 57

 Capítulo 4
[VPN: VIRTUAL PRIVATE
NETWORK]

CONTENIDO
4.1 Introducción
4.2 Tipos de VPN
4.3 Protocolos
4.4 Configuración de un servidor VPN
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

4.1 Introducción
Organizaciones con varias oficinas sucursales a menudo se conectan entre sí
mediante líneas dedicadas debido a la eficiencia y la protección de información
sensible que se transmite por la red. Esto puede ser un asunto costoso,
especialmente para las pequeñas y medianas empresas (PyMEs) que desean
expanderse sin tener que pagar los altos costos asociados a un nivel de tipo
empresarial, como los circuitos o enlaces de datos dedicados.

Para hacer frente a esta necesidad, se han desarrollado redes privadas virtuales o
VPNs (Virtual Private Network). Siguiendo los mismos principios de
funcionamiento que los enlaces dedicados, las VPNs permiten una comunicación
segura entre dos partes (o redes). Las VPNs transmiten sobre el protocolo IP
usando datagramas como capa de transporte, lo que lo hace un conducto seguro
a un destino dado a través de Internet. La mayoría de las implementaciones de
software libre de VPN incorporan estándares abiertos de métodos de encriptación
y cifrado para enmascarar los datos en tránsito.

Algunas organizaciones emplean soluciones VPN de hardware para incrementar la

seguridad, mientras que otros utilizan software o implementaciones basadas en
protocolos. Varios fabricantes ofrecen soluciones de hardware como Cisco, IBM y
Checkpoint. Hay varias soluciones VPN basadas en software libre para Linux como
Openswan (que usa el protocolo IPSec) y OpenVPN que está a punto de
convertirse en un nuevo estándar de la industria por su amplio uso.

Una VPN bien instalada beneficia mucho a una organización. Por ejemplo, puede:

• Ampliar geográficamente la conectividad

• Mejorar la seguridad
• Reducir costos operativos frente a enlaces dedicados tradicionales
• Reducir costos de tránsito y transporte para usuarios remotos
• Mejorar la productividad
• Simplificar la topología de red
• Proporcionar apoyo a teletrabajadores

Una organización podría no requerir todos estos beneficios de la VPN, pero debe
exigir las siguientes características esenciales de una VPN:

• Seguridad. La VPN debe proteger los datos mientras están viajando en la

red pública. Si los intrusos tratan de capturar estos datos, deben ser
incapaces de leerlos o utilizarlos.
• Confiabilidad. Los empleados y oficinas remotas deben ser capaces de
conectarse a la VPN sin problemas en cualquier momento (a menos que
se restrinjan las horas cuando pudieran hacerlo), y la VPN debe
proporcionar la misma calidad de conexión para cada usuario, incluso
cuando está manejando su número máximo de conexiones simultáneas.

VPN: VIRTUAL PRIVATE NETWORK | 59

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

• Escalabilidad. A medida que una empresa crece, debería ser capaz de

ampliar sus servicios de VPN para manejar ese crecimiento sin tener que
reemplazar la tecnología VPN por completo.

4.2 Tipos de VPN

4.2.1 VPN de acceso remoto

Éste es quizás el modelo más usado actualmente y consiste en usuarios que se
conectan a la empresa desde sitios remotos (oficinas comerciales, domicilios,
hotel, aviones, etc.) utilizando Internet como vínculo de acceso. Una vez
autenticados los usuarios, tienen un nivel de acceso muy similar al que tuvieren
en la red local de la empresa. A estos usuarios también se les conoce con el
nombre de roadwarriors.

4.2.2 VPN punto a punto

Este esquema se utiliza para conectar oficinas remotas con la sede central de una
organización. El servidor VPN, que posee una conexión permanente a Internet,
acepta las conexiones vía Internet provenientes de los sitios remotos y establece
el túnel VPN. Los servidores de las sucursales se conectan a Internet utilizando los
servicios de su proveedor local de Internet, típicamente mediante conexiones de
banda ancha. Esto permite eliminar los costosos enlaces de datos dedicados,
sobre todo en las comunicaciones internacionales.

4.2.3 VPN local

Este esquema es el menos difundido pero uno de los más poderosos para utilizar
dentro de la empresa. Es una variante del tipo acceso remoto pero, en vez de
utilizar Internet como medio de conexión, emplea la misma red de área local
(LAN) de la empresa. Sirve para aislar zonas y servicios de la red interna.
Esta capacidad lo hace muy conveniente para mejorar las prestaciones de
seguridad de las redes inalámbricas (WiFi).

Un ejemplo muy clásico es un servidor con información sensible y confidencial,

como las nóminas de sueldos, el cual está ubicado detrás de un equipo VPN que
provee autenticación adicional más el agregado del cifrado, haciendo posible que
sólo el personal de recursos humanos habilitado pueda acceder a la información.

60 | VPN: VIRTUAL PRIVATE NETWORK

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

4.3 Protocolos
Las soluciones de VPN pueden ser implementadas a diferentes niveles del modelo
de red OSI.

4.3.1 Implementaciones de capa 2 (Enlace)

El encapsulamiento a este nivel ofrece ciertas ventajas ya que permite
transferencias sobre protocolos no-IP. Teóricamente, las tecnologías
implementadas en capa 2 pueden tunelizar cualquier tipo de paquetes y en la
mayoría de los casos lo que se hace es establecer un dispositivo virtual de tipo
PPP (Point-to-Point Protocol) con el cual se establece la conexión con el otro lado
del túnel.

Algunos ejemplos de estas tecnologías:

• PPTP (Point-to-Point Tunneling Protocol). Desarrollado por Microsoft, es

una extensión de PPP. Su principal desventaja es que solo puede
establecer un túnel por vez entre pares.

• L2F (Layer 2 Forwarding). Desarrollado principalmente por la empresa

Cisco, ofrece mejores posibilidades que PPTP principalmente en el uso de
conexiones simultáneas.

• L2TP (Layer 2 Tunneling Protocol). Usado por Cisco y otros fabricantes, se

ha convertido en estándar de la industria y combina las ventajas de PPTP y
L2F y además elimina sus desventajas. Dado que esta solución no ofrece
mecanismos de seguridad, para su uso deberá ser combinada con otros
mecanismos generalmente implementados en capa 3 del modelo OSI.

• L2Sec (Layer 2 Security Protocol). Desarrollado para proveer una solución

con seguridad, para ello utiliza SSL/TLS aunque impone una sobrecarga
bastante grande en la comunicación para lograrlo.

4.3.2 Implementaciones de capa 3 (Red)

IPsec (IP Security) es la tecnología más aceptada en este punto y fue desarrollada
como un estándar de seguridad de Internet en capa 3. IPsec se puede utilizar para
encapsular cualquier tráfico de capa 3 pero no el tráfico de capas inferiores, por lo
que no se podrá utilizar para protocolos no-IP como IPX o mensajes de broadcast.
Su principal ventaja es que puede ser usado prácticamente en cualquier
plataforma existiendo una gran variedad de soluciones tanto de software como de
hardware.

VPN: VIRTUAL PRIVATE NETWORK | 61

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Existen dos métodos principales usados por IPsec:

• Modo Túnel. Todos los paquetes IP son encapsulados en un nuevo

paquete y enviados a través del túnel siendo desempaquetados en el otro
extremo y posteriormente dirigidos a su destinatario final. En este modo,
se protegen las direcciones IP de emisor y receptor así como el resto de
metadatos de los paquetes.

• Modo Transporte. Solo la carga útil (payload) de la sección de datos es

cifrada y encapsulada. La sobrecarga entonces, es sensiblemente menor
que en el caso anterior, pero se exponen los metadatos a posibles
atacantes que podrán ver quien se está comunicando con quien.

4.3.3 Implementaciones de capa 7 (Aplicación)

También es posible establecer túneles en la capa de aplicación y de hecho son
ampliamente utilizados hoy en día. El usuario accede a la VPN de la organización a
través de un browser iniciando la conexión en un sitio Web seguro (HTTPS).

La seguridad es lograda mediante el cifrado de tráfico usando mecanismos

SSL/TLS, los cuales han probado ser muy seguros y están siendo constantemente
sometidos a mejoras y pruebas.

4.4 Configuración de un servidor VPN

4.4.1 OpenVPN
OpenVPN es un producto de software creado por James Yonan en el año 2001 y
que ha estado siendo mejorado desde entonces. Ninguna otra solución ofrece una
mezcla semejante de seguridad a nivel empresarial, seguridad, facilidad de uso y
riqueza de características. Es una solución multiplataforma que ha simplificado
mucho la configuración de VPNs dejando atrás los tiempos de otras soluciones
difíciles de configurar como IPsec y haciéndola más accesible para gente inexperta
en este tipo de tecnología.

OpenVPN es una solución para VPN que implementa conexiones de capa 2 o 3,

usa los estándares de la industria SSL/TLS para cifrar y combinar todas las
características de las implementaciones mencionadas en la sección anterior.

Existen ciertos fabricantes de software de seguridad en Linux que usan OpenVPN

como base para la implementación de sus módulos de VPN, tales como: Zentyal,
Endian UTM, Untangle, pfSense, etc.

Para mayor información visite el sitio Web:

http://www.openvpn.net/
62 | VPN: VIRTUAL PRIVATE NETWORK
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

4.4.1.1 Cómo funciona OpenVPN?

TLS (Transport Layer Security) y su predecesor SSL (Secure Socket Layer) son
protocolos de cifrado que proveen seguridad en las comunicaciones sobre
Internet.

RSA (Rivest, Shamir y Aldeman) es un sistema de cifrado de clave pública

desarrollado en 1977. Es el primer y más utilizado algoritmo de este tipo y es
válido para cifrar como para firmar digitalmente.

OpenVPN funciona de dos modos considerados seguros, uno basado en claves

estáticas pre-compartidas y otro en SSL/TLS usando certificados y claves RSA.

• Cifrado simétrico y claves pre-compartidas. Este método se usa cuando

ambos lados usan la misma clave para cifrar y descifrar los datos, de ahí
que se le denomina cifrado simétrico. Dicha clave debe ser instalada en
todas las máquinas que tomarán parte en la conexión VPN. Cualquiera
que tuviere la clave podrá descifrar el tráfico, por lo que si un atacante la
obtuviese, comprometería el tráfico completo de la organización ya que
tomaría parte como un integrante más de la VPN. Es por ello que
mecanismos como IPSec cambian las claves cada cierto periodo. Si bien
SSL/TLS es por lejos la opción más segura, las claves estáticas cuentan con
la ventaja de la simplicidad.
• Cifrado asimétrico con SSL/TLS. SSL/TLS es una de las mejores
tecnologías de cifrado para asegurar la identidad de los integrantes de la
VPN. Cada integrante tiene dos claves, una pública y otra privada. La
pública es distribuida y usada por cualquiera para cifrar los datos que
serán enviados a la contraparte quien conoce la clave privada que es
imprescindible para descifrar los datos. El par de claves pública y privada
es generado a partir de algoritmos matemáticos que aseguran que solo
con la clave privada es posible leer los datos originales. Este método es el
que vamos a utilizar en el presente curso.

4.4.1.2 Ventajas de OpenVPN

OpenVPN provee seguridad, estabilidad y comprobados mecanismos de cifrado

sin sufrir la complejidad de otras soluciones VPN como IPsec.

Además ofrece ventajas que van más allá de cualquier otra solución como:

• Posibilidad de implementar dos modos básicos, en capa 2 o capa 3, con lo

que se logran túneles capaces de enviar información en otros protocolos
no-IP como IPX o broadcast.
• Protección de los usuarios remotos. Una vez que OpenVPN ha establecido
un túnel, el firewall de la organización protegerá el equipo remoto aún
cuando no es un equipo de la red local. Por otra parte, solo un puerto de
red es abierto hacia la red local por el usuario remoto asegurando
protección en ambos sentidos.

VPN: VIRTUAL PRIVATE NETWORK | 63

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

• Las conexiones OpenVPN pueden ser establecidas a través de casi cualquier

firewall. Si se posee acceso a Internet y se puede acceder a sitios HTTPS,
entonces un túnel OpenVPN debería funcionar sin ningún problema.
• Soporte para proxy. Funciona a través de un proxy y puede ser configurado
para ejecutarse como un servicio TCP o UDP y además como servidor
(simplemente esperando conexiones entrantes) o como cliente (iniciando
conexiones).
• Solo un puerto en el firewall debe ser abierto para permitir conexiones,
dado que OpenVPN permite múltiples conexiones en el mismo puerto TCP
o UDP.
• Las interfaces virtuales (tun0, tun1, etc.) permiten la implementación de
reglas de firewall muy específicas.
• Todos los conceptos de reglas, restricciones, reenvío y NAT pueden ser
usados en túneles OpenVPN.
• Soporte transparente para direcciones IP dinámicas. Se elimina la necesidad
de usar direcciones IP estáticas en ambos lados del túnel.
• Ningún problema con NAT. Tanto los clientes como el servidor pueden estar
en la red usando solamente direcciones IP privadas.
• Instalación sencilla en cualquier plataforma. Tanto la instalación como su
uso son increíblemente simples.
• Diseño modular. Se basa en un excelente diseño modular con un alto grado
de simplicidad tanto en seguridad como red.

4.4.1.3 Desventajas de OpenVPN

• No tiene compatibilidad con IPsec, que justamente es el estándar actual

para soluciones VPN.
• Falta de masa crítica.
• Todavía existe poca gente que conoce cómo usar OpenVPN.

4.4.2 Archivos de configuración

EL paquete de software openvpn instala el demónico del servicio, sus archivos

de configuración, tanto de cliente como de servidor y otros archivos relacionados.

La siguiente es una lista de los archivos instalados:

Item Descripción
/etc/rc.d/init.d/openvpn Script de inicialización del demónico de
openvpn
/etc/openvpn/server.conf Archivo de configuración del servidor
OpenVPN
/etc/openvpn/client.conf Archivo de configuración del cliente
OpenVPN

64 | VPN: VIRTUAL PRIVATE NETWORK

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

4.4.3 Iniciar y detener el servicio

Para iniciar el servicio, ejecute el comando como usuario root:

~]# service openvpn start

El servicio OpenVPN levanta por defecto en el puerto UDP 1194 (aunque puede
ser modificado en su archivo de configuración). Para verificar que está levantado
dicho puerto, ejecute el comando:

~]# netstat –anp | grep openvpn

Para detener el servicio, ejecute el comando:

~]# service openvpn stop

Si ha realizado una configuración y desea aplicar los cambios, reinicie el servicio,

así:

~]# service openvpn restart

Por defecto, el servicio openvpn no inicia a tiempo de arranque del servidor en

ningún runlevel. Para que el servicio se inicie a tiempo de arranque, ejecute:

~]# chkconfig openvpn on

4.4.4 Cliente OpenVPN

El mismo paquete de software de servidor OpenVPN puede ser configurado para
ser utilizado como cliente.

OpenVPN es multiplataforma, es decir, que soporta los sistemas operativos Linux,

Microsoft Windows, Mac, e incluso en sistemas operativos móviles como iOS y
Android.

VPN: VIRTUAL PRIVATE NETWORK | 65

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 10
Configuración de un servidor OpenVPN
1. Para instalar el servidor OpenVPN, hay que instalar el paquete de software openvpn,
el cual necesita de las siguientes dependencias:

• openssl
• lzo
• pam
• pkcs11-helper

Si no tiene instalados estos paquetes, ejecute el comando:

~]# yum install openssl lzo pam

2. Una vez instaladas las dependencias, procederemos a instalar el software de servidor

OpenVPN. Puede descargar la última versión del software (en archivos fuente) desde
el sitio:

http://openvpn.net/index.php/download/community-downloads.html

Para este laboratorio, vamos a instalar la versión RPM del paquete de software de
OpenVPN llamado openvpn. Para obtener la versión RPM, búsquelo y descárguelo de
los repositorios de EPEL (Extra Packages for Enterprise Linux) en la siguiente dirección:

http://fedoraproject.org/wiki/EPEL

Una vez que haya descargado el paquete adecuado para su arquitectura de

procesamiento, nos ubicamos en el directorio donde se hizo la descarga y ejecutamos
el comando:

~]# rpm -ivh openvpn-2.2.2-1.el6.x86_64.rpm

Con esto, habremos instalado el paquete de software de OpenVPN en nuestro

servidor.

3. Ahora, debemos generar un Certificado de Autoridad (CA) para el servidor que se

usará para firmar los certificados de los clientes; así como generar también las claves
pública y privada a ser utilizadas por el servidor y sus clientes. OpenVPN incluye un
pequeño paquete de administración de claves RSA, basado en la herramienta
openssl instalada al principio de este laboratorio. Este paquete, el cual se llama
easy-rsa, está compuesto por una serie de scripts (archivos ejecutables) que nos
ayudarán con la generación de estos certificados y claves, el mismo que se encuentra

66 | VPN: VIRTUAL PRIVATE NETWORK

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

ubicado en la ruta /usr/share/openvpn/easy-rsa/2.0, debido a que

estamos usando la versión 2 del software OpenVPN.
Así que procedemos a copiar esta herramienta en el directorio de instalación de
OpenVPN, el cual es /etc/openvpn, con el siguiente comando:

~]# cp -rp /usr/share/openvpn/easy-rsa/2.0 /etc/openvpn/easy-rsa

Nota: El paquete RPM de OpenVPN instalado en el punto anterior aloja la herramienta

easy-rsa en la ruta antes mencionada, pero si está instalando OpenVPN desde sus
archivos fuente o en otras distribuciones de Linux, puede que este directorio se
encuentre en otra ruta diferente.

4. Ingresamos al directorio que acabamos de copiar y vamos crear nuestro Certificado de

Autoridad (CA), para esto ejecutamos:

~]# cd /etc/openvpn/easy-rsa
easy-rsa]# cp openssl-1.0.0.cnf openssl.cnf
easy-rsa]# source ./vars
easy-rsa]# ./clean-all
easy-rsa]# ./build-ca

Y obtendremos una salida similar a esto:

Generating a 1024 bit RSA private key

................................................................
....................++++++
....................++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:EC
State or Province Name (full name) [CA]:GUAYAS
Locality Name (eg, city) [SanFrancisco]:GUAYAQUIL
Organization Name (eg, company) [Fort-Funston]:EXAMPLE
Organizational Unit Name (eg, section) [changeme]:SISTEMAS
Common Name (eg, your name or your server's hostname)
[changeme]:vpnsrv.example.com
Name [changeme]:VPN Server
Email Address [[email protected]]:[email protected]

Con esto habremos generado ya un certificado con los datos detallados

anteriormente. Usted está en la libertad de configurar los datos de acuerdo a su
organización o el lugar donde implementará el servidor OpenVPN.
VPN: VIRTUAL PRIVATE NETWORK | 67
www.palosanto.com [CURSO DE LINUX SEGURIDADES]

5. Ahora vamos a generar el certificado y la llave privada para nuestro servidor VPN, al
cual le llamaremos vpnserver. Ejecutamos el siguiente comando:

easy-rsa]# ./build-key-server vpnserver

El cual mostrará una salida como la siguiente:

Generating a 1024 bit RSA private key

................................................................
...........................................++++++
...............................++++++
writing new private key to 'vpnserver.key'
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:EC
State or Province Name (full name) [CA]:GUAYAS
Locality Name (eg, city) [SanFrancisco]:GUAYAQUIL
Organization Name (eg, company) [Fort-Funston]:EXAMPLE
Organizational Unit Name (eg, section) [changeme]:SISTEMAS
Common Name (eg, your name or your server's hostname)
[vpnserver]:
Name [changeme]:VPN Server
Email Address [[email protected]]:[email protected]

Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'EC'
stateOrProvinceName :PRINTABLE:'GUAYAS'
localityName :PRINTABLE:'GUAYAQUIL'
organizationName :PRINTABLE:'EXAMPLE'
organizationalUnitName:PRINTABLE:'SISTEMAS'
commonName :PRINTABLE:'vpnserver'
name :PRINTABLE:'VPN Server'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until May 2 17:44:29 2023 GMT
(3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
68 | VPN: VIRTUAL PRIVATE NETWORK
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

6. Ahora vamos a generar certificado y llave privada para un cliente, al cual le llamaremos
vpnclient1 (cada estudiante generará un certificado con el número de máquina
asignado, por ejemplo vpnclient3, etc.). Ejecutamos el siguiente comando:

easy-rsa]# ./build-key vpnclient1

El cual mostrará una salida como la siguiente:

Generating a 1024 bit RSA private key

...............................................++++++
..................................++++++
writing new private key to 'vpnclient1.key'
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:EC
State or Province Name (full name) [CA]:GUAYAS
Locality Name (eg, city) [SanFrancisco]:GUAYAQUIL
Organization Name (eg, company) [Fort-Funston]:EXAMPLE
Organizational Unit Name (eg, section) [changeme]:SISTEMAS
Common Name (eg, your name or your server's hostname)
[vpnclient1]:
Name [changeme]:VPN Client 1
Email Address [[email protected]]:[email protected]

Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'EC'
stateOrProvinceName :PRINTABLE:'GUAYAS'
localityName :PRINTABLE:'GUAYAQUIL'
organizationName :PRINTABLE:'EXAMPLE'
organizationalUnitName:PRINTABLE:'SISTEMAS'
commonName :PRINTABLE:'vpnclient1'
name :PRINTABLE:'VPN Client 1'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until May 2 17:54:57 2023 GMT
(3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
VPN: VIRTUAL PRIVATE NETWORK | 69
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

7. Ahora generamos la clave Diffie-Hellman, que será utilizada para la encriptación,

autenticación e intercambio de las claves. El protocolo de acuerdo de claves Diffie-
Hellman permite a las dos partes de una comunicación intercambiar una clave secreta
con seguridad. Para esto ejecutamos el siguiente comando:

easy-rsa]# ./build-dh

El cual mostrará una salida como la siguiente:

Generating DH parameters, 1024 bit long safe prime, generator 2

This is going to take a long time
...........+....................................+...............
.........+......................................................
................................................................
................................................................
..................+................................+.....+......
................................................................
.+............+..+..............................................
.............+...............................................+..
................................................................
..........................................................+.....
................................................................
..................+.......+.....................................
....+........+..................................................
..+..............+.................+............................
................................................................
................................................................
................................................................
...............................+.....+..........................
................................................................
.............................................+..................
.+..........+...................................................
............................................+...................

8. Ahora vemos que dentro del directorio /etc/openvpn/easy-rsa se ha generado

un nuevo directorio llamado keys que es el lugar donde están ubicados los
certificados y llaves del servidor y clientes. Su contenido sería:

Archivo Descripción Lo necesita …

ca.crt Certificado CA Servidor y todos los clientes
ca.key Llave privada CA Servidor solamente
dh1024.pem Parámetros Diffie-Hellman Servidor solamente
vpnserver.crt Certificado del servidor Servidor solamente
vpnserver.csr Requerimiento de certificado del Servidor solamente
servidor
vpnserver.key Llave privada del servidor Servidor solamente
vpnclient1.crt Certificado del cliente Cliente solamente
vpnclient1.csr Requerimiento de certificado del Cliente solamente
cliente
vpnclient1.key Llave privada del cliente Cliente solamente

70 | VPN: VIRTUAL PRIVATE NETWORK

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

9. Copiamos los archivos ca.crt, ca.key, dh1024.pem, vpnserver.crt y

vpnserver.key al directorio /etc/openvpn, con los siguientes comandos:

easy-rsa]# cp keys/ca.crt /etc/openvpn

easy-rsa]# cp keys/ca.key /etc/openvpn
easy-rsa]# cp keys/dh1024.pem /etc/openvpn
easy-rsa]# cp keys/vpnserver.crt /etc/openvpn
easy-rsa]# cp keys/vpnserver.key /etc/openvpn

10. Ahora ya es momento de configurar el servicio OpenVPN en nuestro servidor. Para

hacer esto, copiamos un archivo de configuración de ejemplo del servidor ubicado en
los directorios de documentación del mismo, con el siguiente comando:

~]# cp /usr/share/doc/openvpn-2.2.2/sample-config-files/server.conf
/etc/openvpn

11. Con nuestro editor de texto preferido, procedemos a abrir el archivo de configuración
/etc/openvpn/server.conf, y prestamos atención a estas directivas:

Directiva Descripción
;local a.b.c.d Dirección IP en la que va a escuchar por
conexiones. Por defecto, escucha en todas las
interfaces, así lo vamos a configurar, caso
contrario debería especificar la dirección IP de
su servidor, ya sea pública o privada
port 1194 Puerto donde va a escuchar por conexiones
proto udp Protocolo a utilizar, puede ser TCP o UDP
dev tun Va a funcionar como dispositivo tipo túnel.
tun crea túneles enrutados y tap crea túneles
Ethernet, si se desea hacer un bridge Ethernet
se debe definir como tap
ca ca.crt Certificado CA
cert vpnserver.crt Certificado del servidor
key vpnserver.key Llave privada del servidor
dh dh1024.pem Parámetros Diffie-Hellman
server 10.8.0.0 255.255.255.0 Definimos la dirección de red que se utilizará
para asignar a los clientes VPN cuando se
conecten con el servidor. Si tiene pocos
clientes una red clase C entera o una subred
serían suficientes, caso contrario puede ser
redes clase A o B. La dirección de red aquí
definida debe ser de un rango reservado y no
ser utilizada por otra red en su organización
push “route 192.168.0.0 Definimos la red que están detrás del servidor
255.255.255.0” y a las que el usuario de VPN podrá acceder
remotamente. Por cada red que tenga, cree
una línea con la directiva push. En nuestro
caso vamos a publicar la red privada del
laboratorio

VPN: VIRTUAL PRIVATE NETWORK | 71

www.palosanto.com [CURSO DE LINUX SEGURIDADES]

12. Finalmente, iniciamos el servicio de OpenVPN. Ejecutamos:

~]# service openvpn start

13. Para que OpenVPN se ejecute a tiempo de arranque del servidor, ejecutamos:

~]# chkconfig openvpn on

14. Para ver si nuestro servidor OpenVPN está escuchando conexiones podemos ejecutar:

~]# netstat –anp |grep openvpn

15. Ya que nuestro servidor OpenVPN fue configurado como dispositivo de túnel, debería
estar creado una nueva interfaz de tipo túnel. Para verificar esto, ejecutamos el
comando:

~]# ifconfig

Y deberíamos ver un dispositivo tipo túnel llamado tun0, así:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

De acuerdo a esto, nuestro servidor OpenVPN ya estaría levantado con éxito.

72 | VPN: VIRTUAL PRIVATE NETWORK

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 11
Configuración de un cliente OpenVPN Linux
1. Para configurar un cliente OpenVPN en Linux CentOS 6, hay que instalar el paquete de
software openvpn, ya que el mismo sirve cuando el equipo es servidor o cliente
como en este caso. Repetimos los pasos 1 y 2 del Laboratorio 10.

Nota: Recordemos que OpenVPN es multiplataforma, por lo tanto, también se pueden

encontrar los instaladores para otras distribuciones de Linux como Red Hat, Fedora,
Debian, Ubuntu, etc., así como también otros sistemas operativos de escritorio como
Microsoft Windows y MacOS, e inclusive para sistemas operativos móviles como iOS y
Android.

2. Una vez instalado el paquete de software, procedemos a copiar los certificados y llave
privada para el cliente que generamos en el Laboratorio 10 y los ubicaremos en el
directorio /etc/openvpn del equipo cliente. (Para este laboratorio la máquina
cliente será el equipo del instructor). Los archivos a copiar en el equipo cliente serían:

• ca.crt
• vpnclient1.crt
• vpnclient1.key

Nota: Si va a tener varios clientes que se conectarán a su servidor VPN, entonces,

debería generar en el servidor tantos certificados como clientes vaya a tener. Luego de
esto debe distribuir los archivos de certificado y clave respectivos a sus equipos
clientes. Recuerde que OpenVPN asigna una dirección IP a cada cliente VPN que se
conecta, por lo tanto no debe generar más certificados de las direcciones IP que tenga
disponibles.

3. Ahora vamos a configurar el cliente OpenVPN. Para hacer esto, copiamos un archivo
de configuración de cliente de ejemplo ubicado en los directorios de documentación
del paquete instalador, con el siguiente comando:

~]# cp /usr/share/doc/openvpn-2.2.2/sample-config-files/client.conf
/etc/openvpn

4. Con nuestro editor de texto preferido, procedemos a abrir el archivo de configuración

/etc/openvpn/client.conf, y prestamos atención a estas directivas:

VPN: VIRTUAL PRIVATE NETWORK | 73

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Directiva Descripción
client Especificamos que somos clientes
dev tun Usar la misma configuración aplicada en el servidor
proto udp Usar la misma configuración aplicada en el servidor
remote my-server-1 1194 El nombre del servidor o dirección IP y el puerto.
Podemos definir más de un servidor. Reemplace el
valor my-server-1 con la dirección IP o nombre del
servidor VPN a donde desea conectarse
ca ca.rt Certificado CA que lo obtenemos del servidor
cert vpnclient1.crt Certificado del cliente que fue generado en el servidor
key vpnclient1.key Llave privada del cliente que fue generada en el
servidor

5. Finalmente, iniciamos el servicio de OpenVPN. Ejecutamos:

~]# service openvpn start

6. Para que OpenVPN se ejecute a tiempo de arranque del servidor, ejecutamos:

~]# chkconfig openvpn on

7. Ya que nuestro cliente OpenVPN Linux fue configurado como dispositivo de túnel,
debería estar creado una nueva interfaz de tipo túnel. Para verificar esto, ejecutamos
el comando:

~]# ifconfig

Y deberíamos ver un dispositivo tipo túnel llamado tun0, así:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

De acuerdo a esto, nuestro cliente OpenVPN ya estaría levantado con éxito.

8. En caso de tener algún error, puede revisar el archivo de log /var/log/messages

y verificar todos los mensajes con respecto al servicio de OpenVPN. Ejecute el
siguiente comando:

~]# grep openvpn /var/log/messages

74 | VPN: VIRTUAL PRIVATE NETWORK

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Si su equipo se ha conectado satisfactoriamente con el servidor VPN, debería observar

una línea de log similar a esta:

May 2 15:00:51 laptop openvpn[3904]: Initialization Sequence

Completed

Caso contrario, la conexión no se ha realizado con éxito. Verifique su archivo de

configuración y que los certificados generados en el servidor son los correctos.

9. Recuerde que cuando el cliente se conecta al servidor VPN, éste último le da acceso a
las redes internas de la organización (las que fueron configuradas con la directiva
push en el archivo de configuración del servidor), por lo tanto para verificar que
desde el cliente puede llegar a dichas redes, visualice la tabla de rutas del equipo
cliente. Para esto ejecutamos:

~]# route -n

Y deberíamos ver una línea como se muestra a continuación:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
192.168.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.10.10.0 0.0.0.0 255.0.0.0 U 2 0 0 eth0
0.0.0.0 10.10.10.254 0.0.0.0 UG 0 0 0 eth0

Como podemos observar existe una ruta hacia la red 192.168.0.0/255.255.255.0 que
se encamina por la dirección IP 10.8.0.5 correspondiente a la VPN. Así también vemos
en la cuarta línea que el equipo cliente tiene una dirección IP local de la red
10.10.10.0/255.0.0.0; con esto, es recomendable que la red que configure en el
servidor para otorgar direcciones IP a sus clientes VPN, utilice un direccionamiento IP
diferente a las direcciones de red reservadas, de manera que no vaya a causarse algún
tipo de conflicto para acceder a la red local y la VPN.

VPN: VIRTUAL PRIVATE NETWORK | 75

 Capítulo 5
[FIREWALL]

CONTENIDO
5.1 Introducción
5.2 Firewall
5.3 Conceptos de firewall
5.4 Netfilter
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

5.1 Introducción
Linux está gozando de una creciente popularidad entre usuarios caseros, PyMEs y
grandes organizaciones. Linux no es solamente una plataforma para servidor muy
popular, especialmente para servidores Web, también es excelente trabajando
como gateway o puerta de enlace de una LAN hacia Internet. Detrás de dicho
gateway, continuamente conectado a Internet, están otras máquinas Linux, UNIX,
Microsoft Windows, Mac, impresoras compartidas, etc. Como resultado, usuarios
de estos sistemas están siendo expuestos a problemas de seguridad en los que
nunca tuvieron que pensar anteriormente.

Conectar un sistema Linux a Internet es como dejar una casa abierta al público,
con la puerta delantera completamente abierta, e ir a unas largas vacaciones. Sin
las precauciones del caso, intrusos o atacantes ingresarán y esto quizás sucederá
más pronto que tarde.

El usuario promedio no tiene el tiempo, interés o paciencia necesaria para

aprender todas las facetas de seguridad que se necesitan. Este capítulo intentará
cubrir estos temas y así ayudar al administrador en la configuración de las
seguridades básicas para su sistema conectado a Internet.

5.2 Firewall
El término firewall, en español cortafuegos, tiene un número de significados
dependiendo de su implementación y propósito. Para este capítulo, firewall
significa el equipo conectado directamente a Internet. Aquí es donde sus políticas
de seguridad serán implementadas.

La interface de red externa (WAN) de su equipo firewall es el punto de conexión,

puerta de enlace o gateway a Internet. El propósito de un firewall es proteger lo
que está en su lado del gateway de lo que está en el otro lado.

Una configuración básica de firewall es algunas veces llamada como un firewall de

bastión o de perímetro, porque es la principal línea de defensa en contra de
ataques externos. Detrás de esta línea de defensa está un único computador o un
grupo de computadores conectados en una red.

El propósito de un equipo firewall es simplemente servir como una puerta de

enlace a Internet para otras máquinas en su LAN. Usted pudiera estar ejecutando
servicios locales o privados detrás de este firewall, como impresoras o recursos
compartidos. O desearía que todos sus computadores tuvieran acceso a la Web.
Alguno de sus equipos pudiera almacenar su información financiera privada.
Usted podría querer tener acceso a Internet desde este equipo, pero no quisiera
que nadie ingrese a él. Su configuración y requerimientos determinarán sus
políticas de seguridad. El objetivo de un firewall es de hacer cumplir las políticas
FIREWALL | 77
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

de seguridad, las cuales representan todo al respecto de la implementación de

control de acceso de servicios privados, programas o archivos en sus
computadores.

5.2.1 Tipos de firewall

El término firewall tiene diferentes significados dependiendo de los mecanismos
usados para implementarlo, la capa del protocolo TCP/IP en el cual está
operando, la red y la arquitectura de enrutamiento que se utilizan.

Tres de los conceptos más comunes se refieren a:

• Firewall NAT o Gateway. NAT (Network Address Translation) es usado

para mapear las direcciones IP privadas de los computadores en una red a
una sola dirección IP en el Internet. Un firewall NAT o Gateway es un
equipo de hardware o un software que hace de puente entre la red local e
Internet, y hace que todas las conexiones parezcan ser de la dirección
NAT, no la dirección del equipo local.

• Firewall de filtrado de paquetes. Es normalmente implementado dentro

del sistema operativo y opera en las capas de red y transporte. Protege al
sistema, tomando decisiones de enrutamiento después de filtrar paquetes
basado en la información contenida en la cabecera del paquete IP.

• Firewall proxy de aplicación. Es usualmente implementado como

aplicaciones separadas para cada servicio que está siendo proxeado. Cada
aplicación proxy aparenta ser el servidor para el programa cliente y el
cliente para el servidor real. El proxy establece la comunicación entre el
servidor y la aplicación cliente, sustituyendo la dirección origen por la
suya propia. Esto garantiza la integridad de los datos, filtrado contra virus,
y la implementación de políticas de control de acceso detallado.

5.2.2 Firewall de filtrado de paquetes

Un firewall de filtrado de paquetes consiste de una lista de reglas de aceptación y
denegación. Estas reglas explícitamente definen que paquetes serán y no serán
permitidos a través de la interfaz de red. Las reglas de firewall usan los campos de
la cabecera del paquete IP para decidir si encaminar el paquete hacia su destino,
descartar silenciosamente el paquete, o bloquear el paquete y retornar una
condición de error a la máquina que lo envió. Estas reglas están basadas en una
tarjeta de red específica y la dirección IP del host, en las direcciones IP de origen y
destino de la capa de red, en los puertos de servicio TCP y UDP de la capa de

78 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

transporte, banderas de conexión TCP, los tipos de mensaje ICMP de la capa de

red y si el paquete es entrante o saliente.

La idea general es, que usted necesita controlar cuidadosamente el tráfico que
pasa entre Internet y el equipo que ha conectado directamente a Internet. En la
interface externa, usted filtrará lo que ingresa desde el exterior y también lo que
saldrá de este equipo si fuere su caso.

5.3 Conceptos de firewall

En esta sección trataremos algunos conceptos de red y enrutamiento de paquetes
que debe tener en cuenta para ser usados para la protección de su red.

Muchos de los más actuales routers de Internet proveen características de firewall

integradas, que son capaces de brindar un alto nivel de seguridad para su red
interna. En nuestro caso, nos enfocaremos en un sentido similar para equipos con
sistema operativo Linux.

5.3.1 Enrutamiento de paquetes

El enrutamiento de paquetes (packet forwarding) es un concepto simple donde el
servidor permite a paquetes de datos pasar de una red a otra.

Existen algunas consideraciones iniciales. Primero, el servidor debe tener redes o

gateways definidos en su tabla de enrutamiento para que pueda tomar la decisión
correcta a dónde un paquete necesita ser enrutado. Segundo, el servidor debe
tener activada la característica de enrutamiento de paquetes. Tercero, si los
paquetes enrutados provienen de una red privada y quieren ser dirigidos a
Internet, deben ser traducidos en direcciones IP globalmente enrutables (NAT se
cubrirá más adelante en esta sección) antes de ser enviados a Internet.

En Linux, el enrutamiento de paquetes puede ser habilitado manualmente por el

superusuario o root, o automáticamente cuando el sistema inicia el servicio de
red. Para habilitar o deshabilitar manualmente el enrutamiento de paquetes,
ejecute los siguientes comandos respectivamente:

~]# echo 1 > /proc/sys/net/ipv4/ip_forward

~]# echo 0 > /proc/sys/net/ipv4/ip_forward

Para habilitar automáticamente el enrutamiento de paquetes cuando esté

activado el servicio de red debemos editar la siguiente directiva en el archivo
/etc/sysctl.conf, así:

net.ipv4.ip_forward = 1

FIREWALL | 79
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

El valor por defecto es 0, que significa que el enrutamiento de paquetes está

desactivado.

Nota: Es una práctica muy común para los usuarios configurar el enrutamiento de
paquetes manualmente a través de scripts de control de firewall. Habilitar
automáticamente el enrutamiento de paquetes será más útil hacerlo en un
servidor dedicado.

5.3.2 Filtrado de paquetes

En el enrutamiento de paquetes, el kernel tiene permitido o no mover paquetes
entre diferentes subredes, y si es así, las decisiones son hechas desde su tabla de
enrutamiento.

En el filtrado de paquetes, una aplicación llamada Netfilter (se cubrirá más

adelante en esta sección) almacena una lista de reglas programadas que son
aplicadas contra cada paquete que trata de ingresar, pasar a través, o salir por
alguna de las interfaces de red del sistema. Cada regla es aplicada en orden
secuencial para probar un paquete y si el paquete concuerda con alguna de estas
reglas, es o bien aceptado o rechazado dependiendo de las políticas y las
definiciones de estas reglas.

5.3.3 Network Address Translation (NAT)

La traducción de direcciones de red, o NAT (Network Address Translation), es un
sistema que se utiliza para mapear una red completa (o varias redes) a una sola
dirección IP. NAT es necesario cuando la cantidad de direcciones IP que nos haya
asignado nuestro proveedor de Internet es inferior a la cantidad de computadores
van a acceder a Internet. Generalmente, siempre es así.

NAT nos permite aprovechar los bloques de direcciones IP privadas o reservadas.

Generalmente, una red interna o LAN se suele configurar para que use uno o más
de estos bloques de red. Estos bloques son:

Clase Dirección Red Rango de direcciones IP

A 10.0.0.0/8 10.0.0.0 – 10.255.255.255
B 172.16.0.0/12 172.16.0.0 – 172.31.255.255
C 192.168.0.0/16 192.168.0.0 – 192.168.255.255

Un servidor Linux configurado para NAT tendrá como mínimo dos interfaces de
red, una para Internet (WAN) y la otra para la red interna (LAN). NAT se encargará
de traducir los requerimientos desde la red interna, de modo que parezca que
todos provienen del propio servidor en el que se encuentra configurado el NAT.

80 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Cuando un cliente en la red interna se conecta con un servidor en Internet, envía

paquetes IP destinados a ese equipo. Estos paquetes contienen toda la
información de direccionamiento necesaria para que puedan ser llevados a su
destino. NAT se encarga de estas piezas de información:

• Dirección IP origen
• Puerto origen (TCP/UDP)

Cuando los paquetes pasan a través del servidor NAT, son modificados para que
parezca que se han originado y provienen del mismo servidor NAT. El servidor
NAT registra los cambios que realiza en su tabla de estado, para así poder: a)
invertir los cambios en los paquetes devueltos, y b) asegurarse de que los
paquetes devueltos pasen a través del firewall y no sean bloqueados. Por
ejemplo, podrían ocurrir los siguientes cambios:

• Dirección IP origen: sustituida con la dirección externa del servidor NAT

• Puerto origen: sustituido con un puerto no en uso del servidor NAT
escogido aleatoriamente

Ni la máquina interna ni el servidor de Internet destino se dan cuenta de estos

pasos de traducción. Para la máquina interna, el sistema NAT es simplemente un
gateway a Internet. Para el servidor de Internet destino, los paquetes parecen
venir directamente del sistema NAT; ni siquiera se da cuenta de que existe la
estación interna.

La traducción de paquetes ICMP ocurre de forma parecida, pero sin la

modificación del puerto de origen.

5.3.4 Reenvío de puertos

Cuando hay un servidor NAT delante de la red de una organización, todas las
máquinas de la red tienen acceso a Internet. Pero, ¿qué ocurre si se necesita
acceder desde el exterior a una de las máquinas que hay detrás del servidor NAT?
Aquí es donde entra en escena el reenvío de puertos (port forwarding). El reenvío
de puertos permite enviar el tráfico entrante a una máquina que se encuentre
detrás de un servidor NAT.

El reenvío de puertos tiene algunas implicaciones de seguridad. Crear una entrada

en el firewall para permitir el paso de tráfico a la red interna protegida deja
abierta la máquina interna a merced de un potencial compromiso de seguridad.
Si, por ejemplo, se reenviara el tráfico a un servidor Web interno y se descubriera
una vulnerabilidad en la aplicación de dicho equipo, o en un script de CGI que se
ejecutara en ese servidor Web, entonces esa máquina podría ser comprometida
por un intruso desde Internet. El intruso tendría desde ahí un pasadizo a la red
interna, una vez que se le ha permitido pasar a través del firewall.

FIREWALL | 81
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Estos riesgos se pueden minimizar manteniendo el servidor al que hay que

acceder desde el exterior, confinado firmemente en una red separada. Esta red
separada es la que se suele denominar como una Zona Desmilitarizada (DMZ). De
este modo, si se comprometiera el servidor Web, los efectos se podrían limitar a
la red DMZ, filtrando con cuidado el tráfico que debe pasar desde y hacia la DMZ.

5.4 Netfilter
En Linux, el filtrado de paquetes se controla a nivel del kernel o núcleo. Netfilter
es un componente del kernel que permite definir un sistema de reglas para
aceptar o rechazar los paquetes de red o comunicaciones que pasan por el
sistema. Estos sistemas de reglas conforman lo que se conoce como firewall o
cortafuegos; en otros sistemas los firewall pueden estar implementados en
software y estar desvinculados del sistema operativo, pero en el caso de Linux, el
firewall se puede montar a nivel de kernel y no es necesario instalar un software
adicional que incluso a veces tiene agujeros de seguridad.

Netfilter es una herramienta de firewall que permite no solamente filtrar

paquetes, sino también realizar traducción de direcciones de red (NAT) para IPv4
o mantener registros de log. Además está disponible en prácticamente todas las
distribuciones de Linux actuales.

http://www.netfilter.org/

Netfilter es configurado y controlado por una herramienta llamada IPTables. De

ahora en adelante nos referiremos a Netfilter con el nombre de IPTables.

5.4.1 Operación
IPTables permite al administrador del sistema definir reglas acerca de qué hacer
con los paquetes de red. Las reglas se agrupan en cadenas, cada cadena es una
lista ordenada de reglas. Las cadenas se agrupan en tablas, cada tabla está
asociada con un tipo diferente de procesamiento de paquetes.

Cada regla especifica qué paquetes la cumplen (matching) y un destino que indica
qué hacer con el paquete si éste cumple la regla. Cada paquete de red que llega a
una computadora o que se envía desde una computadora recorre por lo menos
una cadena y cada regla de esa cadena se comprueba con el paquete. Si la regla
cumple con el datagrama, el recorrido se detiene y el destino de la regla dicta lo
que se debe hacer con el paquete. Si el paquete alcanza el fin de una cadena
predefinida sin haberse correspondido con ninguna regla de la cadena, la política
de destino de la cadena dicta qué hacer con el paquete. Si el paquete alcanza el
fin de una cadena definida por el usuario sin haber cumplido ninguna regla de la
cadena o si la cadena definida por el usuario está vacía, el recorrido continúa en la

82 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

cadena que hizo la llamada (lo que se denomina implicit target return o retorno
de destino implícito). Solo las cadenas predefinidas tienen políticas.

5.4.2 Estructura
Todos los paquetes inspeccionados por IPTables pasan a través de una secuencia
de tablas para su procesamiento. Cada una de estas tablas se dedica a un tipo
particular de actividad de paquete y se conforma por una serie de cadenas de
procesamiento o transformación de paquetes. Dentro de estas cadenas es donde
ubicaremos nuestras reglas.

Se podría definir una jerarquía:

Tablas -> Cadenas -> Reglas

Las reglas se van agregando en forma descendente, o podemos decidir en qué

lugar ubicarlas dentro de cada cadena. Las reglas se van evaluando
ordenadamente una a una. Cuando un paquete que ingresa por una cadena
específica hace coincidencia con una de estas reglas, inmediatamente las demás
se dejan de evaluar. El comportamiento es similar al concepto de ACLs en los
equipos Cisco por ejemplo.

La estructura o formato de una regla de IPTables es:

iptables –t [tabla] [comando] [filtros] -j [acción]

Donde:

• tabla. Define la tabla a donde se va a configurar la regla, de acuerdo a la

actividad que va a realizar. Las tablas son: filter, nat y mangle. Se
puede omitir la opción –t y no especificar una tabla, entonces IPTables
asume que se trata de una regla en la tabla filter o de filtrado de
paquetes.
• comando. Define qué es lo que se va a hacer con esa regla, es decir, si
vamos a agregarla, borrarla, reemplazarla, etc.
• filtros. Define los criterios que va a evaluar una regla particular sobre
un paquete dado.
• acción. Define el destino que se le va a dar al paquete una vez que ha
sido evaluado por la regla.

A continuación se detalla con más profundidad cada uno de los componentes de

una regla de IPTables.

FIREWALL | 83
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

5.4.2.1 Tablas de procesamiento de IPTables

Tabla Función Cadena Función de la cadena
filter Filtrado de INPUT Filtra los paquetes entrantes o destinados
Paquetes al firewall
FORWARD Filtra los paquetes a equipos accesibles
mediante otra tarjeta de red (NIC) del
firewall. Filtra paquetes no destinados al
firewall, sino que lo atraviesan
OUTPUT Filtra los paquetes salientes o que se
originan en el firewall
nat Traducción de PREROUTING La traducción de dirección ocurre antes del
direcciones de red enrutamiento. Modifica la dirección IP o
(NAT) puerto destino. Se le llama también NAT
destino o DNAT
POSTROUTING La traducción de dirección ocurre después
del enrutamiento. Modifica la dirección IP o
puerto origen. Se le llama también NAT
origen o SNAT
OUTPUT Traducción de red para paquetes
generados por el firewall. Raramente usada
mangle Modificación de la PREROUTING Modificación de los bits de calidad de
cabecera TCP POSTROUTING servicio del paquete TCP antes de que
OUTPUT ocurra el enrutamiento. Raramente usada
INPUT
FORWARD

5.4.2.2 Comandos de IPTables

Comando Descripción
-A Agrega una regla al final de una cadena
-I [n] Inserta una regla en una posición dada por [n] de acuerdo al
orden numérico descendente de las reglas. Si no se especifica un
número entonces la regla se agrega al inicio de la cadena
-D [n] Elimina una regla en una posición dada por [n] de acuerdo al
orden numérico descendente de las reglas
-F Elimina todas las reglas de la tabla seleccionada
-Z Encera los contadores de la tabla seleccionada
-P [policy] Donde [policy] establece un destino o política por defecto
para una tabla dada. Las políticas pueden ser: ACCEPT, DROP o
REJECT
-L [chain] Lista las reglas configuradas en una cadena en particular definida
por [chain], si no se especifica la cadena, entonces muestra el
listado de todas las reglas configuradas en todas las cadenas de
una tabla en particular. Puede usar este comando seguido de las
opciones –n y –v que le mostrarán mas información relativa a
cada una de las reglas, como el número y el tamaño de paquetes
que han hecho coincidencia con una regla dada

84 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

5.4.2.3 Filtros o criterios de coincidencia de IPTables

Directiva Descripción
-p [protocol-type] Coincide el protocolo. Los tipos pueden ser: tcp, udp, icmp y
all
-s [ip-address] Coincide la dirección IP origen
-d [ip-address] Coincide la dirección IP destino
-i [interface-name] Coincide la interface de red por donde los paquetes entran
(input) al servidor, valores posibles pueden ser por ejemplo:
eth0, tun0, ppp0, etc.
-o [interface-name] Coincide la interface de red por donde los paquetes salen
(output) del servidor, valores posibles pueden ser por ejemplo:
eth0, tun0, ppp0, etc.
--sport [port] Define un puerto origen TCP o UDP. Puede ser un único valor o
--sport [port:port] un rango de puertos de forma ascendente
--dport [port] Define un puerto destino TCP o UDP. Puede ser un único valor o
--dport [port:port] un rango de puertos de forma ascendente
-m multiport –-sports Define una variedad de puertos TCP o UDP origen que van
[port,port] separados por coma. No necesariamente tienen que estar en
un rango dado
-m multiport –-dports Define una variedad de puertos TCP o UDP destino que van
[port,port] separados por coma. No necesariamente tienen que estar en
un rango dado
-m mac -–mac-source Define una dirección MAC origen. Ejemplo: 00:0F:EA:91:04:07
[mac-address]
-m state -–state Define el estado actual de la conexión (connection tracking). Los
[state] valores pueden ser:
• NEW. Le dice al firewall que es el primer paquete que
ve en una conexión, es decir, el inicio de la conexión.
• ESTABLISHED. Representa paquetes de una conexión ya
establecida entre dos hosts.
• RELATED. Representa una conexión que se relaciona
con otra conexión establecida o ESTABLISHED.
• INVALID. Significa que el paquete no puede ser
identificado o no tiene ningún estado.
--icmp-type [type] Define el tipo de mensaje ICMP que será filtrado. Los tipos más
comunes son echo-reply y echo-request. Para una lista
más completa visitar el link:
http://www.faqs.org/docs/iptables/icmptypes.html

FIREWALL | 85
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

5.4.2.4 Acción o destino de procesamiento de las reglas de IPTables

Acción Descripción Opciones más comunes
ACCEPT El paquete es entregado a la N/A
aplicación final o al sistema
operativo para su
procesamiento.
IPTables detiene el
procesamiento de la regla
DROP El paquete es bloqueado. N/A
IPTables detiene el
procesamiento de la regla
LOG La información del paquete --log-prefix "string"
se envía al demonio syslog
para ser registrado en un Le dice a IPTables que agregue un prefijo a
archivo de log. todos los mensajes de log con un string
IPTables continúa con el definido por el usuario. Se usa
procesamiento de la frecuentemente para identificar y detallar
siguiente regla en la tabla. porqué el paquete fue filtrado.
Como no se puede registrar y
filtrar al mismo tiempo, es
común tener dos reglas
similares en secuencia. La
primera registrará el paquete
y la segunda lo filtrará
REJECT Funciona igual que DROP, --reject-with [qualifier]
pero además devolverá un
mensaje de error al host que Donde qualifier indica que tipo de
envía el paquete mensaje de rechazo devuelve y puede ser:
advirtiéndole que dicho
paquete fue bloqueado icmp-port-unreachable (default)
icmp-net-unreachable
icmp-host-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited
tcp-reset
echo-reply

DNAT Se usa para hacer cambios en --to-destination

el destino del paquete. Por [address]<:[port]>
ejemplo: Modificar la
dirección IP o puerto destino address es el nuevo destino al que debe
del paquete ir el paquete y port el puerto al que será
redirigido el tráfico
SNAT Se usa para hacer cambios en --to-source [address]<-
el origen del paquete. Por [address]><:[port]-[port]>
ejemplo: Modificar la
dirección IP o puerto origen Aquí se especifica la dirección o direcciones
del paquete de origen y los puertos o rango de puertos
a ser usados por SNAT

86 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

MASQUERADE Se usa para hacer cambios en --to-ports [port]<-[port]>

el origen del paquete.
Por defecto, la dirección IP Aquí se especifica el rango de puertos
origen a modificar en el origen al que el puerto original puede ser
paquete es la misma usada mapeado
por la interface de red del
firewall

5.4.3 Guardar las reglas de IPTables

Al crear reglas con el uso del comando iptables, éstas se mantienen en la
memoria del sistema mientras está encendido, esto es, si se reinicia el equipo ya
no existirán en el próximo arranque del sistema. Para evitar esto, las reglas debe
ser almacenadas para su aplicación permanente en el sistema. El comando
iptables-save almacena permanentemente la configuración de IPTables en
el archivo /etc/sysconfig/iptables, que es el archivo de configuración
que el servicio IPTables lee para levantar la configuración de firewall. Cuando se
reinicia el sistema, siempre y cuando el servicio de IPTables esté configurado para
ejecutarse a tiempo de arranque, automáticamente el comando iptables-
restore lee la configuración de dichas reglas, las aplica y las convierte en la
configuración activa.

El formato del archivo /etc/sysconfig/iptables es un poco diferente de

la sintaxis que se usa con el comando iptables. La inicialización de las cadenas
es automática y la palabra iptables no figura en las declaraciones de las reglas.

Para guardar las reglas creadas en el archivo de configuración del servicio

IPTables, ejecute el comando:

~]# iptables-save > /etc/sysconfig/iptables

Para restaurar o cargar las reglas creadas en el archivo de configuración del

servicio IPTables, ejecute el comando:

~]# iptables-restore < /etc/sysconfig iptables

Un formato de ejemplo del archivo /etc/sysconfig/iptables o del

archivo en el que guarde mi configuración de reglas es así:

FIREWALL | 87
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

# Generated by iptables-save v1.2.9 on Mon May 6 11:00:07

2013
*filter
:INPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp –j DROP
-A INPUT -p udp –sport 53 -j ACCEPT
-A INPUT -p tcp -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j
ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [144:12748]
COMMIT
# Completed on Mon May 6 11:00:07 2013

5.4.4 Iniciar y detener el servicio de IPTables

Para iniciar, detener y reiniciar IPTables, ejecutamos los siguientes comandos
respectivamente:

~]# service iptables start

~]# service iptables stop
~]# service iptables restart

Para configurar que el servicio IPTables se inicie a tiempo de arranque del sistema,
ejecutamos el comando:

~]# chkconfig iptables on

5.4.5 Verificar el estado de IPTables

Se puede verificar si el servicio IPTables está ejecutándose o no, para esto
ejecutamos el comando:

~]# service iptables status

Este comando mostrará un listado con las reglas aplicadas en todas las cadenas de
las tablas utilizadas de IPTables.

De otra forma, también podemos visualizar las reglas que tenemos ejecutándose,
con los siguientes comandos para las reglas de filtrado de paquetes y de NAT por
ejemplo:

~]# iptables –L –n –v
~]# iptables –t nat –L –n -v

88 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

5.4.6 Cargar módulos de kernel requeridos por IPTables

Algunas veces, IPTables requiere cargar algunos módulos del kernel o núcleo para
activar algunas de sus funciones.

Por ejemplo, cada vez que cualquier tipo de NAT es necesario en su sistema, el
módulo iptable_nat necesita ser cargado. El módulo nf_conntrack_ftp
necesita ser agregado para soportar FTP y siempre debe cargarse con el módulo
nf_conntrack que rastrea los estados de conexión TCP. Y si su servidor FTP
está detrás de un firewall utilice el módulo nf_nat_ftp para que no tenga
inconvenientes de ningún tipo con este servicio.

Los módulos de kernel que pueden ser usados por IPTables están ubicados en las
siguientes rutas:

/lib/modules/2.6.32-71.11.1.el6/kernel/net/netfilter

/lib/modules/2.6.32-71.11.1.el6/kernel/net/ipv4/netfilter

Donde 2.6.32-71.11.1.el6 es la versión de kernel instalado en su sistema

Linux.

Para cargar los módulos adicionales de kernel para IPTables, edite la siguiente
línea en el archivo de configuración /etc/sysconfig/iptables-config y
busque una línea como la siguiente:

IPTABLES_MODULES=""

Esta línea debe ser llenada con los módulos respectivos requeridos para el
correcto funcionamiento de su sistema de firewall. Por ejemplo, si su detrás de su
servidor firewall existen servidores FTP, la línea debería estar configurada como se
muestra a continuación:

IPTABLES_MODULES="nf_conntrack_ftp nf_nat_ftp"

Reinicie el servicio de IPTables para que los módulos de kernel se carguen en el

sistema y pueda usar las funcionalidades que ellos proveen.

FIREWALL | 89
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Laboratorio 12
Configuración de un servidor firewall y gateway de
acceso a Internet
Para el siguiente laboratorio, asumiremos que nuestra infraestructura de red es la siguiente:

• Existe un servidor firewall con sistema operativo CentOS Linux 6.

• El servidor posee dos interfaces de red, una conectada directamente a Internet a
través del router del proveedor y otra interface conectada a la red interna de la
organización
• Los parámetros de configuración de red para el servidor son los siguientes:
o Dirección IP (WAN): 200.24.100.X
o Máscara de red (WAN): 255.255.255.0
o Puerta de enlace por defecto: 200.24.100.254
o Servidor DNS: 8.8.8.8
o Dirección IP (LAN): 192.168.0.X
(Donde X es el número de máquina asignada a usted)
• El servidor firewall va a ser el equipo que permita la salida a Internet de todos los
usuarios de la organización

Las políticas que queremos configurar son las siguientes:

A. Desde Internet (WAN):

1. Permitir acceso a los servicios SMTP y HTTP que se ejecutan en el servidor
desde cualquier equipo en Internet
2. Registrar en los archivos de log todas las conexiones al servicio HTTP que se
ejecuta en el servidor
3. Permitir acceso al servicio SSH que se ejecuta en el servidor solamente desde
la IP de confianza 200.100.50.100
4. Permitir acceso al protocolo ICMP en el servidor
5. Permitir que el servidor pueda acceder al servidor DNS 8.8.8.8 para realizar sus
consultas de DNS
6. Permitir las conexiones realizadas por el propio servidor hacia Internet
7. Todo el tráfico entrante restante es bloqueado
8. El servidor debe permitir la salida a Internet de todos los equipos de la red
local
9. Todos los requerimientos o conexiones dirigidas al puerto TCP 5555 del
firewall enviarlos al puerto TCP 80 de un equipo en la red local.
B. Desde la red local (LAN):
1. Restringa las conexiones al servicio SSH que se ejecuta en el servidor,
proveniente de la dirección IP 192.168.0.100
2. Restringa el acceso a cualquier requerimiento proveniente de un equipo que
tiene la siguiente dirección MAC 00:A0:C9:14:C8:89
3. Todo el tráfico entrante es permitido
90 | FIREWALL
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

4. Restringir el acceso al servicio SMTP en Internet para todos los equipos de la

red local.

Vamos a empezar:

1. Asumiendo que la dirección IP WAN de nuestro servidor es 200.24.100.1 y la dirección

IP LAN es 192.168.0.1, también se asume que la interfaz WAN es el dispositivo eth0 y
la interfaz LAN es el dispositivo eth1, las reglas a configurar serían (el instructor
discutirá cada regla con Ud.):

Regla Comando
A.1 iptables –A INPUT –i eth0 –d 200.24.100.1 –p tcp --dport 25 –j
ACCEPT
A.1 iptables –A INPUT –i eth0 –d 200.24.100.1 –p tcp –-dport 80 –j
ACCEPT
A.2 iptables –I INPUT –i eth0 –d 200.24.100.1 –tcp –-dport 80 –j LOG
A.3 iptables –A INPUT –i eth0 –s 200.100.50.100 –d 200.24.100.1 –p
tcp –-dport 22 –j ACCEPT
A.4 iptables –A INPUT –i eth0 –d 200.24.100.1 –p icmp –j ACCEPT
A.5 iptables –A INPUT –i eth0 –s 8.8.8.8 –d 200.24.100.1 –p udp –-
sport 53 –j ACCEPT
A.6 iptables –A INPUT –I eth0 –d 200.24.100.1 –m state –-state
RELATED,ESTABLISHED –j ACCEPT
A.7 iptables –A INPUT –i eth0 –d 200.24.100.1 –j DROP
A.8 iptables –t nat –A POSTROUTING –o eth0 –s 192.168.0.0/24 –j
MASQUERADE
A.9 iptables –t nat –A PREROUTING –i eth0 –p tcp -–dport 5555 –j
DNAT –-to 192.168.0.50:80
B.1 iptables –A INPUT –i eth1 –s 192.168.0.10 –p tcp -–dport 22 –j
DROP
B.2 iptables –A INPUT –i eth1 –m mac –-mac-source 00:A0:C9:14:C8:89
–j DROP
B.3 iptables –A INPUT –i eth1 -s 192.168.0.0/24 –j ACCEPT
B.4 iptables –A FORWARD –i eth1 –o eth0 –s 192.168.0.0/24 –p tcp –-
dport 25 –j DROP

2. Para listar las reglas configuradas en el cuadro anterior, ejecute el siguiente comando:

~]# iptables -L -n –v
~]# iptables –t nat -L - n –v

3. Una vez que hayamos configurado todo correctamente, procedemos a guardar las
reglas de IPTables en el archivo de configuración /etc/sysconfig/iptables,
para esto, ejecutamos el siguiente comando:

~]# iptables-save > /etc/sysconfig/iptables

Con esto ya podremos guardar las reglas de manera permanente en el archivo

mencionado anteriormente; y se ejecutarán al siguiente arranque siempre y cuando el
sistema tenga configurado al servicio IPTables para arrancar en algún runlevel
especificado.

FIREWALL | 91
www.palosanto.com [CURSO DE LINUX SEGURIDADES]

4. Para el correcto funcionamiento de la regla A8, debemos habilitar el enrutamiento de

paquetes. Esto lo hacemos modificando la siguiente directiva en el archivo
/etc/sysctl.conf, así:

net.ipv4.ip_forward = 1

El valor por defecto es 0, que significa que el enrutamiento de paquetes está

desactivado. Una vez hecho este cambio, reinicie el servicio de red, ejecutando:

~]# service network restart

5. Para verificar que efectivamente las reglas se hayan guardado en el archivo y que van a
ser configuradas en el próximo arranque, simplemente reiniciamos el servicio de
IPTables, con el comando:

~]# service iptables restart

92 | FIREWALL
[CURSO DE LINUX SEGURIDADES] www.palosanto.com

FIREWALL | 93
 Capítulo 6
[PROXY HTTP]

CONTENIDO
6.1 Qué es un proxy?
6.2 Proxy HTTP
6.3 Configuración de un servidor proxy HTTP
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

6.1 Qué es un proxy?

En el contexto de las redes informáticas, el término proxy hace referencia a un
programa o dispositivo que realiza una acción en representación de otro o
también llamado intermediario.

El uso más común es el de servidor proxy, que es un equipo que intercepta las
conexiones de red que un cliente hace a un servidor destino. De ellos, el más
famoso es el servidor proxy de navegación, Web proxy o proxy HTTP
(comúnmente conocido solamente como servidor proxy).

Un servidor proxy intercepta la navegación Web de los clientes, por varios

motivos posibles: seguridad, rendimiento, anonimato, etc.

Como se puede observar, el término proxy tiene un significado muy general,

aunque siempre es sinónimo de intermediario. También se puede traducir por
delegado o apoderado (el que tiene el poder).

6.2 Proxy HTTP

Se trata de un proxy para una aplicación específica: el acceso a la Web. Aparte de
la utilidad general de un proxy, proporciona una caché para las páginas Web y los
contenidos descargados, que son compartidos por todos los equipos de la red,
con la consiguiente mejora en los tiempos de acceso para consultas coincidentes.
Al mismo tiempo libera la carga de los enlaces hacia Internet. También se lo
conoce como proxy caché HTTP.

6.2.1 Funcionamiento
1. El cliente realiza una petición mediante un cliente HTTP (por ejemplo, un
navegador Web) de un recurso de Internet (una página Web o cualquier otro
archivo) especificado por una URL.
2. Cuando el proxy recibe la petición, busca la URL resultante en su caché local.
Si la encuentra, devuelve el documento inmediatamente, si no es así, lo
captura del servidor remoto, lo devuelve al cliente que lo pidió y guarda una
copia en su caché para futuras peticiones.

El caché utiliza normalmente un algoritmo para determinar cuándo un documento

está obsoleto y debe ser eliminado de la caché, dependiendo de su antigüedad,
tamaño e histórico de acceso. Dos de esos algoritmos básicos son el LRU (el usado
menos recientemente, en inglés "Least Recently Used") y el LFU (el usado menos
frecuentemente, "Least Frequently Used”).

PROXY HTTP | 95
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Los sistemas proxy HTTP también pueden filtrar el contenido de las páginas Web
servidas. Algunas aplicaciones que intentan bloquear contenido Web ofensivo
están implementadas como proxy HTTP. Otros tipos de proxy cambian el formato
de las páginas Web para un propósito o una audiencia específicos, para, por
ejemplo, mostrar una página en un teléfono móvil o una PDA. Algunos operadores
de red también tienen equipos proxy para interceptar virus y otros contenidos
hostiles servidos por páginas Web remotas.

6.2.2 Ventajas
• Ahorro de tráfico. Las peticiones de páginas Web se hacen al servidor
proxy y no a Internet directamente. Por lo tanto, aligera el tráfico en la
red y descarga desde los servidores destino, a los que llegan menos
peticiones.

• Velocidad en tiempo de respuesta. El servidor proxy crea una caché que

evita transferencias idénticas de la información entre servidores durante
un tiempo (configurado por el administrador) así que el usuario recibe
una respuesta más rápida.

• Demanda a usuarios. Puede cubrir a un gran número de usuarios, para

solicitar, a través de él, los contenidos Web.

• Filtrado de contenido. El servidor proxy puede hacer un filtrado de

páginas o contenidos basándose en criterios de restricción establecidos
por el administrador dependiendo de valores y características de lo que
no se permite, creando una restricción cuando sea necesario.

6.2.3 Desventajas
• Las páginas mostradas pueden no estar actualizadas si éstas han sido
modificadas desde la última carga que realizó el proxy caché. Un
diseñador de páginas Web puede indicar en el contenido de su Web que
los navegadores no hagan una caché de sus páginas, pero este método no
funciona habitualmente para un proxy.

• El hecho de acceder a Internet a través de un proxy, en vez de mediante

conexión directa, impide realizar operaciones avanzadas a través de
algunos puertos o protocolos.

• Almacenar las páginas y objetos que los usuarios solicitan puede suponer
una violación de la intimidad para algunas personas.

96 | PROXY HTTP
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

6.2.4 Proxy HTTP abierto

En esta configuración, el proxy ejecutará cualquier petición de cualquier
computador que pueda conectarse a él, realizándola como si fuera una petición
propia del proxy. Un proxy se utiliza, normalmente, para almacenar y redirigir
servicios como el DNS o la navegación Web, mediante el cacheo de peticiones en
el servidor proxy, lo que mejora la velocidad general de los usuarios. Este uso es
muy beneficioso, pero al aplicarle una configuración "abierta" a todo Internet, se
convierte en una herramienta para su uso indebido.

6.2.5 Proxy transparente

Un proxy transparente intercepta la comunicación normal en la capa de red sin
necesidad de ninguna configuración especial del cliente. Los clientes no tienen
que ser conscientes de la existencia del proxy. Un proxy transparente se
encuentra normalmente entre el cliente e Internet.

Un proxy transparente se utiliza comúnmente en las empresas para evitar la

evasión de políticas de uso aceptable de Internet, y para aliviar la carga
administrativa, ya que no se requiere ninguna configuración de navegador del
cliente.

Los proxies transparentes también son utilizados por los ISP en algunos países
para ahorrar ancho de banda y mejorar los tiempos de respuesta al cliente
mediante el almacenamiento en caché. Esto es más común en países donde el
ancho de banda es más limitado (por ejemplo, las naciones insulares).

6.3 Configuración de un servidor proxy HTTP

6.3.1 Squid
Squid es un servidor proxy caché de alto rendimiento que maneja todo tipo de
requerimientos Web por petición de un usuario. Es el más utilizado en sistemas
Linux y hay versiones disponibles también para Microsoft Windows.

El servidor proxy Squid tiene algunas características, listas de control de acceso o

ACLs y otros ítems configurables. Este capítulo le mostrará algunas
configuraciones básicas (que es todo lo requerido) para levantar un servidor de
este tipo, y proveer control de acceso para prevenir a usuarios no autorizados
obtener acceso a Internet a través de su proxy. El archivo de configuración de
Squid ha sido muy bien documentado por los desarrolladores y debería proveerle
suficiente información para asistirlo en su configuración.

PROXY HTTP | 97
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Para mayor información visite el sitio Web:

http://www.squid-cache.org/

6.3.2 Control de acceso

El control de acceso nos permite enfocarnos en el aspecto de seguridad de acceso
al servidor proxy con respecto a los clientes. Para implementar políticas de
seguridad, Squid cuenta con las llamadas Listas de Control de Acceso o ACLs. Estas
listas de acceso pueden ser implementadas de diversas formas y diversos niveles
de seguridad. Estos accesos son configurados utilizando dos secciones en el
archivo de configuración de Squid.

Vamos a trabajar con dos elementos para configurar la seguridad de nuestro

servidor proxy: los objetos que representan a las ACLs propiamente dichas y las
reglas de acceso que son el conjunto o reunión de uno o más objetos.

Por ejemplo, una regla de control de acceso sería:

“El equipo de Secretaría (representado por la dirección IP 192.168.0.5) podrá

navegar solamente al dominio google.com”

De aquí, podemos ver que esta regla está compuesta por dos objetos: el primero
representa al equipo de Secretaría (denotado por su dirección IP) y el segundo
representa al dominio google.com que es el único al que este equipo puede tener
acceso. Como habíamos mencionado, cada uno de estos objetos representa una
ACL, por lo tanto se supone que deben existir algunos tipos.

6.3.3 ACLs
Una ACL es un elemento importante en la implementación de seguridad para
nuestros usuarios. Se configuran en el archivo de configuración de Squid.

Para definir una ACL aplicamos la siguiente sintaxis:

acl [nombre] [tipo] [valor]

Donde:

• nombre. Es el nombre o identificador de la ACL. Debe ser único para cada

ACL. Trate de darle un nombre representativo de acuerdo al valor que
contiene.
• tipo. Representa el tipo o clase de ACL de acuerdo al valor que va a
contener, más adelante en esta sección se dará una tabla con los tipos
más utilizados.

98 | PROXY HTTP
 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

• valor. Es el valor que va tener una ACL de acuerdo al tipo que se está
definiendo. Puede ser una dirección IP, un dominio de Internet, una URL,
rangos de tiempo, etc. Se puede definir un valor o varios en la misma
línea, o inclusive estos valores pueden estar definidos en un archivo de
texto aparte.

En el siguiente cuadro citaremos los tipos de ACL más utilizados, su descripción y

un ejemplo de su uso:

Tipo de ACL Descripción

Port Permite definir un valor basado en un puerto de conexión. Al ser Squid un
servicio basado en protocolo de transporte TCP y protocolo de aplicación
HTTP, los puertos a definir serán solamente de este tipo. Ejemplo:

acl puerto port 5555

Src Permite definir un valor basado en una dirección IP origen (source), es decir,
el equipo que origina la conexión. En caso de tener que configurar una
dirección de red, esta debe ser configurada con una máscara corta como /8,
/16, /24, etc. Ejemplo:

acl secretaria src 192.168.0.5

Dst Permite definir un valor basado en una dirección IP destino (destination), es

decir, el equipo destino de la conexión. En caso de tener que configurar una
dirección de red, esta debe ser configurada con una máscara corta como /8,
/16, /24, etc. Ejemplo:

acl servidor_web dst 200.63.34.21

dstdomain Permite definir un valor basado en un dominio destino. Es el dominio destino

de la conexión. Un nombre de dominio se define con un punto (.) por delante.
Ejemplo:

acl dominio dstdomain .google.com

Time Permite definir valores de horarios de navegación, mediante la configuración

de días de la semana y horas del día. Los días son representados por letras
mayúsculas asociados con su nombre en inglés (S=Sunday, M=Monday,
T=Tuesday, W=Wednesday, H=Thursday, F=Friday, A=Saturday) y las horas en
formato de 24 horas. Ejemplo:

acl horario time MTWHF 10:00-19:30

url_regex Permite definir valores de expresiones regulares que se encuentran en un URL

o dirección Web. Ejemplo:

acl palabras_sucias url_regex sex porn

PROXY HTTP | 99
 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

De acuerdo a esto, para el ejemplo mencionado en la sección anterior,

tendríamos dos ACLs que pueden representarse de esta forma:

acl secretaria src 192.168.0.5

acl dominio dstdomain .google.com

Supongamos que mañana quisiéramos darle acceso a mas dominios a parte de

google.com, simplemente agregamos los valores en la misma línea, de esta
manera:

acl dominio dstdomain .google.com .yahoo.com .linux.org

Se ve sencillo, pero si quisiéramos agregar unos 20, 50, 100 o más valores, no
sería estéticamente bueno porque tiende a confusión en la mayoría de los casos.
Squid nos permite definir el nombre de un archivo de texto plano, el cual
contendrá todos los valores a configurar, uno por línea. Así por ejemplo la misma
ACL se representaría así:

acl dominio dstdomain “/etc/squid/dominios.txt”

Donde el contenido del archivo /etc/squid/dominios.txt sería:

.google.com
.yahoo.com
.linux.org

El mismo formato puede ser aplicado para los demás tipos de ACL.

6.3.4 Reglas de acceso

Una vez que hemos aprendido a definir ACLs, vamos a ver la forma en cómo
juntar estos objetos para crear reglas de acceso, quienes son realmente las que
definen las políticas de seguridad de nuestro servidor proxy. Las reglas de acceso
también se configuran en el archivo de configuración de Squid.

Para definir una regla de acceso utilizamos la siguiente sintaxis:

http_access [allow|deny] [!] acl1 acl2 acl3 ...

Donde podemos utilizar solamente un valor de allow (permitir) o deny

(denegar) a la vez. El valor [!] es opcional e implica una negación, es decir, al ser
utilizado cambia el valor de verdad de la regla.

Para el ejemplo de la regla dada en puntos anteriores:

“El equipo de Secretaría (representado por la dirección IP 192.168.0.5) podrá

navegar solamente al dominio google.com”

100 | PROXY HTTP

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Y con las ACLs definidas como:

acl secretaria src 192.168.0.5

acl dominio dstdomain .google.com

La regla de acceso a configurar sería:

http_access allow secretaria dominio

Cabe recalcar que una regla de acceso se puede formar de una o más ACLs, de
acuerdo a nuestras necesidades. Las ACLs que componen una regla se van
comprobando de izquierda a derecha, mientras más ACLs tenga una regla, más
restrictiva es.

De esta forma, el archivo de Squid puede contener varias reglas de acceso, las
cuales se evaluarán en forma descendente. Una vez que una petición de un
cliente hace coincidencia con una regla, las demás ya no se evalúan. De acuerdo a
esto, hay que configurar las reglas de acceso más específicas al principio y las más
generales al final.

6.3.5 Archivo de configuración

EL paquete de software squid instala el demónico del servicio y el archivo de

configuración principal.

La siguiente es una lista de los archivos instalados:

Item Descripción
/etc/rc.d/init.d/squid Script de inicialización del demónico de Squid
/etc/squid/squid.conf Archivo de configuración principal de Squid
/var/log/squid/access.log Archivo de log de conexiones de clientes

6.3.6 Iniciar y detener el servicio

Para iniciar el servicio, ejecute el comando:

~]# service squid start

El servicio Squid levanta por defecto en el puerto TCP 3128 (a menos que usted
configure otro puerto de conexión). Para verificar que está levantado dicho
puerto, ejecute el comando:

~]# netstat –anp | grep squid

Para detener el servicio, ejecute el comando:

~]# service squid stop

PROXY HTTP | 101

 www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Para que el servicio se inicie a tiempo de arranque, ejecute el comando:

~]# chkconfig squid on

6.3.7 Configuración del cliente

Para utilizar el servicio de proxy HTTP en un navegador, hay que realizar la
configuración manual, es decir, hay que configurar la dirección IP o nombre DNS
del servidor proxy y el puerto en el que el proxy escucha por conexiones.

En el caso de tener configurado su servidor proxy en modalidad transparente, no

necesita hacer configuración alguna en el cliente. Pero debe asegurarse de que su
servidor proxy sea el Gateway o puerta de enlace predeterminada de los equipos
de su red que vayan a hacer uso de este servidor proxy transparente.

102 | PROXY HTTP

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 13
Configuración de un servidor proxy HTTP
Para el siguiente laboratorio asumiremos que deseamos implementar las siguientes políticas:

• El equipo del Gerente de la compañía, con dirección IP 192.168.0.1, tendrá acceso a

todos los sitios Web.
• El equipo de Secretaría, con dirección IP 192.168.0.5, solo tendrá acceso a los sitios
palosanto.com y eluniverso.com.
• El resto de los usuarios de la red, representada por la dirección 192.168.0.0/24, tendrá
acceso a cualquier sitio, pero solamente en horario de Lunes a Viernes de 12:00 hasta
las 14:00.
• Nadie podrá acceder a sitios con palabras obscenas, ni siquiera el Gerente de la
compañía. El administrador deberá ingresar los valores en un archivo de texto aparte.

Vamos a empezar:

1. Verificamos que el paquete de instalación de Squid se encuentre instalado en nuestro

equipo, así:

~]# rpm -q squid

squid-3.1.10-16.el6.x86_64

2. Si no es así, procedamos a instalarlo ejecutando el comando:

~]# yum install squid

3. Con nuestro editor de texto preferido, vamos a editar el archivo de configuración de

Squid. Para esto, abrimos el archivo /etc/squid/squid.conf. Una vez ahí,
vamos a localizar la siguiente línea:

http_port 3128

Esta directiva representa el puerto en el que el demonio de Squid escuchará por

conexiones. Pueden configurarse mas líneas similares con lo que podemos configurar
para que Squid escuche en varios puertos al mismo tiempo.

4. Luego hay que configurar el directorio donde queremos que sea almacenado el caché
de las páginas Web accedidas por los clientes, buscamos la siguiente línea:

cache_dir ufs /var/spool/squid 100 16 256

PROXY HTTP | 103

www.palosanto.com [CURSO DE LINUX SEGURIDADES]

Donde 100 representa el tamaño máximo de caché permitido (en MB), y debería ser
ajustado a sus necesidades. Los números 16 y 256 indican el número de
subdirectorios que se crearán a partir del directorio padre, en este caso
/var/spool/squid.

Squid crea un sinnúmero de directorios y guarda en ellos pocos archivos, lo cual es

más eficiente que poner en un solo directorio muchos archivos.

5. Ahora vamos a configurar las ACLs, de acuerdo a los requerimientos de políticas a

implementar dados al principio de este laboratorio. Configuramos nuestras reglas
justo debajo de la línea que se muestra a continuación:

acl CONNECT method CONNECT

Las ACLs a configurar serían así:

acl gerente src 192.168.0.1

acl secretaria src 192.168.0.5
acl usuarios src 192.168.0.0/24
acl dominios dstdomain .palosanto.com .eluniverso.com
acl horario time MTWHF 12:00-14:00
acl extensiones url_regex “/etc/squid/palabras_sucias”

6. Procedemos a configurar las reglas de acceso con las ACLs ya definidas. Justo por
debajo de la siguiente línea:

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

Las reglas de acceso a configurar serían así:

http_access deny extensiones

http_access allow gerente
http_access allow secretaria dominios
http_access allow usuarios horario

7. Guardamos los cambios realizados. Luego, debemos crear el archivo donde se

almacenarán las palabras obscenas que será llenado por el administrador, ejecutamos
el comando:

~]# touch /etc/squid/palabras_sucias

Con nuestro editor de texto preferido, abrimos dicho archivo y agregamos las
siguientes palabras (una palabra por cada línea):

sex
porn
xxx

104 | PROXY HTTP

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

8. Finalmente, vamos a iniciar nuestro servidor proxy ya configurado, ejecutamos:

~]# service squid start

9. Ahora, para verificar que nuestro proxy ha sido correctamente configurado,

necesitamos configurar el cliente o navegador Web para que haga uso del servicio.

• Para configurar de forma manual el proxy en el navegador Mozilla Firefox siga

las siguientes instrucciones:

o Ir al menú Herramientas -> Opciones, después vaya al menú

Avanzado y por último la pestaña Red.

Haga clic sobre el botón Configuración para definir los parámetros del
proxy.

o Seleccione la opción Configuración manual de proxy y escriba la

dirección IP/nombre y puerto del servidor proxy, por ejemplo:

PROXY HTTP | 105

www.palosanto.com [CURSO DE LINUX SEGURIDADES]

o Si desea excluir el uso del proxy para acceder a algunos recursos, cree
una lista separada por coma (,) en el bloque No usar proxy para.

• Para configurar los parámetros de proxy en el navegador Internet Explorer siga

las siguientes instrucciones:

o Ir al menú Herramientas -> Opciones de Internet, después vaya a la

pestaña Conexiones.

106 | PROXY HTTP

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Haga clic sobre el botón Configuración de LAN para definir los

parámetros del proxy.

o Seleccione la opción Usar servidor proxy para LAN y haga clic sobre el
botón Avanzadas para definir los parámetros del proxy

PROXY HTTP | 107

www.palosanto.com [CURSO DE LINUX SEGURIDADES]

o Escriba la dirección IP/nombre y puerto del servidor proxy, por

ejemplo:

o Si desea excluir el uso del proxy para acceder a algunos recursos, cree
una lista separada por coma (,) en el bloque No usar un servidor proxy
para las direcciones que comiencen por.

108 | PROXY HTTP

 [CURSO DE LINUX SEGURIDADES] www.palosanto.com

Laboratorio 14
Configuración de un servidor proxy HTTP en modo
transparente
Para el siguiente laboratorio, vamos a usar la misma configuración del laboratorio anterior ya
que las ACLs y reglas de acceso son las mismas. Nos vamos a enfocar netamente en la
configuración del proxy transparente.

1. Con nuestro editor de texto preferido, abrimos el archivo de configuración de Squid

/etc/squid/squid.conf, y nos ubicamos en la siguiente línea:

http_port 3128

Modifique esta línea para que quede de esta manera:

http_port 3128 transparent

2. Guardamos la configuración realizada. Ahora debemos crear una regla de firewall que
permitirá redireccionar todo el tráfico originado en la red interna que vaya a Internet y
forzarlo para que salga por el proxy. Para esto ejecutamos el siguiente comando:

~]# iptables –t nat –A PREROUTING –i eth1 –s 192.168.0.0/24 –p

tcp --dport 80 –j REDIRECT –to 3128

Donde 192.168.0.0/24 es la dirección de red LAN dónde están ubicados los usuarios.

3. Para trabajar con proxy en modo transparente, debe retirar la configuración manual
de proxy en el navegador Web del cliente y cersiorarse de que el servidor proxy sea la
puerta de enlace predeterminada o default gateway del computador del cliente.

PROXY HTTP | 109