Probando la recién horneada Backtrack 4 con el nuevo juguete, de entrada tenemos la carga del driver resuelta, en el boot entra directamente el rtl8187 así que está funcional y operativa, aunque no todo son buenas noticias.

Este driver tiene algún que otro fallo y nos hace perder la cobertura wifi, empezamos con cortes y al final la conexión se torna tan inestable que hace que navegar sea prácticamente un milagro, menos mal que la comunidad es amplia y disponemos del driver r8187, que, para mas inri, también viene incluído en el núcleo.

Para realizar el cambio de driver para nuestra wifi debemos parar la interfaz para después editar el fichero de bloqueo de drivers, vamos a ello:

#ifconfig wlan0 down
#vi /etc/modprobe.d/blacklist

tenemos que buscar el driver r8187 y tenemos las dos opciones de siempre (un :dd para borrarlo o bien lo dejamos comentado) más la de sustituirla añadiendo tl de modo que lo que bloqueémos realmente sea el modulo rtl8187; a ver, que me lío, en definitiva es meter en la blacklist el otro módulo así que sustituimos blacklist r8187 por blacklist rtl8187; de modo que sustituimos la carga del módulo por defecto por el que realmente nos interesa. Guardamos, cerramos y procedemos a sustituir el driver cargado (o si vamos a lo gonzo reiniciamos, que también vale).

#rmmod rtl8187
#modprobe r8187

ya podemos levantar de nuevo nuestra tarjeta de red, esta vez sin cortes y cumpliendo su función correctamente.

iwconfig wlan0 up

venga, a disfrutar y a probar backtrack (o wifis, allá cada uno XD)

Share on Facebook

la espera ha sido larga pero el fin merece: ya tenemos en la calle la versión final de la backtrack 4, se acabaron las esperas de betas y rcs, que según he visto por ahí han dado sus frutos, una más que depurada versión de linux para administradores de red, basada en ubuntu y con un nuevo kernel.

han ampliado también el número de aplicaciones, tanto en la distro cómo en el repositorio, y además tiene apps que sólo podemos encontrar en dicha distro (interesante, habrá que indagar un poco).

además, el propio equipo de desarrollo agradece el apoyo y ayuda de la comunidad y afirman sin temor que se trata de la mejor versión de backtrack que ha visto la luz.

Descárgala aquí.

Share on Facebook

ni más ni menos que la alfa, que ya ha llegado…

Share on Facebook

tenemos ya cerca de un centenar de instalaciones – redes montadas con wifi, más de una nos está dando muuuuuchos quebraderos de cabeza, así que para finalizar el año le hemos pedido a los reyes un adaptador wifi en condiciones, finalmente nos hemos decantado por una alfa 1000mW usb, ideal para nuestras auditorías con wifislax, backtrak, etc (y por lo que he visto por ahí incluso con kismac).

la verdad es que ya os contaré que tal nos va con el nuevo cacharro, en cuanto llegue ya tiene destino para auditar… aquí os dejo las específicaciones técnicas del juguete.

1. Potencia de salida 1000mW 1W
2. Soporta USB 2.0
3. Funciona en IEEE 802.11b/g (2.4GHz)
4. Transferencia de datos de 54Mbps
5. Modo Ad-Hoc o Infraestructura
6. Software AP (Punto de acceso) funcion de modo AP por software
7. Modo monitor (Chipset Realtek 8187L)

Especificaciones:

Share on Facebook

Al salir del curro me comentaba un compi, que un alemán ha desvelado los secretos más intrínsecos del GSM, la red de telefonía móvil que utilizan (o utilizamos) en el 80% de las llamadas a móviles en el planeta. Karsten Nohl, el “piratilla” germano, hizo el anuncio en el marco del Chaos Communication Congress.

Varios sitios se hacen eco de la noticia, entre ellos elmundo.es, vnunet, movilonia…

Ahora les toca a las operadoras de telefonía móvil “ponerle puertas al campo” y revisar la seguridad de sus comunicaciones.

Share on Facebook

pues sí, tal y cómo están las cosas hoy en día, el quedarse incomunicado puede suponer todo un problema, en parte por cubrirse las espaldas y en parte, aún mayor, por casualidades de la vida, me he llevado una grandísima sorpresa al vaciar el buzón cuando subía para casa…

me he dado cuenta que entre trámites, altas, portabilidades y demás, a día de hoy, tengo contrato con las 4 grandes operadoras país, al no tener ubicación concreta y las exigencias de movilidad en el trabajo que mejor que disponer de cobertura allá dónde vayas…

inventario:

• jablotron de vodafone
• blackberry 9000 bold e internet everywhere de orange
• f480 yoigo
• iPhone 3G S 32Gb de Movistar

pack de comunicación móvil

vamos, lo que sería un completo pack de comunicación móvil XD.

Share on Facebook

El Consejo, compuesto de los consejeros delegados de Panda Security, 21Sec, Hispasec y Secuware, tiene previsto, entre otras cosas, iniciativas para el fomento de:

• La protección de identidad de los consumidores.
• La protección de infraestructuras críticas.
• La creación de leyes nacionales contra el cyber-crimen.
• La protección de la información corporativa.
• La evolución de la estructura gubernamental desde el foco del ámbito físico al del cyberespacio.
• La mejora y el apoyo, desde el punto de vista del Consejo, de la prosperidad económica y la seguridad nacional.

Fuente: 21sec

Share on Facebook

y es que después de casi un mes de continuo viaje (madrid, valencia, huesca, bilbao…) dejándome la vista en las 10″ escasas de mi notebook MEDION AKOYA E1210, a falta del SAMSUNG SyncMaster943w de la oficina, me han hecho meditar y afinar un poquito las necesidades reales de mi trabajo día a día.

No creo que lo pueda tener para esta misma tarde, pero mañana, cuando regrese de Madrid (de nuevo) espero tenerlo encima de mi mesa en la oficina. Mañana tocará cambio intenso por la noche, además tendré que cepillarme el Vista Home Basic que viene licenciado con el juguete y cambiarlo por la nueva versión de Ubuntu 9.04, cuya iso ya tengo bajada y lista para tostar.

ya os contaré que tal con la nueva experiencia…

Share on Facebook

bueno, más que jugando, sacándole jugo a la conexión VPN que conseguimos con el post anterior. En este caso, una necesidad y ganas de retorcer la cosas, hemos metido en nuestra “red” un servidor dedicado que tenemos en housing, pongamos que en… hostinet (publicidad gratuita ;p).

vale, el servidor corre servicios web, para continuar con el ejemplo, este mismo blog… lostintheshell.net, a parte, supongamos que en https://aplicacion.lostintheshell.net tenemos acceso web a una aplicación que debe acceder, o incluso realizar querys en tiempo real, a la información recogida en la BBDD de uno de nuestros servidores locales. (recordamos que en las net-lan de telefónica no se permite la apertura de ningún puerto).

Vale, la cosa es bien sencilla, instalamos en nuestro servidor el software que comentábamos el otro día VPNC, con nuestro fichero de configuración debidamente configurado (recordamos):

LOSTINTHESHELL.conf

IPSec ID LOSTINTHESHELL
IPSec gateway LOSTINTHESHELL1.ipsec.rima-tde.net
IPSec secret LOSTINTHESHELL
IKE Authmode psk

Xauth username berto@LOSTINTHESHELL

NAT Traversal Mode cisco-udp

Bien, pues ya está listo, ¿no?. Pues bien, en este caso no es oro todo lo que reluce, ya que tenemos una problemilla relativamente “gordo”. Tranquilos, no asustarse, que lo explico.

- Tenemos un único punto de acceso a ese servidor dedicado, es decir, accedemos a él por una única ip (da igual que sea través de web, de telnet, de ssh…), su ip pública (que sigue unas reglas de networking); no tenemos acceso físico a ese servidor, ni tan siquiera a un terminal, que no sea a través de ssh, en este punto es dónde debemos tener ¡cuidado!

Al levantar la VPN todo el enrutamiento, por defecto, se hace a través de las reglas establecidas para la VPN, quedando “absorvido” o “anulado” el tráfico habitual del funcionamiento normal del servidor. Es decir, en el mismo momento que levantemos la VPN perdemos el control del servidor, ya que no tenemos modo de acceder al terminal.

Para no encontrarnos con esta problemática, y cómo lo único que perdemos es la conectividad con el servidor, lanzamos un script que nos levante la vpn, pero que después continúe reestableciendo las rutas por defecto, es decir, (re)configurando su red normal para dejarla tal y como estaba antes de establecerse el tunel VPN y estableciendo la red y ruta del tráfico que debe pasar por la VPN. He aquí un ejemplo, suponiendo que nuestra red es de clase B, una 192.168.0.0 y la ip pública de nuestro servidor 91.171.157.227

open-vpn.sh

echo “Conexión realizada con éxito”

#!/bin/bash
# Sencillisimo script realizado por b3r2c0 para establecer la VPN con la NetLan de Telefónica y un servidor dedicado (externo)
echo “Realizando Backup de las DNS locales”
cp /etc/resolv.conf /etc/resolv.conf.local
echo “Conectando a la VPN de l.i.t.s.”
vpnc-connect LOSTINTHESHELL
echo “Manteniendo el GW por defecto para la conexión principal”
route add default gw 91.171.157.254 dev eth0
echo “Añadiendo la gestión de tráfico de la VPN”
route add -net 192.168.0.0 netmask 255.255.0.0 dev tun0
echo “Restaurando DNS”
cat /etc/resolv.conf.local >> /etc/resolv.conf

el default gw que le añado, no es aleatorio, antes de elaborar el mini-script, has de consultar tu configuración de red con ifconfig; por otro lado, el juego de idas y venidas con el resolv.conf es para solventar el problemilla que se nos planteaba en el post anterior, ya que el vpnc machaca tus dns por defecto, así pues nos quedamos con las que teníamos y se las añadimos a las generadas por la net-lan (pese a que no les demos utilidad, más vale prevenir); luego en un script vpn-off.sh, desconectaremos la vpn y le dejaremos sólo las dns previas. Por cierto, no te olvides de darles permisos de ejecución a los scrpits, ejjeej.

ciao.

Share on Facebook

bueno, después de un tiempecillo sin postear nada (pero con mucho post-borrador empezado) debido a la monumental petada de trabajo que tenemos actualmente, voy a apuntarme “on line” unas anotaciones sobre la VPN NET-Lan de Telefónica, que me he vuelto un poco “tarado” para realizar una maraña de conexiones y túneles, una auténtica autopista de la información, ejejej.

El problema empieza cuando la red corporativa es de Cisco y la gestiona Telefónica, con lo cual, si conseguir un soporte mínimamente decente es complicado, trabajar con el software propietario de Cisco versión GNU/Linux, acaba quitando las ganas, sobre todo en servidores en producción.

Después de dar unas cuantas vueltas, y de dar vueltas a tutoriales, todo es muchísimo más sencillo de lo que parece. Al grano, para tener funcional la conexión VPN a tu Net-Lan de Telefónica has de seguir los siguientes pasos (Debian y Debian-like, probado en Ubuntu 8.10 – easy peasy y Debian 5.0 Lenny):

Instalamos el software que nos sirve más que de sobra para esta y otras conexiones VPN, se trata de vpnc, con licencia GPL, que las cosas cuanto mejor se preparan mejor salen

#apt-get install vpnc

no tendremos problemas, dado que se encuentra en los repositorios oficiales de las distribuciones empleadas.

una vez tenemos instalado el vpnc, debemos transformar los ficheros de configuración que nos da Telefónica (.pcf) a un fichero legible para el vpnc, que siguiendo el clasico de los *nix será un .conf guardado en el path /etc/vpnc/.

el vpnc incluye una utilidad que nos hará la conversión de un tipo de fichero a otro directamente, ejecutamos.

#/usr/share/vpnc/pcf2vpnc ruta-fichero.pcf /etc/vpnc/nombre-conexion.conf

ya tenemos el fichero creado, lo ideal sería:

#vim /etc/vpnc/nombre-conexion.conf

IPSec gateway <gateway>
IPSec ID <group-id>
IPSec secret <group-psk>
IKE Authmode hybrid
# Xauth username <username>
# Xauth password <password>

NAT Traversal Mode cisco-udp

Añadir la última línea al final para asegurarnos una mayor compatibilidad con la Netlan; en el caso de que meter el usuario y/o password cada vez que nos conectemos nos suponga un sufrimiento, podemos descomentar las líneas del Xauth y la ejecución será más rápida, un fichero nos quedaría tal que así, llamemoslé, por ejemplo, LITS.conf.

## generated by pcf2vpnc
IPSec ID LOSTINTHESHELL
IPSec gateway LOSTINTHESHELL1.ipsec.rima-tde.net
IPSec secret LOSTINTHESHELL
IKE Authmode psk

## To add your username and password,
## use the following lines:
Xauth username berto@LOSTINTHESHELL
# Xauth password <your password>

NAT Traversal Mode cisco-udp

Con esto tendría listo una conexion a mi NETLAN, denominada LOSTINTHESHELL, y, en este caso, recordaría mi usuario “berto”, pero no la contraseña de acceso, ahora, para conectarme a mi RPV tan sólo tendría que ejecutar…

#vpnc-connect LOSTINTHESHELL

… et voilá.

Actualización: No es mi caso, pero algún compañer@ ha tenido percances del tipo “me conecta 1 vez de cada 10 (o 20); presumiblemente lo he solucionado realizando un ping al gateway y colocando en lugar del nombre la resolución de su IP, algo que puede ir solucionado intrínsecamente con otro problema que dejaré para mañana (el borrado de las DNS en el /etc/resolv.conf cada vez que “cortas” la conexión VPN).

Share on Facebook