Dejar wifi integrada como wlan0 como norma

Hola

Trabajo en un proyecto personal sobre kali para raspberry pi.

No logro entender la versionitis que tiene la gente de offensive security para que les lleve a lanzar 3 versiones de kali al a;o, y haya cambios tan significativos entre ellas.

Estoy mudando mis scripts desde kali 2017.3 a 2018.3, y ahora se me presenta un problema, y es que antes siempre me nombraba mi dispositivo wifi usb como wlan1, y la integrada como wlan0, y ahora hay veces que inicio con la integrada como wlan0, y wlan1 indistintamente. Que le asigne 1 o 0 no responde a nada que yo comprenda. Esto es una gran faena para mis scripts

Alguna idea de como dejar fija la integrada como wlan0?

Otra que me han hecho es que ahora en vez de wlanXmon, las monitor se llaman mon.wlanX. Esto me descabala unos cuantos scripts tambien. Dichosa versionitis. Esto no me preocupa tanto, pero si es molesto de veras.

A que se debe tanto cambio? Dan autenticas ganas de migrar, pero las opciones tampoco son tan buenas.
yo soy de que si algo funciona, no tocarlo salvo por motivos de seguridad, claro. Realmente es necesario el salto de wlanXmon a mon.wlanX cuando llevamos poco tiempo con wlanXmon?

Hola javierbu.
Mi primer consejo para los scripts es** no** usar el nombre de la interfaz sino el nombre “físico” (phyX)
Si haces esto tus scripts serán compatible con todas las interfaces sin importar la distribución y el esquema de nombres en uso.
Es un error usar el nombre.

No es una versionitis ya que no son versiones… Son imágenes del sistema a un momento preciso. El sistema es kali rolling y se hace una fotografía del estado del sistema a un momento preciso para que ahorras tiempo de actualizaciones… Si descargas la primera entrega de kali rolling tendrías 3 años de actualizaciones por hacer después instalar.
En mi opinión le mejor es usar las weekly build si quieres descargar una ISO.

Es lo que pasa por “anular” los nuevos nombres de interfaces. No es exactamente lo mismo que como se hacía antes. Y si enchufas y desenchufas un USB puede resultar que este detectado y nombrado antes de la interna y se invierten los nombres de interfaces,

Todo esto no es un problema si te fijas en phy en lugar de wlan… :wink:

[quote]A que se debe tanto cambio? Dan autenticas ganas de migrar, pero las opciones tampoco son tan buenas.
yo soy de que si algo funciona, no tocarlo salvo por motivos de seguridad, claro. Realmente es necesario el salto de wlanXmon a mon.wlanX cuando llevamos poco tiempo con wlanXmon?[/quote]
No he visto esto de wlanX.mon… ¿Qué version de aircrack-ng tienes instaladas? Es airmon-ng que renombra la interfaz independientemente de la distribución y de los nombres de interfaces.
Las wlanXmon son los nombres por defecto desde 2014, son ya 4 años, y el cambio viene de aircrack-ng, no de offensive security.
Voy a arrancar el Kali para mirar esto y vuelvo por aquí…
… He probado en Kali y no veo nada raro…

[code]root@tekomo:~# airmon-ng

PHY Interface Driver Chipset

phy0 wlan0mon rt2800usb Ralink Technology, Corp. RT2870/RT3070

root@tekomo:~#
[/code]
Aircrack-ng está actualizado con bleeding-edge.
No sé qué decirte… ¿Te molesta reproducir el error y copiar y pegar todo lo que pasa en consola?

yo lo que encontrado con ese nombre de modo monitor es esto:

mac80211
Modo de monitor

Utilice el comando “iw” con el moderno mac80211 para generar una interfaz de monitor real: no olvide iniciar la interfaz

[code]iw phy phy0 interface add mon0 type monitor

ifconfig mon0 up[/code]
NOTA: Los dispositivos mon.wlanX son interfaces de monitor cocidas requeridas por hostapd para comunicarse con el controlador. No son verdaderas interfaces de monitor.

Ver también http://wireless.kernel.org/en/users/Documentation/iw

fuente:
https://sites.google.com/a/martin.cc/main/linux/mac80211

Hola de nuevo y muchas gracias

[quote=crash]NOTA: Los dispositivos mon.wlanX son interfaces de monitor cocidas requeridas por hostapd para comunicarse con el controlador. No son verdaderas interfaces de monitor.
[/quote]
Toda la razon y culpa mia. 1000 perdones. Creo que fui presa de la frustracion al ver que no funcionaba nada despues del upgrade y me deje llevar por el cabreo.

No tenia tan claro que puedo causar el mon.wlanX, pero ahora me queda claro que fue hostapd, que lo uso en varios de mis scripts. Despues de volver a tomar el teclado con mas calma, ya veo que se sigue usando el wlanXmon.

No lo veo tan viable por 2 razones fundamentales. La primera es cuando el script es del tipo "Introduce la interface para hacer tal ataque: " No puedes pedir al usuario que ponga phyX, ademas de que no resolveria el problema. Esto es porque es una loteria que a la integrada se le asigne phy1 o phy0 a cada reinicio, y de ahi parte mi problema.

Y la otra razon, es que son scripts pensados para arrancarse al inicio de la raspberry, tipo wardriving, fakeAP, mana, etc…, y tendriamos un 50% de posibilidades de se asignaran los phyX de la manera que queremos.

Lo que se me ocurre es no dejar en manos del usuario del script elegir con que interface hara tal o cual cosa, y deducirlo con un poco de codigo en el script para buscar la interface ideal para el momento.

Como es una raspberry pi, puedo jugar con que el chipset de la integrada, que es muy concreto

[code]PHY Interface Driver Chipset

phy0 wlan0 ath9k_htc Atheros Communications, Inc. AR9271 802.11n
phy1 wlan1 brcmfmac Broadcom 43430

Missing nexutil, cannot switch to monitor mode.

[/code]

sabiendo que en mi raspberry siempre existira una interface que use el driver brcmfmac, ya es muy sencillo encontrar “la otra” dentro de mi script y usarla para lo que necesite. Algo como…

root@kali:~# airmon-ng | grep phy | grep -v brcmfmac | awk '{print $1}' phy0

Como siempre, quiza no sea la opcion mas elegante, pero al menos deberia funcionar. De esa manera ya encuentro la que NO es integrada para usarla como necesite.

me alegro que te haya servido la información de esa interfaz en modo monitor.
y ahora me pregunto yo… no te sería mas fácil, mirar en los procesos, cual es la interfaz que usa?
por ejemplo yo en mi sistema el proceso en la siguiente ruta

/proc/net/wireless

me dice esto:

Inter-| sta-| Quality | Discarded packets | Missed | WE face | tus | link level noise | nwid crypt frag retry misc | beacon | 22 wlan0: 0000 53. -57. -256 0 0 0 194 7933 0

así que ya se que uso wlan0, esto es por darte alguna idea que sea algo mas sencilla.

Claro que me ayudo saber que fue hostapd el que me genero mon.wlanX. Estaba entre hostapd y kismet al momento de leer tu comentario. Muchas gracias

No entiendo bien lo que me dices y como podria usarlo. Te explico un poco mas a fondo el problema a ver si realmente me ayuda lo que me dices, que no tengo ni idea.

Tengo un script que va pidiendo daros al usuario para lanzar un ataque con hostapd-mana.

Entre otras cosas, le pide el nombre de la interface wireless con el que se levantara el AP con hostadp. Para ello no sirve la broadcom integrada de la rpi. Tambien le pide la interfaz que se usara para dar internet, el nombre de la red, canal, etc. Una vez que quedan alamacenados los datos y confirmados, cada vez que enciendes la raspberry, se lanza automaticamente el ataque con hostapd-mana con los valores que le dijo el usuario. Y el problema es que un reinicio la wifi integrada es wlan1, y al siguiente puede ser wlan0, o wlan1. Y eso como comprenderas, me descabala todo.

Lo que propongo, si no encuentro una solucion mejor, es NO pedirle el nombre de la interface al susaurio (de la que usara hostapd), y en el script que levanta hostapd, incluir una linea tipo…

IFACE_HOSTAPD=`airmon-ng | grep phy | grep -v brcmfmac | awk '{print $1}'`

O cuando proceda, preguntar al usuario si usar la wifi integrada o la usb. Te recuerdo que todo esto es sobre una raspberry. y eso me facilita todo para distinguir la integrada de la(s) demas.

Otra pregunta al respecto para seguir el consejo de kcdtv, le puedo decir a hostapd que use phy0 en vez de decirle que use wlan0?

para que siempre sea la misma tarjeta con el mismo nombre hay que editar un archivo de configuración de systemd en la ruta:

/etc/udev/rules.d/70-persistent-net.rules

si no existe el archivo habría que crearlo.
por ejemplo yo tengo este archivo configurado así.

[code]SUBSYSTEM==“net”, ACTION==“add”, ATTR{address}==“00:21:97:XX:XX:XX”, NAME=“eth0”

SUBSYSTEM==“net”, ACTION==“add”, ATTR{address}==“”, NAME=“”[/code]

en la línea de abajo en NAME=pondría por ejemplo wlan0 u otro nombre que yo quisiera.
y en

ATTR{address}=="ponemos la mac que queramos de ese dispositivo, sea integrada o usb"

ejemplo:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:22:33:44:55", NAME="miwifi"

así puedo llamar a un dispositivo de una manera distinta del otro. esto si es para ti personal, identificaras mejor las interfaces, poniendoles distintos nombres. y aunque reinicie el sistema el nombre siempre será ese.

si es para el público pues entonces como dices esta bien.

Que interesante las rules esas. Me quedo con la info.

De momento estoy editando mis scripts de la manera que comente, agarrando la que NO es inegrada a traves de airmon-ng. hace muy bien su cometido de momento. Le echare un ojo a ese archivo rules y vere como termino implementandolo.

Muchas gracias de nuevo