Encontrar WLANs visibles en los SS.OOs

Tal y como dije hace casi un mes, desde Windows se pueden hacer bastantes cosas con respecto a las redes utilizando comandos tal y como se puede hacer en Linux.

Ahora, leyendo Systemadmin, hablan sobre cómo encontrar las WLANs visibles desde línea de comandos usando Linux, Windows y Mac-OS.

La verdad, no  lo he probado, pero creo que en este caso, no hace falta que repita lo que ya han dicho. ¿No?

Metro exposed

Hace unas semanas, SbD hizo una serie de posts sobre ethernet exposed (a día de hoy, I y II). Esas imágenes de puertos ethernet en sitios públicos y muy accesibles. Esa posibilidad de conectarse a la red de ese lugar sin ningún control.

Ahora, imaginaos que en un lugar público se filtra información de los equipos que tienen conectados. Por poner un ejemplo real. Hace... unas semanas pude hacer esta foto en la estación de Moncloa, en la línea amarilla, sobre las 7:30 de la mañana:

Dirección MAC de Metro de Madrid

Como se puede ver, ahí tenemos una dirección MAC que se nos ha hecho pública. Y, ¿qué información podemos sacar entonces? ¿Nos podemos conectar así como así con esta información? Sólo con esto, poco se puede hacer. Pero, sabiendo que los 6 primeros dígitos de una dirección MAC pertenecen al fabricante, podemos encontrar que pertenece a SEPSA. Mucho ojo, la dirección web que nos muestran no parece que tenga nada que ver con tarjetas de red. Si hacemos una búsqueda de

SEPSA pinto

en Google podemos ver que es una empresa de Pinto, Madrid, que se especializa en la "fabricación y venta de sistemas electrónicos de potencia y sistemas digitalizados de información para control y anuncio en el ferrocarril". Pertenece al grupo Albatros. Por cierto, alguna de estás páginas está un poco desactualizada. 

Con esta información habría que pensar: ¿Es sólo la tarjeta de red de esta empresa o es todo el sistema? Según se puede desprender de la información de su página oficial, lo más probable es que todo el sistema sea suyo. Ahora, tocaría saber qué significan los otros datos. 

Ahora me acabo de preguntar: ¿Esta pantalla estaba así en todas la líneas? ¿Sólo en esta? ¿Sólo en este tren?

Ahora, vamos a otro tren. En esta ocasión, no hace más de una semana y pico. En la misma línea, en dirección opuesta. Es decir, dirección Moncloa. En esta ocasión me llevé otra sorpresa.

Disk failure en Metro de Madrid

No voy a negar que me costó mucho hacer estas fotos. Incluso, como podéis ver, he tenido que unir estas dos imágenes para mostrar el mensaje. Con el traqueteo, me salían movidas. Pero, ahí lo tenemos. El equipo que muestra los vídeos se le fue al garete del disco duro. Y todo el mundo se enteró.

Alguna otra que mostraba más información era esta:

Dispositivos del equipo con un disk boot failure.

En el que podemos ver que 3 USB 1.0, un USB 2.0, sus controladoras IDE (luego, muy nuevo no debe de ser porque cada vez es más difícil encontrar las placas base con IDE, a mi manera de verlo), su tarjeta de red (¿será la que se ve más arriba?). Vamos. Más información sobre lo que se está usando para transmitir la información al público. 

¿Alguno tiene más imágenes de estas? Porque pantallazos azules en el Metro alguna vez sí que han aparecido. O alerts. 

SEO en el blog

Hace unos cuantos meses conté que había hecho unos virtual hands on lab por parte de Informática64. Hace poco, unas semanas más o menos, quise mirar qué formación tenían planeado hacer ahora. Por lo que se me ocurrió buscar

informatica64 vhols

y me llevé una sorpresa mayúscula:

Haciendo SEO sin querer...

No se cómo, pero con esa búsqueda estoy el 4º en la lista. La verdad, estoy muy sorprendido. Estoy que no me lo puedo creer. Supongo que no durará mucho, pero mientras tanto, aquí queda constancia del hecho. :)

La cucaracha, la cucaracha ...

Hace un mes, más o menos, me pasaron un ordenador muy antiguo para que lo destripara. Así, podía conseguir unas cuantas piezas de repuesto. De esas que tarde o temprano acabas usando. Y, como la placa base no me servía para nada y la iba a tirar, se me ocurrió destriparla.

Esta es la placa base:

Placa base para destripar

Lo primero que quise hacer con esta placa base, por extraño que parezca, fue quitarle la cucaracha. ¿Qué cucaracha? La de la BIOS:

Cucaracha BIOS "instalada"

¿Por qué "instalada"? Porque estoy recreando lo que hice. No la he encajado en su posición, simplemente está encima. Total. Cogí la herramienta para extraer estos bichos...

Sacando la cucaracha

Tiré con fuerza, en dos zonas distintas y...

Cucaracha extraida

Y, la placa base...

El hueco de la cucaracha

Ya de paso, y esto no estaba planeado... Voy a desmontar el micro.

Microprocesador Pentium II

Un microprocesador de Pentium II. De los que montaron en modo slot.

Placa base sin microprocesador ni BIOS.

Y, el micro, por los suelos:

Microprocesador Pentium II

Y así se quedan las cosas. La verdad, estas piezas no sirven. Pero, ya que voy a destriparlo del todo... me quedo con unas cuantas cosillas:

Tornillos y jumpers

Aquí están las 3 fotos que he hecho a los tornillos y jumpers. El resto de las cosas... al punto limpio. 

¿Vosotros qué hacéis cuando os llega un equipo de estas características?

Protegiendo con virtualización y sandboxes.

Estoy en LinkedIn. La verdad, ahora no me acuerdo muy bien si tengo el perfil totalmente público o no. Supongo que no, porque intento tener cuidado con todos esos temas. Que lo consiga... eso ya es otra historia.

Entre otros grupos, estoy dentro de uno que se llama... malware analysis. Hay un hilo en el que participé porque me interesaba aprender muy bien a analizar bichos. O, al menos, por analizar los cambios que producían en el sistema objetivo. Ya había jugado con bichos antes. Pero fue eso, jugar. No ver los cambios producidos en el sistema.

Así, algunos de los programas que tengo que probar un año de estos, y que me sugirieron,  sería InCtrl5. O RegShot. Que, según me cuentan, ambos hacen una comparación de dos snapshots del sistema. Un antes y un después. Así, te darán un informe sobre los cambios en el registro, o ficheros añadidos al sistema...

La otra cosa que sugerían, y que ya sabemos, es probar los bichos en una máquina virtual. Ya sea VMware, VirtualPC o VirtualBox, entre las famosas. Además, para mejorar el aislamiento, se podría ejecutar el programa de virtualización sobre una sandbox, como por ejemplo, Sandboxie. La sandbox, que no es algo muy común, permite aislar (en teoría) ese programa o bicho del resto del sistema. Si ya en teoría un proceso sólo puede acceder a su parte de memoria, esto lo que hace es... más o menos como si lo engañara para que en el caso de querer salir de su trozo de memoria asignado, no sea capaz de acceder.

Ahora bien, tal y como comentan en dicho hilo, una sandbox no tiene por qué ser 100% eficaz. En este tema no existe la seguridad absoluta. Del mismo modo que una máquina virtual te puede pasar un bicho sin necesidad de que tenga la red activada. Y sí, se puede hacer. A ver si lo escribo bien: Jhoanna  Rutcouska Joanna Rutkowska, de The invisible things, lo hizo. Es más, cuando dijo que no se podía las casas de software de virtualización dijeron que no lo era. Después de un "sí se puede", "no se puede".

- ¿Ah, no? Entonces ¿Y esto qué es?


Al menos, es tal y como me lo comentaron. La verdad, sólo me he leído un artículo suyo. Y estoy suscrito en los feeds. Pero así lo hizo. Consiguió pasar de una máquina virtual al equipo físico a través de la memoria. Siguiendo con LinkedIn. En dicho comentario han publicado un sitio en el que hablan de los rings del sistema operativo. Está muy bien explicado.

Luego, si nos hacemos la pregunta: ¿puedo usar la sandboxie con las máquinas virtuales? ¿O ambas por separado? Supongo que dependerá de para qué. Si vas a ejecutar un bicho, lo mejor es usar ambas. Al menos, mejor eso que nada. O, tener un equipo que sea exclusivo para esos menesteres y que esté bien aislado. No se. Creo que ahora mismo no me puedo posicionar al respecto. ¿Alguien quiere dar su opinión al respecto?

ifconfig = Linux. ¿Windows?

¿A que sí? ¿A que es muy críptico el asunto de este post? Creo que hace un tiempo ya publiqué algo sobre solucionar problemas de las conexiones en red de Windows. Además, ya dije que tendríamos más historia al respecto.

¿Cómo averiguas una dirección IP desde un linux? Muy sencillo, ¿verdad? Ejecutas:

ifconfig

y, de manera optativa, puedes poner la interfaz de red si te la sabes. Un ejemplo puede ser el de la imagen:

Resultado de ejecutar: ifconfig eth0

Y, ¿cómo hacemos esto en Windows? En Windows podemos ejecutar el comando

ipconfig

que nos devuelve todas las conexiones de red activas. ¿Cómo obtenemos sólo la información de la interfaz que queremos? Uno de los parámetros que permite obtener el de una de las conexiones en concreto es el comando:

netsh

Ya lo usamos la anterior vez para resetear la pila de TCP/IP. En este caso he ejecutado:

netsh int ipv4 show addresses name="Local Area Connection"

que, si lo he transcrito bien, se debería de obtener un resultado como el de la imagen:

Resultado de ejecutar un: netsh int ipv4 show addresses

El resultado es similar a hacer el ipcofig, pero permite filtrar por los datos que queremos. 

¿Qué más podemos hacer? 

En linux, con ifconfig, se puede configurar una dirección IP con un script, o "a mano", con un comando parecido al siguiente:

ifconfig eth0 192.168.116.14 netmask 192.168.116.254 up

De hecho, ese "up" sólo sería necesario si la interfaz en cuestión no estuviera levantada. ¿Y si quisiéramos hacer lo mismo en Windows? Aaah, amigo. Ahí la cosa cambia. Y es donde quería llegar. El problema es que estamos acostumbrados a hacer esa configuración la bonita interfaz gráfica que nos trae el sistema operativo:

Interfaz gráfica para configurar TCP/IP en Windows

¿Y si quisiera configurarla con un fichero por lotes (léase, un batch)? Bueno. Pues volvemos al netsh. Podríamos ejecutar algo como esto:

netsh int ipv4 set address name="Local Area Connection" dynamic dhcp

para que la dirección IP se configure sola. ¡Y yo probando dynamic! La otra opción es especificarla estática:

netsh int ipv4 set address name="Local Area Connection" static 192.168.116.110 255.255.255.0 

¿Y para indicarle los DNSs? Si nos vamos a linux, tenemos un fichero de texto que se encuentra en /etc/resolv.conf

/etc/resolv.conf

Si nos metiésemos en Windows sería algo parecido a lo siguiente:

netsh int ipv4 set dnsserver name="Local Area Connection" static 123.45.67.190 

Si quisieramos un segundo DNS tendríamos que añadirlo

netsh int ipv4 add dnsserver "Local Area Connection" 234.56.78.91 

Lo de añadir más de un DNS no lo había hecho nunca. Por me ha costado ponerlo. De hecho, se puede poner un parametro más a esta última línea que es index=2. Si tuviéramos más servidores en la lista, podríamos indicar en qué posición colocarlo.

Tal y como hicimos antes, se pueden establecer con DHCP:

netsh int ipv4 set dnsserver "Local Area Connection" dhcp 

¿Qué más podemos configurar? Podríamos configurar la puerta de enlace. Muy importante si queremos salir al Interné. En linux, para recordar un poco cómo se hacía, se puede poner esto:

route add default gw 192.168.116.1

¿Y si queremos seguir el mismo sistema en Windows? Podemos hacer el siguiente comando:

netsh int ipv4 set address name="Local Area Connection" gateway=192.168.116.1

Así, podemos establecer estos valores automáticamente. 

No se si hace falta que ponga pantallazos de la ejecución de los otros comandos que no he incluido. Si hiciese falta, por favor, decirlo, y buscaré un hueco para montarlos. También, si queréis aportar algo sobre este tema, no os cortéis. Que para eso está la opción de los comentarios, ¿eh?

P.D: En la vista previa estoy viendo que aunque he cambiado la fuente para los comandos, parece que no se distingue mucho. ¿Qué creéis? Bueno. De momento le pongo este color anaranjado. Así resalta los comandos y no queda muy chillón. De todas formas, por favor, comentadme lo que opináis. Así puedo intentar utilizar siempre el mismo criterio. Muchas gracias.  

Windows - Problemas con TCP/IP

Hace un tiempecillo estaba trabando con unas máquinas virtuales con Windows... ¿2008 puede ser? No me acuerdo muy bien. 2008, 7, Vista... Alguno de estos. Mi problema era que no conseguía que TCP/IP acabara de funcionar del todo bien. Había algún ping que no devolvía datos, otros sí. Haciendo memoria, creo que un

ping localhost

me devolvía resultados de IPv6.

Un

ping 127.0.0.1

me daba... tiempo de espera superado. Puede ser. Vamos, que no había resultados.

Y, un

ping IP_ASIGNADA_AL_%COMPUTERNAME%

también me daba resultados satisfactorios.

Toltal, que buscando... buscando... buscando... Me dieron la solución. Se trata de reseetear la pila del protocolo TCP/IP. ¿Cómo se puede hacer eso? Es muy sencillo. En un símbolo del sistema / cmd, con privilegios de administración, se ejecuta:

netsh int ip reset c:\reset.log

Después, hay que reiniciar el equipo.

De hecho, en teoría, no debería de hacer falta poner la ruta a los logs. Mejor obviarla.

Una vez hayas reseteado, vuelve a intentar el ping otra vez. Debería de funcionar. Aún así, no te fíes si te responde a la primera. Inténtalo varias veces. Si, tienes la mala pata de que vuelve a hacerte lo mismo... Te estará pasando lo mismo que a mí. ¿Cómo lo solucioné? Eliminando el dispositivo de red en cuestión del sistema y permitiendo que volviera a instalarlo por su cuenta al reiniciar el sistema.

Desinstalando la tarjeta de red.

Una vez restaurado el dispositivo, toca volver a ponerle la configuración de red. Pero, eso, ya es otra historia.