-->
Buenas a todos.
Ya hemos conseguido conectarnos de manera remota a nuestro server. Consecuencia: el monitor se lo he devuelto a mi hijo, y mi server ya no tiene ni teclado, ni monitor. Pero antes de seguir instalando servicios, y quitar teclado y monitor, vamos a asegurar un poquito más nuestro acceso. Primero, editamos el archivo de configuración de ssh, y denegamos acceso remoto como root. Es un poco peligroso ir conectándonos como root por ahí a nuestro servidor. Una vez conectados con nuestro usuario “cosillas”, si necesitamos acceso como root, basta con teclear el comando su y poner la contraseña de root.
-->
Además, vamos a cambiar el puerto de acceso por ssh. Hay muchos hackers en la red que se dedican a buscar accesos a servidores en los puertos habituales (0 a 1023), así que vamos a ponérselo difícil. En el mismo archivo, cambiamos el valor de puerto a 12678, por ejemplo. O 27087, o 33288... Mientras no sea un puerto dedicado, tenéis hasta el 65536 para utilizar, es decir, que podéis elegir cualquier puerto desde el 1025 hasta el 65536. Voy a poner el 12321, por ejemplo. Editamos el archivo: nano /etc/ssh/sshd_config
Ahora ya tenemos más seguro nuestro acceso y nos podemos conectar, añadiendo el puerto:
ssh cosillas@cosillas.ftp21.net -p 12321
-->
Hoy vamos a aprender algo de los DNS. Para los que no lo saben, DNS es el sistema que se utiliza para localizar en una red un nombre de equipo determinado. Así, nuestro navegador “sabe” que www.linuxmint.com tiene por dirección IP 109.203.97.80. Y lo sabe gracias a que se lo pregunta a una serie de servidores que hay por ahí fuera, no es porque sea muy listo. En esos servidores se almacena la información que relaciona el nombre de la pagina electrónica con su dirección IP. Y si un servidor no lo sabe, pues se lo pregunta a otro, y así sucesivamente hasta llegar al error de página no encontrada.
Estas búsquedas se van almacenando en dichos servidores en cachés, habitualmente dinámicas. Así, si queremos navegar a la página www.debian.org, y la información de dicha página no se encuentra en los DNS de nuestro proveedor, guardará la información de qué salto ha dado nuestro DNS para encontrar otro DNS que tenga la información, consiguiendo así que el próximo requerimiento de acceso a dicha página sea más rápida. Para evitar sobrecargar dichas cachés (según datos de 2008, Google tenía indexadas 1 trillón de páginas), si en un periodo de tiempo determinado no hay peticiones a esa página, esa información se borra .
Bueno, como vemos, nuestro proveedor nos ofrece unos DNS para poder navegar por la web. Pero, ¿podríamos tener nosotros nuestro propio servidor DNS? Y en caso afirmativo, ¿para qué serviría? Pues la respuesta a la primera pregunta es sí, y a la segunda es para mejorar la velocidad de navegación, aunque no os creáis que es la panacea, ¿eh? El que tenga 10 MB contratados, que no crea que va a navegar a 30 MB.... Eso sí, la navegación a las páginas que más usemos será más rápida, porque crearemos nuestra propia caché.
¿Y cómo funciona? Pues, evidentemente, preguntando a otros servidores DNS.... obvio, ¿no?. Pero, ¿merece la pena?. Yo pienso que para lo que estamos utilizando nuestro servidor, no es necesario tener nuestras propias DNS. Mi experiencia me indica que éstos se crean en sistemas sin acceso a Internet, equipos capados que utilizan únicamente la Intranet de la empresa ó con sistemas proxy para acceso a Internet. Ese no es nuestro caso, pero una pregunta de Eduardo en el post anterior, indicando que quería utilizar su server como gateway, me “obliga” a instalarlo y configurarlo. En un próximo post, instalaremos una segunda tarjeta de red en nuestro server, e implementaremos DNS e IP FORWARDING. Y yo había pensado terminar esto en 4 post..... En fin.....
-->
Y, ¿que sabemos del DHCP? El fin básico de un servidor DHCP es servir direcciones IP a la red local, utilizaremos esta utilidad más adelante para otros servicios. Así que vamos al lío. Primero de todo, desactivar el DHCP de nuestro router. Si, pensad que es una obviedad, pero no seríais los primeros (ni los últimos) que se olvidan de esto. Caso verídico, en carne propia:
Hace unos años, sonaron todas las alarmas en un cliente de mi empresa. Un edificio de tres plantas, con atención al público incluída, unos 200 equipos en total entre CPU's e impresoras de red..... todos, absolutamente todos, sin acceso al servidor después de un corte de luz (nuestro amigo Juanele.... que crack!)
Allá que va Jose... todos haciéndome la ola.... ¡el informático!¡ha llegado el informático!. Entro al servidor, DHCP funcionando, pool definido y correcto, servicio levantado, conexión con la electrónica de red correcta..... Me conecto a la electrónica de red, 5 switch Cisco de 48 bocas estacados, reviso configuraciones, todo correcto..... Bueno, solución del informático, apaga y enciende..... Todo igual.... Me voy a un equipo cualquiera, y veo que la IP no está en el rango de la red corporativa. ¡Meca! ¿Esto qué es?.... ipconfig/release, ipconfig/renew..... y funcionando. Pffff.... me quedan 199..... O encuentro al hijo de …. que ha conectado un router 3Com a la red en su despacho, todavía no sé para qué..... Claro, el router 3Com y los equipos arrancaron antes que el servidor, y como todo va por DHCP, pues cogieron el primer DHCP que encontraron, el del router 3Com.....
nosotros desactivamos el DHCP de nuestro router. Me remito a San Google para ver cómo hacerlo cada uno con el suyo.-->
Ahora en el server:apt-get install dhcp3-server
Vale, da errores. No les hagáis caso, todavía no está configurado. Ahora editamos el archivo /etc/default/isc-dhcp-server para establecer la tarjeta de red que "dará" las direcciones IP.
-->
Editamos el archivo de configuracion que viene predefinido:nano /etc/dhcp/dhcpd.conf
El escenario es el siguiente: queremos crear una red tipo 10.14.100.x/24. Esto quiere decir que tendremos direcciones ip desde la 10.14.100.1 hasta la 10.14.100.254.
Pero no las queremos todas, sólo vamos a repartir 6 direcciones, en concreto desde la 10.14.100.110 a la 10.14.100.115.
El servidor tiene IP 10.14.100.100
El router tiene IP 10.14.100.1
Las DNS de nuestro proveedor son las de Movistar, por ejemplo: 80.58.61.250 y 80.58.61.254.
Queremos asignar a nuestra impresora de red la IP 10.14.100.10, a la cámara web la IP 10.14.100.20, y al ordenador del niño la IP 10.14.100.50
-->
subnet 10.14.100.0 netmask 255.255.255.0{
range 10.14.100.110 10.14.100.115;
option domain-name-servers 80.58.61.250, 80.58.61.254;
option domain-name "cosillas.ftp21.net";
option routers 10.14.100.1;
default-lease-time 600;
max-lease-time 7200;
}
host impresora_red{
hardware ethernet 01:02:03:04:05:06;
fixed-address 10.14.100.10;
}
host camara_web{
hardware ethernet 06:05:04:03:02:01;
fixed-address 10.14.100.20;
}
host computer_hijo{
hardware ethernet 00:01:02:02:01:00;
fixed-address 10.14.100.50;
}
Finalmente reiniciamos el servicio DHCP: /etc/init.d/isc-dhcp-server restart
-->
Configuramos nuestros clientes (cualquier s.o.) para que la IP sea por DHCP, y veremos como van cogiendo la ip con los valores especificados.
Nuestra impresora de red, que tiene por Mac Address 01:02:03:04:05:06, se configurará con la IP 192.168.0.10, nuestra cámara web obtendrá la IP 192.168.0.20. y el ordenador del niño la 192.168.0.50
Esto último nos será bastante útil en los siguientes post de la serie. Teniendo como puerta de enlace nuestro server, y estableciendo la IP que queremos que tenga una tarjeta de red determinada, podemos después, con IPTABLES, efectuar filtros de acceso. Por ejemplo: Nuestro querido hijo está obsesionado con las redes sociales, y las notas no han sido excesivamente buenas. Podemos optar por denegarle acceso total a la web, especificar a qué puertos tiene acceso, etc....
Continuamos con el siguiente paso. ¡Por fin! Vamos a crear nuestro FTP. Luego lo aseguraremos. Como cliente FTP voy a utilizar la consola y CuteFtp.
-->
Pero, ¿qué es un FTP?. FTP es el acrónimo de File Transport Protocol, Protocolo de Transporte de Ficheros. Así, FTP es un protocolo utilizado para transmitir ficheros entre dos ordenadores remotamente. Este protocolo es muy inseguro, ya que la transmisión de los datos de usuario y contraseña se hace en modo texto, sin cifrar, por lo que cualquier sniffer conectado a nuestra red será capaz de ver los datos de acceso a nuestro servidor FTP. Como comentaba en el primer post de esta serie, todo depende de lo “secretos” que sean los datos que tenemos en nuestro FTP, pero aún así, no es de recibo dejar usar nuestro FTP a cualquiera, ¿no?.
El FTP utiliza por defecto el puerto 21. Al igual que SSH, podemos cambiar el puerto utilizado, eso lo dejo al gusto de cada uno. Durante la instalación y pruebas, trabajaré en red local, y al final, abriremos el puerto 21 (o el que hayáis decido cada uno) en el router, redireccionando a nuestro server.
Para dejar acceso a cualquiera, se utiliza el acceso anónimo, que se configura habitualmente como acceso de sólo lectura; pero no es eso lo que buscamos, ¿verdad?. Lo que nos interesa es un FTP robusto, donde tener nuestros datos a mano, en cualquier parte del mundo, a salvo de miradas indiscretas.
¿Cómo evitaremos esto? Se puede configurar el FTP para que exija autenticación al usuario, y la transmisión de datos encriptados. Para ello, tendremos que activar el soporte para TLS (Transport Layer Security ó Seguridad de la Capa de Transporte), en resumen: encriptación de los datos. Para rizar el rizo, tendremos que utilizar certificados SSL, autofirmados o no, que generaremos nosotros mismos (esto se va complicando cada vez más.....)
Llegados a este punto, pregunto: ¿Alguien pensó de verdad que esta aventura sería fácil?
-->
Al que quiera salir corriendo sólo le diré una cosa: Correr es de cobardes y de malos toreros.
Vamos al lío.
No hay una guía única para construir nuestro FTP. Donde unos dicen -”este punto es imprescindible, y tiene que ser de esta manera”- otros dicen todo lo contrario. Esto no tiene porqué ser un problema, sino una muestra de la versatilidad y capacidad de configuración del mismo. Y en este punto, tengo que deciros que no es porque estemos en Linux, ya que lo mismo ocurre en el lado oscuro (al César lo que es del César). Yo voy a montar el mío, como a mí me gusta. Podéis seguirme, utilizarme de guía, o hacer todo lo contrario, faltaría más.
Conectados al server, tecleamos: apt-get install proftpd
Se ejecuta el configurador:
Seleccionamos la opción
independiente (standalone), así, el servicio se ejecuta como un proceso independiente, y se finaliza la instalación:
-->
Como veis, ha creado el directorio /home/ftp, y los usuario ftp y proftpdcon el grupo nogroup. Después veremos para qué sirve. Bueno, pues os lo creáis o no, esto ya está montado. Ya me estoy imaginando vuestras caras. Y todo el rollo de antes, ¿para qué?. Vamos paso a paso. Nos conectamos al FTP con nuestro usuario cosillas:
-->
… tenemos el servidor más inseguro del mundo. Con el trabajito que nos dimos asegurando el SSH, ahora resulta que cualquier hijo de vecino puede “escuchar” nuestro password, y después puede robarnos nuestra clave de root.... Si, vale, no tenemos el servidor de la CIA, pero, por lo menos yo, o hago las cosas bien, o no las hago. Vamos a arreglarlo un poco. Podemos restringir el acceso al directorio home del usuario que se conecta, o bien a un directorio específico.
Editamos el archivo de configuración y vamos cambiando datos:
nano /etc/proftpd/proftpd.conf
UseIPv6 -> cambiamos el valor a off
ServerName -> cambiamos el valor. En mi caso, "cosillas"
Descomentamos la entrada DefaultRoot, y, o bien la dejamos como está (sólo dejaría acceso al home del usuario conectado) o bien añadimos el directorio donde queremos que se conecte. Voy a utilizar la primera opción, dejándolo de la siguiente manera:
DefaultRoot ~
Así, conseguimos que no se pueda salir del home del usuario.
-->
¿Es suficiente con eso? De momento si. No voy a tratar la instalación de un FTP anónimo, no me interesa. Es muy sencillo para quien quiera hacerlo, sólo tiene que descomentar la parte del archivo de configuración protfpd.conf y cambiar alguno de los valores por defecto para adaptarlo a vuestro server (viene todo comentado, en perfecto inglés).
Yo voy a ir un paso más allá, y voy a asegurar mi FTP. Voy a exigir la autenticación del usuario, y la encriptación de los datos transmitidos. Para ello, tenemos que activar TLS (Transport Layer Security ó Seguridad de la Capa de Transporte). Activando TLS, aseguramos nuestros datos, tanto de usuario/contraseña como de información transmitida. Para ello, utilizaremos certificados. Los certificados son emitidos por entidades certificadoras independientes y de confianza reconocida. Pero eso cuesta dinerito.
Es posible crear un certificado "auto-firmado", que nos servirá para autentificarnos en nuestro server, no lo intentéis utilizar para otra cosa, porque saltarán todas las alarmas de seguridad..... Es broma, no aparecrá el FBI, pero no os servirá para autentificaros en sistemas “oficiales”.
Sin perder el tiempo con teoría, instalamos el software necesario: apt-get openssl ca-certificates
-->
Vamos a crearnos una carpeta de trabajo para los certificados, mkdir certificates y trabajaremos desde ella.
Lo primero que vamos a hacer es generar una clave privada:
openssl genrsa -des3 -out server.key 2048
-->
Como veis, está asegurada por una clave, que tendremos que teclear siempre, o podemos generar una versión de esta clave sin la protección de la contraseña:
openssl rsa -in server.key -out server.key.signed
-->
¡ATENCION! Esta clave sin contraseña, debe ser tratada con esmero, y hacerla sólo accesible al usuario root:
chmod 600 server.key.signed
-->
Bien. El siguiente paso sería generar un pedido de certificación a una entidad certificadora. Nos va a pedir una serie de datos.
openssl req -new -key server.key -out server.csr
-->
Una vez generado el pedido de certificación, se supone que debería ser enviado a una entidad certificadora, que nos devolvería el certificado firmado. Como eso cuesta dinerito, y estamos en crisis, utilizamos el pedido para generar nosotros mismos el certificado firmado. Estamos seguros que somos nosotros mismos, ¿no?.... pues para qué vamos a pagar a alguien para que diga que si, que somos nosotros.... Ea, pues eso:
openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
-->
Pues ya tenemos nuestro propio certificado, firmado y válido por diez años, para nuestro servidor. Eso sí, hay que copiarlos a su sitio correspondiente:
Copiamos server.key y server.key.signed a /etc/ssl/private/
Copiamos server.crt a /etc/ssl/certs/
-->
Bueno, pues si habéis conseguido generar sin error vuestro certificado, vamos a indicarle al FTP que sólo se pueden conectar con certificados, aunque realmente lo que nos interesa es que la información se transmita de manera cifrada, pero para conseguir esto último, es necesario activar la conexión mediante certificados.
Es sencillo: Editamos el archivo /etc/proftpd/tls.conf y descomentamos las lineas siguientes:
TLSEngine
TLSLog
TLSProtocol
-->
Descomentamos y escribimos nuestro certificado:
TLSRSACertificateFile /etc/ssl/certs/server.crt
TLSRSACertificateKeyFile /etc/ssl/private/server.key.signed
-->
Descomentamos el siguiente valor, ya que si no lo hacemos, el FTP aceptaría también conexiones sin firmar:
-->
Añadimos la siguiente línea:
TLSOptions NoSessionReuseRequired
Salvamos los cambios.
Ahora editamos el archivo /etc/proftpd/proftpd.conf para incluir el archivo anterior:
Include /etc/proftpd/tls.conf
-->
Reiniciamos proftpd y probamos a conectarnos, ahora con el programa filezilla:
Vemos que exige conexión por SSL. Editamos una nueva conexión:
Marcamos los siguientes valores y damos a conectar:
Aceptamos el certificado emitido por el servidor y.....
Et voilá, ya tenemos nuestro ftp funcionando y asegurado. Es el momento de activar en el router el reenvío de paquetes recibidos por el puerto 21 a la IP de nuestro server para poder conectarnos desde cualquier sitio.
-->
En fín, aquí os dejo el FTP. Espero que os sirva, y volveré en un par de semanas, porque éste que está aquí, se va a la playa en dos días, y no pienso llevarme mi portátil. Necesito desconectar.
Saludos y que lo paséis bien.
