Protocolos de seguridad (septiembre 2017)
A. Principales caractersticas.
INTRODUCTION
Un protocolo de seguridad define las reglas que
gobiernan estas comunicaciones, diseadas para que
el sistema pueda soportar ataques de carcter
malicioso.
Protegerse contra todos los ataques posibles es
generalmente muy costoso, por lo cual, los
protocolos son diseados bajo ciertas premisas con
respecto a los riesgos a los cuales el sistema est
expuesto.
I. PROTOCOLO IPSEC (IP SECURITY)
Una de las debilidades del protocolo original de
Internet es que carece de cualquier tipo de
mecanismo de propsito general para garantizar la
autenticidad y la privacidad de los datos a medida
que se pasa a travs de la internetwork. Dado que
los datagramas IP normalmente deben ser
encaminados entre dos dispositivos a travs de
redes desconocidas, cualquier informacin en ellos
est sujeta a ser interceptada e incluso posiblemente
modificada. Con el uso creciente de Internet para
aplicaciones crticas, se necesitaban mejoras de
seguridad para IP. Para ello, se desarroll un
conjunto de protocolos denominados IP Security o
IPSec.[1]
IPSec es un grupo de extensiones de la familia del
protocolo IP pensado para proveer servicios de
seguridad a nivel de red, de un modo transparente a
las aplicaciones superiores.
Control de accesos.
Integridad no orientada a la conexin.
Autenticacin del origen de datos.
Rechazo o reenvi de paquetes.
Confidencialidad.
Negociacin de compresin IP.
Adems de esto, es independiente de los algoritmos
criptogrficos actuales, contempla su
implementacin con IPv4 e IPv6, siendo un
componente obligado en IPv6.
B. Modo de funcionamiento.
Modo transporte (IP seguro):
- Se protege la carga til IP (payload) (capa de
transporte).
- Comunicacin segura extremo a extremo.
- Requiere implementacin de IPSec en ambos
hosts.
Modo tnel (IP seguro dentro de IP
estndar):
- Se protegen paquetes IP (capa de red).
- Para la comunicacin segura entre
routers/gateways de seguridad slo se puede usar
este modo.
- Permite incorporar IPSec sin afectar a los hosts.
Se integra cmodamente con VPNs.[2]
 II. SSL (SECURE SOCKETS LAYER)
Secure Sockets Layer (SSL) fue el protocolo
criptogrfico ms implementado para proporcionar
seguridad a travs de las comunicaciones por
Internet antes de que fuera precedido por TLS
(Transport Layer Security) en 1999. A pesar de la
depreciacin del protocolo SSL y la adopcin de
TLS en su lugar, la gente todava se refiere a este
tipo de tecnologa como "SSL".
SSL proporciona un canal seguro entre dos
mquinas o dispositivos que operan a travs de
Internet o una red interna. Un ejemplo comn es
cuando SSL se utiliza para asegurar la
comunicacin entre un navegador web y un servidor
web. Esto convierte la direccin de un sitio web de
HTTP a HTTPS, la 'S' significa 'seguro'.
Con tantas transacciones y comunicaciones de
nuestro da a da en lnea, hay muy poca razn para
no usar SSL. SSL admite los siguientes principios de
seguridad de la informacin:
Cifrado: protege las transmisiones de datos
(por ejemplo, navegador a servidor, servidor
a servidor, aplicacin a servidor, etc.)
Autenticacin: asegrese de que el servidor
al que est conectado sea el servidor correcto.
Integridad de datos: asegrese de que los
datos que se solicitan o envan son los que
realmente se entregan.
SSL se puede utilizar para proteger:
Transacciones en lnea con tarjeta de crdito
u otros pagos en lnea.
Trfico basado en Intranet, como redes
internas, comparticin de archivos, extranets
y conexiones de bases de datos.
Servidores Webmail como Outlook Web
Access, Exchange y Office Communications
Server.
La conexin entre un cliente de correo
electrnico como Microsoft Outlook y un
servidor de correo electrnico como
Microsoft Exchange.
La transferencia de archivos a travs de
HTTPS y FTP (s) de servicios, tales como
propietarios de sitios web actualizacin de
nuevas pginas a sus sitios web o la
transferencia de archivos de gran tamao.[3]
III. HTTP VS HTTPS
HTTP, Es un protocolo que permite la
comunicacin entre diferentes sistemas. Ms
comnmente, se utiliza para transferir datos de un
servidor web a un navegador para ver pginas web.
El problema es que los datos HTTP no estn
encriptados y pueden ser interceptados por terceros
para recopilar datos que se pasan entre los dos
sistemas.
Esto se puede resolver usando una versin segura
llamada HTTPS, donde el "S" significa seguro.
Esto implica el uso de un certificado SSL - "SSL"
significa capa de sockets seguros - que crea una
conexin cifrada segura entre el servidor web y el
navegador web.
Sin HTTPS, cualquier dato transmitido es inseguro.
Esto es especialmente importante para los sitios
donde se transmiten datos confidenciales a travs de
la conexin, como los sitios de comercio electrnico
que aceptan pagos con tarjeta en lnea o las reas de
inicio de sesin que requieren que los usuarios
introduzcan sus credenciales.
A. Cul es el proceso para cambiar a HTTPS?
Los pasos bsicos son los siguientes.
Adquiera un certificado SSL y una direccin
IP dedicada de su empresa de alojamiento.
Instale y configure el certificado SSL.
Realice una copia de seguridad completa de
su sitio en caso de que necesite volver.
Configure cualquier enlace interno duro
dentro de su sitio web, desde HTTP a
HTTPS.
 Actualice cualquier biblioteca de cdigo,
como JavaScript, Ajax y cualquier
complemento de terceros.
Redireccione cualquier enlace externo que
controle a HTTPS, como las listas de
directorios.
Actualice las aplicaciones htaccess, como
Apache Web Server, LiteSpeed, NGinx
Config y su funcin de administrador de
servicios de Internet (como Windows Web
Server), para redirigir el trfico HTTP a
HTTPS.
Si est utilizando una red de distribucin de
contenido (CDN), actualice la configuracin
SSL de su CDN.
Implementar redireccionamientos 301
pgina por pgina.
Actualice los vnculos que utiliza en las
herramientas de automatizacin de
marketing, como los enlaces de correo
electrnico.
Actualice las pginas de destino y los
enlaces de bsqueda pagados.
Configure un sitio HTTPS en Google Search
Console y Google Analytics.[4]
B. Versiones HTTP.
0.9 (lanzada en 1991).
HTTP/1.0 (mayo de 1996)
HTTP/1.1 (junio de 1999)1
HTTP/1.2 (febrero de 2000)
HTTP/2 (mayo de 2015)
IV. FTP VS FTPS
FTP es un protocolo muy bien establecido,
desarrollado en la dcada de 1970 para permitir que
dos computadoras para transferir datos a travs de
Internet. Una computadora acta como el servidor
para almacenar informacin y la otra acta como el
cliente para enviar o solicitar archivos desde el
servidor. El protocolo FTP utiliza tpicamente el
puerto 21 como su principal medio de
comunicacin. Un servidor FTP escuchar las
conexiones del cliente en el puerto 21.
Los clientes FTP se conectarn al servidor FTP en
el puerto 21 e iniciarn una conversacin. Esta
conexin principal se denomina Conexin de
Control o Conexin de Comando. Normalmente, el
cliente FTP se autenticar con el servidor FTP
enviando un nombre de usuario y una contrasea.
Despus de la autenticacin, el cliente y el servidor
normalmente, a travs de una serie de comandos
sincronizados controlados por Command
Connection, negociarn un nuevo puerto comn
denominado Conexin de datos sobre el que se
transferir el archivo. La conexin de control
permanece inactiva hasta el final de este
intercambio, cuando informa que la transferencia de
archivos ha fallado o se ha completado
correctamente. La conversacin entre el cliente y el
servidor se realiza en texto plano: toda la
comunicacin entre las dos partes se enva
desprotegida, literalmente, a travs de Internet. Esto
hace FTP muy inseguro; no sera terriblemente
difcil para un tercero, como un hombre en el medio
atacante (MITMA), para robar las credenciales de
los usuarios.
Mientras que el FTP genrico no es seguro, se han
aadido extensiones a lo largo de los aos para
permitir la seguridad de las conversaciones FTP, es
decir, la TLS (2048 bit Transport Layer Security), la
versin ms actualizada del antiguo estndar SSL
de 1024 bits. FTP a travs de SSL (FTP / S, como
es comnmente conocido) permite el cifrado de las
conexiones de control y de datos, ya sea de forma
concurrente o independiente. Esto es importante
porque la negociacin de la conexin SSL lleva
mucho tiempo y tener que hacerlo dos veces, una
vez para la conexin de datos y una vez para la
conexin de control, puede resultar costosa si un
cliente planea transferir un gran nmero de archivos
pequeos.
FTP / S normalmente se ejecuta en el puerto 990 ya
veces en el puerto 21, la principal diferencia es que
el puerto 990 es un FTP / S implcito, y el puerto 21
es un FTP / S explcito. Si un cliente se conecta a
un servidor FTP / S en el puerto 990, se supone que
el cliente tiene la intencin de realizar SSL. Por lo
tanto, el apretn de manos SSL tiene lugar
inmediatamente; se le denomina Implcito porque el
nmero de puerto implica seguridad. Clientes FTP
que se conectan en el puerto 21 y la intencin de
utilizar SSL para la seguridad tendr que dar el paso
adicional para indicar explcitamente sus
intenciones mediante el envo de una AUTH SSL o
AUTH TLS comando al servidor. Una vez que el
servidor recibe este comando, las dos partes realizan
un apretn de manos SSL y entran en un estado
seguro, por lo que el puerto 21 se denomina
xplicit. Esto permite al cliente la oportunidad de
activar una mayor seguridad cuando sea necesario o
acelerar el proceso en transferencias de archivos
menos sensibles a la seguridad.[5]
V. SET (SECURE ELECTRONIC TRANSACTION)
Secure Electronic Transaction (SET) es un sistema
para garantizar la seguridad de las transacciones
financieras en Internet. Fue apoyado inicialmente por
Mastercard, Visa, Microsoft, Netscape, y otros. Con
SET, se da a un usuario una cartera electrnica
(certificado digital) y se realiza una transaccin y se
verifica mediante una combinacin de certificados
digitales y firma digital entre el comprador, el
comerciante y el banco del comprador de manera que
garantice la privacidad y la confidencialidad. SET
hace uso de Secure Sockets Layer (SSL) de
Netscape, tecnologa de transaccin segura (STT) de
Microsoft y el protocolo de transferencia segura de
hipertexto (S-HTTP) del sistema Terisa). SET utiliza
algunos, pero no todos los aspectos de una
infraestructura de clave pblica (PKI).
A. Cmo funciona?
Suponga que un cliente tiene un explorador
habilitado para SET, como Netscape o Microsoft
Internet Explorer y que el proveedor de
transacciones (banco, tienda, etc.) tiene un servidor
habilitado para SET.
El cliente abre una cuenta bancaria MasterCard o
Visa. Cualquier emisor de una tarjeta de crdito es
algn tipo de banco.
El cliente recibe un certificado digital. Este archivo
electrnico funciona como una tarjeta de crdito
para compras en lnea u otras transacciones. Incluye
una clave pblica con una fecha de caducidad. Ha
sido a travs de un cambio digital al banco para
garantizar su validez.
Los comerciantes de terceros tambin reciben
certificados del banco. Estos certificados incluyen
la clave pblica del comerciante y la clave pblica
del banco.
El cliente realiza un pedido en una pgina Web, por
telfono o por otros medios.
El navegador del cliente recibe y confirma en el
certificado del comerciante que el comerciante es
vlido.
El navegador enva la informacin del pedido. Este
mensaje se cifra con la clave pblica del
comerciante, la informacin de pago, que se cifra
con la clave pblica del banco (que no puede ser
leda por el comerciante) y la informacin que
garantiza el pago slo se puede utilizar con este
pedido en particular.
El comerciante verifica al cliente comprobando la
firma digital en el certificado del cliente. Esto puede
hacerse remitiendo el certificado al banco oa un
verificador externo.
El comerciante enva el mensaje de pedido al banco.
Esto incluye la clave pblica del banco, la
informacin de pago del cliente (que el comerciante
no puede descifrar) y el certificado del comerciante.
El banco verifica el comerciante y el mensaje. El
banco utiliza la firma digital en el certificado con el
mensaje y verifica la parte de pago del mensaje.
El banco firma digitalmente y enva la autorizacin
al comerciante, que entonces puede llenar el
pedido.[6]
VI. SSH (SECURE SHELL)
SSH puede referirse tanto al protocolo de red
criptogrfica como al conjunto de utilidades que
implementa ese protocolo. SSH utiliza el modelo
cliente-servidor, conectando una aplicacin cliente
de Shell segura, el final en el que se muestra la
sesin, con un servidor SSH, el final en el que se
ejecuta la sesin.
Aparte de Microsoft Windows, el software SSH se
incluye por defecto en la mayora de los sistemas
operativos. SSH tambin soporta tneles, reenvi de
puertos TCP y conexiones X11 arbitrarias, mientras
que la transferencia de archivos puede realizarse
utilizando los protocolos de transferencia segura de
archivos o de copia segura (SCO) asociados. Un
servidor SSH, por defecto, escucha en el puerto
TCP 22.
La suite SSH se compone de tres utilidades-slogin,
ssh y scp que son versiones seguras de las
anteriores utilidades UNIX inseguras, rlogin, rsh,
rcp. SSH utiliza criptografa de clave pblica para
autenticar el equipo remoto y permitir que el equipo
remoto autentique al usuario, si es necesario.
La primera versin de SSH apareci en 1995 y fue
diseada por Tatu Ylnen, un investigador de la
Universidad de Tecnologa de Helsinki que fund
SSH Communications Security. Con el tiempo
varios defectos se han encontrado en SSH-1 y ahora
es obsoleto. El conjunto actual de protocolos Secure
Shell es SSH-2 y fue adoptado como estndar en
2006. No es compatible con SSH-1 y utiliza un
intercambio de claves Diffie-Hellman y una
comprobacin de integridad ms fuerte que utiliza
cdigos de autenticacin de mensajes para mejorar
la seguridad. Los clientes y servidores SSH pueden
utilizar una serie de mtodos de encriptacin, siendo
la mayora ampliamente utilizada AES y Blowfish .
Hasta el momento, no se conocen vulnerabilidades
explotables en SSH2, aunque la informacin filtrada
por Edward Snowden en 2013 sugiere que la
Agencia de Seguridad Nacional podra descifrar
algn trfico SSH.
Shellshock , un agujero de seguridad en el
procesador de comandos Bash , se puede ejecutar a
travs de SSH, pero es una vulnerabilidad en Bash,
no en SSH. En realidad, la mayor amenaza para
SSH es la mala gestin de claves. Sin la creacin
centralizada adecuada, la rotacin y la eliminacin
de claves SSH, las organizaciones pueden perder el
control sobre quin tiene acceso a qu recursos y
cundo, especialmente cuando se utiliza SSH en
procesos automatizados de aplicacin a aplicacin.
A. SSH vs TELNET.
Telnet fue diseado para funcionar dentro de una
red privada y no a travs de una red pblica donde
las amenazas pueden aparecer. Debido a esto, todos
los datos se transmiten en texto plano, incluyendo
contraseas. Este es un problema de seguridad
importante y los desarrolladores de SSH utilizan
cifrados para que sea ms difcil para otras personas
oler la contrasea y otra informacin relevante.
Telnet tambin omite otra medida de seguridad
llamada autenticacin. Esto asegura que la fuente de
los datos sigue siendo el mismo dispositivo y no
otro. Sin autenticacin, otra persona puede
interceptar la comunicacin y hacer lo que desea.
Esto tambin se aborda en SSH, ya que utiliza una
clave pblica para autenticar la fuente de los datos.
Debido a las medidas de seguridad necesarias para
que SSH sea utilizado en las redes pblicas, cada
paquete contiene menos datos para dar cabida a los
datos de los mecanismos de seguridad. Con el fin de
transmitir la misma cantidad de datos, que tendra
que tomar mucho ms ancho de banda. Esto se
llama sobrecarga y fue un problema tan importante
cuando la velocidad de Internet era muy baja, ya
que se traduce en un xito de rendimiento.
Los problemas de seguridad de Telnet obligaron a
mucha gente a usar SSH para protegerse. No tard
mucho tiempo antes de que SSH reemplazara a
Telnet en la gran mayora de sus usos. Sin embargo,
Telnet no se desvaneci porque todava se utiliza en
algunas reas, principalmente en pruebas y
depuracin. Las extensiones de Telnet se
desarrollaron para proporcionar seguridad, pero no
se utilizan en la mayora de las implementaciones
de Telnet.
Se puede decir que:
1. SSH y Telnet comnmente sirve el mismo
propsito
2. SSH es ms seguro en comparacin con Telnet
3. SSH cifra los datos mientras Telnet enva datos
en texto plano
4. SSH utiliza una clave pblica para la
autenticacin, mientras que Telnet no utiliza
ninguna autenticacin
5. SSH agrega un poco ms de sobrecarga al ancho
de banda en comparacin con Telnet
6. Telnet ha sido prcticamente reemplazado por
SSH en casi todos los usos.[7]

REFERENCIAS

[1] Charles M. Kozierok [En lnea]. Available:

http://www.tcpipguide.com/free/t_IPSecurityIPSecProtocols.ht
m
[2] MariCarmen Romero Ternero [En lnea]. Available:
http://www.dte.us.es/personal/mcromero/docs/ip/tema-
seguridad-IP.pdf
[3] GlobalSign [En lnea]. Available:
https://www.globalsign.com/en/ssl-information-center/what-
is-ssl/
[4] Tony Messer [En lnea]. Available:
https://www.entrepreneur.com/article.
[5] SRT Secure [En lnea]. Available:
https://southrivertech.com/whats-difference-ftp-sftp-ftps/
[6] Margaret Rouse [En lnea]. Available:
http://searchfinancialsecurity.techtarget.com/definition/Secure
-Electronic-Transaction.
[7] ] Margaret Rouse [En lnea]. Available:
http://searchsecurity.techtarget.com/definition/Secure-Shell