Cuando la BIOS va por su cuenta …

… en cuestiones de red termina por liarse.

Más de dos días me ha costado encontrar el problema. Resulta que reemplacé una de las máquinas de facturación, una instalación Linux con Debian, con un equipo nuevo, más moderno, más potente, más cuqui, pero donde prácticamente no toqué la configuración del sistema (la del BIOS).

Estaba reutilizando la instalación previa en el disco y, ya que los núcleos de Debian que empleo son genéricos, no vi razón para ello. Arrancar y gozar del sistema.

Bueno, el goce lo he tenido yo porque me he encontrado una situación bastante absurda: no había forma de que el servidor DHCP de la red registrase el nombre correcto de la máquina.

Todo lo demás funcionaba excepto un par de detalles: al no tener el nombre correcto no podía acceder vía SSH para actualizarla ni VNC para asistir al operador en vivo y en directo. Todo por dirección IP.

Buscando y buscando en los registros veía que el nombre era siempre uno muy especial: SOE28219 y el sufijo de la red local, pero ni rastro del que tenía que tener.

Así que me dio por hacer un barrido de la red y me encuentro, oh sorpresa, con un servicio abierto tal que así:

$ sudo nmap -sT 192.168.100.74

Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-27 11:05 CEST
Nmap scan report for 192.168.100.74
Host is up (0.0027s latency).
Not shown: 995 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
111/tcp   open  rpcbind
631/tcp   open  ipp
5900/tcp  open  vnc
16993/tcp open  amt-soap-https
MAC Address: 2C:41:38:93:FD:B5 (Hewlett-Packard Company)

Lo primero que pensé es que había algún programa rarito y busqué entre los procesos de la máquina sin ningún éxito. Procedí, un poco en plan loco, a instalar programas para detectar procesos ocultos, troyanos y rootkit (rkhunter, tiger, unhide, …) y nada de nada. Es una máquina de trabajo sencilla, no tiene nada raro conectado, y tampoco pueden instalar programas por su cuenta. Ni lo intentan, para ser claros.

Y es entonces cuando me fijo en la descripción del servicio: amt-soap-https y me da por buscar en la red y, ¡ mira por dónde ! resulta que corresponde al interfaz de un mecanismo muy específico de Intel llamado Intel Active Management Technology.

Este mecanismo, del que hablan en el wiki de Debian, no es más (ni menos) que una forma de gestionar remotamente un equipo conectado en red. En red, ojo, y he aquí donde está todo el problema: el BIOS emplea la misma interfaz de red para solicitar una dirección IP al servidor central con un nombre de cliente específico. Activa entonces un servidor en esa misma dirección y se queda a la escucha. Además filtra las conexiones cuando son desde la propia máquina así que sólo aparece desde fuera. En algunos foros y páginas de la red lo llaman directamente backdoor, y vaya que lo es.

Lo hace regularmente, encima, por lo que es bastante normal encontrarse entradas como la siguiente en el registro:

Apr 27 09:34:10 barbacana dnsmasq-dhcp[378]: DHCPDISCOVER(br-lan) 192.168.100.74 2c:41:38:93:fd:b5
Apr 27 09:34:10 barbacana dnsmasq-dhcp[378]: DHCPOFFER(br-lan) 192.168.100.74 2c:41:38:93:fd:b5
Apr 27 09:34:10 barbacana dnsmasq-dhcp[378]: DHCPREQUEST(br-lan) 192.168.100.74 2c:41:38:93:fd:b5
Apr 27 09:34:10 barbacana dnsmasq-dhcp[378]: DHCPACK(br-lan) 192.168.100.74 2c:41:38:93:fd:b5 operador
Apr 27 09:38:49 barbacana dnsmasq-dhcp[378]: DHCPREQUEST(br-lan) 192.168.100.74 2c:41:38:93:fd:b5
Apr 27 09:38:49 barbacana dnsmasq-dhcp[378]: DHCPACK(br-lan) 192.168.100.74 2c:41:38:93:fd:b5 SOE88219

Así que el sistema operativo solicita una dirección IP a la red, se le ofrece una y se anota el nombre de máquina requerido. Un poquito después el BIOS pide de nuevo la dirección y al ser la misma MAC el sistema se la renueva y apunta el extraño nombre.

Hay herramientas en Linux para poder aprovechar las ventajas del mecanismo. Un paquete llamado amtterm (Serial-over-lan (sol) client for Intel AMT, console version) pero que tiene problemas para conectar por fallos en el certificado digital así que por ahí no he conseguido nada tampoco. Como curiosidad anoto que el puerto 16993 es para conexiones SOAP sobre HTTPS y el puerto 16992 para conexiones sin cifrado.

En resumen: puede que tenga utilidad para mi en algún futuro pero por ahora sólo es una molestia.