Linux: haga que el apagado no sea ejecutable por seguridad

Hoy he apagado una máquina de producción por error porque pensé que estaba en mi máquina local. Lo sé, error de novato :-(

Como solución para que no vuelva a ocurrir, estaba pensando en eliminar el permiso de ejecución para el comando de apagado ya que esa máquina debería estar siempre encendida.

¿Es eso una buena idea? ¿Puedes ver algún efecto secundario no deseado al hacer eso?

Saludos, Dan

Completamente otro enfoque de cómo ser advertido de que trabaja en una máquina de producción es marcar el terminal. Por ejemplo, el user@machine:~#texto podría ser rojo en las máquinas de producción, verde en el desarrollo, etc. Aquí hay un buen tutorial sobre cómo hacer esto: Color Bash Prompt

El mejor consejo que puedo darle es que no inicie sesión como usuario root a menos que necesite acceso root, y asegúrese de tener una contraseña root / sudo diferente en cada máquina.

Hacer que el apagado sea inaccesible es una opción, pero no es una buena. De cualquier alias shutdowna shutdown -ay touch /etc/shutdown.allowochmod a-x /sbin/shutdown

Además, ¿dónde termina? ¿También vas a rechazar detener, reiniciar e iniciar?

Algunos puntos a considerar:

1. ¿Qué estabas haciendo como root en un sistema de producción durante el tiempo de producción? Configure sus sistemas para que no tenga que ser root en ellos para el trabajo diario. Nunca debe ser root en un sistema de producción sin una muy buena razón.
2. Aprende la importante lección. Cuando es root, debe verificar dos veces antes de presionar enter. SUDO no es una protección si solo escribe su contraseña para continuar, sin pensar. La coloración rápida, como lo menciona mkudlacek, es una herramienta muy útil para ayudar a garantizar que no esté en el sistema incorrecto.
3. No te metas con las herramientas integradas. Es probable que rompa las actualizaciones y vuelva loco a las nuevas contrataciones. Si desea cambiar algo, use su propio archivo de alias.

No creo que jugar con los permisos shutdownsea ​​la forma de manejar la situación. Básicamente acabas de aprender una lección. Ánimo.

He hecho el mismo tipo de cosas: obtener largas cadenas de sesiones de SSH, luego jugar con las rutas en una de las máquinas por las que me hicieron pasar, interrumpiéndome. He estropeado una solicitud rsync, lo que lleva a la destrucción sistemática de un sistema en el otro lado del mundo. Me he ejecutado rm -rf / pathen un servidor de producción. (Esa vez aprendí cómo funcionaban las restauraciones).

Entonces, mucho más viejo y con suerte un poco más sabio, ahora tengo reglas estrictas que me impongo.

• Todos los mensajes raíz terminan con un #, sin importar qué otra información contenga.
• Cada vez que estoy en el indicador #, literalmente me siento en mis manos antes de presionar la tecla Intro.
• Si tengo alguna duda sobre lo que estoy a punto de hacer o dónde estoy realmente o cómo llegué allí, lo cancelo y lo reconstruyo nuevamente desde una condición de inicio conocida.
• Cuando cometo un error (y todavía los cometo, aunque cada vez son menos frecuentes y más oscuros a medida que pasa el tiempo), averigua inmediatamente lo que he hecho, a quién he impactado y confiesa mis pecados. . Luego suelte todo lo demás y deshaga el daño lo más rápido y mejor que pueda.

La naturaleza de mi trabajo requiere que pase mucho tiempo en muchas indicaciones de raíz variadas, pero gracias a mis errores en el pasado mantengo una conciencia situacional mucho mejor que cuando comencé.

Si estás usando Ubuntu, entonces prueba Molly-guard. Como se discutió en esta pregunta similar .

Depende, de verdad. Podría intentar simplemente envolver el comando, pero significa que si realiza actualizaciones o mejoras que afectan a ese ejecutable, puede olvidarse de él y hacer que arruine una actualización. Jugar con los comandos de apagado del sistema puede ser un PITA, especialmente si tiene nuevas contrataciones o un reemplazo que termina sin saber que estaba jugando con los archivos binarios del sistema.

Personalmente, consideraría envolver el comando en una secuencia de comandos que identifique el sistema por nombre y te haga confirmar que eso es lo que realmente quieres hacer antes de ejecutar el binario real, o que tienes que escribir una cierta secuencia de letras para confirmar el apagado antes de que se ejecute el binario. Eso debería hacer una pausa.

Puede considerar configurar el símbolo del sistema para incluir el nombre de la máquina, al menos en los servidores. Simplemente podría ayudar a evitar que otros comandos se ejecuten en la máquina incorrecta en el futuro. Es más efectivo si los nombres de las máquinas están coloreados para que se destaquen e incluso podría codificar con colores para identificar los roles del servidor.

Una forma es no usar suy / o iniciar sesión directamente en root. Es mejor iniciar sesión directamente en la cuenta Y tener una contraseña diferente para rootla máquina local y la clave ssh.

Por supuesto, es además de estar atento al indicador rojo '#'.

Sí, eliminar el bit de ejecución en el comando de apagado es la forma más sencilla y segura de prevenir apagados accidentales, especialmente si tiene un entorno de escritorio como KDE en la máquina y desea evitar apagados accidentales al cerrar la sesión.

En cuanto a que las personas nuevas se confundan, creo que lo primero que harán será ls -l /sbin/shutdownaveriguar por qué no funciona (especialmente si tienen el buen hábito de completar nombres ejecutables de tabulación). Obviamente, debe informarles sobre cualquier cambio que haya realizado.

Para mayor seguridad, puede agregar una línea para /etc/rc.localeliminar el bit de ejecución del comando de apagado para que no olvide restablecerlo después de un reinicio.

simplemente puede eliminar / sbin / de la ruta de la raíz. de esa manera, debe escribir la ruta completa para ejecutarlo, y generalmente soluciona los accidentes.