Tema 8
No toda comunicación de red ofrece el mismo nivel de protección. Elegir un protocolo inseguro o uno seguro cambia por completo el riesgo de exposición, la facilidad de interceptación y la confianza con la que se puede operar un servicio.
Un protocolo de red define cómo se intercambia información entre sistemas. Esa definición no solo afecta compatibilidad o rendimiento, sino también seguridad. Algunos protocolos nacieron en contextos donde la confidencialidad y la autenticación fuerte no eran prioridades. Otros fueron diseñados o evolucionaron para responder a esas necesidades.
En entornos modernos, mantener protocolos inseguros suele implicar exponer credenciales, sesiones, comandos o archivos a sniffing, manipulación o suplantación. Por eso, migrar hacia protocolos seguros es una de las mejoras más claras y de mayor impacto en la protección de una red.
En este tema compararemos pares habituales de protocolos para entender qué riesgos introduce cada uno y qué beneficios aporta su alternativa segura.
Un protocolo no es inseguro solo porque sea antiguo. Lo es cuando su diseño o su implementación dejan expuestos elementos críticos de la comunicación. Las debilidades más comunes son:
La versión segura de un protocolo o un protocolo alternativo bien diseñado suele introducir uno o varios de estos mecanismos:
HTTP es un protocolo de aplicación utilizado para transferir páginas web y otros recursos. Por sí solo, no cifra la comunicación. HTTPS combina HTTP con TLS para aportar confidencialidad, integridad y autenticación del servidor mediante certificados digitales.
En HTTP tradicional, un observador en el camino puede ver:
Con HTTPS correctamente implementado, gran parte de esa información queda protegida frente a interceptación y manipulación.
| Riesgo | Cómo ocurre | Impacto |
|---|---|---|
| Sniffing | El tráfico viaja visible para observadores | Exposición de contenido y credenciales |
| MITM | El atacante intercepta y modifica respuestas | Redirecciones o inserción de contenido malicioso |
| Secuestro de sesión | Cookies visibles o reutilizables | Acceso no autorizado a cuentas |
| Falsa confianza | El usuario asume legitimidad sin validación robusta | Mayor exposición a fraude o phishing |
HTTPS mejora mucho la seguridad del canal, pero no convierte automáticamente una aplicación en segura. Si la aplicación tiene vulnerabilidades lógicas, mala gestión de sesiones o autenticación deficiente, TLS no resolverá esos problemas.
HTTPS protege el transporte. Aun así, deben cuidarse:
Telnet fue durante años un protocolo clásico para acceso remoto interactivo a equipos y servidores. Su problema principal es que transmite información en claro, incluyendo usuario, contraseña y comandos ejecutados.
SSH, o Secure Shell, fue diseñado precisamente para ofrecer acceso remoto seguro. Proporciona cifrado, autenticación del servidor y distintos mecanismos de autenticación del cliente, además de capacidades adicionales como túneles y copia segura.
Usar Telnet para administrar infraestructura expone uno de los activos más sensibles de una red: el plano de control. Por eso su reemplazo por SSH es una medida básica de endurecimiento.
Eso no significa que cualquier SSH sea automáticamente seguro. La gestión de claves, los algoritmos habilitados, el acceso desde redes adecuadas y la autenticación multifactor siguen siendo importantes.
FTP fue diseñado para transferir archivos entre sistemas, pero no cifra ni credenciales ni contenidos. Además, su operación involucra varios aspectos del canal de control y de datos que pueden complicar filtrado y exposición.
SFTP, en cambio, funciona sobre SSH y proporciona una transferencia de archivos segura dentro de un canal cifrado. No debe confundirse con FTPS, que es otra forma de securizar FTP mediante TLS. En este curso nos enfocamos en SFTP por su uso extendido y por la claridad conceptual del cambio respecto de FTP.
En contextos donde se transfieren datos sensibles, mantener FTP es una decisión difícil de justificar desde la seguridad.
| Aspecto | FTP | SFTP |
|---|---|---|
| Cifrado | No | Sí, a través de SSH |
| Credenciales protegidas | No | Sí |
| Integridad del canal | Débil o inexistente | Sí |
| Gestión de autenticación | Más limitada | Puede usar claves y políticas SSH |
| Seguridad general | Baja | Muy superior |
Aunque este tema se centra en tres pares muy comunes, la misma lógica aplica a muchos otros servicios de red:
Elegir un protocolo seguro no solo protege el contenido del tráfico. También cambia cómo se diseña el monitoreo, cómo se publica un servicio, qué controles compensatorios hacen falta y qué tan fácil resulta escalar la protección a lo largo del tiempo.
Por ejemplo, mantener un protocolo inseguro puede obligar a reforzar mucho más la segmentación, restringir severamente desde dónde se accede o depender de túneles adicionales para compensar una debilidad del diseño original.
Los protocolos seguros son una de las capas más directas y efectivas de protección en redes. No eliminan todos los riesgos, pero reducen de manera sustancial la capacidad de observar, robar o manipular comunicaciones. Elegir correctamente entre una opción insegura y una segura es una decisión básica que impacta en toda la arquitectura.
En el próximo tema estudiaremos cifrado en tránsito, TLS, certificados y PKI para profundizar en los mecanismos que hacen posible muchas de estas comunicaciones seguras.