Blogs Libres

Criado Indomable
Sebastian D. Criado
Criado Indomable trata sobre »

» Nueva documentación de Nightwing y Lugro-Mesh

Se encuentra disponible nueva documentación en el sitio de la red comunitaria libre Lugro-Mesh y del proyecto de firmware libre Nightwing sobre diversos temas que ayudarán a difundir tanto la idea como los metodos para lograr la expanción de la red wireless en la ciudad de Rosario y alrededores.

En principio se ha desarrollado documentación sobre Hardware Utilizado y probado con nightwing, así coo el Software Utilizado tanto en el firmware mismo como en el servidor de autenticación de usuarios.

En cuanto a la documentación propiamente de nightwing, se ha puesto a disposición metodos para flashear dispositivos de la linea Ubiquiti (nano station, bullet, etc) como el metodo para flashear los dispositivos utilizando RedBoot mediante LAN sin la necesidad de usar un cable serie.

por criadoindomable a la(s) 11:53 PM etiquetas: gnu , linux , lugro , lugro-mesh , mesh , nightwing , redes , redes comu , software libre , wireless (Comentarios)

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» Un poco de informacion sobre SPF

Es normal escuchar hablar sobre implementar SPF para reducir el SPAM, y aunque ayuda mucho, no es el objetivo principal del mismo. Entonces, que es SPF ? Si nos remitimos a la misma Wikipedia nos dice que SPF "es una protección contra la falsificación de direcciones en el envío de correo electrónico. "

Que sucede, cuando se ideo el protocolo SMTP se pensó en un esquema muy similar a lo que se conocía, que es el correo postal, tratando de imitarlo lo mejor posible. Pero al hacer esto nos encontramos en Internet con un problema que existe en la vida real, y es que al recibir una carta, por mas que esta sea "certificada" y solicite que confirmemos su recepción, al momento de recibirla nadie nos garantiza la identidad del emisor de la misma. Para contrarrestar este problema es que surgio SPF.

SPF es una técnica por la cual, al momento de recibir un correo podemos, a través de una consulta DNS, verificar si el IP desde el cual estamos recibiendo el correo esta autorizado para entregar correos del dominio del emisor., y con esto decidir si aceptamos o no el correo.

Para que esta verificación se pueda llevar a cabo tienen que haber sucedido dos procesos totalmente independientes. Por un lado el emisor tiene que haber agregado un registro del tipo TXT especialmente armado en su zona DNS, con el listado de los servidores autorizados a enviar sus correos. Y por otro lado, el administrado del servidor de correo del dominio receptor debe configurar su servidor para realizar la verificación de cada correo entrante.

El agregar los registros para la verificacion del SPF a nuetro dominios es una tarea relativamente simple y generar el registro aun mas gracias a que existen un par de sitios que nos ayudan a generar ese registro especial que luego deberemos agregar a nuestro servidor DNS. Entre los sitios que nos ayudan a generar este registro podemos destacar el sitio de openSFP.

Un registro SPF mas o menos simple, para nuestro dominio example.com, puede llegar a ser algo mas o menos asi:

example.com. IN TXT "v=spf1 a ptr a:192.168.1.1 a:mail.example.com -all"

Con esta linea agregada al archivo de nuetra zona DNS estamos indicando que los servidores que pueden entregar correos para el dominio example.com son:

a -> el ip con el cual resuelva el dominio (que se obtiene con un simple dig example.com a)
prt -> cualquier IP que al resolver el inverso se encuentre dentro de la zona example.com ( dig -x ip_del_servidor_emisor )
a:192.168.1.1 -> el IP 192.168.1.1
a:mail.example.com -> el IP que tenga el registro mail.example.com (dig mail.example.com a)

La ultima parte de la linea, el "-all" es la política que debe emplear el receptor en caso de no coincidir el IP del servidor emisor con alguno del listado. En nuestros caso, el "-all" indica que solo los IP indicados en el registro son los autorizados para enviar correos, y por ende si se recibe un correo de otro IP que no este listado, deben ser ser tratados como falsos y descartados.

La política opuesta es la de "?all", con la cual estamos indicando que pueden llegar correos de IP que no estén listados, y que estos correos deben ser tratados como "neutrales" y ser aceptados.

Existe una tercer política, y es la que en realidad se sugiere utilizar en la mayoría de los casos, que es "~all". Esta política es considerada como un "softfail" o "falla leve". Esto nos permite indicarle al receptor que puede que el IP del cual esta recibiendo el correo no este listado entre los IP validos pero que puede no ser una falsificación de identidad, y en ese caso que también utilice otros medios para terminar la verificación.

Entre esas otras técnicas que se realizan en caso de un "softfail", es buscar entre la cabecera del correo entrante alguno de los IP validos, para saber si el origen del correo es alguno de los servidores permitidos. Esta ultima política es la que debemos utilizar, por ejemplo, si nuestro servidor de correo utiliza a otro servidor para reenviar los correos (servidor relay o smarthost ) y no siempre conocemos el IP de salida de ese servidor relay.

Con este simple registro TXT agregado a nuestra zona DNS es que estaremos evitando que terceros envíen correos en nombres nuestro, y con ello evitando, por ejemplo, los rebotes de los mail de SPAM enviados por otros usando nuestro dominio.

por Pablo Vargas a la(s) 11:37 AM etiquetas: herramientas sysadmin , linux , redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» Bloquear el acceso a Gtalk pero no a Gmail con Squid

Hace algunos días me tope con el siguiente inconveniente configurar un proxy Squid (no transparente) en el cual debía permitir solo el acceso a los correos de Gmail y no al resto de las aplicaciones como por ejemplo el chat, lo hice de la siguiente manera y funciono si alguien tiene una forma mejor que lo postee ;)

Primero que nada agregar las siguientes lineas en el squid.conf

acl cl_congmail src "/etc/squid3/acl/cl_congmail.txt"
acl gmail url_regex "/etc/squid3/acl/gmail.txt"
acl urlmalos url_regex "/etc/squid3/acl/urlmalos.txt"

http_access deny urlmalos
http_access allow gmail cl_congmail

- En el archivo cl_congmail.txt van todas las ips que queremos que tengan gmail por ej:

192.168.1.1
192.168.1.2

- En el archivo gmail.txt puse lo siguiente

.gmail.com
.mail.google.com
.google.com:443

- En el archivo urlmalos si queremos bloquear Gtalk puse la siguiente url

^http://chatenabled.mail.google.com

por _JaR_ a la(s) 3:36 PM etiquetas: herramientas sysadmin , redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» Ejecutando comandos en multiples servidores

Uno de los problemas con los que me he encontrado en estas ultimas semanas es la de trabajar de manera sistemática ejecutando el mimo comando sobre varios servidores (un poco menos 200 servidores).

Debido a que esto es mas que molesto (sobre todo por lo rutinario), entonces recordando el viejo comando "expect" empecé a buscar algún script para poder automatizar un poco este tipo de tarea.

Así es como me encontré con los el repositorio de script de nixCraft, de donde rescate un simpático script para poder ingresar a un servidor ssh pasando de parametro la clave, el servidor y el comando a ejecutar.

Despues de unas modificaciones al script el mismo quedo algo mas o menos asi:

#!/usr/bin/expect -f
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# For use:
#  ./sshlogin.exp password server command arg1
#
# ----------------------------------------------------------------------
# Basado en http://bash.cyberciti.biz/security/expect-ssh-login-script/
# ----------------------------------------------------------------------

# set Variables
set password [lrange $argv 0 0]
set ipaddr [lrange $argv 1 1]
set scriptname [lrange $argv 2 2]
set arg1 [lrange $argv 3 3]
set timeout -1

# now connect to remote UNIX box (ipaddr) with given script to execute
spawn -noecho ssh -o "ConnectTimeout 10" root@$ipaddr $scriptname $arg1
match_max 100000

expect {
    # first time
    "*continue connecting*"  { send -- "yes\r"; exp_continue }

    # for passphase key
    "*passphrase*" { send -- "$password\r"; exp_continue }

    # for password
    "*assword*" { send -- "$password\r"; exp_continue }

    # for timeout
    "timeout" { exit }
}

Con ese script podemos, por ejemplo saber cuanto tiempo lleva encendido alguno de nuestros servidores:

./sshlogin.exp la_clave el_server uptime

Con esto, solo hemos resuelto la mitad del problema, que es poder ejecutar el comando sin tener que esperar a que nos pida la clave. Pero la segunda parte es la mas facil.

Vamos a partir generando un archivo con los servidores y sus claves, algo asi como:

servidor_1:clave_1
servidor_2:clave_2
servidor_3:clave_3

Y con un simple script como el siguiente, podemos recorrer el listado de servidores y claves y ejecutar el comando en todos ellos:

#!/bin/bash
mkdir -p log
for linea in `cat server.lst`
do
     server=`echo $linea |awk -F":" '{ print $1 }'`
     clave=`echo $linea |awk -F":" '{ print $2 }'`

     ./sshlogin.exp $clave $server "(wget -q -O - http://miservidorweb.com/inventario.sh|bash)" > log/$server
done

Con esto podemos descargar un script de un servidor y ejecutarlo en el servidor remoto y guardar el resultado en la maquina local.

por Pablo Vargas a la(s) 12:12 AM etiquetas: herramientas sysadmin , linux , redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» "La telepresencia de Cisco" en numeros (Cisco Telepresence)

10 fueron los requerimientos de la gente de marketing le paso a ingenieria como base para desarrollar la Telepresencia
3 pantallas de "súper alta definición" componen el modelo CT 3000p
1080 x 1900 es la resolución de la imagen de cada una de las pantallas y cada una de las cámaras (una cámara por pantalla).
65" es el tamaño de cada pantalla.
4 enchufes de 20 Amperes se necesita para el CTP3000.
10 paliet es lo que ocupa el CTP3000p cuando esta envalado.
7975 es el modelo de telefono IP de Cisco que utilizan para controlar el equipo de Telepresencia (en ves de un control remoto).
4 son los modelos de los end-point de telepresencia (3000, 3200, 1000 y 500).
400KB o mas debe ser el buffer de entrada del switch donde se conecte el end-poing.
1740 paquetes por segundo transmite el CTP3000 en su maxima calidad de imagen.
1 Gbps debe ser la interfase del switch a la que se conecte.
5.5 Mbps ocupa cada uno de los flujos de video (el CTP3000 usa 3 flujos ).
200 ms de restardo es lo máximo permitido en el enlace de punto a punto.
40 ms es el jitter máximo permitido
0.2% de perdida de paquetes es lo máximo permitido

48 son los flujos de video que puede manejar el equipo de Connferencia Multipuntos.
15 ms es el delay agregado por el eqiupo de Multipunto (no hace transcoding).
240 Mbps seria el cosumo maximo de red del equipo Multipunto.

Aproximadamente 1000 son los equipos ya instalados e el mundo.
pero cerca de 300 estan son de Cisco para uso interno.

y para terminar.... hablemos del precio, que aunque nunca lo mencionaron, estamos hablando de que montar dos puntos con un CTP3000 puede estar un poco por debajo de los u$d 500.000 !!!

por Pablo Vargas a la(s) 5:51 PM etiquetas: redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» Usando a Google como Proxy Web

Aunque si siguera con los titulos "sensacionalistas" de los ultimos post, a este le podria haber puesto "Como saltar las restricciones de un proxy web usando Google Web ToolKit".

Revisando los registros del apache de uno de los server, vi un link desde el que habían llegado varias visitas que me llamo la atención. A primera vista parecia una referencia normal desde google, pero al ver los parametros pasados al servidor de Google me parecio extraño. La URL desde donde venia la visita era algo asi como:

http://www.google.es/m/search?eosr=on&mrestrict=xhtmlonly&q=blog+jamon+vino+

Al ingresar a la url se ve que es uno mas de los servicios de Google. En este caso se trata de la versión para teléfonos móviles del buscador.

Pero lo interesante pasa la hacer click sobre los links y ver lo que trae de resultado, ya que estos links no direccionan al sitio, sino que utilizan las Google Web Toolkit de Google e instaladas un el servidor de Google y funcionando como un PROXY WEB.

Entonces los que navegan desde su celular, solo accede al servidor de Google y este de encarga de adaptar cada una de las pagina para que se vean bien en los dispositivos moviles.

Hasta aca, todo bien, si no fuera que cualquiera, desde cualquier navegador puede accederlas, entonces despues de unas simples pruebas llegamos a que si en nuestros navegador ingresamos a la siguiente direccion:

http://www.google.es/gwt/n?u=http%3A%2F%2Fwww.google.com

Podemos acceder al buscador de Google usando a Google como Proxy, y con esto saltar las limitaciones en los proxy web impuestas por algún malvado SysAdmin :P

por Pablo Vargas a la(s) 12:59 PM etiquetas: herramientas sysadmin , movilidad , redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» Probando la velocidad de un sitio WEB

En varias ocasiones he usado el Apache Benchmark (AB) del Apache 2 para probar los servidores web y medir los tiempos de conexión y de respuesta, pero hace unos meses encontré una herramienta muy interesante para poder hacer lo mismo con una pagina web y cada uno de sus componentes (imagenes, js, rss, etc, etc).

Se trata de una de las herramientas del sitio Pingdom.com desde la cual le podemos pasar un URL y genera estadisticas y un grafico con los datos de conexion y tiempo de respuesta de la pagina.

Entre las detalles a destacar, se encuentran dos. Por un lado que mide el tiempo de acceso a cada uno de los componentes de la pagina, e indicando de donde viene el objeto. Esto es muy útil cuando en una pagina se introducen contenidos de otros sitios o servidores, para poder determinar quien es el que genera la "demora" al cargar la pagina. Dato también interesante para cuando la pagina contiene publicidad o se utilizan template o scripts gratuitos de terceros.

Por otro lado, se pueden guardar los resultados de las pruebas, por lo que se puede probar varias veces y en horas diferentes del dia y después poder ver los resultados, o inclusive guardar las pruebas para luego ser revisadas por un tercero, y ya que estamos acá les paso el el reporte de este blog del dia 31 de julio, o sea que por lo menos un par de meses quedan guardados los resultados.

Luego, entre las otras herramientas de Pingdom.com también tenemos un ping y un traceroute que por ahí también son útiles para probar conectividad con los sitios web.

por Pablo Vargas a la(s) 1:13 PM etiquetas: herramientas sysadmin , redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» System Rescue CD alcanza la version 1.0

Una de las mejores distro para reparar sistemas (tantos Windows como Linux) llega a la versión 1.0 después de tantos años de trabajo.

El día 3 de marzo del 2008 liberaron la versión 1.0 de System Rescue CD con mejoras muy interesantes entre las que se destacan:

Kernel 2.6.24
Soporte para lectura y escritura de particiones NTFS
Soporte para arrancar por PXE
Nuevo Driver Xvesa con soporte para mas placas de video
Mejor soporte para placas WI-FI

Cabe destacar que esta distro, a pesar de recién alcanzar la versión 1.0 no es nueva, sino que vio la luz por allá a principios del 2003, solo que el líder del proyecto Francois Dupoux ha preferido priorizar la calidad de la herramienta sobre el resto de los aspecto de la distro

Con esta distro se pueden hacer tareas como:

Redimensionar particiones existentes
Grabar y restaurar tablas de particiones
Recuperar GRUB o LILO
Revisar la integridad de los discos duros
Hacer resguardo de la informacion del disco en un CDROM, DVDROM o por la red
Revisar el disco en busca de virus
Testear la memoria RAM en buscar de fallos
Buscar y reconocer hardware.

El sitio oficial de esta distro es http://www.sysresccd.org/Main_Page desde la cual puede bajar la imagen ISO de unos 180 MB

por Pablo Vargas a la(s) 11:43 AM etiquetas: linux , redes

Pablo Vargas
Pablo Vargas
El Jamon y el Vino trata sobre »

» Linksys WRT54G v6 - Linux Device 1

Es conocida mi cercana relación con el sistema operativo del pinguinito, al punto tal que hace tiempo que no uso los productos del “Guillermo Puertas”, y los siguientes tres articulos no es mas que una ratificación de mi casi fanatismo por LINUX y el esfuerzo por meterlo en todos lados... El primer articulo, es para contar mis experiencias sobre como instalar DD-WRT en un Linksys WRT54G v5.

Entre las cosas interesantes que tienen los router Linksys WRT54G es que usa una placa base estandar llamada WRT, para la cual ya se han hecho muchas mini distribuciones de Linux, entre las que se encuentra DD-WRT, OpenWRT o Tomato, que le agregan muchas funcionalidades extra que no vienen con el firmware original.

Desde que Cisco compro Linksys y la convirtio en su linea de productos hogareños, Cisco les ha ido quitando, de manera sistematica caracteristicas a los productos Linksys para hacerlos menos atractivos y poder marcar bien la diferencia de calidad con los productos marca Cisco y los Linksys. En los primeros router inalambricos Linksys WRT54G, desde version 1 a la 4, poseian 16 MB de memoria RAM y 4 MB de memoria FLASH, pero a partir de la version 5 de este equipo recortaron estos dos valores a 8 MB de memoria RAM y a 2 de memoria FLASH, argumentando que con esto se reducian muchos los costos de los equipos.

Esta reducción en las características de hardware nos reduce mucho las posibles distro que podemos llegar a instalar en estos equipos. Tengamos en cuenta que 2 MB de FLASH nos dicen que el kernel mas todas las aplicaciones, al comprimirlas tienen que ocupar solo 2MB. Hasta el momento la única distro que se puede instalar es la MICRO versión de DD-WRT. Pero como los muchachos de Cisco son unos “fantásticos” (en realidad los quiero :P ) también le cambiaron la forma de arrancar al equipo, por lo que antes de poder flashear nuestra mini distro, primero tenemos que cargarle un nuevo arrancador a nuestro router, para después poder instalar la micro distro.

Lo que continua de este documento no es mas que la “receta de cocina” de como flashear un router inalámbrico Linksys WRT54G v6.

Ingredientes:

Un Rotuer Inalámbrico Linksys WRT54G v0.6
Patchord UTP
Una computadora con IP fijo, NO COMO CLIENTE DHCP (y preferentemente con Linux :P )
Un cliente de ftfp
Descargar el VXworks Prep v0.3
Descargar el VXworks Kiler G v0.6
Descargar el DD-WRT Micro

Receta:

Lo primero que vamos hacer es conectar nuestro Rotuer a la PC e ingresar a través de la interfase web a la sección de administración y vamos a actualizar el firmware que tiene por el VXworks Prep V0.3. Luego de un instante la pantalla se pondra en blanco. Aca debemos reiniciar nuestro router.
Al reiniciar, nuevamente a través de nuestro navegador web ingresamos al router a la dirección http://192.168.1.1 , en este momento el router se encuentra en modo mantenimiento por eso no solo tomo el ip 192.168.1.1 sino que en la web que vemos solo nos da la opción de subir otro firmware. Acá subimos el VXworks Killer G. Una vez terminado veremos la leyenda de "Success". Nuevamente reiniciamos el router.
Ahora, al reiniciar el equipo veremos que los LED frontales quedan titilando. En este punto desde una consola le transferimos el Micro DD-WRT por ftfp con el siguiente comando:

tftp -v -m binary 192.168.1.1 -c put dd-wrt.v23_micro_generic.bin

Si en este momento nos da un error al transferir la imagen bin, es porque la versión del VXworks Killer que hemos usado NO ES CORRECTA, pues no tengan miedo, aun se puede arreglar. Consigan la versión correcta y con el mismo comando le pasan la versión correcta del VXworks Killer

tftp -v -m binary 192.168.1.1 -c put vxworks_killer_g_v06.bin

Una vez transferido el Micro DD-WRT, hay que esperar un tiempo importante (varios minutos) para esperar que la imagen copie a la memoria flash. Luego de esperar unos minutos, reiniciamos el router y listo ya tenemos nuestro Router Linksys WRT54G v6 con Linux !!! Para acceder nuevamente usamos nuestro navegador web a la dirección http://192.168.1.1

por Pablo Vargas a la(s) 3:35 PM etiquetas: linux , redes

Blogs Libres

Blogs Libres

Sobre que habla la gente de este planeta

Meta

Gente

Saludos