Content Delivery Network (CDN)

“Content Delivery Network” (CDN)  o Red de Entrega de Contenidos es la forma moderna de garantizar que nuestra página web pueda ser visitada por millones de usuarios y consiste, de manera muy simplificada, de repartir nuestro contenido estático a través de servidores ubicados físicamente en distintas partes del planeta, de tal manera que según sea la dirección IP del visitante se contacte con el servidor más cercano. Veamos ahora los detalles ¡vamos!

“Content Delivery Network” (CDN).

Content Delivery Network versus tradicional imagen de Wikipedia
Content Delivery Network versus tradicional imagen de Wikipedia

Para poder entender hacia dónde vamos debemos ver de dónde venimos.

El primer servidor web.

Tim Berner-Lee, inventor del hiperenlace y del internet tal como lo conocemos, arrancó con un ordenador avanzado para la época fabricado por la compañía “NEXT Computers” la cual fue fundada por el legendario Steve Jobs luego de que lo despidieron de “Apple Computer”, la empresa por él creada. En aquellos años 90 nosotros comprábamos la revista PCMagazine en castellano donde daban cuenta en un artículo que esas computadoras NEXT tenían la increíble cantidad de 1024 megabytes en RAM y costaba cada una más de 10 mil US$ ¡sorprendente!

Primer servidor web NEXT en el CERN
Primer servidor web NEXT en el CERN

A dicho computador le pegaron un papelito indicando que era un servidor y que no debía ser apagado, estaba alojando la primera página web del mundo y pocos usuarios se conectaban a ella, específicamente los investigadores del CERN (“European Organization for Nuclear Research” Organización Europea para la Investigación Nuclear).

Montando nuestra primera página web.

Pues hoy en día tenemos los mismos recursos -incluso rebasan- que contaban y disponían los investigadores europeos: ordenadores con más de 8 mil megabytes de RAM y 4 núcleos de 64 bits con conexiones fijas a internet con más de 1 mbps de velocidad y sin ningún límite de megabytes son comunes, ¿Qué nos impide montar en nuestro hogar u oficina nuestra página web? La limitación es que nuestro proveeedor de internet muy probablemente nos proporcionará una dirección IP dinámica: al apagar el modem y volverlo a encender tendremos una dirección IP diferente y a nuestros usuarios tendremos que volver a notificarles del cambio. Para evitar dicho inconveniente desde los albores del nacimiento del internet se utilizan los DNS “Domain Name Service” Servicio de Nombres de Dominios: son ordenadores que uno les pregunta por un dominio (dirección web) y nos devuelve la dirección IP para conectarnos al ordenador que contiene la página web deseada.

Lo anterior lo podemos simplificar con los teléfonos móviles celulares: cuando una amiga os da su número simplemente lo ingresamos al teléfono y le damos marcar y listo, la encontramos y conectamos. Pero luego recordar ese número es el problema, para ello nuestro celular tiene una agenda donde podemos colocar el nombre de la chica asociada a su número telefónico. En este ejemplo el DNS sería la agenda de contactos y el número de teléfono sería la dirección IP. Huelga decir que los DNS son más avanzados que la agenda de contactos: si un dominio cambia su dirección IP ésta es automáticamente actualizada, cosa que no hace el programita de agenda de contactos del celular (a menos que llamara todos los días a la chica confirmando el número telefónico ¡Qué locura!).

Tráfico hacia nuestra página web.

Con este escenario, un ordenador en nuestra casa u oficina, con un acceso a internet las 24 horas del día sin limites de megabytes y una dirección IP fija y un DNS configurado estamos prestos a difundir al mundo nuestro trabajo sobre el software libre. Pero para hacerle honor a la verdad, lo que distingue un servidor web de un ordenador normal es la redundancia de sus componentes, así que tienen al menos dos fuentes de poder (si una se “quema”queda la otra funcionando y se puede cambiar sin necesidad de apagar el servidor)tienen al menos dos discos duros en RAID (escriben y leen los mismos datos en ambos discos) y también se pueden reemplazar sin apagarlo (al conectar un disco nuevo automáticamente la tarjeta madre copiará los datos del disco viejo al nuevo y “emparejará” la información), memoria RAM de seguridad que -adivinen- internamente son dobles y almacenan y comparan ambas copias constantemente y también tienen dos o más tarjetas de red, generalmente ethernet con cables de cobre o fibra óptica, de igual manera si una falla queda la otra funcionando -y no se pueden reemplazar porque son integradas a la tarjeta madre pero se puede adicionar una(s) en una(s) ranura(s) PCI libre-.

En cuanto a qué podremos hacer con un ordenador con dos o más tarjetas de red (si tenéis un ordenador portátil con tarjeta de red inalámbrica y  ethernet podéis hacer pruebas)  varios usos le podemos dar:

  • Ambas tarjetas de red conectados a un concentrador/enrutador en una red de área local con diferentes direcciones IP (por supuesto de área local): podemos balancear la carga para enviar nuestra página web por ambas tarjetas, eso se configura facilmente con ifenslave para luego aplicar modprobe.
  • Una tarjeta de red conectada al modem y la otra al concentrador/enrutador para trabajarlo como “puente”.
  • Una tarjeta de red conectada al enrutador/concentrador y la otra a otro ordenador con una base de datos para aislar y aumentar la seguridad de nuestra información (páginas web dinámicas).
  • Una tarjeta de red conectada a un concentrador y la otra a otro para crear dos segmentos de red.
  • Muchas otras combinaciones (aquí imaginen ustedes).

Esto que acabamos de explicar es para ir “abriendo la mente”, para lo que luego queremos explicar acerca de los CDN’s.

Para continuar optaremos por configurar nuestro modem/concentrador/enrutador (hoy en día se puede dar los tres aparatos en uno, por eso decimos que tenemos más poder de hardware que los investigadores del CERN en los años 90). En todo caso explicamos que:

  • Un modem, generalmente ADSL, nos conecta a internet.
  • Un enrutador toma una dirección IP asignada a nuestro modem (que está en “modo puente”) y traslada las peticiones (NAT) a nuestra red de área local (LAN).
  • Un concentrador amplía la cantidad de puertos necesarios para conectar hasta 255 ordenadores en un segmento de red (la mayoría de enrutadores tienen 4 puertos físico alámbricos, son pocos en realidad).

Así las cosas nuestro enrutador recibe las peticiones y las reenvía a nuestro servidor web: hasta allí todo va bien, pero ¿qué sucede si recibimos más visitas?

Ampliando la cantidad de ordenadores en una LAN.

Con 4 ordenadores podemos realizar el siguiente esquema para atender más visitantes:

  • Ordenador 1: recibe las peticiones y balancea la carga de trabajo hacia los ordenadores 2 y 3.
  • Ordenadores 2 y 3 son los servidores web como tal, reciben las cabeceras de peticiones de ordenador 1.
  • Ordenador 4: será donde guardemos nuestra página web y que los ordenadores 2 y 3 se encargarán de verificar constantemente si tienen la última versión de nuestra página web.

Este esquema tiene como ventaja, por supuesto, el poder atender más visitantes, manteniendo nuestro trabajo original en el ordenador 4 y teniendo respaldos en los ordenadores 2 y 3, el punto débil de la cadena sería el ordenador 1, que balancea la carga ya que si falla se cae por completo nuestro dominio, ojo con eso. Como desventaja podríamos mencionar, entre otras, el registro de los visitantes (quién ha sido atendido por ordenador 2 y quién por ordenador 3), problemas con las carpetas temporales en el caso que nuestros usuarios necesiten “subir” archivos a nuestra página web y con respecto al lenguaje PHP el almacenamiento de las variables de sesión que no serán iguales para todas las páginas (aquí debemos aclarar que nuestra página web es un sitio web conformado por varias páginas que pueden ser servidas tanto por ordenador 2 y ordenador 3: un visitante puede ver una hoja en ordenador 1 y al cabo del tiempo al volver a visitar el balanceo de carga lo envia a ordenador 3 por lo tanto las variables de sesión PHP serán con distintos valores, lo que pudiera ocasionar problemas de programación -“amnesia” de las aplicaciones-).

Añadiendo más “ancho de banda” a nuestra conexión a internet.

Pues que llega un momento que nuestro humilde modem ADSL no da para más velocidad, así que le pedimos a nuestro Proveedor de Servicio de Internet (“Internet Service Provider” ISP) nos suba la velocidad pero va a ser que no, lo máximo ya lo tenemos, 10 mbps y ADSL2 que llega a 25 mbps no está disponible… Pues agregamos otra línea telefónica y otro modem y en teoría nuestro ISP debería colocarlos en modo vinculado “bonding”: con la misma dirección IP transmite por ambos modem entre nuestra casa u oficina hasta la central telefónica más cercana. ¿Recuerdan la redundancia de tarjetas de red en los servidores? Pues bueno, aquí es lo mismo, es una habilitación en una de las capas del modelo OSI, específicamente la capa física (de hecho cada modem en sí mismo cumple con esa capa y cada capa es independiente de las otras capas tanto por encima como por debajo).

Servidores espejos “mirrors”.

Pues he aquí que nuestro negocio o portal educativo ha crecido y expandido en todo nuestro país, o incluso hacia el exterior , así que decidimos contratar alojamiento web en nuestro país y/o el exterior. En esos ordenadores contratados colocaremos una sincronización de archivos para que al modificar nuestros ficheros se copien, al cabo de cierto tiempo, a los servidores espejo.

Como ya tenemos configurado nuestro balanceo de carga lo único que tenemos que configurar es que se redirija hacia unas direcciones IP que no están en nuestra red de área local, sino en internet. El pequeño detalle de esta configuración estriba en que nuestro alojamiento debe ser dedicado, tal como tenemos montado en nuestra casa u oficina, si es alojamiento compartido deberemos comprar otro dominio web porque de esa manera es que sabe un servidor web compartido qué datos mostrar al visitante.

shared hosting
shared hosting

Si contratamos un servidor dedicado bien puede ser una máquina real o, lo que es más común hoy en día, una máquina virtual que igual compartiremos con otros sitios web un ordenador físico pero con varias máquinas virtuales que tendrán sus propias tarjetas de red virtuales con sus propios y únicos MAC por los cuales se podrán identificar y asignar sus propias direcciones IP fijas (esto es particularmente atractivo para cuando migremos, por fin, a las direcciones IPv6)

Inconvenientes de los servidores espejos.

Pues como ya se habrán percatado, nuestra debilidad sigue siendo el “balanceador de carga”: nuestro dominio y por medio de los DNS sigue devolviendo una única dirección IP, la de nuestro ordenador en nuestra casa u oficina, ¡pues he aquí la brillante solución de los CDN!

CDN “Content Delivery Network”.

De nuevo simplificaremos al máximo para ilustrar de manera didáctica sobre el como funciona. A nivel mundial las direcciones IP están repartidas por grandes proveedores de acceso a internet o incluso por países enteros. Acá en Venezuela CANTV tiene su rango de direcciones IP asignadas, así que para los servidores web es “facil” determinar si nuestro visitante esta conectado por medio de ese proveedor de internet, simplemente comparando la dirección IP contra los rango registrados. Pueden incluso llegar  a determinar desde cual ciudad se conectan. Basado en esto:

  • Una empresa decide montar un CDN a nivel mundial, así que va país por país donde montar una granja de servidores con acceso a internet por medio de algún proveedor que a su vez tiene su rango de direcciones IP asignadas. Aparte de la compra de conexión en sí como tal, también se incluye la compra de un rango de direcciones IP para asignarlas a los ordenadores de la nueva granja.
  • El siguiente paso es configurar con algunas de esas máquinas unos servidores DNS (generalmente uno principal y otro secundario). Dichos servidores DNS estarán a la orden de los servidores DNS del proveedor de internet y llevarán registro de los dominios web que van a alojar.
  • Este procedimiento se repite país por páis, o región por región.
  • Una vez tengan “armada” la red es hora de ofrecer el servicio, no sin antes “unificar” todos sus servidores DNS para que operen como un conjunto armónico.

¿Cómo funciona el CDN?

Al comprar nosotros un alojamiento en CDN lo primero que tenemos que hacer es configurar ante quien nos vendió el nombre o dominio web y establecer los DNS de la empresa que ofrece el servicio CDN. Nuestro trabajo es seguir manteniendo nuestro “balanceador de carga” como siempre lo hemos hecho pero con privilegios especiales para que los ordenadores del CDN tengan acceso y copien nuestra página web y la distribuyan por cada una de las granjas de servidores que nombramos anteriormente.

Lo brillante de la idea de los CDN es analizar la dirección IP de un visitante de nuestra página web RECORDAD que primero tiene que pasar por los DNS del CDN para saber la dirección IP de nuestro balanceador de carga… PUES VA A SER QUE NO porque si nuestro visitante está más cerca de una granja de servidores del CDN pues le pasa esa dirección IP al visitante de una manera totalmente transparente, al fin y al cabo es una copia exacta de nuestra web lo que le va a ser retribuida al internauta.

Un  asunto importante para un CDN es el poder identificar según la dirección IP recibida del webnauta de dónde viene para redirigirlo a la granja de servidores más cercana -y que contiene copia de nuestra página(s) web-. Es por ello que muchas empresas ofrecen para descargar sus bases de datos, con su respectivo “manual de uso”, por ejemplo, desde MaxMind podeis visitar su página designada al respecto en este enlace. Esencialmente se resume en este comando, siempre respetando y considerando de no abusar del servicio:

wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCityv6-beta/GeoLiteCityv6.dat.gz

Dicha base de datos es utilizada por aplicaciones de seguridad para proteger servidores web de ataques maliciosos. Dado el caso que suframos un ataque masivo de denegación de servicio (millones de dispositivos al mismo tiempo visitan nuestra página web con la intención de saturarla y colapsarla) pues simplemente será repartida a lo largo y ancho del planeta. Puede darse el caso que el ataque provenga, por ejemplo, de millones de dispositivos infectados que están localizados fisicamente en Europa: pues bien las granjas de servidores ubicadas en Europa (digamos que hayan tres, una en Francia, otra en Inglaterra y otra en Italia) solo esas tres granjas de servidores serán colapsados, si es que pueden, mientras que las demás granjas en el resto del mundo mantendrán nuestra página web incólume.

 

Conclusión.

Si queremos simplificar a tope podríamos decir, en una gran perspectiva, que los CDN actúan como unos “balanceadores de carga” pero a una gran medida, no sin antes realizar un arduo rabajo de sincronización de DNS y contenidos web. Esperamos les haya sido útil la información.

Fuentes consultadas.

En idioma castellano.

En idioma inglés.

Recursos multimedia.

ProFTPD logotipo

ProFTPD tutorial en GNU/Linux Debian/Ubuntu

Muchas veces necesitamos copiar archivos de una computadora a otra de manera rápida y para ello podemos utilizar el Protocolo de Transferencia de Archivo (FTP por sus iniciales en inglés File Transfer Protocol). Pero para ellos debemos utilizar (sin importar el tipo  sistema operativo en ambas máquinas) un programa servidor y un programa cliente. Para el programa servidor en esta oportunidad presentamos ProFTPD un programa de código abierto -software libre- sobre el sistema operativo GNU/Linux. Para este tutorial utilizaremos Ubuntu como máquina servidora de archivos: bajoe ste ambiente instalaremos el ProFTPD.

Breve historia del FTP.

En 1971, mucho antes de inventarse el protocolo TCP/IP, ya había la necesidad de copiar archivos de un ordenador a otro, el problema es que ambas máquinas tenían sus propios “sistemas operativos” (eran los albores de la infomática: en realidad era un software que servía única y exclusivamente a cada modelo de máquina en particular, hoy día le decimos “firmware”). Para resolver este problema el programador indio Abhay Bhushan propuso la norma en el documento RFC 114 donde esbozó cómo hablarían las máquinas por medio de una conexión indirecta. Este método de conexión indirecta significaba que no se necesitaba un nombre de usuario o identificación (o incluso contraseña alguna) para acceder a los archivos de una computadora destinada a alojar datos (archivos).

Para aquella época la seguridad era muy simple: ¿quién tiene dinero para comprar una computadora y de paso tenerla en linea? “La nube” -como se empeñan en llamarla hoy- era muy pequeña, todos se conocían. Por ello no se pretendía ir más allá de resolver el problema de pasar datos por medio del  Programa de Control de Red de trabajo (NCP por sus siglas en inglés de “Network Control Program“) la primigenia y precursora capa de red para entonces. Aquí el sr. Bhushan propuso utilizar los caracteres ASCII siguientes para controlar los paquetes al transmitirlos: SOH, STX, ETX, DC1, DC2, DC3, US, RS, GS y FS. También se definió los comandos a utilizar definidos por un solo caracter ASCII: recordad que el hardware era lentísimo y cada bit ahorrado era tiempo ganado. Esto fue un denominador común en el nacimiento de TODOS los protocolos de esa época: debido a la limitación de hardware existente MENOS ES MÁS -y cuya principal consecuencia fue el “bug” del milenio en el año 2000, pero esa es otra historia-.

Así, por ejemplo, el comando “Retrieve” (descargar un archivo) se iniciaba con la letra “R” a lo que el servidor respondía con un “ready-to-send (rs)” enviando el caracter “>” y finalizaba de enviar el archivo con el comando “complete_file” enviando el caracter “*” (todo lo anterior “encapsulado” por los códigos STX y ETX, entre otros). Si quereís ahondar más en el uso de caracteres ASCII como “protocolo” de intercambio de información podeís hacer click en este enlace.

Ya para 1980 esta norma fue reemplazada por la RFC 765 donde soportaba los entonces nuevos protocolos TCP y TELNET (el señor Jon Postel, proponente, así aclara en la introducción donde asume el conocimiento previo de dichas normas). Además incluye una terminología donde incluye conceptos nuevos acorde con la tecnología y hardware exitentes y los comandos dejan de ser de un solo caracter a varios, iniciando así un lenguaje de alto nivel (lo comprendemos los humanos, por ejemplo, desconectarse o “logout” se enviaba un comando “QUIT“).

En 1985 de nuevo el señor Jon Postel -junto con J. Reynolds- lanza la RFC 959 donde reconoce los nuevos artefactos de computación y los define, aparte de agregar comandos opcionales como el famoso MKD -“make directory”, crear un directorio- sumando funcionalidad práctica los programas clientes. Esta sigue siendo la norma vigente hoy en día y la razón de su longevidad es que es muy parecida a todas las cosas que podemos hacer hoy día por medio de una linea de comandos en nuestras propias computadoras: copiar, renombrar, mover archivos, etc.


Nota curiosa: Jon Postel es el creador de 8 servidores de dominio raíz DNS agrupados bajo la figura de Internet Assigned Numbers Authority (IANA), lo cual hizo para separarse de la ARPANET (4 servidores raíz en control del ejército de los EE.UU.) sin perder conexión nunca -ni en ningún momento- ambas redes entre sí. A pesar de sus detractores, fue una acción heróica y por represión el gobierno hizo que se detractara en sus acciones y una semana después se adueñó de la IANA -incluso la Wikipedia apunta que la fundó el gobierno lo cual no es así, el autor intelectual es Postel- y el incidente quedó registrado en el RFC 2468. Postel murió 9 meses después del asunto debido a un ataque al corazón -¿quién no se preocuparía si tu propio gobierno te reprime en tus pensamientos?- y con el pasar de los años el triunfo fue para Jon Postel: hoy la IANA es apenas un departamento de la ICANN donde los “civiles” somos en realidad quienes controlamos los nombres de dominios en internet -insisto: siguen habiendo detractores de que no tenemos ese control pero esa discusión no la detallaremos en esta entrada-.


En 1994 en la RFC 1579 se agrega se Firewall-Friendly FTP (passive mode), en  1997 se hace un enmienda para agregarle seguridad en la RFC 2228 y en 1998 en la RFC 2428 hace soporte para IPv6 y define un nuevo modo pasivo de conexión. Este modo pasivo se agrega para dar soporte a servidores FTP que están en una red de área local regida por un NAT (un enrutador utilizado para compatir una conexión a internet entre varios ordenadores o artefactos) o un “Firewall” (filtro de conexiones entrantes utilizado para evitar entradas no autorizadas en una computadora).

Pero para que conozcaís cual es la diferencia entre modo activo y modo pasivo, vamos a explicarlo corriendo el riesgo de ser demasiados simplistas -catedráticos, PhD, licenciados, etc. perdonadme por adelantado debido a lo que os voy a decir-. El esquema de conexión (conocido hoy como conexión en modo activo) es el siguiente:

Conexión modo activo:

  1. Un servidor de archivos ejecuta constantemente (da servicio) un programa que “escucha” en el puerto 21 y “habla” por el puerto 20 (imaginemos una carretera doble vía: así evitamos colisiones de paquetes).
  2. Un cliente dado conoce la dirección IP del servidor y abre un puerto de escucha N.
  3. El cliente envia el comando “PORT” acompañado de su dirección IP y el puerto N abierto en el paso 2 al puerto 21 del servidor.
  4. El servidor envia respuesta por su puerto 20 al puerto N del cliente.
  5. Se ejecutan más comandos, los que se necesiten o deseen.
  6. Se cierra la conexión por cualquiera de las dos partes tras lo cual quien recibe el aviso de cierre contesta indicando que también cierra la conexión.

Conexión modo pasivo:

  1. Un servidor de archivos ejecuta constantemente un programa que “escucha” en el puerto 21 y “habla” por el puerto 20.
  2. Un cliente dado conoce la dirección IP del servidor y simplemnte envia al puerto 21 del servidor el comando “PASV” (está prohibido enviar algo más, es decir se vnia SIN parámetros).
  3. El servidor recibe por el puerto 21 y procede a abrir un puerto “de salida” N.
  4.  El servidor contesta por el puerto 20 enviando un código “227” más un texto explicativo más su propia dirección IP acompañado del puerto N abierto en el paso 3.
  5. El cliente recibe el mensaje del punto anterior y cuyo formato es el siguiente: “227 Entering Passive Mode. A1,A2,A3,A4,a1,a2” donde A1~A4 es la dirección IP y a1*256+a2=puerto N abierto en el servidor.
  6. Se ejecutan más comandos, los que se necesiten o deseen.
  7. Se cierra la conexión por cualquiera de las dos partes tras lo cual quien recibe el aviso de cierre contesta indicando que también cierra la conexión.

Comandos de respuesta numerados y agrupados.

En la sección anterior pudieron observar que el servidor responde con un comando numerado, 227 en el caso del comando PASV. En realidad todos los comandos que comienzan con el número 2 son comandos de respuesta exitosa y que se espera por un nuevo comando que no tiene que ver con el comando previamente enviado. El resto de las numeraciones de respuesta son las siguientes:

 1XX Comando exitoso y se espera un hilo de comandos (mantener orden estricto).
 2XX Comando exitoso y se esperan nuevos comandos.
 3XX El comando ha sido aceptado pero necesita más datos para completarlo.
 4XX El comando no se aceptó de manera temporal, se puede intentar de nuevo más tarde.
 5XX El comando se negó de plano, no reintentar.
 6XX Son utilizados en protocolos seguros de transferencia.
 X0X Errores de sintaxis o comandos superfluos.
 X1X Mensajes informativos.
 X2X Referentes a conexión.
 X3X Referentes a ingreso a cuentas y autenticación.
 X4X No especificados en la norma.
 X5X Referentes a sistemas de archivos.

Como podéis observar hay diversas combinaciones posibles, no obstante ya hay unos mensajes predefinidos que podéis observar en este enlace. No obstante no quiere decir que no hay más mensajes, por ejemplo Microsoft -empresa que gusta de hacer las cosas a su manera apalancados por muchísimo dinero de por medio- creó su propio mensaje no normado e identificado con el número 234 (“2” comando exitoso pero “3” se necesitan más datos para acceder a la cuenta y “4” un mensaje solo para nosotros los seres humanos). Así que si creaís vuestro propio sofware libre de servidor FTP no dudéis de informar a vuestro clientes con el código 234 cuando tengan problemas para autenticarse con vosotros y se lo explicáis bien amablemente. 😉


ProFTPD logotipo
ProFTPD logotipo

Breve historia del ProFTPD.

ProFTPD nace de la necesidad de tener un software con mayor seguridad y con miras a complementar al servidor web Apache. Sus autores invirtieron mucho tiempo y esfuerzo en WU-FTPD (wuarchive-ftpd), un servidor FTP para Unix, al cual le corrigieron muchos errores de seguridad. Pronto se dieron cuenta que lo mejor era comenzar un proyecto totalmente nuevo al cual denominaron ProFTPD. Su creador fue Jesse Sipprell (hoy retirado de su desarrollodo) y es mantenido a la fecha por TJ Saunders -y su equipo-.

Instalación del ProFTPD.

Teniendo nuestros repositorios bien configurados, abrimos una ventana terminal y ganamos acceso con usuario raíz root e introducimos los siguientes comandos:

apt-get update
apt-get install proftpd

Veremos algo similar a esto por pantalla:

apt-get install proftpd
apt-get install proftpd

Durante su instalación nos hará una sola pregunta, si lo queremos ejecutar sobre inetd (un demonio “daemonque escucha y recibe las solicitudes y ejecuta el programa adecuado) o si lo queremos ejecutar de manera completa “standalone“. La decisión en este caso depende de si queremos descargar archivos de vez en cuando o si queremos un servir múltiples conexiones. Con la capacidad de hardware de hoy en día el cual es más que suficiente para la mayoría de los usuarios, de manera predeterminada está seleccionada la opción “standalone“.

Y listo ¿A que fue fácil, verdad o no? Ahora para probarlo nos podemos conectar desde cualquier otro ordenador o dispositivo en nuestra red de área local con la dirección IP del servidor y con nuestro nombre de usuario -y contraseña- en nuestra distribución Ubuntu. Por defecto, todos los usuarios registrados en el sistema operativos del servidor tienen acceso vía ftp. Desde cualquier distribución GNU/Linux podemos conectarnos rápidamente por medio de la linea de comandos gracias a la utilidad ftp desarrollada para Unix en  4.2 BSD, acá ponemos una captura de pantalla hecha en Debian:

man ftp (4.2 BSD)
man ftp (4.2 BSD)

Configuración del ProFTPD.

Una vez probado os daréis cuenta que ProFTPD honra sobradamente los deseos del señor Abhay Bhushan. Aunque no podemos conectarnos de manera indirecta podemos habilitar la conexión anónima a nuestro servidor de la siguiente manera: se acostumbra utilizar como nombre de usuario la palabra anónimo en inglés “anonymous” y como contraseña nuestro correo electrónico con las restricciones de solo lectura en todos los directorios disponibles y como solo escritura en la carpeta “incoming”. Para ello debemos modificar al archivo “/etc/proftpd/proftpd.conf”. Primero debemos respaldar dicho archivo por asia caso cometemos cualqueir error podremos restaurar rapidamente los valores:

cp /etc/proftpd/proftpd.conf /etc/proftpd/proftpd.conf.bak
nano /etc/proftpd/proftpd.conf

E introducimos el contenido siguiente, tal como aconsejan en la propia página web de ProFTPD:

<Anonymous /home/ftp>
 # After anonymous login, daemon runs as user/group ftp.
 User ftp
 Group ftp

# The client login 'anonymous' is aliased to the "real" user 'ftp'.
 UserAlias anonymous ftp

# Deny write operations to all directories, except for 'incoming' where 
 # 'STOR' is allowed (but 'READ' operations are prohibited)

<Directory *>
 <Limit WRITE>
 DenyAll
 </Limit>
 </Directory>

<Directory incoming>
 <Limit READ >
 DenyAll
 </Limit>
 <Limit STOR>
 AllowAll
 </Limit>
 </Directory>

</Anonymous>

Luego ejecutamos el reinicio del servicio ftp:

sudo service proftpd restart

Unav vez reiniciado el servicio procedemos a comprobar de nuevo la conexión.

También es aconsejable cambiar, según nuestras necesidades, los siguientes parámetros de igual manera como acabamos de hacer con las conexiones anónimas:

  • UseIPv6: podemos colocarlo en “off” mientras no usemos IPv6, por defecto viene “on”.
  • ServerName: por defecto al instalarse le coloca el nombre dado al ordenador por medio del sistema operativo, pero tal vez necesitemos colocarle el nombre de nuestra empresa u organización.

Enlaces consultados.

En idioma castellano:

En idioma inglés:

En idioma castellano:

IPv6

Internet Protocol v6 (IPv6)

IPv6

A manera de prólogo.

Pues que con los bajos precios del petróleo aquí en Venezuela tenemos una fuerte crisis económica y apenas hemos podido pagar el alojamiento de esta vuestra página web -humilde sitio- y hemos estado alejados de la escritura. En la década de los 90 nos sucedió igual -duramos una semana comiendo sólo arroz- pero es de grata recordación una película que vimos en esa época sobre “El Diario de Ana Frank” -transmitida por una televisora llamada “Niños Cantores“- y que nos recuerda que podríamos estar mucho peor –mal de muchos, consuelo de tontos-. Pero lo cierto del caso es que el libro se escribió y existe, y es una prueba de la perseverancia y esperanza de la humanidad.

Por ello decidimos seguir preparándonos para el futuro, ya vendrán días de sol luego de estos días de lluvia -y hasta de tormenta- SEGUIMOS, NO NOS DETENEMOS. Retomamos, entonces, el tema de la informática desde sus bases, y algo que desde que estamos conectados a internet y aún usamos día a día es el “Internet Protoco version 4” o, por su acrónimo en inglés, IPv4. Simplemente el IPv6 viene a ser el sucesor (¡ea, que nos han volado la versión 5!) y para decirlo en forma llana, pues viene a proporcionarnos, prácticamente, direcciones IP infinitas, es decir, números de identificación exclusivas para cada adaptador de red (que eso ya lo sabéis, por ejemplo es bastante común que cada ordenador portátil tenga hoy en día al menos 2 maneras de conectar al internet: por ethernet o por WI-FI) pues cada uno de ellos tiene una dirección IP independendiente (luego veremos que esto no necesariamente así en IPv6).

Historia del protocolo IiPv6.

Vint Cerf, “Evangelista” en Jefe en la empresa Google, y uno de los fundadores del internet, expone la próxima versión del internet, IPv6, y por qué la necesitamos.

Cuando el internet fue puesto en práctica en 1983, nadie nunca soñó que habrían millardos de dispositivos y usuarios intentando estar en línea. Pero así como una red de telefonía se queda sin números telefónicos para sus abonado, el internetactual se quedó sin direcciones IP en 2013, y si no implementamos el Protocolo de Internet v6 (IPv6), no tendremos el espacio que necesitemos para que el internet crezca y esto podría liarlo, hacerlo inseguro e insustentable.

En el vídeo el señor Cerf nos explica con mayores detalles, usad los subtítulos generados en castellano (spanish) si es necesario:

Allí tenéis, pues, los enlaces PUROS Y DUROS hacia los conceptos, eso os llevará bastante tiempo analizar y asimilar o en el caso de los más avezados, recordar.

Aprendiendo de los mejores.

Debemos aprovechar el uso de la tecnología al máximo, es por ello que encontré esta exposición en Youtube, cortesía de “el maligno Alonso” (no nos asustéis, no tiene nada que ver con religión) y describe de la siguiente manera:

Conferencia de Rafael Sánchez (@r_a_ff_a_e_ll_o) de Eleven Paths sobre cómo montar un escenario de hacking IPv6 en Internet con un VPS y túneles IPv4/IPv6. Más información sobre esta sesión en esta URL.

Sin más aquí os dejo el vídeo, que va de lo más básico (una muy buena introducción a los conceptos y “bien machacado”) hasta lo más avanzado ( IPv6 dentro túnel VPS con IPv4, máquinas virtuales, Kali Linux, nmap, etc.) que es, como dicen ellos allá “para flipar” (aquí decimos “tripear” del inglés “to trip”, viajar o “elevarse”):

Podemos destacar los siguientes datos de la conferencia:

  • Podemos asignar a cada centímetro cuadrado de la superficie de la Tierra una dirección IPv6 (nos atrevemos a decir, además, que incluso sobrarían direcciones).
  • En Alemania está prohibido la exploración “escaneo” de red, osea, el estar revisando direcciones IP a ver cuáles tienen puertos abiertos “en escucha” -MUY IMPORTANTE este dato
  • En España aún no utilizan IPv6, vamos que para Venezuela lo puedo entender pero no justifico que allá estén retrasados con eso (una crítica con todo respeto).
  • NAT es una chapuza, estamos muy de acuerdo con eso.
  • En la conferencia no lo comenta pero CONSIDERAMOS -olvidemos por un momento que existe el “Wi-Fi“- el modelo “modem”+”router” desaparecerá porque precisamente los enrutadores fueron hechos para simplificar la implementación de una NAT, le facilita la vida a los usuarios. QUEREMOS DECIR que con IPv6 usaremos “modem“+”ethernet hub” o “modem”+”network switch” que aunque parecen lo mismo NO LO SON. Con el “ethernet hub” se envían, sin retraso, cada paquete a todas las computadoras conectadas al aparato. EN CAMBIO el segundo, “network switch” sólo enviará los paquetes a la máquina a la cual está destinada PERO con el costo de un retraso de hasta 1,2 milisegundos ya que debe recibir todo el paquete, leerlo y analizar de dónde viene y a donde va. Para mayor información, leer este excelente, corto y conciso manual (parece tecnología vieja PERO NO LA SUBESTIMÉIS por favor)

Para cada átomo en la Tierra hay 100 direcciones IPv6.

Podemos comenzar con esa abrumadora cifra: podemos asignar 100 direcciones IPv6 a cada átomo en la Tierra, al haber tanta oferta el “negocio” de las direcciones IP fijas o estáticas caerán a costo cero, ¡imaginamos!

Aquí ampliaremos sobre el tema (en construcción).


<Eso es todo, por ahora>.

Let’s Encrypt @LetsEncrypt.

Let’s Encrypt” es un proyecto de la “Electronic Frontier Foundation” en colaboración con la “Linux Foundation” para promover uso del protocolo HTTPS.

For english speakers: this is a merely translation into castilian language of an article year ago published by “Electronic Frontier Foundation” (also known as EFF acronym) where it announces the starting project “Let’s Encrypt”.

Let’s Encrypt: Vamos a encriptar.

Esta es una mera traducción al idioma castellano de un artículo publicado a hace un año atrás por la “Electronic Frontier Foundation” (también conocida por su acrónimo EFF) donde anuncian el comienzo del proyecto “Let’s Encrypt” (vamos a encryptar -la web-). Los enlaces web originales del artículo están en idioma inglés sin embargo algunos otros que agregué por mi cuenta están en castellano para rápidamente ayudar a entender algunos conceptos, si es que deseaís ampliar tus horizontes. Sin más, aquí va:


Hoy la EFF se complace en anunciar “Let’s Encrypt”, una nueva iniciativa de Autoridad de Certificación (CA por sus siglas en inglés) que hemos comenzado junto a Mozilla, Cisco, Akamai, IdenTrust e investigadores de la Universidad de Michigan cuyo objetivo es limpiar las barricadas restantes para la transición de la web del protocolo HTTP al protocolo HTTPS.

A pesar de que el protocolo HTTP ha tenido un éxito enorme, es inseguro de manera inherente. Cada vez que usted utilice una página web HTTP, siempre estará vulnerable a los problemas, incluyendo robo de cuentas y usurpación de identidad, vigilancia y seguimiento de gobiernos, compañías o ambos en conspiración; inyección de guiones maliciosos dentro de páginas; y censura cuyo objetivo son palabras específicas o sitios web específicos. El protocolo HTTPS, aunque todavía no es perfecto, es una gran mejora en todos los frentes, y necesitamos mudar a futuro cada sitio web al protocolo HTTPS por defecto. Con un lazamiento programado para el verano (boreal) del 2015 la Autoridad de Certificación “Let’s Encrypt” automáticamente expedirá y administrará certificados sin costo para cualquier sitio web que los necesite. Configurar un servidor web de HTTP al HTTPS con esta Autoridad de Certificación será tan fácil como emitir un comando, o hacer click en un botón.

El más grande obstáculo para el despliegue del HTTPS ha sido la complejidad, la burocracia y el costo que los certificados que HTTPS requiere. Estamos familiarizados con los mensajes de advertencias y error producidos por certificados mal configurados. Esas advertencia son una pista de que HTTPS (y otros usos del TLS/SSLseguridad de la capa de transporte/capa de conexión segura-) depende de una complejidad horrororosa y una burocracia estructuralmente disfuncional para la autenticación.

Advertencia de no-certificado.
“Let’s Encrypt” eliminará la mayoría de los tipos de errores de advertencias de certificados.

Instalación rápida y segura.

La necesidad de obtener, instalar y administrar certificados de esa burocracia es la mayor razón para que los sitios web sigan usando HTTP en vez de HTTPS. En nuestras pruebas, típicamente le toma a un programador web de 1 a 3 horas habilitar la encriptación por primera vez. El proyecto “Let’s encrypt”apunta a resolverlo reduciendo el tiempo a 20 ó 30 segundos. Usted puede ayudar a probar e indagar más sobre cómo funciona el agente de software “Let’s Encrypt” en su vista previa para desarrollador u observe un video de éste en acción:

“Let’s Encrypt” empleará un número nuevo de tecnologías para una verificación automatizada de manejo seguro de dominios y emisión de certificados. Usaremos un protocolo que estamos desarrollando llamado ACME entre servidores web y la Autoridad de Certificación, la cual incluye apoyo para nuevas y fuertes normas de validación de dominios. También emplearemos conjuntos de datos de certificados distribuidos a lo largo y ancho del internet, tales como el propio Observatorio Descentralizado SSL de la EFFF, el de la Universidad de Michigan, y el Registro Transparente de Certificados de Google, para tomar decisiones de mayor seguridad con respecto si un certificado es de emisión segura.

La Autoridad de Certificación “Let’s Encrypt” será operada por una nueva organización sin fines de lucro llamada Grupo de Investigación de Seguridad en Internet (Internet Security Research Group -ISRG-). “Electronic Frontier Foundation” ayudó a juntar esta iniciativa con Mozilla y la Universidad de Michigan, y se ha unido en el lanzamiento con socios tales como Cisco, Akamai e IdenTrust.

El equipo central que trabaja en la Autoridad de Certificación “Let’s Encrypt” y agente de software incluye a James Kasten, Seth Schoen, y Peter Eckersley por parte de la EFF; Josh Aas, Richard Barnes, Kevin Dick y Eric Rescorla por parte de Mozilla; Alex Halderman y James Kasten por parte de la Universidad de Michigan.


Por último (y fué publicado el 19 de octubre de 2015) les invito a ver el fruto del trabajo realizado durante largos años de colaboración unificada, la primera página “¡Hola mundo!” con certificados intermedios de referencia cruzada, de nuevo traduzco para ustedes (si usted sabe traducir mejor POR FAVOR registrese y comente esta entrada):


“Let’s Encrypt” es segura.

Estamos muy complacidos en anunciar que hemos recibido las firmas cruzadas proporcionadas por IdenTrust, lo cual significa que nuestros certificados son ahora seguros en la mayoría de navegadores web. Esto es un hito significativo debido a que los visitantes de sitios web con certificados “Let’s Encrypt” pueden disfrutar de una experiencia de navegación segura sin que requiera ninguna configuración especial.

Ambos certificados intermedios “Let’s Encrypt”, llamados “Autoridad X1 Let’s Encrypt” y “Autoridad X2 Let’s Encrypt”, recibieron firmas cruzadas. Los servidores web necesitarán ser configurados con el certificado de firmas cruzadas apropiado como aprte de la cadena de confianza. El cliente “Let’s Encrypt” manejará esto automáticamente.

Usted puede ver un ejemplo de un servidor utilizando un certificado “Let’s Encrypt” bajo una nueva firma cruzada intermedia aquí.
Información personal vital y de negocios está circulando por internet con más frecuencia que nunca, y es tiempo de encriptar todo esto. Es por eso que hemos creado “Let’s Encrypt”, y estamos animados en ser el gran paso que nos acerce a brindar conexiones seguras a cada rincón de la web.


Actualizado el lunes 18 de abril de 2016.

Cada día son más y más personas que reportan del éxito de “Let’s Encrypt” y aseguran sus sitios web con este protocolo seguro de comunicación para mantener la privacidad y seguridad de los internautas.

 

Estamos seguros que algún día aseguraremos esta vuestra página web para ustedes ¡pero @CaracasHosting POR AHORA no me deja siquiera instalar mi propio certificado autogenerado!

<Eso es todo, por ahora.>