Seguridad de red para administración de servidores

Principios de seguridad aplicables a la administración de servidores

La seguridad de red para administrar servidores se basa en reducir al mínimo lo que puede comunicarse con el servidor y lo que el servidor puede comunicar hacia afuera. En la práctica, esto se traduce en controlar quién accede, desde dónde, a qué servicios y con qué tipo de tráfico, manteniendo evidencia (logs) para detectar y responder a intentos no autorizados.

Mínimo privilegio (en red)

Aplicado a red significa: permitir solo los flujos estrictamente necesarios para operar y administrar. Todo lo demás se deniega por defecto. Ejemplo: si un servidor solo necesita ser administrado por SSH desde una red administrativa, no hay razón para aceptar SSH desde Internet ni desde redes de usuarios.

• Regla mental: deny all + excepciones explícitas.
• Separar “tráfico de administración” del “tráfico de aplicación”.
• Evitar accesos “temporales” sin fecha de caducidad (reglas que se quedan para siempre).

Segmentación (para limitar el alcance de incidentes)

La segmentación reduce el impacto si un equipo se compromete. Aunque ya se haya visto segmentación a nivel lógico, aquí importa el principio: los segmentos deben tener políticas distintas. Un servidor en producción no debería tener el mismo nivel de exposición que un equipo de pruebas o una estación de trabajo.

• Separar redes: administración, servidores, usuarios, monitoreo/backup.
• Controlar el tráfico entre segmentos con políticas (firewall/ACL).
• Permitir “saltos” administrativos mediante un punto controlado (por ejemplo, un bastion/jump host), en lugar de abrir administración desde muchas redes.

Superficie de exposición

La superficie de exposición es el conjunto de servicios y rutas por las que un servidor puede ser alcanzado. Se reduce cerrando puertos, limitando orígenes, deshabilitando servicios innecesarios y evitando publicar interfaces administrativas.

• Menos servicios escuchando = menos oportunidades de ataque.
• Menos orígenes permitidos = menos probabilidad de acceso no autorizado.
• Menos rutas de administración = mejor trazabilidad y control.

Control de tráfico (qué se permite y cómo se inspecciona)

El control de tráfico se implementa con firewalls en el host, firewalls perimetrales/entre segmentos y ACL en equipos de red. El objetivo es definir políticas por dirección (origen/destino), puerto/protocolo y estado de conexión, y registrar lo relevante.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Firewalls: stateless vs stateful y reglas básicas

Firewall stateless (sin estado)

Un firewall stateless evalúa cada paquete de forma independiente. Las reglas suelen basarse en IP origen/destino, puerto y protocolo. Es simple y rápido, pero requiere reglas adicionales para permitir tráfico de retorno y puede ser más propenso a errores de configuración.

Firewall stateful (con estado)

Un firewall stateful mantiene una tabla de estados de conexiones (por ejemplo, TCP). Si una conexión fue permitida al iniciarse, el tráfico de retorno asociado se permite automáticamente. Esto reduce reglas y mejora la seguridad al distinguir tráfico “relacionado/establecido” de tráfico nuevo.

Elementos de una regla típica

• Dirección: entrada (inbound) o salida (outbound).
• Acción: permitir/denegar/rechazar.
• Protocolo: TCP/UDP/ICMP (y otros).
• Origen/Destino: IP o rango (idealmente lo más específico posible).
• Puerto: servicio (por ejemplo, 22/TCP para SSH).
• Estado: NEW, ESTABLISHED, RELATED (en firewalls con estado).
• Registro: loguear coincidencias (especialmente denegaciones relevantes).

Ejemplos de políticas (conceptuales)

Ejemplo 1: permitir administración SSH solo desde un host autorizado (jump host) y denegar el resto.

INBOUND: allow tcp from 10.10.50.10 to SERVER port 22 (ssh) state NEW,ESTABLISHED
INBOUND: allow tcp from SERVER to 10.10.50.10 port >1024 state ESTABLISHED (retorno)
INBOUND: deny tcp to SERVER port 22 from any (log)

Ejemplo 2: permitir solo lo necesario para un servicio web y bloquear administración desde redes no administrativas.

INBOUND: allow tcp from any to SERVER port 443 (https)
INBOUND: deny tcp to SERVER port 80 (si no se usa)
INBOUND: deny tcp to SERVER port 22 from any (log)  # excepto red/host admin

Ejemplo 3: salida controlada (egress). Útil para limitar exfiltración y reducir impacto si un proceso malicioso intenta comunicarse.

OUTBOUND: allow udp to NTP_SERVERS port 123
OUTBOUND: allow tcp to REPO_MIRROR port 443
OUTBOUND: deny all (log selectivo)

Nota práctica: el control de salida debe aplicarse con cuidado para no romper actualizaciones, monitoreo o integraciones; aun así, es una capa valiosa cuando se define de forma explícita.

Listas de Control de Acceso (ACL) en equipos de red

Las ACL son filtros aplicados en routers/switches de Capa 3 (y en algunos casos en switches avanzados) para permitir o denegar tráfico según criterios como IP, protocolo y puertos. Se usan para reforzar segmentación y limitar movimientos laterales entre redes.

Cuándo usar ACL vs firewall

• ACL: control rápido y cercano al enrutamiento; útil para bloquear/permitir flujos entre subredes con reglas relativamente simples.
• Firewall: inspección más rica (estado, perfiles, NAT avanzado, logging centralizado, IDS/IPS en algunos casos) y políticas más expresivas.

Buenas prácticas con ACL

• Aplicar la ACL en el punto correcto: cerca del origen para bloquear temprano, o cerca del destino para proteger un segmento crítico (según el caso).
• Orden importa: las reglas se evalúan en secuencia; colocar primero las más específicas.
• Final implícito: muchas ACL tienen un “deny any” implícito; documentar y registrar cuando sea posible.
• Evitar rangos demasiado amplios: preferir hosts o subredes mínimas necesarias.

Ejemplo conceptual de ACL para administración

Objetivo: permitir que solo la red administrativa acceda por SSH a la red de servidores, y denegar el resto.

permit tcp ADMIN_NET any -> SERVERS_NET port 22
permit icmp ADMIN_NET any -> SERVERS_NET (opcional, para diagnóstico)
deny   ip  any -> SERVERS_NET (log si el equipo lo soporta)

VPN para acceso administrativo seguro

Una VPN (Virtual Private Network) crea un canal cifrado entre el administrador y la red interna, permitiendo administrar servidores sin exponer servicios administrativos a Internet. En administración, la VPN suele ser el primer control para “entrar” a la red de forma segura, y luego se aplican controles adicionales (firewall/ACL, bastion, MFA, etc.).

Conceptos clave

• Túnel cifrado: protege confidencialidad e integridad del tráfico administrativo.
• Autenticación: valida al usuario/dispositivo (idealmente con MFA y certificados).
• Alcance (split-tunnel vs full-tunnel): define si solo el tráfico a redes internas va por VPN o todo el tráfico del cliente.
• Control de acceso: una VPN no debe dar “acceso total”; debe entregar rutas y permisos mínimos (por ejemplo, solo a la red de administración o a un bastion).

Patrones recomendados para administración

• VPN + bastion/jump host: el usuario entra por VPN y luego accede a servidores solo desde el bastion. Ventaja: centraliza logs y reduce orígenes.
• VPN con políticas por grupo: diferentes perfiles (operaciones, DBA, soporte) con rutas/puertos permitidos distintos.
• Acceso “just-in-time”: habilitar acceso temporal (por ventana de mantenimiento) cuando sea posible.

Guía práctica: endurecimiento de SSH y validación con escaneos controlados

Objetivo: reducir la exposición de SSH, fortalecer autenticación, registrar intentos y verificar desde un host autorizado que la política funciona.

Paso 1: limitar quién puede llegar a SSH (red y host)

Defina un origen único o reducido para administración (por ejemplo, un jump host o una subred administrativa). Luego aplique controles en dos capas: (1) firewall/ACL de red y (2) firewall del propio servidor.

• En red: permitir TCP/22 solo desde el origen autorizado hacia el servidor.
• En el servidor: permitir TCP/22 solo desde el origen autorizado y denegar el resto (con logging selectivo).

Ejemplo conceptual (host firewall):

allow tcp from 10.10.50.10 to any port 22
deny  tcp from any to any port 22 (log)

Paso 2: usar claves SSH y deshabilitar contraseñas

Las claves reducen el riesgo de fuerza bruta y credenciales reutilizadas. Use claves modernas y proteja la clave privada con passphrase.

1. En el equipo del administrador, genere una clave (ejemplo con Ed25519): ssh-keygen -t ed25519 -a 64
2. Copie la clave pública al servidor (por canal seguro): ssh-copy-id usuario@servidor
3. En el servidor, edite la configuración de SSH (/etc/ssh/sshd_config) y aplique como mínimo:
   • PasswordAuthentication no
   • PubkeyAuthentication yes
   • PermitRootLogin no (administrar con usuario normal + elevación controlada)
4. Recargue el servicio SSH (según sistema): systemctl reload sshd o systemctl reload ssh

Recomendación adicional: si necesita cuentas compartidas por operación (no ideal), use claves por persona y controle el acceso mediante grupos y authorized_keys con comentarios y rotación.

Paso 3: reducir el “ruido” y endurecer parámetros de SSH

Estos ajustes ayudan a disminuir intentos automatizados y mejorar control:

• Cambiar el puerto no sustituye controles, pero puede reducir escaneo masivo: Port 2222 (si se hace, actualice firewalls/ACL y documentación operativa).
• Limitar usuarios/grupos: AllowUsers o AllowGroups.
• Limitar intentos: MaxAuthTries 3.
• Deshabilitar autenticación por teclado si no se usa: KbdInteractiveAuthentication no (según distribución).
• Restringir reenvíos si no se requieren: AllowTcpForwarding no, X11Forwarding no.

Paso 4: registrar intentos y centralizar evidencia

La seguridad operativa depende de visibilidad. Asegure que los intentos de acceso queden registrados y sean revisables.

• Verifique logs de SSH (según sistema): /var/log/auth.log o journalctl -u sshd.
• Active logging de denegaciones en firewall/ACL cuando sea viable (evite inundación: registre solo eventos relevantes como intentos a puertos administrativos).
• Si existe un sistema de logs central (syslog/SIEM), envíe eventos de autenticación y firewall para correlación.

Paso 5: validar con escaneos controlados desde un host autorizado

La validación confirma que la superficie expuesta es la esperada. Realice pruebas solo desde un host autorizado y en una ventana controlada, para no generar alertas innecesarias ni afectar servicios.

1. Defina el origen autorizado: por ejemplo, el jump host 10.10.50.10.
2. Escaneo de puertos esperado (ejemplo con nmap): nmap -sS -p 22,80,443,ICMP? servidor (ajuste a su caso). Si SSH está en otro puerto: nmap -sS -p 2222 servidor.
3. Verifique resultados: solo deben aparecer abiertos los puertos necesarios (por ejemplo, 22/tcp solo accesible desde el origen autorizado; 443/tcp si hay servicio web).
4. Prueba negativa desde un origen no autorizado (si es posible en laboratorio o red controlada): confirme que SSH no responde o es bloqueado.
5. Correlacione con logs: confirme que los intentos bloqueados aparecen en los registros (SSH y/o firewall) con IP origen y timestamp.

Checklist rápido de endurecimiento (para uso operativo)