SFTP y SSH brindan un potente acceso al servidor debajo de un sitio WordPress. Ese acceso es invaluable para implementaciones, WP-CLI, resolución de problemas y recuperación, pero también puede eludir las protecciones del panel y cambiar todos los archivos al que puede acceder el servidor web. Trátelo como un acceso privilegiado a la infraestructura, no como un cómodo inicio de sesión compartido.
Una configuración segura tiene cuatro cualidades: transporte cifrado, identidades individuales, privilegios mínimos y evidencia confiable. Debería ser fácil responder quién se conectó, desde qué dispositivo aprobado, qué podrían cambiar y cómo se eliminará su acceso.
Conozca los protocolos que está permitiendo
SFTP es el protocolo de transferencia de archivos SSH. Opera a través de SSH y cifra la sesión. No es lo mismo que el FTP tradicional y no es el mismo protocolo que FTPS, que agrega TLS a FTP. Confirme lo que realmente proporciona su servidor en lugar de asumir que una aplicación etiquetada como "cliente FTP" está utilizando un modo seguro.
SSH proporciona un shell interactivo o un canal de comando. SFTP puede estar restringido a operaciones de archivos, mientras que SSH puede ejecutar WP-CLI, inspeccionar registros, cambiar servicios y ejecutar scripts. Ofrezca a los usuarios sólo la capacidad que requiere su trabajo; un diseñador que carga recursos rara vez necesita un shell sin restricciones.
Cuando se utiliza el acceso al servidor para solucionar problemas de complementos o administrar WordPress desde la línea de comandos, siga las prácticas de privilegios mínimos en nuestra WordPress servicio de auditoría de seguridad en lugar de dar a cada colaborador acceso administrativo completo.
Cree cuentas individuales y elimine credenciales compartidas
Cada empleado, contratista y automatización debe tener su propia identidad. Las cuentas individuales hacen que los registros sean útiles, permiten permisos limitados y le permiten revocar el acceso de una persona sin interrumpir a todo el equipo. Evite nombrar cuentas con una función genérica si eso oculta quién las controla.
Mantener un registro de acceso con el propietario de la cuenta, propósito comercial, directorios o comandos aprobados, método de autenticación, fecha de creación y fecha de revisión. Durante la baja, elimine la cuenta o clave, finalice las sesiones activas cuando sea posible, rote los secretos compartidos a los que la persona pueda acceder y revise la actividad reciente.
Las cuentas de servidor son sólo una capa de privilegios. Utilice la misma mentalidad de inventario para WordPress usuarios con nuestra guía para detectar administradores WordPress pícaros y cambios de privilegios inexplicables.
Prefiere claves SSH bien administradas
La autenticación de clave pública evita enviar una contraseña reutilizable al servidor. Genere una clave separada para cada persona o sistema automatizado, proteja las claves privadas con una frase de contraseña segura cuando sea operativamente posible y guárdelas en un administrador de contraseñas aprobado, un llavero seguro o un dispositivo respaldado por hardware.
Nunca envíe claves privadas por correo electrónico, ni las pegue en tickets ni copie una clave en todo el equipo. No almacene claves de implementación en un repositorio público o dentro de la raíz del documento WordPress. Para la automatización, utilice un almacén secreto dedicado y exponga la clave solo al trabajo que la necesita.
El proceso de almacenamiento, rotación y revocación debe alinearse con los controles de nuestra WordPress guía de gestión de secretos. Un secreto no es seguro simplemente porque esté fuera de wp-admin.
Endurecer SSH sin bloquear al equipo de recuperación
Valide el acceso basado en claves en una segunda sesión antes de deshabilitar la autenticación de contraseña. Mantenga abierta la sesión actual, pruebe la configuración, confirme la consola de emergencia o el procedimiento de recuperación del proveedor de alojamiento y solo entonces realice cambios de autenticación más estrictos. Una configuración segura que deja varado al equipo durante una interrupción crea un riesgo diferente.
Cuando administre el demonio SSH, considere negar el inicio de sesión directo como root, limitar los usuarios o grupos permitidos, deshabilitar las contraseñas vacías, reducir los métodos de autenticación no utilizados y restringir las funciones de reenvío que no son necesarias. La configuración correcta depende del sistema operativo, el modelo de alojamiento y el proceso de recuperación, así que cámbielas mediante un procedimiento reversible y documentado.
Los controles de red pueden reducir aún más la exposición. Los cortafuegos de alojamiento administrado, una VPN, un host bastión o listas de permitidos cuidadosamente mantenidas pueden restringir dónde se originan las conexiones administrativas. No confíe únicamente en una lista de IP permitidas: las direcciones cambian, las credenciales aún pueden ser robadas y las reglas mal configuradas pueden bloquear el acceso de emergencia legítimo.
Pon estas ideas en práctica.
Desde una mejora puntual hasta una web completa, te ayudamos a definir el alcance y llevarlo a cabo.
Hablemos de mi webSoluciones avanzadas de seguridad de WordPressCuéntanos tus objetivos. Solemos responder en menos de 4 horas con preguntas y próximos pasos prácticos.
Limita lo que cada cuenta puede alcanzar
Dirija a los usuarios de SFTP a los directorios que realmente mantienen. Destinos separados de producción, preparación y respaldo. Para implementaciones automatizadas, restrinja la cuenta a la ruta y los comandos necesarios en lugar de otorgar un shell interactivo completo. Evite dar permiso al proceso de un sitio web para modificar más partes del servidor de lo que requiere su función.
La configuración de propiedad y modo es importante después de cada carga. Sigue nuestro WordPress guía de permisos de archivos y evite permisos de escritura mundial como 777, que pueden exponer archivos a otros procesos o usuarios en el servidor.
Una transferencia segura aún puede generar código malicioso o no revisado. Utilice el control de versiones y un proceso de implementación cuando sea posible, escanee los archivos cargados y compare los cambios de producción con una versión aprobada. Restrinja las ediciones directas a emergencias y registre los cambios.
Proteja las estaciones de trabajo y verifique la identidad del servidor
El servidor es sólo una parte de la relación de confianza. Mantenga los dispositivos del administrador parcheados, cifrados y protegidos mediante la seguridad de los terminales. Bloquee la pantalla, separe los perfiles personales y laborales cuando sea práctico y elimine las claves de los dispositivos perdidos o reemplazados.
Verifique las claves del host cuando se conecte a un servidor por primera vez e investigue cambios inesperados en las claves del host. Aceptar ciegamente una nueva huella digital puede ocultar una conexión al sistema incorrecto o un evento de intermediario. Publique huellas digitales confiables a través de un canal autenticado separado para el equipo.
Registrar, alertar y revisar
Recopile eventos de autenticación SSH exitosos y fallidos, direcciones de origen, nombres de cuentas y tiempos de sesión. Alerta sobre fallas repetidas, acceso desde ubicaciones inesperadas, cuentas inactivas que se activan, nuevas claves autorizadas y conexiones fuera de los períodos de mantenimiento normales.
Conecte los registros de infraestructura con los eventos del sitio web cubiertos en nuestro WordPress guía de monitoreo de seguridad por lo que un nuevo inicio de sesión en el servidor, un cambio de archivo y la creación de un administrador se pueden investigar como una sola línea de tiempo.
Revise el acceso según un cronograma y después de cada cambio de personal, proveedor o alojamiento. Verifique los archivos de claves autorizadas y los paneles de control de los proveedores, no solo una hoja de cálculo. La fuente de la verdad es el acceso que todavía funciona.
Planifique para errores y emergencias
Antes de modificar permisos, autenticación o configuración del servidor, realice una copia de seguridad verificada y sepa cómo restaurarla sin depender de la ruta de acceso que está cambiando. Mantenga los códigos de recuperación, el acceso a la consola y los contactos de escalada protegidos pero disponibles para los servicios de respuesta autorizados.
Utilice los ejercicios de recuperación en nuestro WordPress guía de copia de seguridad y recuperación ante desastres para confirmar que los archivos, la base de datos y la configuración se pueden restaurar después de un comando accidental o una cuenta comprometida.
Si se produce un acceso sospechoso, desactive la identidad afectada, conserve los registros, rote las credenciales expuestas, compare archivos con versiones en buen estado y evalúe si se podía acceder a los secretos de la base de datos o de la aplicación. No borre la evidencia antes de comprender el alcance.
Una lista de verificación práctica de SFTP y SSH
Utilice SFTP en lugar de FTP sin cifrar; crear cuentas individuales; prefiera claves protegidas únicas; restringir directorios y comandos; verificar las huellas digitales del host; fortalecer SSH mediante cambios probados; proteger los dispositivos del administrador; monitorear el acceso y los cambios de claves; revisar las cuentas periódicamente; y mantener un camino de recuperación independiente.
Para propiedad continua, revisiones de acceso, actualizaciones seguras y preparación para incidentes, nuestro WordPress servicio de mantenimiento de seguridad puede gestionar los controles operativos que son fáciles de pasar por alto después de la configuración inicial.
Preguntas frecuentes
¿Cuál es la diferencia entre SFTP y FTP?
SFTP transfiere archivos a través del protocolo SSH y cifra la conexión. El FTP tradicional envía datos y credenciales sin una protección de transporte equivalente a menos que se configure un modo TLS separado. SFTP y FTPS son protocolos diferentes.
¿Deberían los administradores de WordPress utilizar claves SSH en lugar de contraseñas?
Las claves SSH generalmente son preferibles para el acceso al servidor administrativo cuando se generan, almacenan y revocan correctamente. Primero valide el acceso a la clave, proteja las claves privadas con frases de contraseña o almacenamiento respaldado por hardware y mantenga una ruta de recuperación probada antes de deshabilitar la autenticación de contraseña.
¿Puedo dar una cuenta SFTP a todo el equipo?
Una cuenta compartida debilita la responsabilidad y dificulta la salida. Proporcione a cada persona o automatización una identidad individual con solo los directorios y comandos que necesita, luego elimine ese acceso cuando finalice el trabajo.
¿Con qué frecuencia se deben rotar las claves SSH?
Rote las claves inmediatamente cuando un dispositivo, contratista o clave privada pueda verse comprometido y cuando una persona abandone o cambie de función. Para la rotación de rutina, siga un cronograma documentado basado en el riesgo y verifique que las claves antiguas realmente se retiren de cada ubicación de claves autorizadas.
