Ricardo Bartolomé

Como deje a medio comentar el otro día, habíamos configurado el cliente y el servidor DNS de modo que, con un alias llamado “WPAD” apuntando a la máquina con ISA Server el cliente en modo “Detección automática de proxy” se autoconfigurase. Pero claro, vemos más cómodo configurarlo por DHCP, pues configuramos el servidor DHCP de Windows de modo que dé IP’s desde 10.10.0.115 a 10.10.0.120 por ejemplo. En la opciones de la “zona” (no me acuerdo de como se llamaba exactamente, y lo tengo en la punta de la lengua), delegación creo recordar, asignamos la opción “router”, “dns” y creamos una nueva llamada “WPAD” que luego explicaré.
En la opción router pondremos el la IP privada del ISA Server, en nuestro caso es 10.10.0.215, en servidores DNS pondremos los de la academia, que son 192.168.0.2 y 192.168.0.1. la nueva “pción” que añadiremos se llamará WPAD, cuyo identificador sera 252, del tipo “cadena” y cuya cadena será:

http://10.10.0.215/wpad.dat

Lo que hace es, que el cliente al pedir por difusión al servidor DHCP (cualquiera) IP, este le asignará una IP, una gateway, unos DNS y un “alias” WPAD, de modo que el explorador sepa por que puerto conectarse al proxy del ISA Server.

A ver que hornada nueva os traigo el próximo día, agur.

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.