¿Cuáles son las formas recomendadas de defender una instalación remota de *nix por parte de un administrador torpe?

¿Cuáles son las formas recomendadas de defender una instalación remota de *nix por parte de un administrador torpe?

De vez en cuando (a menudo durante mucho tiempo), tengo dificultades al ejecutar un comando que arruina por completo una máquina Linux.

Más recientemente, volví a montar accidentalmente la partición raíz (pensando que era la nueva unidad USB que acababa de formatear) y luego procedí a cortar recursivamente la partición para mí (nuevamente, simplemente tratando de otorgarme acceso de usuario a la unidad USB). ). Tan pronto como me di cuenta de lo que había hecho (a mitad de proceso), lo aborté, pero el daño ya estaba hecho. Muchos programas principales ya no eran propiedad de root, por lo que la máquina estaba esencialmente en un estado zombificado. Algunas funciones de usuario (ssh, rsync) todavía funcionaban, pero las cosas del nivel de administración estaban totalmente bloqueadas. No se pudo montar, desmontar, volver a conectar a sesiones de pantalla, reiniciar, etc.

Si la máquina estuviera aquí en la sala de estar conmigo, "repararla" (reinstalarla) habría sido trivialmente fácil. Pero no lo es. Está en la casa de mi hermano. No le gusta mucho que lo guíe durante las reparaciones/reinstalación, y lo entiendo. Entonces, iré en unos días para reparar el daño que hice (y, con suerte, instalaré algo más resistente a los errores de administración).

Digo todo eso para hacer la pregunta: ¿Cuáles son las formas recomendadas de proteger una instalación contra la torpeza del administrador?

Cosas no consideradas, o consideradas y descartadas rápidamente:

  1. Fortalecer al administrador para que no ejecute comandos estúpidos: una gran idea, pero no funcionará, porque como ser humano, ocasionalmente hago cosas que luego me doy cuenta de que son una mala idea. Lo que busco hacer es pensar más allá de mí mismo de antemano, de modo que cuando haga algo estúpido, la máquina se negará y me daré cuenta de "¡Oh, mierda! ¡Eso podría haber sido muy malo (TM)! No hagamos eso". de nuevo."

Cosas que he considerado:

  1. Montar la partición raíz como de solo lectura: protegería la raíz de cambios, lo que podría tener efectos negativos si se espera que las partes se puedan escribir, y no lo son. Además, no necesariamente protegería la partición para que no se vuelva a montar en otro lugar como lectura-escritura.
  2. Utilice una imagen raíz comprimida de solo lectura de algún tipo con una capa grabable similar a una unión encima para que nunca se realicen cambios en la raíz y un reinicio solucione cualquier error: esto estaría bien si nunca es necesario realizar cambios. hacerse en la raíz, y tal vez /etc podría recargarse/rellenarse desde un archivo persistente en otro lugar.
  3. Use btrfs con instantáneas regulares (diarias, tal vez), de modo que si se comete un error, la recuperación sea más fácil: aún podría ser subóptimo ya que requeriría la intervención directa del usuario, y no sé si podría guiar a otra persona a través de los cambios para revertir el ups.
  4. Utilice una distribución Linux/BSD más "activa"/"integrada" diseñada más teniendo en cuenta la estabilidad/previsibilidad/seguridad en lugar de una distribución más genérica

Tal como están las cosas ahora, es probable que use la opción 4 para instalar un sistema algo más limitado que la instalación completa de Debian que había estado usando. Pero como solo un servidor de archivos y un cliente de torrents, debería funcionar bien, y como máquina remota, defender la máquina de mí mismo es una gran ventaja.

Respuesta1

La dura verdad es que nada puede protegerte de tu propia estupidez. No hay una interfaz DWIM (haz lo que quiero decir). La computadora no puede distinguir entre lo que es intencional y lo que es accidental. No importa cuánta abstracción acumule en un comando perdido incorrecto, puede destruirlo todo.

La respuesta sencilla esbaja la velocidad y presta atención a lo que estás haciendo.

Respuesta2

Ejecute su instalación en una máquina virtual. Tome una instantánea de un buen estado conocido. Tome instantáneas antes de hacer algo arriesgado. No haga casi nada en el entorno anfitrión. Si comete un error, conéctese al entorno host y restaure la instantánea.

Respuesta3

Nada te impide pegarte un tiro en el pie. "Pensaste" que la partición raíz es una memoria USB. Con la misma facilidad se podría confundir una máquina importante con una máquina virtual desechable (nos pasa a todos).

Lo importante es hacer que el servicio que brindan sus computadoras sea redundante.

En este caso, podría tener dos versiones de Linux instaladas en dos particiones separadas. Puedes decirle a tu hermano que inicie el otro (solo una idea).

Lo más importante es que realice copias de seguridad y tenga una estrategia de restauración.

En este caso, dado que ha asumido la responsabilidad de la PC de su hermano, debe realizar copias de seguridad continuas de todos los datos que pueda y conservar varias copias consigo.

También puede proporcionarle a su hermano una unidad USB Linux para arrancar, con un servidor SSH y una contraseña configurada. Y configure su PC para que arranque desde USB. Luego, en caso de emergencia, simplemente pídale que inserte la memoria USB y reinicie la PC.

Respuesta4

No hagas cosas como usuario root. Configure sudo para permitir que su cuenta habitual realice tareas de root, pero con una contraseña. Esto le brinda una última oportunidad de ver lo que realmente está haciendo.

Pero cuando lo ejecute como root, configure alias para comandos comunes que fuercen el uso interactivo. por ejemplo, alias rm="rm -i"avisará rmantes de la eliminación. Puede anular explícitamente con -f(una decisión consciente) si realmente lo desea rm *(entonces sería rm -f *).

No dijiste qué FS había en el USB. Generalmente son VFAT. Puede montarlos con opciones para que cada archivo parezca pertenecer a un usuario específico. Entonces nunca tendrás que correr chown -r ...y así eliminarás la posibilidad de cometer un error.

Haga que el indicador del shell raíz se coloree de rojo para recordarle que está ejecutando con privilegios elevados.

Generalmente, le dificulta hacer las cosas como root, con obstáculos como solicitudes de contraseña, etc.

Ahora, después de solucionarlo, puede obtener acceso a otra máquina similar y usarla findpara mostrarle los programas SUID/SGID. Luego haga que el disco dañado coincida con el chmodcomando.

información relacionada