Ningún programa garantiza control total. El adolescente puede abrir otro navegador, instalar un APK, añadir una segunda cuenta, usar un dispositivo ajeno o simplemente encontrar un servicio nuevo en lugar del bloqueado. Las limitaciones técnicas reducen el riesgo y dan tiempo al padre para notar un problema, pero no reemplazan los acuerdos familiares y un diálogo abierto y de confianza. En esta guía intentaré ayudar con la parte técnica.

Qué herramientas son relevantes para Android

Primero hay que elegir no la aplicación «más estricta», sino la herramienta para la tarea concreta. Control de tiempo, filtrado de sitios y localizador familiar resuelven problemas distintos. No conviene instalar de entrada dos sistemas que bloqueen aplicaciones: pueden entrar en conflicto, solicitar permisos del sistema a la vez e interferir con el funcionamiento normal del teléfono.

Family Link sigue siendo un buen punto de partida para un smartphone Android con Google Play. Kaspersky Safe Kids y Kids360 conviene considerarlos cuando la familia necesita un sistema de control parental independiente y no solo las reglas de Google. Dónde están mis hijos es mejor usarlo como localizador adicional, no como la única forma de proteger el teléfono.

Qué ajustar antes de instalar aplicaciones

• Cuenta separada para el niño. No use una cuenta de Google común para toda la familia. Un inicio de sesión compartido no permite separar historial, compras, reglas de Google Play y accesos.
• Bloqueo de pantalla. El PIN o la contraseña del padre no deben coincidir con el código de desbloqueo del teléfono del niño. Si no, el niño podrá confirmar instalaciones y cambiar reglas desde el dispositivo del adulto.
• Autenticación de dos factores en la cuenta del padre. La gestión de Family Link, las compras y el grupo familiar están ligados a la cuenta de Google del adulto.
• Prohibir perfiles extra. Un segundo usuario u otra cuenta en el dispositivo suele anular la configuración de control.
• Reglas para dispositivos de repuesto. Una tableta, un móvil antiguo, el ordenador de un familiar o el teléfono de un amigo no quedarán bajo las mismas restricciones si solo se configura un dispositivo Android concreto.

Cómo configurar Google Family Link

Family Link es adecuado para Android con servicios de Google. La aplicación del padre está disponible para Android y iPhone. En el teléfono del niño debe haber una cuenta de Google separada vinculada al grupo familiar.

En Android 8.1 y posteriores la configuración inicial suele estar en ====code====

Ajustes → Bienestar digital y control parental

Ajustes → Google → Todos los servicios → Niños y familia → Control parental

Tras conectar, abra Family Link en el teléfono del padre y compruebe que la aplicación muestra el smartphone correcto. Si el niño usa varios dispositivos Android o un Chromebook, hay que revisar los ajustes en cada uno de ellos.

Cómo limitar el tiempo de pantalla en Family Link

En Family Link hay un límite diario general, un horario de bloqueo y limitaciones por aplicación. Configurar solo un temporizador general es incómodo: tras su fin pueden quedar inaccesibles mapa, transporte, agenda escolar o la llamada a los padres.

1. Establezca el límite diario.
   En Family Link seleccione el perfil del niño y pulse ====code====

   Tiempo de pantalla → Límites de tiempo → Límite diario

   ============= . Defina valores separados para días laborables y fines de semana.
2. Configure el modo nocturno y el horario de estudio.
   Abra ====code====

   Tiempo de pantalla → Límites de tiempo → Horario semanal

   ============= . Indique las horas en que el teléfono debe quedar bloqueado. Ese horario ayuda a eliminar juegos nocturnos y la cadena de vídeos antes de dormir.
3. Ponga límites para aplicaciones concretas.
   Vaya a ====code====

   Tiempo de pantalla → Límites de tiempo → Límites por aplicación

   ============= . Elija el juego, la red social o el servicio de vídeos cortos y después pulse ====code====

   Establecer límite

   ============= .
4. Revise las aplicaciones sin límite.
   En la misma sección existe la opción ====code====

   Sin límites de tiempo

   ============= . No deje aquí el navegador, servicios de vídeo ni juegos. Normalmente solo deben estar sin límites las llamadas, mapas, servicios escolares y transporte.
5. Use tiempo adicional manualmente.
   Bajo el nombre del dispositivo en la sección ====code====

   Tiempo de pantalla

   ============= hay ====code====

   Tiempo adicional

   ============= . Permite añadir minutos si el niño necesita terminar una conversación, enviar la tarea o volver a casa.

No se pueden limitar por tiempo las aplicaciones del sistema. Además, el informe de Family Link contabiliza el tiempo que la app aparece en pantalla, no el que trabaja en segundo plano. Música, navegación y algunos mensajeros pueden no reflejarse completamente en las estadísticas.

Cómo prohibir aplicaciones y compras

La aprobación de descargas y el bloqueo de una aplicación instalada funcionan de modo distinto. La aprobación impide descargar una nueva aplicación sin el consentimiento del padre. El bloqueo cierra una aplicación que ya está en el smartphone.

Para bloquear una app abra el perfil del niño y vaya a ====code====

Tiempo de pantalla → Límites de tiempo → Límites por aplicación

Permitido

Bloqueado

Listo

Para las solicitudes de instalación abra ====code====

Ajustes → Google Play → Aprobación de compras y descargas → Qué requiere aprobación

Cualquier contenido

Google Play permite volver a descargar aplicaciones que el padre aprobó antes, así como programas de la biblioteca familiar. Por eso es útil revisar la lista de juegos y servicios instalados una vez al mes en lugar de fiarse solo de solicitudes antiguas de aprobación.

Cómo activar las restricciones por edad en Google Play

El filtro por edad y la solicitud de aprobación conviene usarlos juntos. El filtro oculta parte del catálogo, y la aprobación permite revisar una app concreta antes de instalarla.

En Family Link abra el perfil del niño y pulse ====code====

Ajustes → Google Play

Aplicaciones, juegos, películas y series

Libros

En el propio teléfono Google Play ofrece un PIN local: ====code====

Google Play → icono de perfil → Ajustes → Familia → Restricciones de contenido → Ir a la sección "Control parental"

Cómo configurar el filtro de sitios

En Family Link abra el perfil del niño y vaya a ====code====

Ajustes → Google Chrome e Internet

• Permitir acceso a todos los sitios. Chrome solo bloqueará las direcciones que añada el padre.
• Bloquear sitios para adultos. Google intenta limitar el acceso a la mayoría de sitios con contenido explícito, pero no garantiza cobertura completa.
• Permitir únicamente sitios aprobados. El modo más estricto. El niño solo podrá abrir direcciones de la lista del padre.

En las secciones ====code====

Sitios aprobados

Sitios bloqueados

Cómo prohibir un segundo perfil y la instalación de APK

Family Link gestiona la cuenta controlada de Google. Si en el teléfono aparece un segundo usuario o una cuenta de adulto, parte de las restricciones deja de funcionar.

En Family Link abra el perfil del niño y vaya a ====code====

Ajustes → Dispositivos en los que está iniciada la sesión → dispositivo del niño

Añadir y eliminar usuarios

Compruebe aparte la instalación de apps desde fuentes externas. En Pixel y en móviles con interfaz similar la ruta suele ser: ====code====

Ajustes → Aplicaciones → Acceso especial → Instalar aplicaciones desconocidas

Permitir instalación desde esta fuente

En Samsung, Xiaomi, Redmi, Honor y otros modelos los nombres de los apartados pueden variar. Use el buscador de ajustes del teléfono con palabras como «instalar aplicaciones desconocidas», «fuentes desconocidas» o «acceso especial».

Cómo configurar Kaspersky Safe Kids

Kaspersky Safe Kids es adecuado para familias que buscan un control parental independiente de las herramientas de Google. El servicio permite limitar el tiempo de uso del dispositivo, controlar aplicaciones, filtrar sitios, recibir notificaciones y ver la ubicación del dispositivo compatible.

1. Instale Kaspersky Safe Kids en el teléfono del padre e inicie sesión en la cuenta My Kaspersky.
2. Instale la aplicación en el teléfono del niño.
3. En el dispositivo del adulto seleccione el modo ====code====

   Padre

   ============= , y en el dispositivo infantil finalice la conexión del perfil del niño.
4. Permita solo los accesos del sistema que sean necesarios para las funciones elegidas. Sin acceso a las estadísticas de uso, la geolocalización o capacidades especiales de Android, algunas restricciones no funcionarán.
5. Configure los límites de tiempo, la lista de programas prohibidos, las categorías de sitios y las notificaciones.

Antes de activar el filtro web compruebe si se abren los sitios escolares, la agenda electrónica, los servicios bancarios de los padres y las apps de transporte. Si el filtro bloquea por error un recurso importante, el niño buscará otro navegador o pedirá desactivar el control completamente.

Cómo configurar Kids360

Kids360 usa dos aplicaciones: Kids360 se instala en el teléfono del padre y Alli360 en el del niño. El servicio ofrece límites de tiempo, bloqueo de apps seleccionadas, horario, estadísticas de uso, control web y geolocalización.

1. Instale Kids360 en el teléfono del padre.
2. Instale Alli360 en el teléfono del niño y vincule ambos dispositivos mediante el perfil familiar.
3. En la sección familia seleccione el dispositivo del niño.
4. Establezca el límite diario y el horario de bloqueo para la hora de dormir, estudio o tareas familiares.
5. Elija las aplicaciones que debe limitarse o bloquearse.
6. Compruebe el control web y la geolocalización si la familia realmente necesita esas funciones.

Kids360 permite bloquear automáticamente las aplicaciones tras el límite diario y según el horario. Antes de activarlo revise la lista de excepciones: mapas, llamadas, servicios escolares y transporte no deben desaparecer de forma inesperada cuando el niño esté fuera de casa.

Cuando hace falta un localizador y no un control completo

«Dónde están mis hijos» es útil cuando a la familia le importa saber si el niño ha llegado al colegio, a casa o al entrenamiento. El servicio muestra la ubicación del dispositivo, el historial de desplazamientos y permite recibir notificaciones sobre lugares fijados. Las estadísticas de uso del teléfono pueden ayudar a detectar un problema con el tiempo de pantalla.

El localizador no filtra sitios, no sustituye las restricciones de edad de Google Play y no bloquea aplicaciones peligrosas. No conviene presentar la geolocalización como protección en internet: el teléfono puede estar en casa mientras el niño habla con un desconocido por un mensajero permitido.

Por qué los adolescentes eluden las restricciones

El adolescente rara vez busca una forma de eludir las reglas solo para romper la prohibición. La causa puede ser un límite demasiado corto, bloqueo de un sitio escolar necesario, la falta de una vía rápida para pedir tiempo adicional o la sensación de vigilancia constante. Cuanto más precisas estén las normas, menos motivos habrá para buscar atajos.

Añadir y eliminar usuarios

Cómo no convertir el control en un conflicto continuo

• No establezca un único límite para todo. Juegos, vídeos cortos, servicios escolares y comunicación con familiares requieren reglas distintas.
• Deje una forma de pedir una excepción. En Family Link existe ====code====

  Tiempo adicional

  ============= . En otros servicios puede levantarse temporalmente un bloqueo o cambiarse el horario.
• Comenten las nuevas aplicaciones antes de instalarlas. No solo importa la clasificación por edad y el juego, sino la publicidad, las compras, los chats con desconocidos, la cámara, el micrófono y la geolocalización.
• No active una vigilancia constante sin motivo. La geolocalización es útil en el viaje y en una emergencia, pero el mapa no explica qué le pasa al niño ni si necesita ayuda.
• Revisen los ajustes juntos. El niño entiende qué datos están disponibles para el padre y el adulto detecta permisos excesivos, aplicaciones antiguas y excepciones olvidadas.

Qué revisar una vez al mes

• Lista de dispositivos y cuentas conectadas al perfil del niño.
• Prohibición de añadir nuevos usuarios.
• Aplicaciones con estado ====code====

  Sin límites de tiempo

  ============= .
• Nuevos juegos, navegadores, servicios VPN y gestores de archivos.
• Permisos de cámara, micrófono, contactos, fotos y ubicación.
• Restricciones de edad en Google Play y reglas de aprobación de descargas.
• Contraseña y autenticación de dos factores de la cuenta del padre.

FAQ: preguntas sobre control parental en Android

Zero Trust elimina la confianza automática. El sistema verifica cada solicitud y determina quién ingresa, desde qué dispositivo, a qué servicio, con qué privilegios, desde dónde y con qué nivel de riesgo. Si la verificación no pasa, el acceso se limita, requiere confirmación adicional o se bloquea.

El enfoque no surgió como una moda que reemplaza términos antiguos, sino como respuesta a problemas reales como phishing, contraseñas robadas, ataques vía contratistas, portátiles comprometidos, servicios en la nube y permisos demasiado amplios dentro de las empresas. El analista John Kindervag promovió activamente el término Zero Trust, y luego NIST y CISA describieron el modelo en detalle. Hoy el enfoque funciona no como un producto aislado, sino como un conjunto de reglas, procesos y tecnologías.

Qué significa Zero Trust

Zero Trust no significa desconfiar de los empleados. El modelo verifica no las cualidades personales, sino las condiciones técnicas del acceso. Un usuario puede ser de buena fe, pero la contraseña pudo robarse, el portátil pudo infectarse, la sesión pudo caer en manos de un atacante o los permisos antiguos pueden permanecer tras un traslado de puesto.

La idea principal es sencilla. No se puede conceder acceso solo porque el usuario esté en la oficina, se conectó a la VPN o ya inició sesión antes. Para cada acción importante hay que verificar la identidad, el dispositivo, considerar el rol y entender a qué datos accede la persona.

• Verificar explícitamente. Se tienen en cuenta la contraseña, MFA, el dispositivo, la red, el rol, el grupo, la sensibilidad de los datos y las señales de riesgo.
• Conceder los mínimos permisos. El empleado accede solo a los sistemas y datos necesarios para su trabajo.
• Asumir que puede ocurrir una intrusión. Incluso tras un inicio de sesión exitoso, el sistema limita el movimiento entre servicios y registra acciones sospechosas.

En el esquema antiguo la VPN a menudo daba al usuario gran parte de los recursos internos. En Zero Trust el acceso se emite con mayor precisión. El usuario se conecta a una aplicación concreta, carpeta, base, panel o API. Un contable no necesita el repositorio de desarrolladores, un contratista no necesita todo el sistema de archivos y un administrador no requiere permisos máximos permanentes durante toda la jornada.

De qué partes se compone el modelo

Es más práctico analizar Zero Trust por áreas que por nombres de productos. CISA en su modelo de madurez identifica cinco áreas principales: identidad, dispositivos, red, aplicaciones y cargas de trabajo, y datos. Todas las partes deben funcionar en conjunto. Si se activa MFA pero se mantienen cuentas compartidas y antiguos privilegios administrativos, no se logrará un modelo de confianza cero completo.

A nivel de herramientas, en Zero Trust suelen participar IAM, SSO, MFA, EDR, ZTNA, PAM, DLP, SIEM y sistemas de gestión de dispositivos. Pero enumerar productos no sustituye el orden en los accesos. Primero hay que entender quién tiene permisos, por qué se necesitan y quién se encarga de revisarlos.

Por qué las empresas necesitan Zero Trust

Zero Trust es necesario cuando ya no se pueden verificar los accesos solo por la localización de la conexión. Un empleado puede abrir el correo en la oficina, luego entrar en el CRM desde casa y por la noche conectarse al almacenamiento en la nube desde una tablet personal. En ese caso es más seguro verificar no la red en sí, sino el usuario, el dispositivo, la acción y los datos.

• Reduce el riesgo tras el robo de una contraseña. Si las credenciales cayeron en manos de un atacante, un usuario y contraseña no bastan. Las verificaciones adicionales incluyen MFA, el estado del dispositivo, el rol del usuario, el lugar de acceso, la hora, el tipo de recurso solicitado y el comportamiento en la sesión.
• Limita el acceso de contratistas y personal temporal. Al equipo externo a menudo le hace falta un servicio, carpeta, repositorio o panel concreto, no el conjunto completo de recursos internos. El acceso se puede dar por la duración del contrato y revocar sin buscar manualmente cuentas en varios sistemas.
• Reduce el daño en caso de cuenta comprometida. Si un atacante obtiene la cuenta de un empleado, no podrá pasar fácilmente a sistemas vecinos, carpetas compartidas, bases de datos o paneles administrativos. Los permisos sobrantes se retiran, las acciones se verifican y los intentos sospechosos quedan registrados.
• Ordena los permisos. La empresa ve quién accede a datos importantes, quién concedió permisos y por qué son necesarios. El orden es crítico al despedir, cambiar de puesto, tratar datos personales o acceder a sistemas financieros.
• Ayuda a proteger servicios en la nube. Correo, documentos, CRM, almacenamientos y analítica pueden estar con diferentes proveedores. Zero Trust traslada la atención desde la dirección del servidor hacia el usuario, el dispositivo, la acción y el valor de los datos.

Las primeras mejoras suelen comenzar con acciones básicas. Hay que activar MFA, eliminar cuentas compartidas, cerrar permisos innecesarios, verificar dispositivos y configurar registros de acceso. Si no, las discusiones sobre Zero Trust rápidamente se convierten en un esquema que queda bien en una presentación pero no ayuda a investigar un incidente.

Cómo implantar Zero Trust sin cambios bruscos

Es mejor implementar Zero Trust por etapas. Intentar reorganizar todos los accesos de golpe suele provocar quejas de usuarios, excepciones urgentes y un retorno temporal a reglas antiguas. Conviene empezar por un inventario. Hay que saber quién trabaja en la empresa, qué servicios se usan, dónde están los datos importantes, qué dispositivos se conectan, quién tiene permisos administrativos y qué integraciones funcionan con claves API.

1. Depurar las cuentas. Eliminar ex empleados, inicios compartidos, administradores innecesarios y cuentas sin propietario.
2. Activar MFA. Empezar por correo, VPN, paneles de administración, nubes, Git, sistemas financieros y servicios con datos personales.
3. Verificar los dispositivos. Portátiles y smartphones deben inventariarse, actualizarse, cifrarse y protegerse con EDR u otra solución similar.
4. Reducir los permisos innecesarios. Revisar grupos, roles, accesos a carpetas, bases, repositorios y funciones administrativas.
5. Restringir el acceso a servicios internos. Donde sea posible, sustituir el VPN amplio por acceso a aplicaciones concretas.
6. Configurar los registros. Debe verse quién inicia sesión, fallos de MFA, cambios de permisos, descargas grandes y acciones de administradores.

Para la primera fase es mejor elegir un área clara. Pueden servir los accesos administrativos, el correo y MFA, el trabajo de contratistas, la protección de datos personales o la eliminación del VPN amplio. Cuando la parte elegida funcione sin excepciones constantes, el enfoque se puede ampliar a otros sistemas.

Dónde las empresas cometen errores

Zero Trust no funcionará si se plantea como un proyecto solo del departamento de seguridad. Se necesitan administradores, propietarios de sistemas empresariales, RR. HH. y responsables de unidades. RR. HH. sabe quién fue contratado, trasladado o despedido. Los propietarios de sistemas entienden quién necesita acceso. Los administradores conocen las limitaciones técnicas. Seguridad transforma la información recibida en reglas y controles.

• Imponen restricciones estrictas sin explicar. Si a los empleados se les prohíbe de repente un acceso habitual y no se explica la razón, empezarán a buscar soluciones alternativas como correo personal, mensajería, cuentas compartidas y pedir a colegas que descarguen documentos.
• Olvidan las cuentas técnicas. Los scripts, integraciones, robots, CI/CD, copias de seguridad y monitorización suelen operar con permisos amplios. Hay que gestionar esos sistemas por separado.
• Mantienen métodos de acceso antiguos. La empresa despliega SSO y MFA, pero una aplicación sigue aceptando contraseña local. Es fácil pasar por alto una vía alternativa en la verificación.
• No revisan los permisos. Los accesos se acumulan con el tiempo. Un empleado cambia de puesto, participa en proyectos, obtiene permisos temporales y luego esos permisos permanecen abiertos.

Otro problema es confiar excesivamente en un solo producto. SSO, MFA o ZTNA son útiles, pero cada herramienta cubre solo una parte de la tarea. Sin tener en cuenta usuarios, dispositivos, datos y registros, Zero Trust queda en un conjunto de configuraciones aisladas.

Qué herramientas pertenecen a Zero Trust

El modelo de confianza cero no se ata a una sola clase de software. En grandes empresas el sistema se construye con varios niveles de protección. Una parte se encarga del acceso, otras controlan dispositivos, permisos, datos e investigaciones.

Para orientarse se pueden usar NIST SP 800-207, el modelo de madurez de CISA y los principios Zero Trust de Microsoft. Al elegir soluciones habrá que considerar requisitos sobre la ubicación de los datos, disponibilidad de productos, compatibilidad con directorios de usuarios existentes y soporte de sistemas ya implantados.

FAQ: cinco preguntas sobre Zero Trust

La herramienta está pensada para redes internas, donde servidores de archivos, estaciones de trabajo y directorios de servicio almacenan durante años documentos antiguos, copias de seguridad, scripts y archivos de configuración. En esos entornos con frecuencia quedan datos que permiten el acceso a servicios en la nube, repositorios, sistemas de compilación, bases de datos y aplicaciones internas.

SMB se usa en entornos Windows para el acceso en red a archivos y otros recursos. A través de él funcionan las carpetas compartidas de departamentos, los directorios personales de usuarios, los recursos administrativos, las carpetas con instaladores, informes y copias de seguridad. Sulla ayuda a comprobar rápidamente esos recursos y a identificar hallazgos peligrosos.

La utilidad no sustituye a un sistema de prevención de fugas, a una auditoría de permisos o a un inventario completo de los almacenes de archivos. Su objetivo es encontrar datos sensibles en recursos compartidos SMB accesibles y producir resultados en un formato útil para el análisis manual o para un procesamiento posterior.

Qué hace Sulla

Sulla puede funcionar en dos modos básicos. En el primer modo el usuario proporciona credenciales de dominio y el nombre del dominio; la utilidad detecta controladores de dominio, obtiene la lista de equipos activos, comprueba los recursos compartidos SMB disponibles y ejecuta la búsqueda de datos sensibles. En el segundo modo el operador indica un recurso compartido concreto o una lista preparada de objetivos.

Los datos sensibles los busca Titus. Es un motor de Praetorian, escrito en Go, que desarrolla ideas de NoseyParker. Contiene reglas para la detección de claves, tokens, cadenas de conexión y otras credenciales.

Funcionalidades principales de Sulla:

• busca automáticamente recursos compartidos SMB en hosts conectados a Directorio Activo;
• comprueba solo aquellos recursos compartidos a los que hay acceso de lectura;
• comprueba un recurso compartido concreto sin recorrer el dominio;
• carga la lista de objetivos desde un archivo en formato CSV o UNC;
• modo solo detección, en el que Sulla recoge rutas UNC sin buscar datos sensibles;
• excluye recursos compartidos, directorios y extensiones mediante expresiones regulares;
• modo rápido por defecto con límites de profundidad, tiempo y número de archivos;
• modo completo para una comprobación más profunda de objetivos seleccionados;
• extrae texto de documentos, PDF, archivos comprimidos y otros binarios mediante la bandera ====code====

  --extract

  ============= ;
• guarda informes en formatos txt, json, jsonl, sarif y capability-sdk;
• muestra hallazgos a medida que se detectan con niveles de criticidad Critical, High, Medium o Low.

Cómo funciona la búsqueda

Al ejecutarse en dominio, Sulla usa registros DNS SRV del tipo ====code====

_ldap._tcp.dc._msdcs.<domain>

En el modo de detección Sulla descarta cuentas de Directorio Activo deshabilitadas y equipos que no han mostrado actividad en más de cuatro meses. Al trabajar con espacios de nombres DFS la utilidad elimina duplicados de objetivos para no comprobar el mismo recurso físico a través de rutas distintas. Ese enfoque reduce tráfico innecesario y acelera el recorrido de redes grandes.

Tras el descubrimiento Sulla no lee todos los archivos. Por defecto está activado el modo rápido. En él la utilidad usa una lista de nombres, subcadenas y extensiones prioritarias, por ejemplo nombres como ====code====

id_rsa

credentials

.ps1

El modo rápido filtra no solo por exclusiones. Sulla además selecciona archivos que aparentan ser valiosos para buscar credenciales. El modo completo ====code====

--full

El modo completo tiene otro coste. Funciona considerablemente más tiempo y es más adecuado para la comprobación puntual de un recurso compartido o de una lista pequeña de objetivos. Al recorrer un dominio masivo, el modo completo puede generar carga adicional en la red y en los servidores de archivos.

Por defecto Sulla limita el tamaño de archivo a escanear a 5 MB. El parámetro ====code====

--max-scan-size

0

--extract

Las exclusiones estándar ayudan a reducir el ruido. Sulla omite recursos compartidos del sistema como ====code====

IPC$

print$

ADMIN$

node_modules

.git

vendor

El usuario puede ver las exclusiones por defecto mediante ====code====

--show-default-exclusions

-xe

-xd

-xs

--no-default-exclusions

--keywords

Un detalle útil es el archivo ====code====

interesting_exclusions.csv

Formatos de informes

Sulla soporta varios formatos de salida. ====code====

txt

json

jsonl

sarif

El formato ====code====

capability-sdk

<domain>.tabularium

Los informes deben tratarse como datos sensibles. Los formatos habituales ====code====

txt

json

jsonl

sarif

Para quién es apropiado Sulla

Sulla es útil para equipos que comprueban la red interna y quieren entender rápidamente qué credenciales están almacenadas en recursos compartidos SMB. La herramienta encaja con especialistas en pruebas de penetración, equipos de evaluación ofensiva, equipos de defensa, administradores de Directorio Activo e ingenieros responsables de la seguridad de claves y tokens fuera de los repositorios.

Escenarios claros donde Sulla resulta adecuado:

• comprobar servidores de archivos durante una prueba de penetración;
• buscar claves olvidadas de servicios en la nube, GitHub, GitLab, Jenkins, Slack y otros sistemas;
• analizar carpetas compartidas antiguas antes de una migración o de desmantelar un servidor de archivos;
• comprobar SYSVOL, directorios con scripts administrativos y carpetas de copia de seguridad;
• generar una lista de recursos compartidos SMB para análisis manual mediante el modo solo detección;
• elaborar informes para la corrección interna de los problemas encontrados.

No se debe ejecutar Sulla en una red ajena sin permiso. Para comprobar recursos compartidos SMB se necesita el consentimiento del propietario de la infraestructura, elegir la cuenta con cuidado y comprender la posible carga. El modo completo y la lectura de texto en binarios conviene usarlos donde se conozca de antemano el volumen de datos y la lista de servidores.

Instalación y ejecución

La documentación incluye compilaciones listas para Linux x86_64 y Linux ARM64. Tras la descarga el archivo debe marcarse como ejecutable.

====code====
# Linux x86_64

wget -O sulla https://github.com/praetorian-inc/Sulla/releases/latest/download/sulla-linux-amd64

chmod +x sulla



# Linux ARM64

wget -O sulla https://github.com/praetorian-inc/Sulla/releases/latest/download/sulla-linux-arm64

chmod +x sulla
=============

La segunda opción es ejecutar mediante Docker. Es conveniente cuando no se desea instalar la utilidad en el sistema.

====code====
docker pull ghcr.io/praetorian-inc/sulla:latest



docker run --rm --privileged --network=host 

  -v $(pwd):/sulla_output -w /sulla_output 

  ghcr.io/praetorian-inc/sulla:latest 

  -u admin -p secret123 -d corp.local -o results -of txt,json
=============

Para el recorrido del dominio se usa un comando con nombre de usuario, contraseña y dominio. En ese modo Sulla detectará el controlador de dominio, encontrará los recursos compartidos disponibles y escribirá el informe en los formatos seleccionados.

====code====
sulla -u admin -p secret123 -d corp.local -o results/ -of txt,json
=============

Para un inventario previo se puede activar el modo solo detección. El comando mostrará la lista de rutas UNC disponibles, que luego se pueden filtrar manualmente y pasar en un archivo separado.

====code====
sulla -u admin -p secret123 -d corp.local -do -o
=============

Si la lista de objetivos ya está preparada, Sulla acepta un archivo mediante ====code====

--target-file

====code====
sulla -tf corp_local_discovered_smb_shares.txt 

  -u admin -p secret123 -d corp.local -o results/
=============

Para comprobar un recurso compartido puntual se usan las banderas ====code====

-h

-s

====code====
# Comprobación anónima

sulla -h 192.168.1.100 -s public



# Comprobación con credenciales de dominio

sulla -h fileserver.corp.local -s SYSVOL 

  -u admin -p secret123 -d corp.local -o results/
=============

Ventajas y desventajas

--extract

interesting_exclusions.csv

Licencia

Sulla se publica como proyecto de código abierto bajo la licencia Apache-2.0. La licencia permite usar, copiar, modificar y distribuir el código si se cumplen sus condiciones y se mantienen los avisos. Para uso corporativo conviene comprobar adicionalmente las políticas internas sobre código abierto, almacenamiento de informes y tratamiento de datos sensibles.

Conclusión

Sulla resuelve una tarea concreta: busca datos sensibles en recursos compartidos SMB. En dominios grandes la comprobación manual de servidores de archivos se vuelve poco práctica, y las carpetas compartidas suelen contener scripts antiguos, copias de seguridad, configuraciones y documentos con accesos.

La utilidad combina el descubrimiento de dominio, el recorrido de recursos compartidos SMB, la filtración y el motor Titus en una herramienta de consola. El modo rápido permite obtener hallazgos iniciales con rapidez, mientras que el modo completo y ====code====

--extract

El riesgo principal no es ejecutar Sulla, sino los resultados. Los informes pueden contener claves y contraseñas en uso. Tras completar la comprobación hay que analizar los hallazgos, revocar credenciales expuestas, actualizar accesos, cerrar permisos innecesarios en los recursos compartidos y eliminar las causas iniciales de la fuga. En ese proceso Sulla no es un sistema de protección por sí mismo, sino una herramienta práctica para revisar periódicamente los almacenes de archivos internos.

SSO, o inicio de sesión único, elimina esa fragmentación. El usuario se verifica a través del proveedor corporativo de identidad, y los servicios conectados aceptan el resultado de esa verificación. Las aplicaciones no reciben la contraseña del empleado ni la almacenan. Confían en el sistema que gestiona las cuentas, la autenticación multifactor (MFA), los grupos, las funciones y las políticas de acceso. A continuación explico con más detalle cómo está organizado.

Qué es SSO y en qué se diferencia del inicio de sesión convencional

En la autorización habitual cada aplicación verifica al usuario de forma independiente. El correo tiene su propia base de cuentas, el CRM tiene la suya y el panel interno, otra. El administrador debe crear al usuario por separado, otorgar permisos, activar o desactivar el acceso y repetir lo mismo en otros sistemas.

En SSO la verificación la asume el proveedor de identidad. A menudo se le denomina IdP. Puede ser Microsoft Entra ID, Keycloak, Active Directory Federation Services u otro servicio de gestión de cuentas. En este esquema la aplicación se llama proveedor de servicios: no verifica la contraseña, sino que acepta la confirmación firmada por el IdP.

Este enfoque es especialmente importante al despedir a alguien, al cambiar de puesto y al trabajar con proveedores externos. Si la cuenta se desactiva en el proveedor de identidad, la persona pierde el acceso a los servicios conectados. Si un empleado pasa del departamento de ventas al departamento financiero, los permisos se pueden cambiar mediante grupos y roles, y no manualmente en cada aplicación.

SSO no sustituye a un gestor de contraseñas. Un gestor guarda contraseñas distintas y ayuda a no repetirlas. El inicio de sesión único cambia el propio esquema de acceso: el empleado se verifica en un solo lugar y las aplicaciones reciben el resultado de esa verificación. En una arquitectura corporativa razonable estas herramientas funcionan de forma complementaria. SSO protege los servicios de trabajo principales, y el gestor de contraseñas permanece para cuentas poco usadas, accesos de emergencia y sistemas sin soporte de inicio único.

Cómo funciona el inicio de sesión con SSO

Desde fuera el proceso parece sencillo: el empleado abre un servicio y elige iniciar sesión con la cuenta corporativa. Internamente se realizan varias comprobaciones. El servicio envía al usuario al proveedor de identidad, que verifica la cuenta, la contraseña, el segundo factor, el dispositivo, la dirección IP, la pertenencia a un grupo o el rol, y después devuelve a la aplicación una respuesta protegida.

1. El usuario abre un servicio corporativo.
2. El servicio detecta que no hay sesión local y redirige al usuario al IdP.
3. El IdP verifica la cuenta y aplica políticas de acceso: MFA, dispositivo, red, función, grupo.
4. Tras una verificación satisfactoria, el IdP emite una respuesta para la aplicación.
5. La aplicación verifica la firma, el tiempo de validez, la URL de retorno y los atributos del usuario.
6. Si todo es correcto, el servicio crea una sesión y abre el acceso.

Un detalle importante: la aplicación no recibe la contraseña, sino la confirmación de identidad. En SAML esto es una aserción firmada; en OpenID Connect, un ID token. La respuesta suele incluir el identificador del usuario, la dirección de correo electrónico, el nombre, grupos u otros atributos. Con esa información el servicio decide a quién dejar pasar y qué permisos otorgar.

Los errores en este esquema suelen relacionarse no con SSO en sí, sino con la configuración. Por ejemplo, una URL de retorno mal indicada, la ausencia de verificación de la firma, tokens con una duración excesiva, grupos que no se sincronizan o un inicio de sesión local con contraseña que sigue activo después de una migración. Por eso la implementación de SSO no puede reducirse al mero intercambio de metadatos entre dos sistemas.

SAML, OpenID Connect y OAuth 2.0: dónde suelen confundirse

En solicitudes y contratos a menudo se menciona soporte de OAuth, aunque lo que la empresa necesita es el inicio de sesión de empleados con la cuenta corporativa. OAuth 2.0 en sí resuelve otra tarea: permite que una aplicación obtenga acceso limitado a un recurso en nombre del usuario o de un servicio. Para el inicio de sesión de usuarios basado en OAuth 2.0 se utiliza OpenID Connect.

Si la empresa compra un SaaS, la especificación debe ser concreta: se necesita SAML SSO o OpenID Connect para el inicio de los usuarios. De lo contrario se puede obtener una integración para APIs, pero no la autorización adecuada de empleados con la cuenta corporativa.

Qué aporta SSO a la seguridad corporativa

El efecto principal de SSO es la gestión centralizada del acceso. El administrador trabaja con una única cuenta de empleado, no con un conjunto de credenciales dispersas en distintos servicios. Esto acelera la incorporación, los traslados entre departamentos y la revocación de accesos tras un despido.

SSO es especialmente útil para empresas con empleados remotos, proveedores externos y un gran número de servicios en la nube. Pero el inicio único no sustituye otras medidas de protección. Son necesarias la autenticación multifactor, el control de administradores, cuentas de emergencia separadas, la monitorización de accesos, el respaldo del IdP y un procedimiento claro de recuperación.

Dónde SSO puede crear nuevos riesgos

El proveedor de inicio único se convierte en un sistema crítico. Si no está disponible, los usuarios no podrán abrir servicios donde no exista una sesión activa. Si un atacante obtiene acceso a una cuenta administrativa del IdP, podrá cambiar reglas de acceso, añadir aplicaciones, otorgar permisos y eludir las restricciones habituales.

Otro riesgo son los métodos de acceso antiguos. Tras configurar SSO algunos servicios siguen aceptando contraseñas locales. El usuario parece entrar con la cuenta corporativa, pero en la aplicación queda una contraseña separada de la que se olvidaron. En un incidente ese acceso alternativo es fácil de pasar por alto.

Conviene revisar por separado las cuentas de servicio y las claves API. SSO gestiona el acceso de personas, pero no siempre revoca los accesos que usan integraciones, scripts, robots y procesos técnicos. Si un empleado creó una clave API personal para exportar datos, desactivar su cuenta SSO puede no revocar automáticamente esa clave.

• Active la autenticación multifactor para los administradores del IdP sin excepciones.
• Limite el acceso al panel de administración por roles.
• Guarde las cuentas de emergencia por separado y verifíquelas según el reglamento.
• Desactive el acceso local después de la migración, si el servicio lo admite.
• Revise las claves API, los tokens y las cuentas de servicio al desvincular a empleados.

Qué soluciones considerar en 2026

La elección depende de los servicios ya utilizados y de los requisitos de despliegue. Si la empresa trabaja con Microsoft 365, Teams, SharePoint e infraestructura Windows, normalmente se considera Microsoft Entra ID. Tiene muchas integraciones corporativas listas, autenticación multifactor, acceso condicional y gestión de aplicaciones.

Para infraestructuras propias a menudo se elige Keycloak. Soporta OpenID Connect, OAuth 2.0 y SAML, puede trabajar con LDAP y Active Directory, y admite roles, grupos y proveedores externos de identidad. La ventaja de Keycloak es la flexibilidad y el control sobre el despliegue. La desventaja: el sistema hay que actualizarlo, respaldarlo, monitorizarlo y protegerlo de forma independiente.

En los servicios rusos conviene comprobar el soporte de inicio único según la documentación del proveedor y el plan contratado. En Yandex 360 para empresas SSO se configura mediante SAML 2.0. En Kontur.SSO se describe el inicio en los productos de Kontur a través de proveedores corporativos de autenticación.

Cómo implementar SSO sin errores innecesarios

Conviene empezar por un inventario. Hay que elaborar una lista de servicios, propietarios, métodos de acceso, administradores locales, cuentas de servicio y claves API. Sin esa tabla es fácil conectar SSO solo para las aplicaciones visibles y olvidar paneles antiguos, cuentas de prueba e integraciones.

1. Reúna la lista de servicios. Indique el propietario, la criticidad, el método de acceso y el soporte de SAML u OpenID Connect.
2. Defina la fuente de usuarios. Los datos deben provenir de un directorio actualizado, LDAP, Active Directory o del sistema de recursos humanos.
3. Configure grupos y roles. Las aplicaciones deben recibir atributos claros sin ajustes manuales tras cada cambio de puesto.
4. Active MFA antes del despliegue masivo. Un inicio único sin segundo factor protege poco frente al phishing y al robo de contraseñas.
5. Realice un piloto. Empiece con un servicio y un grupo pequeño de empleados, verifique el inicio, el cierre de sesión, los roles y el registro de eventos.
6. Bloquee accesos alternativos. Tras la verificación, desactive las contraseñas locales, elimine cuentas administrativas sobrantes y revise las claves API.

Después del lanzamiento es necesario revisar periódicamente los permisos. El propietario del servicio debe confirmar quién tiene acceso, qué grupos se usan y qué cuentas ya no son necesarias. Sin esa revisión el inicio único se convierte pronto en una vitrina ordenada sobre un desorden antiguo.

Preguntas frecuentes: cinco preguntas sobre SSO

La forma más rápida para casi cualquier teléfono: aplicación de llamadas → *#06# → IMEI en la pantalla. El código funciona sin realizar la llamada; por lo general no es necesario pulsar el botón de llamada. Si el teléfono tiene dos tarjetas SIM o eSIM, el dispositivo puede mostrar IMEI e IMEI2. El segundo número corresponde al segundo módulo celular o a la segunda línea.

Cómo averiguar el IMEI en iPhone

Método 1. A través de los ajustes de iOS. Ajustes → General → Información → IMEI o IMEI2. En algunos modelos también se muestran EID, número de serie e ICCID. Para copiar el número, mantenga pulsada la línea del IMEI y seleccione copiar, si iOS ofrece esa opción. Si no es posible copiar, haga una captura de pantalla o anote el número sin espacios. Al facilitárselo al operador o al servicio técnico, verifique las 15 cifras.

Método 2. Mediante el código *#06#. Teléfono → Teclado → *#06# → ventana con los identificadores del dispositivo. Anote el IMEI o haga una captura de pantalla.

Método 3. A través de la bandeja SIM. Bandeja SIM → grabado pequeño con el IMEI. Este método no sirve en modelos sin bandeja física SIM y no siempre es práctico por el tamaño muy reducido de la tipografía.

Método 4. A través de la caja. Caja de fábrica → etiqueta con códigos de barras → IMEI. En la etiqueta suelen figurar el número de serie, el IMEI y los códigos de barras. Compare el número de la caja con el de los ajustes si compra un iPhone de segunda mano. La discrepancia puede indicar una caja ajena, un cambio de carcasa u otro escenario sospechoso.

Método 5. A través de la página de Apple ID. Cuenta de Apple → sección de dispositivos → iPhone correspondiente → información del dispositivo. Este método ayuda cuando no se tiene el teléfono a mano pero se conserva el acceso a la cuenta.

Cómo averiguar el IMEI en Android

Método 1. A través de los ajustes de Android. Ajustes → Acerca del teléfono → IMEI. En la mayoría de dispositivos el IMEI aparece directamente en esta pantalla. Si no aparece: Estado → Información del teléfono → Información del dispositivo. Los nombres varían en Samsung, Xiaomi, HONOR, vivo, OPPO, realme, Motorola y otros fabricantes.

En Google Pixel: Ajustes → Acerca del teléfono → IMEI. En Samsung Galaxy es más sencillo: Ajustes → Acerca del teléfono o Información del dispositivo. En modelos antiguos de Samsung a veces es necesario abrir además la sección Estado.

Método 2. Mediante el código *#06#. Aplicación de llamadas → *#06# → IMEI en la pantalla. Android mostrará el IMEI, el número de serie y otros identificadores si el fabricante los ha añadido en esa pantalla. En un teléfono con dos tarjetas SIM pueden aparecer dos números: IMEI para la primera línea e IMEI2 para la segunda.

Método 3. A través de la caja del teléfono. Caja de fábrica → etiqueta con códigos de barras → IMEI. Los fabricantes suelen imprimir IMEI, número de serie, modelo y códigos de barras en la parte inferior o lateral del embalaje. Al comprar un teléfono usado, compare la caja con el número en los ajustes y no confíe solo en la etiqueta.

Método 4. A través de la bandeja SIM o la carcasa. Bandeja SIM, tapa trasera o etiqueta bajo la batería extraíble → IMEI. En modelos modernos con carcasa de vidrio y batería no extraíble esa marcación puede no existir.

Método 5. A través de Google Encontrar mi dispositivo. Encontrar mi dispositivo → smartphone seleccionado → icono de información → IMEI. Google indica que así se puede ver el IMEI de un Pixel vinculado, y en parte de los dispositivos Android este método también permite ver el identificador de forma remota.

No publique el IMEI de forma pública ni lo envíe a personas desconocidas. El IMEI puede facilitarse al operador de telefonía, al servicio oficial, a la aseguradora, a la policía al denunciar un robo o al comprador si verifica conscientemente el dispositivo antes de la transacción.

La información se ofrece para la comprobación legal del propio dispositivo, la compra, la venta, la reparación y la gestión con el operador de telefonía. No utilice identificadores ajenos, no falsifique el IMEI y cumpla la legislación rusa.

La principal ventaja de Arch Linux reside precisamente en la configuración manual. El usuario elige la estructura de particiones, el cargador de arranque, los servicios de red y el entorno gráfico futuro. Ese enfoque requiere algo más de tiempo comparado con Ubuntu o Fedora, pero ayuda a entender cómo está organizado el sistema bajo el capó. En esta guía veremos la instalación actual de Arch Linux en un equipo con UEFI, prestando atención al particionado seguro del disco, la correcta configuración de la partición EFI y los errores típicos que con más frecuencia impiden que el sistema arranque después del primer reinicio.

Arch Linux no instala el sistema en lugar del usuario ni oculta las decisiones principales tras un asistente. Ese enfoque puede asustar a principiantes, pero enseña bien a comprender Linux. En este artículo se muestra la instalación en un equipo común con UEFI. El punto de partida oficial está en la guía de ArchWiki, la imagen del sistema se descarga desde la página de descargas de Arch Linux. Antes de empezar guarde los archivos importantes, porque los comandos de particionado y formato borrarán los datos del disco elegido.

Qué preparar antes de instalar Arch Linux

Para instalar el sistema se necesita un equipo con procesador de 64 bits, una memoria USB de al menos 2 GB, internet estable y un disco libre o una partición libre. Es mejor contar con al menos 4 GB de RAM y 30 GB en disco, especialmente si se quiere un entorno gráfico. Arch Linux está orientado a la arquitectura x86-64, por lo que los equipos antiguos de 32 bits no son compatibles.

Descargue la ISO más reciente desde el sitio oficial. En la página de descargas el proyecto publica sumas de verificación y firmas, por lo que conviene verificar la imagen antes de grabarla. Si trabaja desde Linux, la imagen se puede grabar en una memoria USB así. En el comando reemplace el nombre del archivo y el dispositivo por sus valores. Indique todo el medio, por ejemplo ====code====

/dev/sdb

/dev/sdb1

====code====
lsblk
sudo dd bs=4M if=archlinux-version-x86_64.iso of=/dev/sdX conv=fsync oflag=direct status=progress
=============

Para Windows sirven Rufus o balenaEtcher. El principio es el mismo: seleccione la ISO y la memoria USB objetivo.

Reinicie el equipo, abra el menú de selección de arranque y elija la memoria USB en modo UEFI. Si está activado Secure Boot, la instalación puede no iniciarse. Para una primera instalación es mejor desactivar temporalmente Secure Boot en la configuración del firmware y luego configurar un arranque seguro.

Instalación paso a paso de Arch Linux desde la terminal

Tras iniciar el sistema aparecerá la línea de comandos como root. Hay que comprobar que el sistema arrancó en modo UEFI. Es fácil de verificar: el comando mostrará ====code====

64

====code====
cat /sys/firmware/efi/fw_platform_size
ls /sys/firmware/efi/efivars
=============

Si el primer comando indica que no existe el archivo, el equipo no arrancó en UEFI. En ese caso reinicie y elija en el menú de arranque la opción de la memoria USB con la etiqueta UEFI.

Compruebe la conexión a internet. La red por cable normalmente se configura sola. Para Wi-Fi use ====code====

iwctl

wlan0

====code====
iwctl
device list
station wlan0 scan
station wlan0 get-networks
station wlan0 connect "NOMBRE_RED"
exit
ping archlinux.org
=============

Sincronice la hora. Un reloj incorrecto a veces impide la verificación de certificados y la descarga de paquetes.

====code====
timedatectl set-ntp true
timedatectl
=============

Localice el disco para la instalación. Tenga cuidado: ====code====

/dev/nvme0n1

/dev/sda

====code====
lsblk
=============

Abra la herramienta de particionado. En el ejemplo se usa un disco NVMe ====code====

/dev/nvme0n1

/dev/sda

====code====
cfdisk /dev/nvme0n1
=============

En ====code====

cfdisk

Para la partición swap bastan 4 u 8 GB. Si se desea hibernación, el tamaño de swap debe ser al menos igual al de la memoria RAM. En instalaciones modernas en vez de una partición separada a menudo se opta por un archivo swap o zram, pero para una primera instalación manual una partición swap separada es más sencilla.

¡Importante! Después de guardar la tabla de particiones ejecute ====code====

lsblk

============= de nuevo y anote con precisión los nombres de las particiones que va a formatear. No se fíe automáticamente de ====code====

p1

============= , ====code====

p2

============= , ====code====

p3

============= : el orden depende de cómo creó las particiones en ====code====

cfdisk

============= .

====code====
lsblk
=============

Tras comprobarlo formatee las particiones. En mi ejemplo EFI está en ====code====

/dev/nvme0n1p1

/dev/nvme0n1p2

/dev/nvme0n1p3

lsblk

/dev/sda1

/dev/sda2

/dev/sda3

====code====
mkfs.fat -F 32 /dev/nvme0n1p1
mkswap /dev/nvme0n1p2
mkfs.ext4 /dev/nvme0n1p3
=============

Monte las particiones en el entorno de instalación. La partición raíz se monta en ====code====

/mnt

/mnt/boot

====code====
mount /dev/nvme0n1p3 /mnt
mount --mkdir /dev/nvme0n1p1 /mnt/boot
swapon /dev/nvme0n1p2
=============

Instale el sistema base. El paquete ====code====

base

linux

linux-firmware

networkmanager

grub

efibootmgr

intel-ucode

amd-ucode

====code====
pacstrap -K /mnt base linux linux-firmware nano networkmanager sudo grub efibootmgr intel-ucode
=============

Si el equipo tiene procesador AMD, el comando será así.

====code====
pacstrap -K /mnt base linux linux-firmware nano networkmanager sudo grub efibootmgr amd-ucode
=============

Cree el archivo ====code====

fstab

====code====
genfstab -U /mnt >> /mnt/etc/fstab
cat /mnt/etc/fstab
=============

Cambie al sistema instalado. A partir de aquí los comandos afectan al futuro Arch Linux y no al entorno temporal de la memoria USB.

====code====
arch-chroot /mnt
=============

Configure la zona horaria. En el ejemplo se indica la zona de Moscú, pero puede elegir la suya desde el directorio ====code====

/usr/share/zoneinfo

====code====
ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
hwclock --systohc
=============

Configure la configuración regional. Para un sistema en ruso puede habilitar la localización rusa y la inglesa. El inglés suele ayudar al buscar errores, porque muchos mensajes en internet se discuten así.

====code====
sed -i 's/^#(en_US.UTF-8 UTF-8)/1/' /etc/locale.gen
sed -i 's/^#(ru_RU.UTF-8 UTF-8)/1/' /etc/locale.gen
locale-gen
echo "LANG=ru_RU.UTF-8" > /etc/locale.conf
echo "KEYMAP=us" > /etc/vconsole.conf
=============

Establezca el nombre del equipo y el archivo hosts básico. En lugar de ====code====

archpc

====code====
echo "archpc" > /etc/hostname
cat > /etc/hosts <<EOF
127.0.0.1 localhost
::1 localhost
127.0.1.1 archpc.localdomain archpc
EOF
=============

Defina la contraseña de root, cree un usuario normal y permita al grupo wheel ejecutar comandos administrativos con sudo.

====code====
passwd
useradd -m -G wheel -s /bin/bash user
passwd user
EDITOR=nano visudo
=============

En el editor busque la línea ====code====

# %wheel ALL=(ALL:ALL) ALL

#

Ctrl+O

Enter

Ctrl+X

====code====
%wheel ALL=(ALL:ALL) ALL
=============

Active NetworkManager para que tras el reinicio el equipo configure automáticamente la red por cable y ofrezca herramientas cómodas para Wi-Fi. La documentación oficial del paquete está en la página de NetworkManager.

====code====
systemctl enable NetworkManager
=============

Instale el cargador de arranque GRUB para UEFI. ArchWiki describe GRUB como GRUB 2. Para un equipo UEFI normal el siguiente comando suele funcionar. Si el cargador no aparece en el menú del firmware, puede repetir el comando con el parámetro ====code====

--recheck

====code====
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ARCH
grub-mkconfig -o /boot/grub/grub.cfg
=============

En este punto el sistema mínimo está listo. Salga del sistema instalado, desmonte las particiones y reinicie. Antes del nuevo arranque retire la memoria USB.

====code====
exit
umount -R /mnt
reboot
=============

Primer inicio y configuración del entorno de escritorio

Tras el reinicio inicie sesión con el usuario creado y actualice el sistema. Arch Linux usa un modelo de actualizaciones continuas, por lo que el hábito de instalar actualizaciones con regularidad es especialmente útil. Tras una gran actualización es aconsejable reiniciar y sólo después instalar un entorno gráfico pesado.

====code====
sudo pacman -Syu
sudo reboot
=============

Si necesita un escritorio gráfico, instálelo manualmente. Para GNOME, el comando:

====code====
sudo pacman -S gnome gdm
sudo systemctl enable --now gdm
=============

Para KDE Plasma:

====code====
sudo pacman -S plasma sddm
sudo systemctl enable --now sddm
=============

Si después de la instalación no hay Wi-Fi, compruebe si NetworkManager está en ejecución y conéctese mediante el menú de texto.

====code====
sudo systemctl status NetworkManager
nmtui
=============

El sistema puede no arrancar por tres razones: el equipo no arrancó en UEFI, la partición EFI está montada incorrectamente o el comando ====code====

grub-install

arch-chroot /mnt

systemctl enable NetworkManager

Conclusión

Instalar Arch Linux no es algo complejo ni "sólo para técnicos". Es un proceso ordenado que requiere disciplina y pasos claros. El principal riesgo no es la complejidad de los comandos, sino elegir el disco incorrecto y copiar ejemplos ajenos sin entenderlos. Verifique los nombres de las particiones con ====code====

lsblk

El peligro principal es que el atacante ingrese haciéndose pasar por un usuario legítimo. El sistema de defensa ve un nombre de usuario correcto y una contraseña válida. Tras la autenticación exitosa comienza la lectura encubierta del correo, la descarga masiva de archivos, la configuración de reglas de reenvío y los intentos de acceder a las redes corporativas internas.

La intrusión no se reduce a un simple intento de todas las combinaciones posibles. Los atacantes recurren con mayor frecuencia a ataques por diccionario, pulverización de contraseñas (password spraying) y relleno de credenciales (credential stuffing). El relleno de credenciales funciona de forma muy eficaz: un empleado usa su contraseña laboral en un sitio externo, ese sitio se compromete y la red corporativa queda vulnerable. Hoy analizamos en detalle cómo funciona este proceso y cómo protegerse y proteger a su equipo frente a estas amenazas.

En qué se diferencia el bruteo de cuentas de la fuerza bruta habitual

La fuerza bruta clásica implica probar la contraseña de un objetivo concreto. En el entorno corporativo, los atacantes actúan con más audacia. Toman bases de datos filtradas ya preparadas, listas de contraseñas populares y las aplican inmediatamente a todos los empleados de la empresa.

El método de pulverización de contraseñas ayuda a sortear las protecciones básicas. El sistema suele bloquear a un usuario tras varios intentos fallidos de acceso. Los atacantes tienen esto en cuenta y prueban una contraseña débil en miles de nombres de usuario distintos. La defensa debe analizar el panorama global de las autenticaciones en toda la empresa, no solo el comportamiento de usuarios individuales.

Por qué las cuentas corporativas se convierten fácilmente en objetivo

La infraestructura corporativa contiene numerosos puntos de entrada. Entre ellos están el correo, la VPN, los escritorios remotos, el CRM, los rastreadores de tareas, los paneles de administración y portales antiguos para contratistas. Muchos de estos sistemas son accesibles directamente desde Internet, usan un inicio de sesión único y durante años funcionan sin auditoría de privilegios.

• Reutilización de contraseñas. Los empleados usan contraseñas iguales para cuentas laborales y personales.
• Contraseñas débiles. Las personas eligen palabras cortas, nombres de estaciones, el año actual o el nombre de la empresa.
• Ausencia de segundo factor. Una sola contraseña da acceso completo al correo, la VPN o los discos en la nube.
• Cuentas antiguas. Los accesos de empleados despedidos, contratistas y cuentas de prueba permanecen activos.
• Cuentas de servicio. Las contraseñas se almacenan en texto plano dentro de scripts, archivos de configuración y repositorios.
• Monitorización débil. El equipo de seguridad no detecta errores masivos de autenticación ni accesos desde países inusuales.

El correo siempre está en especial riesgo. Con él se recuperan contraseñas de otros servicios corporativos, se coordinan transferencias financieras, se reenvían documentos internos y enlaces confidenciales. Al obtener acceso al buzón, el atacante rara vez actúa abiertamente. Lee la correspondencia, estudia los flujos financieros y prepara de forma discreta el terreno para un ataque a gran escala.

Un riesgo aparte lo representan las cuentas de administradores. El compromiso de un empleado corriente causa problemas locales, pero la toma de la cuenta de un administrador conduce a una catástrofe. Los atacantes desactivan rápidamente mecanismos de protección, crean cuentas ocultas propias, obtienen acceso directo a copias de seguridad y controlan toda la red.

Cómo proteger las cuentas corporativas

La seguridad no comienza solo con pedir una contraseña compleja. Primero hay que eliminar las vulnerabilidades básicas. Es necesario evitar la reutilización de contraseñas, implantar la autenticación multifactor, limitar el número de intentos de acceso y eliminar los perfiles inactivos de empleados.

1. Implantar la autenticación multifactor para correo, VPN, servicios en la nube, administradores y sistemas financieros.
2. Bloquear el uso de contraseñas débiles, populares y previamente comprometidas.
3. Fomentar el uso de frases de contraseña largas en lugar de exigir solo símbolos especiales.
4. Configurar límites estrictos en el número de intentos de autenticación y bloqueos temporales ante actividad sospechosa.
5. Detectar el uso de una misma contraseña en distintas cuentas, accesos desde países atípicos y errores masivos de autenticación.
6. Bloquear cuentas inmediatamente tras el despido de un empleado o la finalización del trabajo con un contratista.
7. Separar estrictamente los privilegios de usuarios ordinarios y administradores de sistema.

En Microsoft Entra, por ejemplo, está disponible la función «Smart Lockout». Esta bloquea intentos sospechosos de adivinación automática de contraseñas, pero permite a los usuarios normales acceder sin impedimentos. Lógica similar se aplica en otras soluciones corporativas. El objetivo principal es bloquear al atacante sin afectar masivamente a empleados reales por picos accidentales de errores de acceso.

La autenticación multifactor por sí sola no basta. Los códigos SMS protegen menos que las aplicaciones dedicadas, las claves físicas y la tecnología de claves de acceso. Los administradores y el personal financiero requieren los métodos de acceso más fiables. Debería prohibirse técnicamente la aceptación de notificaciones push sin introducir un código contextual adicional.

Qué hay que monitorizar

Una política de seguridad estricta requiere control constante. Los ataques a redes corporativas siempre dejan huellas detectables. Entre ellas están errores frecuentes de autenticación, conexiones desde direcciones IP atípicas, la prueba de contraseñas contra la lista completa de empleados, la configuración repentina de reenvíos de correo y la descarga de volúmenes gigantescos de información interna.

• Numerosos inicios fallidos. Prestar especial atención a errores de autenticación en distintos usuarios en un corto periodo.
• Geografía anómala. El sistema registra un inicio de sesión exitoso desde un país donde el empleado nunca ha trabajado.
• Movimiento imposible. Las autenticaciones se producen en lugares geográficamente distantes con intervalos físicos irreales.
• Cambios en buzones. El usuario crea de repente reglas de reenvío oculto o borra masivamente la correspondencia laboral.
• Comportamiento sospechoso. Tras el acceso comienza inmediatamente la descarga de archivos, intentos de acceder a carpetas ajenas o de abrir paneles de administración.
• Ataques al segundo factor. Se observan fallos frecuentes al confirmar notificaciones push o intentos de asociar un dispositivo desconocido.

Los registros de eventos deben recopilarse desde todas las fuentes disponibles. Proveedores de identidad, servidores VPN, sistemas de correo, herramientas de protección de endpoints, SIEM, proxies y plataformas en la nube aportan datos útiles. Una fuente aislada rara vez muestra el cuadro completo del ataque. Un acceso exitoso puede parecer totalmente legítimo hasta que los analistas revisan las acciones agresivas posteriores del usuario en el correo corporativo.

Tras el compromiso de una cuenta, el simple cambio de contraseña no resuelve el problema. Es necesario cerrar forzosamente todas las sesiones activas, volver a verificar los dispositivos de autenticación vinculados y eliminar las reglas de reenvío creadas por el atacante. Además, hay que revisar el historial de acceso a archivos de los últimos días y determinar con precisión el alcance de la fuga de datos.

Qué no se debe hacer

Una protección ineficaz a menudo parece excesivamente estricta en el papel. Las empresas obligan a los empleados a cambiar la contraseña cada mes y exigen una mezcla ininteligible de caracteres, mientras ignoran el segundo factor y no comprueban las bases de datos filtradas actuales. Como resultado, los empleados inventan contraseñas predecibles y los atacantes las adivinan fácilmente con scripts automáticos.

• No forzar a los empleados a cambiar contraseñas de forma periódica sin una necesidad real.
• No considerar que los caracteres especiales sustituyen por completo la longitud y la unicidad de una frase de contraseña.
• No dejar cuentas de servicio sin un propietario responsable y sin auditorías periódicas.
• No almacenar contraseñas corporativas en hojas de cálculo, chats de trabajo, código fuente o documentos de texto.
• No permitir que los administradores usen cuentas privilegiadas para trabajo rutinario diario.
• No desactivar mecanismos de protección por comodidad en recursos accesibles desde Internet.

Una protección fiable se construye combinando varios enfoques simples. Es necesario implantar contraseñas largas, autenticación multifactor, límites estrictos en los intentos de acceso y monitorización continua de la actividad. Una configuración aislada no detendrá al atacante, pero un conjunto de medidas básicas hará que el ataque masivo de contraseñas sea poco rentable y demasiado complejo para los atacantes.

FAQ: preguntas frecuentes

En un ataque masivo de fuerza bruta nadie introduce manualmente la combinación 123456 en el formulario de inicio de sesión. Los atacantes escriben scripts para realizar solicitudes automáticas, cargan diccionarios de contraseñas, bases de datos filtradas, usan proxies y sortean las restricciones. La protección debe diseñarse tanto a nivel de la contraseña como del servicio. El sistema debe limitar la cantidad de intentos, detectar actividad sospechosa y solicitar un segundo factor.

La gente a menudo considera segura una contraseña como P@ssw0rd!, y percibe una frase larga de varias palabras como una protección débil. Una contraseña corta con sustituciones de letras por símbolos se rompe más rápido que una frase larga y comprensible para su propietario. Aumentar la longitud ofrece más combinaciones posibles. Las sustituciones predecibles llevan tiempo incluidas en los diccionarios de los atacantes.

Cómo funciona la fuerza bruta

Primero los atacantes eligen el objetivo. Puede ser una cuenta, correo, VPN, panel de administrador, servicio en la nube, archivo, base de hashes o una cuenta local. Luego determinan el método de adivinación. Los servicios en línea se protegen limitando el número de intentos de inicio de sesión. Si roban una base de hashes, la velocidad de prueba fuera del sitio aumenta mucho. Las solicitudes ya no pasan por el formulario de autenticación.

El principal peligro para los usuarios es reutilizar la misma contraseña en diferentes sitios y usar combinaciones cortas. Si una contraseña se filtra desde un servicio, los atacantes la probarán en correo, redes sociales, marketplaces, nubes y sistemas corporativos. Las secuencias cortas son fáciles de probar, incluso si contienen símbolos especiales.

Por qué la longitud suele ser más importante que la complejidad

Antes la complejidad de una contraseña se reducía a exigir mayúsculas, dígitos y símbolos. En respuesta, la gente inventaba combinaciones predecibles. Los usuarios ponían un nombre, un año, un signo de exclamación o cambiaban letras por símbolos parecidos. Formalmente se cumplían los requisitos. En la práctica los atacantes llevan tiempo añadiendo esos patrones a sus algoritmos.

Las contraseñas largas funcionan mejor. Cada palabra o símbolo adicional aumenta drásticamente el número de combinaciones posibles. Una frase de varias palabras aleatorias se memoriza con facilidad y protege mejor que una mezcla corta de símbolos. Una frase segura evita citas conocidas, títulos de películas, letras de canciones o información personal obvia.

• Una contraseña corta con sustituciones predecibles de letras por símbolos funciona mal.
• Los nombres, fechas de nacimiento, nombres de ciudades, nombres de mascotas y números de teléfono son una protección débil.
• Es mucho más fiable crear una frase larga con varias palabras no relacionadas.
• La mejor solución es una contraseña única generada por un gestor de contraseñas para cada servicio.

Las recomendaciones actuales del NIST aconsejan a los servicios permitir contraseñas largas. A los desarrolladores no les conviene imponer reglas obligatorias de mezcla de tipos de caracteres. Además, las normas recomiendan comprobar las nuevas contraseñas en listas de valores filtrados, populares o demasiado simples. Una política de contraseñas adecuada reduce el riesgo real sin complicar a las personas con requisitos excesivos.

Cómo proteger la cuenta contra la adivinación

El riesgo de intrusión disminuye sin configuraciones complicadas. Basta con crear contraseñas largas y únicas, instalar un gestor de contraseñas y activar la autenticación de dos factores. El soporte de inicio de sesión mediante clave de acceso (passkey) mejora la situación. La contraseña deja de ser el principal secreto vulnerable.

1. Usar una contraseña única para cada servicio importante.
2. Crear contraseñas largas en lugar de añadir símbolos a palabras cortas.
3. Almacenar las credenciales en gestores de contraseñas en lugar de en blocs de notas, hojas de cálculo o navegadores sin protección.
4. Activar la autenticación en dos factores mediante aplicaciones, claves hardware o passkeys.
5. Revisar contraseñas antiguas tras filtraciones y cambiar las credenciales comprometidas.

Para proteger cuentas personales se necesitan contraseñas únicas y un segundo factor. Estas reglas aplican especialmente al correo, bancos, servicios gubernamentales, servicios laborales, almacenamiento en la nube y mensajería. La seguridad del correo es crucial. Desde el buzón es fácil recuperar acceso al resto de cuentas.

Los gestores de contraseñas no solo almacenan datos. Evitan introducir usuario y contraseña en sitios falsos. Las aplicaciones no rellenan la información en dominios ajenos. Este enfoque sirve como un buen filtro adicional contra el phishing.

Qué debe hacer la empresa

En las empresas, el propio sistema de autenticación suele ser la vulnerabilidad. La fuerza bruta tendrá éxito si no hay límites de intentos. La situación empeora con la activación selectiva de la autenticación multifactor (MFA), la conservación de perfiles antiguos y la costumbre de los empleados de repetir contraseñas en diferentes recursos.

• Limitar los intentos de inicio de sesión con retardos, bloqueos temporales y protección frente a solicitudes masivas.
• Activar la autenticación multifactor para correo, VPN, paneles de administrador, plataformas en la nube y acceso remoto.
• Prohibir contraseñas populares, filtradas, cortas y similares al nombre de usuario.
• Monitorizar anomalías para detectar múltiples inicios fallidos, autorizaciones desde países nuevos e intentos de prueba contra listas de empleados.
• Eliminar los perfiles de exempleados, usuarios de servicio antiguos y cuentas de prueba.
• Almacenar las contraseñas de forma segura usando hashing robusto.

El estándar OWASP describe la limitación de intentos de inicio de sesión como la restricción de intentos de acceso. La tecnología aplica límites, retardos y otras medidas contra el adivinamiento. En una red corporativa esas medidas se combinan con el registro de eventos. El equipo de seguridad de la información debe ver las fuentes de las solicitudes, las cuentas objetivo y las repeticiones de intentos en distintos servicios.

Una política de seguridad adecuada descarta exigir el cambio de contraseñas cada 30 días sin motivos justificables. El cambio frecuente provoca que la gente cree variantes predecibles. Los usuarios simplemente toman la contraseña antigua y añaden un nuevo dígito al final. Es mucho más eficaz exigir frases largas, bloquear combinaciones débiles conocidas, activar la autenticación multifactor y solicitar la actualización solo ante sospecha real de compromiso.

Errores comunes con las contraseñas

La mayoría de errores con las contraseñas son cotidianos. La gente busca autenticarse rápido, memorizar la combinación y no complicarse la vida. Los atacantes explotan activamente esos hábitos.

• Usar la misma contraseña en correo, redes sociales, tiendas y servicios laborales.
• Hacer una palabra corta aparentemente más segura añadiendo un solo dígito o símbolo al final.
• Guardar credenciales en archivos en el escritorio o en hojas compartidas.
• Activar MFA solo para el equipo directivo, dejando sin protección a administradores y empleados.
• Los servicios permiten intentos de inicio de sesión indefinidos sin retardos ni bloqueos.
• Dejar cuentas antiguas activas tras la salida de personal o la finalización de proyectos.

La principal vulnerabilidad sigue siendo la reutilización de contraseñas. Una frase larga y única para cada servicio evita muchos problemas. Este enfoque funciona mucho mejor que exigir añadir un símbolo al final de una palabra.

Preguntas frecuentes

El problema parece técnico, pero con mayor frecuencia no está relacionado con una avería del teléfono, sino con un conflicto de controladores, el modo USB incorrecto, una versión antigua de Platform Tools o un cable demasiado “inteligente” que solo sirve para cargar. ADB es sensible a los detalles. Para transferir fotos un cable puede servir, pero para la depuración por USB ya no.

ADB significa Android Debug Bridge. La herramienta conecta el ordenador y el dispositivo Android, permite instalar aplicaciones, leer registros, ejecutar comandos de shell y reiniciar el smartphone en recovery o en bootloader. Por eso una falla de ADB afecta no solo a los desarrolladores, sino también a usuarios habituales que quieren eliminar aplicaciones innecesarias, restaurar el dispositivo o instalar una actualización.

Qué significa Android ADB Interface código 10

El error «Android ADB Interface código 10» suele aparecer en el Administrador de dispositivos de Windows. El sistema indica que el dispositivo no pudo iniciarse. Exteriormente el smartphone puede cargarse, detectarse como almacenamiento o cámara, pero la interfaz ADB no funciona. Windows ve la conexión, sin embargo no puede vincular correctamente el teléfono, el controlador y el servicio ADB.

El código 10 rara vez señala una causa única. Con mayor frecuencia tras el error está un controlador inadecuado, un conflicto de controladores antiguos, un fallo tras instalar la utilidad del fabricante o un modo de conexión incorrecto. Windows puede elegir el controlador MTP, el antiguo Google USB Driver, un controlador ADB universal o el paquete del fabricante y luego confundirse entre ellos.

El primer paso es sencillo: hay que cambiar el cable y el puerto USB. Es mejor conectar el smartphone directamente al puerto trasero del ordenador, sin hub, alargador ni estación de acoplamiento. En un portátil conviene probar otro conector. El cable debe admitir la transferencia de datos, no solo la carga. Un signo simple: el teléfono debe mostrarse en el sistema como dispositivo para transferir archivos.

Luego hay que comprobar el modo USB en el smartphone. Tras la conexión Android suele mostrar la notificación «Cargando por USB». En el menú de notificaciones hay que elegir «Transferir archivos» o un modo similar. Para ADB también hay que activar la «Depuración por USB» en las opciones de desarrollador. Si ya apareció la solicitud de confianza hacia el ordenador pero la conexión falló, ayuda la opción «Revocar permisos de depuración por USB».

En Windows conviene abrir el Administrador de dispositivos, encontrar el dispositivo Android ADB Interface problemático, eliminar el dispositivo junto con el controlador, desconectar el smartphone y reiniciar el ordenador. Tras el reinicio es preferible instalar un controlador actualizado del fabricante del dispositivo o Google USB Driver, si se trata de Pixel y escenarios compatibles. Los paquetes universales de controladores es mejor no usar, porque a menudo añaden entradas conflictivas.

ADB no detecta el teléfono: lista vacía en adb devices

El comando adb devices debería mostrar la lista de dispositivos conectados. Una lista vacía significa la ausencia de una sesión ADB operativa. La causa está en el cable, el smartphone, el controlador o la utilidad ADB. El sistema puede mostrar el teléfono en el explorador, pero ADB no reconoce el dispositivo.

El diagnóstico se realiza por etapas. Primero se actualizan las herramientas Android SDK Platform Tools. Las versiones antiguas de adb funcionan de forma inestable con dispositivos nuevos y versiones actuales de Android. Ejecute los comandos desde la nueva carpeta platform-tools, evitando directorios antiguos en la variable PATH.

Luego se reinicia el servicio ADB. En la línea de comandos se ejecutan sucesivamente los comandos

====code====
adb kill-server
adb start-server
adb devices
=============

Si la lista queda vacía tras el reinicio, revise la pantalla del smartphone. Android muestra la solicitud «¿Permitir depuración por USB?». Sin la confirmación el ordenador no obtiene acceso. La opción «Permitir siempre desde este ordenador» es útil, pero ante fallos conviene revocar los permisos antiguos y confirmar la confianza de nuevo.

Un problema independiente surge cuando en el ordenador hay varias versiones de adb instaladas. Por ejemplo, una en Android Studio, otra en la carpeta del flasheador, otra en un viejo conjunto de Platform Tools. Como resultado, el comando adb del terminal puede usar la versión equivocada. Se puede comprobar la ruta con where adb en Windows o which adb en Linux y macOS.

Unauthorized, offline y device not found

El estado unauthorized indica que el teléfono es visible, pero no confía en el ordenador. Normalmente ayuda desbloquear la pantalla, desconectar y volver a conectar el cable y luego confirmar la clave RSA. Si no aparece la ventana de confianza, hay que abrir las opciones de desarrollador, revocar los permisos de depuración por USB, reiniciar ADB y conectar el dispositivo otra vez.

El estado offline indica una conexión inestable entre el cliente ADB y el dispositivo. La causa puede ser una versión antigua de adb, un cable defectuoso, un puerto USB problemático o un proceso adbd atascado en el smartphone. A menudo ayuda la combinación: adb kill-server, reiniciar el teléfono, cambiar el cable y usar Platform Tools actualizadas.

El mensaje device not found aparece cuando el comando requiere un dispositivo conectado, pero ADB no encuentra un objetivo adecuado. Ese error suele surgir después de adb devices con lista vacía. Otra causa: al ordenador están conectados varios dispositivos Android o emuladores y el comando no sabe a cuál dirigirse. En ese caso hay que indicar el número de serie con el parámetro -s.

====code====
adb -s SERIAL_NUMBER shell
=============

El error more than one device/emulator significa precisamente que ADB ve varios objetivos. El usuario puede desconectar los dispositivos sobrantes, cerrar el emulador o elegir explícitamente el número de serie deseado. Ese enfoque es especialmente útil al trabajar con un teléfono y un emulador Android al mismo tiempo.

Fastboot funciona, pero ADB no

ADB y Fastboot a menudo se perciben como la misma herramienta, pero funcionan en modos distintos. ADB se necesita cuando Android está cargado y ha permitido la depuración. Fastboot funciona en el cargador de arranque, cuando el sistema operativo Android aún no se ha iniciado. Por eso la situación «fastboot devices detecta el smartphone, pero adb devices no» no es contradictoria.

En modo bootloader ADB no reconoce el dispositivo. Para comprobar la depuración por USB hay que arrancar el sistema Android. Puede ocurrir lo contrario: ADB reconoce el smartphone en el sistema, pero Fastboot no funciona por falta del controlador del bootloader. Windows suele exigir controladores distintos para ADB y para el modo bootloader.

Antes de flashear o restaurar el dispositivo conviene comprobar ambas órdenes

====code====
adb devices
fastboot devices
=============

Si solo funciona una de las dos, no es necesario reinstalar todos los componentes. Basta identificar el modo actual del dispositivo, verificar el controlador correspondiente y ejecutar el comando desde la carpeta actual de Platform Tools.

Lista de comprobación para corregir errores frecuentes de ADB

La mayoría de problemas de ADB se resuelven con métodos básicos. Un diagnóstico ordenado ahorra tiempo y reduce el riesgo de eliminar un controlador necesario o instalar un paquete dudoso. La comprobación comienza por la conexión física, luego pasa a los ajustes de Android, los controladores y la versión de las herramientas.

1. Cambiar el cable USB por uno que permita transferencia de datos.
2. Conectar el smartphone directamente a otro puerto USB.
3. Desbloquear la pantalla del teléfono antes de conectar.
4. Activar las opciones de desarrollador y la «Depuración por USB».
5. Elegir el modo USB «Transferir archivos» si Android solo ofrece carga.
6. Revocar los permisos de depuración por USB y confirmar la confianza de nuevo.
7. Instalar Android SDK Platform Tools actualizados.
8. Reiniciar el servicio con los comandos adb kill-server y adb start-server.
9. Eliminar el dispositivo Android ADB Interface problemático en Windows e instalar el controlador correcto.
10. Comprobar que no queden varias versiones conflictivas de adb en el sistema.

Si el error Android ADB Interface código 10 persiste tras reinstalar el controlador, conviene borrar todos los controladores Android antiguos, reiniciar el ordenador y conectar el smartphone en un escenario limpio. En equipos corporativos pueden interferir las políticas de seguridad, la prohibición de instalar controladores o las herramientas de control de dispositivos USB. En esos casos el problema no está en el teléfono.

Conclusión

Los errores de ADB rara vez resultan amables. Los estados código 10, unauthorized, offline, la salida vacía de adb devices y device not found dan la impresión de una avería grave. En la práctica la causa suele ser la ruptura de una cadena. La falla la provocan el cable, el modo USB, los permisos de depuración, el controlador de Windows o una versión obsoleta de Platform Tools.

El diagnóstico se organiza con un algoritmo claro. Primero se comprueba la conexión física y los ajustes de Android, luego se actualiza ADB y se reinstalan los controladores. Esa secuencia ayuda a localizar el problema y encontrar el punto de ruptura entre el ordenador y el smartphone.

ADB requiere una configuración precisa. Cuando el ordenador reconoce el smartphone, Android muestra la solicitud de confianza y el comando adb devices muestra el número de serie, la configuración básica está completa. Las órdenes posteriores se ejecutan con estabilidad y los errores dejan de parecer fallos del sistema.

Preguntas frecuentes

El término proviene de la medicina, donde se clasifica a los pacientes según la urgencia de la atención. En un SOC funciona una lógica similar: resulta imposible investigar en profundidad cada notificación de SIEM, EDR, de protección de correo, del cortafuegos o del sistema de monitorización. El flujo de eventos supera regularmente los recursos temporales del equipo. Por eso primero es necesario identificar los incidentes más críticos.

Un triaje de calidad no sustituye la investigación. El procedimiento ayuda a identificar de forma rápida la dirección del análisis posterior, a involucrar a los especialistas necesarios, a bloquear las amenazas y a recopilar datos antes de que desaparezcan las evidencias de actividad.

Por qué es necesario el triaje

Sin triaje, el equipo de seguridad se sobrecarga de alertas. Un suceso puede ser una conexión normal de un empleado en viaje, otro un error de regla, un tercero un intento de fuerza bruta de contraseñas y un cuarto el inicio de un ataque de ransomware. Analizar las señales por orden de llegada crea el riesgo de pasar por alto un incidente peligroso.

• Eliminar el ruido: excluir duplicados, eventos de prueba, reglas obsoletas y detecciones que se confirmaron como falsas.
• Detectar casos urgentes: identificar rápidamente una infección, la compromisión de una cuenta, movimientos laterales en la red o una fuga de datos.
• Recopilar contexto: identificar el usuario, el host, el nivel de privilegios, el proceso en ejecución, así como los eventos previos y posteriores.
• Asignar prioridad: decidir qué eventos requieren respuesta inmediata y qué tareas pueden aplazarse.

En la práctica, el triaje lleva unos minutos. La investigación completa puede durar horas o días, pero la decisión inicial debe tomarse con rapidez. Requieren especial atención los incidentes relacionados con cuentas de dominio, servidores con bases de datos críticas, estaciones de trabajo de administradores o actividad sospechosa en la infraestructura en la nube.

Cómo se realiza el triaje de un incidente

El triaje comienza por comprobar la fuente de la señal. El analista evalúa el origen del suceso, la hora de la detección, la existencia de alertas similares, las características del activo afectado y la concordancia del comportamiento con la actividad normal del usuario o del sistema.

1. Comprobar la fuente: SIEM, EDR, pasarela de correo, IDS, WAF, servicio en la nube o registro de la aplicación.
2. Examinar el activo: estación de trabajo, servidor, controlador de dominio, buzón de correo, cuenta, recurso en la nube.
3. Evaluar el contexto: usuario, hora, geolocalización del acceso, proceso, comando, archivo, dominio, dirección IP.
4. Buscar eventos relacionados: qué ocurrió antes de la detección y qué cambió después.
5. Asignar un estado: falsa alarma, sospecha, incidente confirmado, escalado urgente.

Un indicador aislado rara vez indica un ataque. Un acceso sospechoso puede deberse a un viaje de trabajo y un proceso poco habitual a una actualización de software. La situación cambia si el acceso desde una dirección nueva coincide con una descarga masiva de archivos y la creación de una regla de reenvío de correo.

Cómo establecer prioridades

La prioridad no depende solo de la categoría de la regla. El mismo evento en un portátil de prueba y en un servidor con datos de clientes tiene una criticidad distinta. Un triaje eficaz tiene en cuenta la naturaleza del activo, el valor de los datos, los privilegios del usuario y el daño potencial.

Normalmente se clasifican los eventos en cuatro niveles: bajo, medio, alto y crítico. La prioridad baja espera su turno sin problema, mientras que la alta debe tratarse lo antes posible. Si el incidente es crítico, el equipo activa inmediatamente la respuesta: aísla el host, restablece contraseñas, bloquea tokens, desactiva el reenvío de correo, termina el proceso malicioso o simplemente corta el acceso externo.

Errores comunes en el triaje

El triaje no funciona si el analista saca el suceso de contexto y solo mira una línea. No basta con ver un hash de archivo detectado: hay que averiguar de dónde proviene y si llegó a ejecutarse. Y si el sistema registra un acceso desde otro país, conviene comprobar de inmediato las sesiones VPN, el calendario de viajes, la actividad previa del empleado y lo que hizo tras autenticarse.

• Creer ciegamente en el nombre de la regla. Una etiqueta llamativa de «estado crítico» en el panel de control no siempre indica una amenaza real.
• Olvidar las particularidades del activo. La misma alerta en el servidor de prueba de un desarrollador y en el controlador principal de dominio tiene niveles de gravedad completamente distintos.
• Ignorar los eventos relacionados. Una notificación aislada rara vez muestra el panorama; siempre hay que revisar la cadena de acciones antes y después.
• Acumular alertas antiguas. Si no se gestionan a tiempo los atrasos, entre la montaña de alertas antiguas se puede pasar por alto un ataque reciente.
• No dejar anotaciones. Sin un breve resumen, el equipo volverá una y otra vez a perder tiempo en los mismos casos banales.

Un buen triaje deja un panorama claro: qué ocurrió, si la señal es fiable, qué sistemas están afectados, qué se ha comprobado y cuál es el siguiente paso. Todo esto se registra en una breve nota de trabajo para que el siguiente analista pueda retomar la tarea sin preguntas innecesarias.

Preguntas frecuentes