Ricardo Bartolomé

Buenas de nuevo. Hoy de tarde fue brutal, nunca trabajé tanto, en serio. Bermejo nos mando un ejercicio bastante peculiar, os explico:

Imaginad que tenemos una empresa con conexión a internet. Ésta pasa por un router que a la vez hace funciones de cortafuegos, por lo tanto este cortafuegos, de ahora en adelante “Router externo”, tiene una IP pública y una privada que es 172.16.0.254. En esta red 172.16.0.0/16 y sin haber subredes, es la zona desmilitarizada (DMZ) donde se encuentra un servidor Web con acceso SSH (172.16.0.1), un servidor DNS (172.16.0.2) y una máquina con “Escritorio remoto de Windows 2003″ (172.16.0.3). Después de esta zona DMZ, hay aún otra red, la de los ordenadores de la empresa en sí, montaba en 10.0.0.0/24. Los equipos son 10.0.0.1, 10.0.0.2 y 10.0.0.3.
Estos clientes tienes que poder navegar, recibir correo y demás, y a la vez estar protegidos de internet.
Por otra parte, los clientes 1 y 3 pueden acceder al servidor DNS, escritorio remoto y a la Web del servidor, pero no a SSH. El otro equipo, el equipo 2, con IP 10.0.0.2/24, tendría prohibido el acceso a escritorio remoto. SSH como es un servicio privilegiado, solo una IP debería poder acceder a él y es la IP 192.168.16.114 (Si, es privada, pero luego el explico).

Como veis es algo lioso, hoy hemos terminado casi lo que comprende la zona privada (DMZ y Clientes). Nos falta pasarle unos filtros en Windows 2003, con políticas por defecto DROP (perdón, denegar xD) y permitir solo lo que queremos.

El router externo tendrá que hacer prerouting con el puerto 22 y permitir navegar y demás. El prerouting se usaría para que un ssh -p 22 usuaario@IPPublica, le llebase hasta el servidor interno de la red donde el servidor SSH está corriendo.

El tema de por qué el Cliente externo que ha de estar solamente autorizado a conectar a SSH , tenga una IP 192.168.16.114 es la siguiente. El esquema en clase está así:

Internet –> 212.x.x.x || EISO (Enrrutador de la academia) || 192.168.x.x (En nuestor caso, aula 16, sería 192.168.16.1) –> 192.168.16.254 || Router externo || 172.16.0.254 –> DMZ en 172.16.0.0/16 –> 172.168.0.253 || Router Interno || 10.0.0.253 –> Clientes en 10.0.0.0/24

Bien, así, desde 192.168.16.114 se tendrá que pasar por el Router externo para acceder a la DMZ.

Muy útil y entretenido, solo le falta uan cosa, hacerlo bajo la SuSE Enterprise y sí, lo haremos

Agur

Arf, estioy asqueado, ayer después de haber comido en “El descanso” e ir para clase, nos tocó clase con Bermejo. Como es de costumbre aún, estumimos dando NAT en Windows 2003. Vamos resumiendo, haciendo de pasarela de conexiones y haciendo de router, la primera se basaba en un equipo 10.0.0.2 pidiese a 192.168.16.169 (SuSE Enterprise 9) una web teniendo como puerta de enlace 10.0.0.1 (El router Windows 2003).
El otro método era poner tanto el servidor como el cliente en clase C (pero diferentes redes) y como gateway a 10.0.0.1 (el 2003). Luego el cliente (192.168.9.112) accedería a 192.168.9.216 (La interface 2 del router) y éste le redirigiese la petición al puerto 80 a 192.168.16.169 (El servidor web), vamos, como un router propiamente dicho hace.
En IPTAbles si no me equivoco elprimer caso sería POSTROUTING y el segundo PREROUTING.

Luego estuvimos con Angel, enrrutando los marávillosos Cisco 2600. Una estaba en Asturias, otro Cantabria, Galicia y León y teniamos que usar RIP v.2 para el encaminamiento entre ellos. El tema del enrrutamiento ya está terminado, empezaremos con algo nuevo pero no recuerdo lo que dijo, os informaré.

Hoy tenemos 6 horas con Bermejo, dijo que nos dejaría salir antes, a ver a que hora nos suelta y que coño haremos… sobre las 6 y media os escribiré algo.

Agur

Ayer en clase estuvimos haciendo un túnel SSL, para usar telnet cifrado añadiéndole así seguridad, no solo para telnet sino para cualquier otro servicio que queramos.

Telnet:
net start/stop tlntsvr –> Activa o desactiva el server

TelnetClients –> Se ha de crear un grupo co el mismo nombre y dentro introducir los usuarios que queramos que inicien sesión.

tlntadmn config sec -NTLM –> Desactivar NTLM, que es el uso de usuario del cliente automaticamente.
tlntadmn start/stop –> Otro metodo de activar/desactivar el servidor

Stunnel: Con esta utilidad disponible para Windows y para GNU/Linux podremos hacer un túnel SSL cifrado.

Del equipo A al equipo B conectaremos mediante el puerto 23 al 1100 del servidor con stunnel, por ejemplo, y en el servidor (B) se redirigirá al 23.

En el Cliente:


stunnel -c -d 100 -r B:23

-c –> cliente
-d puerto –> Escuchar en el puerto 23
-r –> Para que conecte remotamente al equipo B:puerto donde estará otrro servidor escuchando.

En el servidor ejecutamos:

stunnel -p /ruta/hasta/el/certificado/stunnelo.pem -d 1100 -r 23

Al hacer telnet a localhost conectaremos al servidor remoto.

Bajamos stunnel y lo ejecutamos, vemos que da un error porque falta un archivo de configuracion, lo creamos:

Cliente: stunnel.conf

client=yes
[telnet]
accept=23
connect=servidor_remoto:6060


Servidor: stunnel.conf

client=no
cert=stunnel.pem
[telnet]
accept=6060
connect=23

Si no tenemos el “stunnel.pem” lo descargaremos de La web de Stunnel, aunque lo más recomendable sería hacernos un propio certificado para que no nos secuestren las sesiones. Para crearlo:

# openssl req -x509 -nodes -newkey rsa:4096 -days 365 -keyout stunnel.pem -out stunnel.pem

Proximamente haremos un túnel SSL UDP, pues el anterior era sólo TCP y no servía para jugar a juegos on-line. Y claro, como bien dice Javi:

Así nadie sabrá la configuración de alerones, de neumáticos ni nada y ganaréis siempre.