Conectando dos ap La Solución

Respecto a los artículos publicados: Conectado dos ap anteriores.
Hemos detectado que el problema está en la versión del servicio dhcpd del server Linux, si bien todavía no hemos detectado el porqué del mal funcionamiento.
Por el momento la solución: migrar a dhcp3-server con las mismas configuraciones.
Saludos y espero como siempre que estas lineas le sean de utilidad a alguien.

Como hostear .com.ar en casa.

Bueno, hace unos días en la lista de gulfrre surgió una duda de cómo hacer para poder hostear un .com.ar por ej en un enlace ADSL. Por ello he decidido postear esta pequeña guía de cómo hacerlo.
Materiales necesarios:
1 PC (con conexión a internet y SO "Preferentemente *nix").
En NIC Argentina (Entidad Registrante, Persona Responsable)
Proveedor de DNS (zoneedit en nuestro caso).
Mate amargo y una mañana de domingo.
Paso 1:
Vamos a ir a la pag de NIC Argentina quien es el ente encargado de la delegación de dominios .ar
Allí podemos entre otras acciones realizar consultas sobre nombres de dominio .com.ar, .gov.ar, .int.ar, .mil.ar, .net.ar y .org.ar; nosotros particularmente vamos a seguir los pasos para registrar un .com.ar, para ello buscamos nuestro dominio que para el ej vamos a llamar eldominioquequiero



Paso 2:
Como podemos observar en el siguiente screeshot, el dominio consultado se encuentra disponible así que vamos a tomarlo.


Paso 3: Consiste en indicar el dominio a registrar junto con el email del registrante ej el nuestro



Paso 4: Aquí debemos previamente como en varios form buscar datos, en este caso los de la Entidad Registrante (si no la tenemos podemos pedir el alta a NIC Argentina mediante una serie de trámites Guía del Solicitante)


Paso 5: Una vez encontrada la Entidad la seleccionamos.


Paso 6: El siguiente, paso es buscar una persona responsable (Pelín espero que lo seas :) jajajaja).


Paso 7: Si tuvimos suerte la seleccionamos


Paso 8: En este paso tenemos que delegar los dns. Para lo cual hay 2 opciones: La primera es sólo para reservar el dominio y la segunda, la cual vamos a elegir nosotros es para realizar la delegación puesto que contamos con los dns de zoneedit para ello.


Paso 9: Vamos a crearnos una cuenta en zoneedit y vamos a agregar una zona para nuestro dominio (no usé el mismo dominio que registramos en nic sólo para que se vea completo en la captura, pero aclaro que acá va el que registramos en nic.ar).


Paso 10: Una vez agregada la zona. Zoneedit nos provee de los datos necesarios para completar la pantalla siguiente de nic.ar


Paso 11: Ya casi termina. Tenemos que ingresar la información de los dns que nos brindó zoneedit.


Paso 12: Le damos buscar ZoneEdit Inc


Paso 13: Seleccionamos los datos del ISP en este caso ZoneEdit Inc (NO NUESTRO ISP, esta información para los dns's)


Paso 14: Le damos buscar el contacto técnico (en este caso Zone Admin)


Paso 15: Lo seleccionamos.


Paso 16 el último vamos todavía: Chequeamos que la información sea la correcta y completamos la verificación textual.

El trámite en NIC Argentina puede tardar un par de días y hay que tener en cuenta que:
Cuando llega el correo automático de NIC no debemos modificarlo en lo más mínimo. Sólo debe responderse una vez leído. Ojo acá por que hay clientes de correo que agregan información a nuestros mails.
Ahora lo que nos queda es usar alguna aplicación para que zoneedit se entere de nuestras renovaciones de IP (en caso de que tengamos un servicio dinámico). Para esto vamos a usar el comando links o links2 funcional en casi todos los *nix.
Lynx -source -auth=USER:PASS 'http://dynamic.zoneedit.com/auth/dynamic.html?host=DOMINIO'
Bueno eso es todo gente, espero que haya sido útil nos vemos.

Se puede tomar m@te desde google?

Hoy me levanté temprano y preparé un mate que no pude tomar porque se me trancó la bombilla y antes de cambiarla por otra pensé… Será posible tomar un m@te desde google?
Realicemos el experimento entonces…
Materiales necesarios:
M@te / PC / dispositivo con conexión a Internet (mate)
Bombilla armable por tramos (propiedad de varias telcos y carriers)
Termo con agua (Google)
Si analizamos el tiempo aproximado desde que el agua ingresa a la bombilla hasta que pudiésemos degustarla sería:
Ping www.google.com
Respuesta desde 64.233.161.104: bytes=32 tiempo=200ms TTL=246 (Lo cual no está nada mal tratándose de agua importada, “que si nos ponemos a pensar tal vez sea nuestra pero ese es otro tema jeje” los invito a que tomen un mate en 200ms)
Ahora se me ocurre pensar: (como diría el prócer Don Raúl Binagi)
a) Por donde pasa el agua?
Pathping www.google.com
Traza a www.l.google.com[64.233.161.104] sobre caminos de 30 saltos como máximo:
0 mi pc [192.168.1.10]
1 mi router [192.168.1.1]
2 200.3.60.9
3 host10.200-3-81.telecom.net.ar [200.3.81.10]
4 core1-1-0-0.mia.net.google.com [198.32.124.133]
5 host10.200-3-81.telecom.net.ar [72.14.238.57]
6 host10.200-3-81.telecom.net.ar [72.14.238.137]
7 64.233.175.169
8 216.239.48.190
9 od-in-f104.google.com [64.233.161.104]
Procesamiento de estadísticas durante 225 segundos...
Salto RTT Perdido/Enviado =Pct Perdido/Enviado = Pct Dirección
0 server [192.168.1.10]
1 2ms 0/ 100 = 0% 0/ 100 = 0% my.router [192.168.1.1]
2 42ms 0/ 100 = 0% 0/ 100 = 0% 200.3.60.9
3 177ms 0/ 100 = 0% 0/ 100 = 0% host10.200-3-81.telecom.net.ar [20
0.3.81.10]
4 177ms 0/ 100 = 0% 0/ 100 = 0% core1-1-0-0.mia.net.google.com [19
8.32.124.133]
5 189ms 0/ 100 = 0% 0/ 100 = 0% host10.200-3-81.telecom.net.ar [72
.14.238.57]
6 201ms 0/ 100 = 0% 0/ 100 = 0% host10.200-3-81.telecom.net.ar [72
.14.238.137]
7 200ms 0/ 100 = 0% 0/ 100 = 0% 64.233.175.169
8 202ms 0/ 100 = 0% 0/ 100 = 0% 216.239.48.190
9 203ms 0/ 100 = 0% 0/ 100 = 0% od-in-f104.google.com [64.233.161.
104]
Traza completa.

En esta ocasión nuestra bombilla se armó con 10 tramos de los cuales los 2 primeros son nuestros 0 mi pc y 1 mi router. El resto de la bombilla de quién es entonces? Veamos, podemos preguntarle a lacnic(Registro de Direcciones de Internet para America Latina y Caribe):

whois 200.3.60.9
owner: Telecom Loopbacks
ownerid: AR-TELO-LACNIC
De entre toda la data que nos brinda el comando podemos observar que ahora la bombilla es de Telecom de argentina
whois 200.3.81.10
owner: Telecom BBIP
ownerid: AR-TEBB-LACNIC
Y hasta aquí lo sigue siendo
Esto está bueno miren:
whois 198.32.124.133
OrgName: Exchange Point Blocks
OrgID: EPB
Address: PO 12317
City: Marina del Rey
StateProv: CA
PostalCode:
Country: US
Espero no equivocarme, pero por lo que he observado en sucesivas búsquedas esta parte de la bombilla corresponde al NAP of the Americas ver además a nombre de Terremark y ver también

whois 72.14.238.57
OrgName: Google Inc.
OrgID: GOGL
NetRange: 72.14.192.0 - 72.14.255.255
De acá en adelante la bombilla ya es de Don Google incluyendo los rangos:
NetRange: 216.239.32.0 - 216.239.63.255
NetRange: 64.233.160.0 - 64.233.191.255
Y muchos +
Bueno ahora que sabemos de quién es la bombilla podemos tomar el mate tranquilos. PERO!!!

b)Pasa siempre por el mismo lugar?
pathping www.google.com

Traza a www.l.google.com[209.85.165.99] sobre caminos de 30 saltos como máximo:
0 server [192.168.1.10]
1 my.router [192.168.1.1]
2 200.3.60.9
3 249.37.3.200.telecom.net.ar [200.3.37.249]
4 249.37.3.200.telecom.net.ar [200.3.37.157]
5 249.37.3.200.telecom.net.ar [200.3.37.234]
6 mia7-telecom-argentina-1-ar.mia.seabone.net [195.22.199.117]
7 france-telecom-fr-mia2.mia.seabone.net [195.22.199.46]
8 so-3-0-0-0.atlcr2.Atlanta.opentransit.net [193.251.240.189]
9 so-4-0-0-0.atlcr1.Atlanta.opentransit.net [193.251.240.85]
10 google-us-customers-3.GW.opentransit.net [193.251.250.226]
11 249.37.3.200.telecom.net.ar [72.14.239.21]
12 216.239.43.142
13 eo-in-f99.google.com [209.85.165.99]
No necesariamente el agua fluye por la misma bombilla, salvo que alguien lo garantice por ejemplo con QoS (comprar una bombilla sólo para nosotros).
Espero que la comparación haya sido de su agrado, nos vemos.

IDS qué se sabe? Portsentry como NIDS

En este post vamos a ver cómo usar Porsentry (un excelente NIDS o IPS como quieran calificarlo, desarrollado por la empresa Psionic desde octubre del 2002 propiedad de Cisco), en su configuración básica, dejando a gusto del consumidor los aderezos.

Vamos a usar un 2.6.17-gentoo-r7, con iptables 1.3.5-r4 y portsentry 1.2

A lo nuestro:

~# emerge iptables

~# emerge portsentry

Ahora tenemos que configurar portsentry para ello vamos a hacer una copia del file de ejemplo

~# cp /etc/portsentry/portsentry.conf.sample /etc/portsentry/portsentry.conf

y luego lo editamos:

~# vi /etc/portsentry/portsentry.conf

En la sección Port Configurations vamos a usar la siguiente configuración de puertos TCP y UDP que queremos scannear:

# Un-comment these if you are really anal:

TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,

513,514,515,540,635,1080,1524,2000,2001,4000,4001,5742,6000,

6001,6667,12345,12346,20034,27665,30303,32771,32772,32773,

32774,31337,40421,40425,49724,54320"

UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,

518,635,640,641,666,700,2049,31335,27444,34555,32770,32771,

32772,32773,32774,31337,54321"

NOTA: Ojo acá los que usan Xserver por el puerto 6000.

y comentamos las demás.

En la sección Advanced Stealth Scan Detection Options decomentamos las líneas:

ADVANCED_PORTS_TCP="1024"

ADVANCED_PORTS_UDP="1024"

para decirle a portsentry, que en modo avanzado, solamente monitoree por debajo de éstos.

Además vamos a decomentar:

# Default TCP ident and NetBIOS service

ADVANCED_EXCLUDE_TCP="113,139"

# Default UDP route (RIP), NetBIOS, bootp broadcasts.

ADVANCED_EXCLUDE_UDP="520,138,137,67"

lo cual nos servirá para evitar falsos positivos si es que estamos por ej. en un entorno WIN donde NetBIOS hace uso de TCP 113 auth para autenticar y 139 netbios-ssn para gestionar la sesión. Y los puertos UDP 520 para efs y ruteo local, 138 netbios-dgm, 137 netbios-ns y 67 bootps.

En la sección Configuration Files debemos especificar una serie de variables necesarias para el buen funcionamiento:

IGNORE_FILE="/etc/portsentry/portsentry.ignore"

La variable IGNORE_FILE guarda el path de un file llamado portsentry.ignore que será el lugar donde debemos agregar los hosts o redes que NO QUEREMOS scannear. Por lo general los hosts / redes de confianza irían aquí.

HISTORY_FILE="/etc/portsentry/portsentry.history"

La variable HISTORY_FILE guarda el path de un file llamado portsentry.history donde se almacenarán todos hosts que fueron denegados desde la instalación del servicio y

BLOCKED_FILE="/etc/portsentry/portsentry.blocked"

La variable BLOCKED_FILE guarda el path de un file llamado portsentry.blocked similar a la anterior sólo que ésta guarda los hosts denegados en la sesión actual o hasta el siguiente reinicio.

En la sección Misc. Configuration Options, vamos a decomentar:

RESOLVE_HOST = "1"

lo cual permitirá realizar el giro de las solicitudes de búsqueda DNS de los host atacantes.

En la sección Ignore Options, vamos a incluir:

BLOCK_UDP="1"

BLOCK_TCP="1"

estas variables van a indicarle a portsentry que en caso de detección de un ataque, bloque los puertos TCP y UDP para el target en cuestión. Podemos elegir que hacer 0: no bloquear, 1 bloquear y 2 correr comandos externos que bien podría ser generar alguna alerta a los administradores, a través del envio de mails por ej.

La sección Dropping Routes está dedicada a limitar / restringir rutas o host a través de reglas en las tablas locales. Por ej: podríamos incluir la siguiente:

KILL_ROUTE="/sbin/route add -host $TARGET$ gw 333.444.555.666"

la cual agregaría una entrada a nuestra tabla de ruteo local, indicándole al SO que cualquier tráfico proveniente de la IP contenida en $TARGET$ (la cual sería de nuestro atacante) sea enviada a un gateway inexistente. *IMPORTANTE* sólo una de éstas reglas pueden estar activas a la vez.

Si bien lo anterior podría servirnos en ataques no muy elevados, lo que se recomiendo es usar algún tipo de firewall para añadir más seguridad. Para ello podemos agregar reglas de firewall como por ej. la siguiente:

KILL_ROUTE="/usr/local/bin/iptables -I INPUT -s $TARGET$ -j DROP"

la cual impediría el tráfico de entrada proveniente de nuestro posible atacante.

NOTA: existen varias implementaciones de firewalls soportadas en distintas plataformas, iptables es sólo un ej.

Casi finalizando, contamos con la sección TCP Wrappers de la cual vamos a decomentar la opción:

KILL_HOSTS_DENY="ALL: $TARGET$"

la cual incluirá la IP de nuestro atacante en el file /etc/hosts.deny (una medida más de seguridad) independiente del packet filter que usemos.

Por el momento no vamos a incluir nada en la sección External Command, pero si mencionaremos que es posible accionar un comando tanto antes como después la aplicación de una regla.

NOTA: No se recomienda realizar contra ataques al origen como medida de defensa, está comprobado estadísticamente que es peor que la enfermedad.

Para finalizar la sección Scan trigger value, nos servirá para decirle a portsentry con qué rapidez actuar en caso de detección de tráfico anómalo, si especificamos esta variable en 0, le estaremos diciendo al mismo que reaccione inmediatamente. Lo anterior es lo que vamos a hacer:

SCAN_TRIGGER="0"

Podríamos establecerlo en valores como 1 o 2 para dar un aviso primero y luego aplicar reglas, etc.

No soy partidario de utilizar mensajes de banneo, pero cabe aclarar que esta posibilidad está abierta si alguien lo desea en la sección Port Banner Section.

Lo que nos queda:

Verificar que nuestro iptables esté funcionando correctamente para lo cual vamos a ejecutar:

~# /etc/init.d/iptables status

* status: stopped

y si está parado como en nuestro caso vamos a iniciarlo.

~# /etc/init.d/iptables start

• Loading iptables state and starting firewall ... [ ok ]

Antes de iniciar a portsentry vamos a editar dos files:

El primero:

~# vi /etc/conf.d/portsentry

#PORTSENTRY_MODES="udp tcp"

#PORTSENTRY_MODES="stcp sudp"

PORTSENTRY_MODES="atcp audp"

donde vamos a seleccionar el modo de scanneo del mismo.

El segundo Y NO SE OLVIDEN a menos que quieran ser vaneados uds mismos:

~# vi /etc/portsentry/portsentry.ignore

#Para evitar bannear el uso de loopback

127.0.0.1/32

#Para evitar bannear nuestro host ej.

172.16.0.178

#Podríamos incluir redes completas como el caso de

172.16.0.0/24

Ahora si a iniciar portsentry:

~# /etc/init.d/portsentry start

• Starting portsentry ... [ ok ]

Listo ahora los logs pueden verse en el messages, ya que portsentry trabaja con syslog y es ahí donde los almacena.

Por ej podríamos verlo con:

~# tail -F /var/log/messages | grep portsentry

Por el momento eso es todo.

Categoría and Technorati tags: catNetworking

Raman Amplification in SAN - for Disaster Recovery

Cuán lejos debe estar un Data Center primario de un secundario? Este artículo escrito por Per B. Hansen - Director, Business Development, Optical Solutions ADVA Optical Networking, nos da una pauta de cuán lejos debe estar un DC primario de un secundario y las tecnologías aplicadas en la actualidad para que dicha separación sea por ej. de 200km con velocidades de hasta 10Gbps.

Categoría and Technorati tags: catNetworking

Conectando dos ap, por ahora sin solución Pate II

Bien... Continuando con la travesía de conexión, se agregó un nuevo dispositivo también de la marca Encore al esquema propuesto, debido a no haber encontrado solución alguna a la conexión entre los 2 AP. Lo que se probó en esta ocasión es usar en uno de los extremos un AP de los que ya teníamos y en el otro extremo un LAN Extender ENRXWI-G (la nueva adquisición), luego el esquema resultante fue el siguiente:

AP (ENHWI-G) <------------------>EX (ENRXWI-G)

||-------------------------------------------------------||

DHCP Server ---------------------------------Cliente

Conf.1

Aclaraciones:

a) Las IP’s tanto del AP como del EX fueron introducidas a mano y eran del mismo rango que las del Server.

b) Se anularon las funciones DHCP del AP.

c) El SSID fue el mismo siempre para todos los dispositivos como así también lo fue el canal de transmisión.

Curiosidades:

1) Prueba: Se realizó la primer prueba, haciendo que una laptop se conecte al único puerto ethernet del EX (vía wire & wireless) y solicite una IP.

Resultado: No funcionó ni wire, ni wireless. Sin embargo las solicitudes ARP llegaban al DHCP Server del otro extremo.

2) Prueba: Se le asigno a mano una IP (estática) a la laptop conectada al EX.

Resultado: Funcionó pero no tenía sentido para la configuración DINAMICA que necesitábamos.

3) Prueba: Se hizo que el EX solicite DHCP en lugar de tener asignada una IP estática.

Resultado: Funcionó pero solamente hasta el EX llegaban los ARP (no a la laptop).

4) Prueba: Se invirtieron las posiciones de los dispositivos de la siguiente manera:

EX (ENRXWI-G) <------------------>AP (ENHWI-G)

||-------------------------------------------------------||

DHCP Server ---------------------------------Cliente

Conf.2

Resultado: Funcionó, la laptop recibió una IP vía DHCP con todas las configuraciones necesarias, gw, dns, etc. Pero no podían rutearse los paquetes hacia fuera (Internet). (Tema pendiente a investigar por qué sucede esto).

A todo esto, le hemos escrito a la gente de Encore, quienes muy amablemente nos han contestado diciendo: Sres. gracias por contactarnos y toda la historia, pero Uds. están locos jajaja (en realidad no dijeron eso): lo que quieren hacer no es viable con esos dispositivos, tema WDS y demás yerbas.

Respuesta de Encore:

Thank you for contacting Encore Electronics Technical Support. If you are trying to do this wirelessly, it is not going to work. The ENHWI-G does not support WDS. Only the ENRXWI-G does support WDS.

Wired it will work as long as you assign different IP address to each router. Make sure that only one of the routers has DHCP enabled. I World also recommend that with the three routers that have DHCP disabled. Are not connected to the network through their Wan port.

XX
Encore Electronics Technical Support
www.encore-usa.com

Conclusión:

No hay nada mejor que la estandarización y sobre todo los estándares abiertos.

Hurgando en las profundidades de Internet he encontrado una serie de sites que tal vez diluciden u obscurezcan el panorama con frases como: “The WDS feature is not completely specified in IEEE or Wifi standards”. Analizando un poco el tráfico ARP (con la Conf.1) vimos que al DHCP Server llegan las solicitudes con la MAC de la laptop y éste le enviaba una respuesta que aparentemente quedaba en el EX, quien no era capaz de redirigirla. También hay un draft en http://grouper.ieee.org/groups/802/11/ sobre WDS que tal vez pueda ayudar a estandarizar las cosas proponiendo un sistema de flags sobre el BSSID en las tramas 802.11.

Por ahora es lo que hay pero prometo seguir danto pelea…

Categoría and Technorati tags: catNetworking

Conectando dos ap, por ahora sin solución

Con un amigo estamos intentando conectar dos puntos mediante dos access point encore ENHWI-G, lo raro es que la primera vez que los conectamos logramos hacer lo que queríamos, a continuación les explico la secuencia:
1 Se encendió el primer dispositivo desde ahora llamado ap1 y se configuró de la siguiente manera:

ap1
IP=10.2.0.1
netmask=255.255.0.0
domainname=mydomain.com.ar
ssid=mynet
Eso fue lo único que se hizo en el primer dispositivo.

2 Se encendió el segundo dispositivo desde ahora llamado ap2 y se configuró de la siguiente manera:

ap2
IP=10.2.0.2
netmask=255.255.0.0
domainname=mydomain.com.ar
* el ssid=mynet pero fue tomado automáticamente por el dispositivo al arrancar.

Luego de esto, comenzamos a realizar las pruebas:
1 Se conectó al switch que trae el ap1 un DHCP server mediante un patchcord.
2 En el otro extremo en el ap2 se conecto al switch también mediante un patchcord una pc que debería tomar una dirección mediante el DHCP mencionado.
3 Así fue, la pc tenía asignada una IP del DHCP server de la clase que éste otorgaba 10.1.0.*
4 Se realizó un trazado de ruta mediante el comando tracert y vimos que todo funcionaba correctamente, los ap no aparecían en ésta, eran transparentes y sólo cumplían su función de backbone.

Problemas:
Llevamos los dispositivos a su destino final y lo único que hicimos fue cambiar el ssid... Nuuu para qué lo tocamos, desde ese momento nuestra configuración dejó de funcionar y hasta el momento sigue sin hacerlo, de eso ya hace 2 días y sigo googleando, foreando y maileando sin soluciones. Ni bien lo solucionemos lo publico, de más está decir que si alguien ya lo hizo que nos avise.

Categoría and Technorati tags: catNetworking