Configuración inicial de CentOS 7 para sistemas heredados
Fecha de publicación：
Actualizado:
Artículos técnicos > Configuración inicial de CentOS 7 para sistemas heredados
Estado 2026 y uso seguro
Conclusión: No comience una nueva versión de producción en CentOS Linux 7: llegó al final de su vida útil el 30 de junio de 2024. En un sistema de la familia RHEL compatible, actualice a través de DNF, cree usuarios administrativos designados, configure la hora y el nombre de host deliberadamente, mantenga el firewall habilitado y siga aplicando SELinux.
Qué aprenderás
- Qué configuración de referencia intentaba establecer la lista de verificación original de CentOS 7.
- Cómo el ciclo de vida, la gestión de paquetes, systemd, firewalld y SELinux cambian la decisión de 2026.
- Cómo tratar una secuencia de comandos antigua como evidencia de migración en lugar de como un estándar de compilación seguro.
Para quién: administradores que heredan un host CentOS 7 o traducen un runbook antiguo a una plataforma compatible.
Situación en 2026: Los siguientes comandos se conservan como material histórico de CentOS 7. No desactive permanentemente SELinux para que una aplicación funcione; Red Hat recomienda aplicar el modo y los diagnósticos permisivos temporales solo cuando sea necesario. Cree y pruebe una migración en lugar de depender de paquetes archivados.
Nota de seguridad: Los comandos y ejemplos de configuración del artículo original no se han vuelto a ejecutar en un entorno de producción actual. Verifique las versiones compatibles, las copias de seguridad, los controles de acceso y los pasos de reversión en un entorno de prueba independiente antes de aplicarlos.
Fuentes primarias oficiales
Resumen.
Este procedimiento histórico documenta la configuración inicial de CentOS 7.6 (1810). En un sistema nuevo, los mismos objetivos deben aplicarse con las herramientas y recomendaciones de seguridad de una distribución compatible.
Índice de contenidos
- configuración básica
- 1-1. Comprobación del sistema operativo
- 1-2. Instalación de la herramienta
- 1-3. Desactivar selinux
- 1-4. usuario operativo adicional
- 1-5. Cambiar la contraseña del usuario root
- 1-6. Configuración para prohibir el ingreso de usuarios no operativos (prohíbe el ingreso del usuario root y otros usuarios).
- 1-7. sincronización horaria
- 1-8. Configuración de la autenticación de claves
- resumen
1. configuración básica
Esta sección describe la configuración básica necesaria inmediatamente después de instalar CentOS.
1-1. Comprobación del sistema operativo
En primer lugar, comprueba que tienes instalado el sistema operativo correcto.
[root@hostname ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
'CentOS Linux release 7.6.1810 (Core)' es el sistema operativo instalado. Compruebe que es correcto.
1-2. Instalación de la herramienta
Inmediatamente después de la instalación, no se pueden ejecutar comandos básicos como ifconfig. Por lo tanto, la instalación se lleva a cabo para que la red básica y otros comandos puedan ser ejecutados por los comandos yum.
Por favor, realice esto si es necesario, ya que es posible modernizar lo que ya se ha instalado con 'yum -y update'.
[root@hostname ~]# yum install -y net-tools
[root@hostname ~]# yum install -y wget
[root@hostname ~]# yum install -y tcpdump
[root@hostname ~]# yum install -y traceroute
net-tools: El comando ifconfig y otros pueden ser utilizados después de la instalación.
wget obtiene recursos mediante protocolos como HTTP y HTTPS.
tcpdump captura y analiza paquetes de red. Las capturas pueden contener datos sensibles y requieren controles de acceso adecuados.
traceroute examina la ruta de red hacia un destino; los filtros pueden producir resultados incompletos.
1-3. Configuración histórica de SELinux
El procedimiento original desactivaba SELinux. Esta medida reduce la protección del host y no se recomienda en una instalación actual; conviene mantener el modo enforcing y corregir las etiquetas o reglas de política.
Si un diagnóstico controlado requiere el modo permissive, el cambio debe ser temporal: se revisan las denegaciones y después se restaura enforcing. SELinux es una capa preventiva de control de acceso obligatorio y también limita el impacto de una intrusión. Los comandos siguientes solo documentan el procedimiento antiguo de CentOS 7.
El procedimiento histórico era el siguiente:
[username@hostname ~]$ getenforce
Disabled
Si no está "Desactivado", se puede cambiar mediante el siguiente procedimiento.
[username@hostname ~]$ vi /etc/selinux/config
SELINUX=enforcing
SELINUX=disabled
El ejemplo histórico modifica SELINUX, no SELINUXTYPE. Sin embargo, desactivar SELinux elimina una capa de protección importante. En sistemas nuevos conviene mantener enforcing y corregir las etiquetas o políticas de la aplicación. Este cambio solo debería usarse como diagnóstico temporal en un entorno de pruebas aislado.
La opción surte efecto después de reiniciar. Antes debe existir un acceso de consola y un procedimiento de reversión ya comprobados.
1-4. usuario operativo adicional
La administración diaria debe realizarse con una cuenta nominal sin privilegios, elevándolos mediante sudo o su solo cuando sean necesarios. Así se limita el alcance de los errores y se conserva una auditoría más clara.
Incluso en un servidor personal de aprendizaje, mantener sesiones root no es una práctica segura. Las cuentas y permisos deben separarse según el principio de mínimo privilegio; el acceso root remoto se desactiva después de comprobar una cuenta administrativa alternativa.
A continuación se indican los pasos para añadir usuarios.
[root@hostname ~]# useradd xxxxxx
[root@hostname ~]# passwd xxxxxx
Nota: xxxxxx representa la cuenta nueva. Utilice una contraseña única y suficientemente larga o, preferiblemente, autenticación mediante claves SSH administradas según la política aplicable.
1-5. Cambiar la contraseña del usuario root
Si no es el usuario root, cambie al usuario root con su - y ejecute el siguiente comando
[username@hostname ~]$ su -
[root@hostname ~]# passwd
No conserve la contraseña inicial ni use valores comunes como «root», «password» o «1234». La antigua recomendación fija de ocho caracteres ya es insuficiente: la contraseña debe ser más larga, única e impredecible. Conviene combinarla con claves SSH, límites de intentos y, cuando proceda, autenticación multifactor.
Los servidores expuestos a Internet reciben intentos automatizados con independencia de su tamaño. Las políticas de contraseña y acceso remoto deben validarse antes de la puesta en servicio.
1-6. Configuración para prohibir el ingreso de usuarios no operativos (prohíbe el ingreso del usuario root y otros usuarios).
Limite las cuentas con acceso remoto y desactive el inicio directo como root. Root omite muchos límites de permisos, pero no equivale a desactivar «todas las medidas de seguridad»; los controles de red, el registro y el control de acceso obligatorio siguen siendo relevantes.
El ejemplo heredado usa AllowUsers para limitar SSH. Mantenga una segunda sesión abierta y pruebe la cuenta nueva, incluida la elevación de privilegios, antes de aplicar el cambio para evitar perder el acceso administrativo.
[username@hostname ~]$ su -
[root@hostname ~]# vi /etc/ssh/sshd_config
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#LoginGraceTime 2m
PermitRootLogin no
AllowUsers xxxxxx
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
Nota: xxxxxxxx es el nombre de usuario operativo que acaba de añadir.
Un punto a tener en cuenta aquí es que si el nombre de AllowUsers es incorrecto, nadie podrá entrar, así que compruebe los nombres de usuario cuidadosamente.
Comprueba la sintaxis y reinicia sshd.
[root@hostname ~]# /usr/sbin/sshd -t
[root@hostname ~]# systemctl restart sshd
Sin cerrar la sesión actual, verifique en una segunda sesión que la cuenta normal puede acceder y elevar privilegios según lo previsto. Después confirme que el acceso remoto como root se rechaza.
1-7. sincronización horaria
Compruebe que la hora está sincronizada. A veces, la hora del servidor no está sincronizada, por lo que la fecha y la hora de salida del registro salen a una hora diferente de la esperada y se tarda mucho en analizar el problema.
Comprobar la puesta en marcha del proceso de sincronización horaria (chronyd). Compruebe el estado de la sincronización horaria. Ten en cuenta que CentOS7 es 'chronyd', pero los anteriores son 'ntpd', así que ten cuidado si estás en el 6 o anterior.
[root@hostname ~]# ps aux | grep chronyd
chrony 567 0.0 1.3 117804 13664 ? SL 5月04 0:04 /usr/sbin/chronyd
root 32489 0.0 0.0 112732 972 pts/1 S+ 16:30 0:00 grep --color=auto chronyd
[root@hostname ~]# timedatectl
Local time: día (del mes) 2020-11-29 16:30:43 JST
Universal time: día (del mes) 2020-11-29 07:30:43 UTC
RTC time: día (del mes) 2020-11-29 07:30:43
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
Está bien si 'Hora local' coincide con la hora actual, 'NTP habilitado' es sí y 'NTP sincronizado' es sí.
1-8. Configuración histórica de claves SSH
La autenticación mediante clave pública SSH reduce la exposición a ataques de contraseña cuando las claves y los permisos se gestionan correctamente.
El ejemplo original genera en el servidor una clave privada RSA-2048 sin frase de contraseña y luego la copia al cliente. En una configuración actual, conviene generar una clave Ed25519 en un cliente de confianza, protegerla con frase de contraseña cuando sea viable, instalar solo la clave pública en el servidor y probar una segunda sesión antes de desactivar las contraseñas.
Los comandos siguientes se conservan como procedimiento histórico.
[username@hostname ~]$ su - xxxxxx
[xxxxxx@hostname ~]$ ssh-keygen -t rsa -b 2048
xxxxxx representa la cuenta añadida. En este flujo obsoleto del lado del servidor, aceptar todos los valores predeterminados genera una clave privada sin cifrar. Una frase de contraseña cifra la clave privada almacenada; no convierte el acceso mediante clave pública en autenticación por contraseña del servidor. Las claves nuevas deben generarse en un cliente de confianza y la clave privada debe permanecer allí.
A continuación, compruebe que la clave se ha creado.
[xxxxxx@hostname ~]$ ll /home/xxxxxx/.ssh
El procedimiento original comprobaba la clave privada id_rsa y la clave pública id_rsa.pub. Después cambiaba el nombre de la clave pública y movía la privada para descargarla:
[xxxxxx@hostname ~]$ mv /home/xxxxxx/.ssh/id_rsa.pub /home/xxxxxx/.ssh/authorized_keys
[xxxxxx@hostname ~]$ mv /home/xxxxxx/.ssh/id_rsa /home/xxxxxx/id_rsa
La generación y transferencia de una clave privada desde el servidor se conserva solo como contexto histórico y no debe repetirse en una instalación nueva. El procedimiento original eliminaba la copia del servidor tras transferirla:
[xxxxxx@hostname ~]$ rm /home/xxxxxx/id_rsa
Antes de desactivar la autenticación por contraseña, debe probarse el acceso mediante clave pública en una segunda sesión y confirmar una vía de recuperación independiente.
[username@hostname ~]$ su -
[root@hostname ~]# vi /etc/ssh/sshd_config
PasswordAuthentication yes
PasswordAuthentication no
Comprueba la sintaxis y reinicia sshd.
[root@hostname ~]# /usr/sbin/sshd -t
[root@hostname ~]# systemctl restart sshd
Esto completa la configuración de la autentificación de la clave.
2. resumen
La lista original cubría la identificación del sistema, las herramientas, las cuentas administrativas, el acceso SSH y la sincronización horaria.
No debe utilizarse como base actual de producción. Es necesario partir de la guía de seguridad de una distribución compatible, mantener SELinux y el cortafuegos activos y preparar una vía de reversión para los cambios de acceso.