Mi objetivo es tener un túnel VPN en un único puerto en la IP pública de un servidor y poder ingresar SSH al servidor con una capa VPN adicional de cifrado.
DETALLES DE LA CONFIGURACIÓN DEL SERVIDOR:
Estoy ejecutando CentOS 7 tanto en el servidor como en los clientes. Los documentos que he leído hasta ahora parecen centrarse en una configuración que se ejecuta a través del navegador y retransmite el tráfico de Internet. No necesito que el servidor transmita nada. ¿Puedo acceder al puerto SSH del servidor a través de VPN y dejar el tráfico de Internet (80/443) solo en el servidor y el cliente? El servidor aún debe poder servir 80/443 al público a través de Apache y el cliente debe acceder a Internet con normalidad.
Respuesta1
Si me lo permite, me tomaré la libertad de descomponer su pregunta, dar un paso atrás y ayudarlo a recorrer todo el proceso de diseño de la solución para que podamos determinar una solución viable para usted. Hay una serie de imprecisiones en su pregunta sobre el protocolo SSH, las VPN y, en general, cómo diseñamos sistemas seguros. Trabajemos con ellos aquí.
En la actualidad, su pregunta solicita orientación para implementar tecnologías específicas. Sin embargo, el planteamiento de su problema no evalúa la amenaza específica que enfrenta, por lo que es prematuro diseñar una solución; en este sentido tienesXY tiene problemasa nosotros.
Cualquier implementación que realice no resolverá el problema (porque, de hecho, el problema está en otra parte) o agregará complejidad donde una solución más simple es adecuada. Además, una complejidad innecesaria no es deseable, ya que puede ser una fuente de mayores vulnerabilidades de seguridad.
Defina rigurosamente su problema
Deberíamos sercentrado en objetivos,no centrado en soluciones. Deberíamos definir los objetos de nuestro dominio problemático, determinar los factores contribuyentes a considerar, comprender las amenazas que enfrentamos y sólo entonces podremos comenzar a determinar qué tecnologías y procesos se pueden elegir para resolver el problema en cuestión. Un proceso que podemos seguir:
- Identificar el problema– ¿Cuál es la dificultad específica que buscamos resolver? La dificultad debe ser un problema objetivo y mensurable, respaldado por pruebas contundentes de su existencia a partir de observaciones realizadas en el terreno.
- Determinar supuestos y restricciones.– ¿Hay elementos específicos que podamos suponer que se encuentran en un estado particular y se imponen otras condiciones a la solución propuesta? Una restricción importante debe incluir los costos directos de implementación de la solución (compra de hardware, software o tiempo de consultoría) y los costos indirectos (realizar cambios en los procesos, capacitar al personal, adaptarse a la productividad perdida).
Identificar actores de amenazas(por problemas de seguridad) –Ningún sistema o proceso es 100% seguro.. Necesitamos determinar cuidadosamente la naturaleza de todos los adversarios que probablemente lancen un ataque para determinar si nuestra solución previene adecuadamente dichos ataques. Esto se aplica tanto al diseño de sistemas de seguridad física del mundo real como al diseño para resultados técnicos.
Por ejemplo, en su evaluación, puede considerar factores tales como:
- Capacidades de tu adversario– ¿Qué conocimientos tienen? ¿Tienen acceso a recursos específicos para ayudar en un ataque?, etc.
- Su posición– existe una diferencia sustancial entre un script kiddie en la última milla de un servicio de Internet residencial y un actor estatal con acceso a posiciones en la red desde las cuales los ataques de intermediario son factibles
Sutermostato de riesgo y riesgo– ¿Qué motiva al actor a atacarle a usted o a su organización específicamente? Por ejemplo, ¿su sistema almacena o procesa datos confidenciales y/o privilegiados que normalmente son de naturaleza restringida y pueden ser valiosos para otros (datos personales, secretos de la empresa, etc.)? ¿Tiene una posición privilegiada en una red desde la cual se pueden lanzar más análisis o ataques (por ejemplo, un enrutador central en un ISP, una puerta de enlace fronteriza en el perímetro de una red sensible en una gran corporación)?
Esto ayuda a identificar si estamos tratando con un actor de Amenaza Persistente Avanzada (APT) que busca atacartúespecíficamente, o si estamos defendiendo a oportunistas. Es mucho más fácil defenderse de un oportunista que pasa si tienes protecciones modestas que te hacen parecer seguro en relación con la competencia.
Además, identificar su apetito por el riesgo (sutermostato de riesgo) contribuye a optimizar el resultado para cubrir adecuadamente los riesgos identificados sin exagerar.
- Decisión de implementación– utilizando la información recopilada de este proceso, teniendo en cuenta las limitaciones descritas y nuestra postura sobre el riesgo, identificar la tecnología adecuaday procesocambios para solucionar el problema,o revisar las limitaciones o el perfil de riesgo si no se puede identificar una solución.
Durante todo el proceso recordamosLa seguridad es un proceso, no un destino.. No podemos "comprar" seguridad como una mercancía disponible en el mercado, y cualquiera que sugiera eso está mintiendo o tiene motivos ocultos (probablemente de enriquecimiento pecuniario).
Tu problema específico
Su pregunta es increíblemente completa, por lo que podemos seguir nuestro proceso en detalle con sus problemas específicos:
El problema
Experimenté un servidor comprometido según el análisis de rkhunter y quiero mitigar la posibilidad de que esto vuelva a suceder.
El problema específico es un compromiso pasado de la máquina, del cual se desea minimizar cualquier recurrencia.
El objetivo principal que puedo identificar a partir de su pregunta es proteger la máquina contra eventos de compromiso remoto que pueden tener lugar a través de una red pública (como Internet). Un objetivo secundario es garantizar la confidencialidad y la integridad de las sesiones de shell remotas en la máquina remota.
Suposiciones y Restricciones
Documentemos estos puntos para guiar nuestra solución:
- Los servicios del sitio web público expuestos desde la máquina son seguros
- Las estaciones de trabajo desde las que inicia conexiones remotas no son servidores proxy para atacar la máquina servidor en cuestión. Por ejemplo, ellos mismos no están infiltrados (por lo que no son un vector para la filtración o modificación de claves, o para que los binarios utilizados para establecer conexiones sean manipulados). Es posible que desee explorar las debilidades de seguridad de cualquier máquina cliente por separado o agruparlas en una sola evaluación.
- La máquina del servidor es físicamente segura y es poco probable o se descarta la manipulación de la configuración de hardware o software por parte de una persona que atiende físicamente la máquina. (Es poco probable que una máquina a la que un atacante haya tenido acceso físico siga siendo su máquina).
- Se supone que la red está comprometida. Puede haber actores que tengan la capacidad de interceptar o desviar nuestros paquetes.
- Queremos utilizar software disponible gratuitamente para lograr los aspectos técnicos de nuestra solución.
- Suponemos que los usuarios están adecuadamente capacitados para que se puedan descartar los ataques al software húmedo (operadores humanos) (por ejemplo, amenazas de ingeniería social). Nuevamente, en principio, estos rara vez se mitigan adecuadamente y son una debilidad para la mayoría de las organizaciones, pero esto es un error del servidor, por lo que, además de una mención pasajera, descartaré los aspectos no técnicos del modelo de ataque.
- Es aceptable si la solución requiere distribución fuera de línea o verificación de claves antes de la primera conexión.
- Se supone que las primitivas criptográficas conocidas son inmunes a ataques de puerta trasera o no divulgados públicamente.
Modelo de amenaza
No puedo determinar adecuadamente su modelo de amenaza porque no tengo visibilidad de su organización e infraestructura, ni poseo una descripción general del portafolio de datos que procesa o de las redes privadas a las que puede estar conectado internamente. A partir de la información pública de su perfil, puedo ver que puede trabajar en una ubicación que procesa propiedad intelectual confidencial en nombre de otros, lo que constituiría una recopilación de datos de riesgo medio a alto para amenazas de ataque específicas. (Esta amenaza puede extenderse a los sistemas personales que usted opera).
Implementación
Diseñemos una solución que cumpla con nuestros objetivos. Para fortalecer la máquina, debemos considerar rutas de ataque públicas. Expone dos servicios y hemos asumido que el servicio web no es vulnerable. Por lo tanto, debemos considerar la conexión de shell remota.
Para este propósito,SSH es más que capazde cumplir con sus requisitos sin el envoltorio adicional de una sesión VPN. Casi cualquier equipo Unix es capaz de ejecutar un demonio SSH, y un número significativo está expuesto directa o indirectamente a redes hostiles sin infiltración.
¿Cómo se ajusta SSH a nuestros objetivos?
Secure Shell (SSH) está diseñado para proporcionar confidencialidad e integridad de las sesiones de shell remotas. Lo hace utilizando enfoques criptográficos; en particular, a los hosts se les asigna una o más claves de host que pueden usarse para identificar positivamente el host en las máquinas cliente que se conectan.
Ataques de intermediario en SSH
Como ha identificado correctamente, SSH es susceptible a un ataque de intermediario en un escenario específico: la mayoría de los usuarios no inspeccionan las claves de host presentadas por la máquina en la conexión inicial; ellos despliegan unconfianza en el primer usopolítica. Si un MitM puede proporcionar claves de host alternativas en este punto, es factible interceptar la sesión SSH ahora y en conexiones futuras sin mayor detección. La detección sin inspeccionar la clave de host almacenada en caché requeriría neutralizar la amenaza MitM o conectarse desde una red no comprometida para que se pueda presentar la verdadera clave de host del host remoto.
Como nos preocupa MitM, debemos diseñar una solución para mitigarlo. Las opciones disponibles para usted incluyen (no exhaustivas):
- Conexión únicamente a través de redes confiables. Esto no es viable ya que no cumple con nuestros objetivos o suposiciones sobre las conexiones a través de redes públicas.
- Distribución de la huella digital de la clave del host (o su clave pública completa) antes de la conexión inicial. Utilice el
ssh-keygencomando en el servidor para obtener la huella digital, distribúyala a los usuarios y pídales que comparen la huella digital presentada en la primera conexión con la versión en el servidor. Sólo deben iniciar sesión si la huella digital coincide. - Publique las claves del host en DNS y firme la zona mediante DNSSEC. Asegúrese de que todos los clientes que se conectan utilicen un solucionador de validación de DNSSEC y verifique las claves de host basadas en DNS.Más información aquí. Este enfoque evita la carga de distribuir y verificar manualmente la clave del host, pero requiere la presencia de componentes técnicos específicos que aún no están muy extendidos en muchas redes.
Ataques de contraseña de fuerza bruta
Otra vulnerabilidad de un demonio SSH en ejecución son los ataques de fuerza bruta a contraseñas. Es común que los atacantes exploren su caja en busca de servicios SSH e intenten la autenticación utilizando una lista común de nombres de usuario y contraseñas. Es probable que las casillas con nombres de usuario en la lista pública y contraseñas débiles se vean comprometidas. Los métodos para mitigar esto incluyen:
- Cambiar el demonio SSH para usar autenticación basada en claves y deshabilitar la autenticación de contraseña desde la Internet pública. Genere un par de claves RSA para su cuenta de usuario utilizando
ssh-keygenuna cantidad grande (por ejemplo, >2048) de bits, o una cantidad adecuada de bits para un par de claves firmado con otro sistema criptográfico. - El uso de software permite
fail2banobservar sus registros y agregar reglas de firewall para bloquear más intentos de conexión desde la misma dirección después de alcanzar un umbral de inicio de sesión fallido.
¿Ayudaría una VPN?
Las soluciones VPN pueden resolver el mismo problema que usted busca resolver con el túnel SSH. Es posible que utilicen un enfoque técnico diferente o sistemas criptográficos diferentes, pero ambos son adecuados para cumplir con sus obligaciones de seguridad. Ambos también incurren en gastos generales similares (por ejemplo, la obligación de distribuir previamente o verificar las claves con cada parte por adelantado es idéntica).
La funcionalidad adicional proporcionada por una VPN parece innecesaria en este caso particular si lo único que desea operar es un servidor shell remoto. Ejecutar una VPN probablemente conlleva un riesgo adicional al serotrodemonio ejecutándose en su máquina y un mayor vector de ataque.