Trucos de seguridad de la línea de comando [cerrado]

La línea de comandos y las secuencias de comandos son peligrosas. Haz un pequeño error tipográfico con rm -rf y estarás en un mundo de dolor. Confunde la producción con la etapa en el nombre de la base de datos mientras ejecuta un script de importación y está conectado (si están en el mismo servidor, lo que no es bueno, pero sucede). Lo mismo para notar demasiado tarde que el nombre del servidor donde se colocó no es el que pensaba que era después de ejecutar algunos comandos. Tienes que respetar el Hole Hawg .

Tengo algunos pequeños rituales antes de ejecutar comandos arriesgados, como hacer una verificación triple del servidor en el que estoy. Aquí hay un artículo interesante sobre seguridad de la empresa .

¿Qué pequeños rituales, herramientas y trucos te mantienen a salvo en la línea de comando? Y me refiero a cosas objetivas, como "primero ejecuta ls foo *, mira la salida de eso y luego sustituye ls con rm -rf para evitar ejecutar rm -rf foo * o algo así", no "asegúrate de saber qué comando hará ".

Uno que funciona bien es usar diferentes colores de fondo en su shell para servidores de producción / ensayo / prueba.

Tenga un plan de retroceso en mente antes de comenzar.

• ZIP un archivo / directorio en lugar de eliminarlo de inmediato
• configura el enrutador (cisco) para reiniciar en 'x' cantidad de minutos y no 'wr' de inmediato
• asegúrese de que la interfaz que está cambiando no sea la que ingresó al sistema. Esta podría ser la interfaz del enrutador a la que hizo telnet o el puerto ethernet VNC'd.
• nunca inicie sesión como 'root'
• hacer una copia de seguridad. Comprueba que es bueno. hacer otro
• pregúntale a alguien de confianza '¿Estoy a punto de hacer algo tonto aquí?'

Tengo una solución de baja tecnología para algunos de estos.

He desarrollado un hábito inactivo de hacer lo siguiente (cuando planeo trabajar como root):

• Primero, inicie sesión como un usuario normal, luego use sudo su - rootpara cambiar a root. Hago esto como una preparación mental, un recordatorio de que me he metido mentalmente en un área muy peligrosa y que debo estar alerta y en guardia en todo momento. Por extraño que parezca, este pequeño ritual por sí solo me ha ahorrado un montón de pena simplemente reforzando que no puedo ser descuidado .
• Cada comando se escribe pero la tecla [Retorno] nunca se presiona. Nunca .
• Sin comando es cada vez ejecutada sin entender exactamente lo que hace. Si está haciendo esto sin saber lo que hace, está jugando a la ruleta rusa con su sistema.
• Antes de presionar la tecla [Volver], el comando que se golpeó en la CLI se examina cuidadosamente a simple vista. Si hay alguna duda, cualquier indicio de posible problema, se vuelve a examinar nuevamente. Si esa duda persiste, el comando se deja en la línea y uso Alt-F2 en otra consola para consultar las páginas de manual, etc. Si en una sesión gráfica, inicio un navegador y busco un poco.
• Ningún usuario común es entregado sudoen mis sistemas, no porque sea ​​un BOFH , sino porque sin preparación y entrenamiento, es como darle un arma cargada a un mono. Al principio es divertido y divertido, hasta que el mono mira por el cañón y aprieta ...

Cuando uso rm, siempre voy cdprimero al directorio, luego uso un prefijo de ./para asegurarme de que el directorio sea correcto, es decir

cd /usr/some/directory ; rm ./targetfile

o especifico la ruta completa del archivo

rm /usr/some/directory/targetfile

que es un PITA pero ... más vale prevenir que curar.

Este es específico de Windows Powershell.

Como política agregamos lo siguiente a la máquina profile.ps1 en cada servidor. Esto asegura que lo siguiente sea cierto:

1. Las ventanas de la consola de administración de PowerShell tienen un color de fondo rojo oscuro
2. Administrador se agrega al título
3. El mensaje "Advertencia: Powershell se está ejecutando como administrador". está escrito al inicio
4. La barra de título tiene el prefijo "Administrador:"
5. Las utilidades estándar (como scripts de shell corporativos, vim e infozip) están en el camino.

$ currentPrincipal = New-Object Security.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
& {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrador))
    {
        (get-host) .UI.RawUI.Backgroundcolor = "DarkRed"
        host claro
        write-host "Advertencia: PowerShell se está ejecutando como administrador. n"
    }

    $ utilidades = $ nulo
    if ([IntPtr] :: tamaño * 8 -eq 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: archivos de programa (x86)} \ Utilities"
    }
    más
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: archivos de programa} \ Utilities"
    }
    if ((Test-Path $ utilities) -and! ($ env: path -match $ utilities.Replace ("\", "\\")))
    {
        $ env: ruta = "$ utilidades; $ {env: ruta}"
    }
}

indicador de función
{
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrador))
    {
        if (! $ host.UI.RawUI.WindowTitle.StartsWith ("Administrador:"))
        {$ Host.UI.RawUI.WindowTitle = "Administrador:" + $ host.UI.RawUI.WindowTitle}
    }
    'PS' + $ (if ($ nestedpromptlevel -ge 1) {'>>'}) + '>'
}

Estoy de acuerdo con todas las respuestas anteriores, pero tengo que enfatizar este consejo muy, muy importante:

Sepa cuándo evitar la multitarea.

Me aseguro de que el nombre de host del sistema en el que estoy esté en el indicador bash (u otro shell). Si estoy chrooteado, me aseguro de que eso también esté ahí de alguna manera.

Una vez estaba instalando un sistema Gentoo desde otra distribución de Linux en vivo y accidentalmente ejecuté un comando bastante destructivo (no recuerdo lo que era ATM, alguna variante de rm) en el shell incorrecto, lo que provocó que un montón de cosas en el sistema en vivo eliminado, en lugar de cosas desde dentro del chroot. A partir de entonces, siempre lo hice

export PS1="(chroot) $PS1"

cada vez que estaba trabajando dentro de un chroot.

Hay algunas cosas importantes a tener en cuenta antes de realizar un cambio de servidor:

• Asegúrate de estar en el servidor correcto

• Tenga en cuenta ** cuántas personas se verán afectadas por esta acción * (si comete un error o no)

• Antes de escribir la tecla 'enter', tenga en cuenta la posibilidad de deshacer

• Pregúntese si este comando tiene el potencial de desconectar su sesión (regla fw, mal apagado, etc.). Asegúrese de que haya una conmutación por error para volver (especialmente si está fuera del sitio)

Si aún no lo ha hecho, alias rm to rm -i

Regla 1 - hacer copias de seguridad

Regla 2: NUNCA agregue envoltorios "molly guard" a los comandos estándar, haga su propia versión, claro, pero no tome el nombre, simplemente lo morderá cuando esté en un sistema que no configuró.

Los trucos rápidos como colores diferentes para el árbol de directorios raíz y (parcial) son excelentes ayudantes, pero de nuevo, asegúrese de que puede trabajar sin ellos.

Esto puede parecer contrario a la intuición y menos ardiente, pero el mejor consejo de seguridad de la línea de comandos que tengo es: Si hay una alternativa en modo GUI disponible y práctica, entonces USARLA .

¿Por qué? Bastante sencillo. El modo GUI generalmente tiene una red de seguridad incorporada, en forma de "advertencia: estás a punto de gruñir el freeblefrop, ¿estás seguro de que quieres hacer esto?" Incluso si no, te ralentiza, dando más espacio para pensar. Le permite verificar las opciones más fácilmente antes de comprometerse con ellas, puede hacer capturas de pantalla antes y después de los estados, lo protege de errores tipográficos; Todas las cosas buenas, útiles y útiles.

En el caso clásico del temido "rm -rf", ¿crees que es más fácil emitirlo accidentalmente desde una GUI o una CLI?

Al final, no hay vergüenza en recurrir a la GUI. No evitará infaliblemente desastres mayores; es tan posible ser gatillo feliz en una GUI como lo es en una CLI; pero si te salva una vez, se demuestra que vale la pena.

Use el sentido común y no ejecute comandos que no entiende. Eso es todo un buen consejo. Si te apetece escribir el camino absoluto de todo lo que pasas a rm, o ejecutar cualquier cosa a través de sudo, siéntete libre. Prefiero su -c entonces. Al menos no almacena en caché la contraseña. No me sentiría cómodo con que cualquier usuario normal pueda ejecutar cosas con privilegios de root sin verificación de contraseña.

Hay algunas cosas que puede poner en su ~ / .bashrc para hacer las cosas un poco más seguras, como:

alias srm='rm -i'

Permitiéndole tener una alternativa segura de rm, ...

Pero al final, puedes y siempre lo arruinarás. El otro día tuve una secuencia de comandos de configuración desaparecida en toda mi carpeta / usr / bin, rompiendo varias cosas. Sí, una simple "instalación de instalación" de cualquier tipo de software con un error puede dañar su sistema. NUNCA estás a salvo, hagas lo que hagas. A lo que me refiero es a lo más importante:

Mantenga copias de seguridad regulares.

En lugar de alias rm a rm -i, ¿no sería mejor usar alias para decir remove o saferemove (y usarlos como su herramienta de eliminación preferida)? Luego, cuando usas una caja que no ha configurado esto, no se hace daño.

Asegúrese de nunca ejecutar el comando que encuentre en línea a menos que comprenda completamente lo que están haciendo.

Su sistema puede ser diferente al del póster, y eso podría causar un mundo de dolor.

Una obvia para la seguridad de la línea de comandos desde una perspectiva de Unix / Linux es el uso adecuado de la cuenta raíz.
Un rm -rf como root es generalmente más peligroso que como usuario, y es vital usar cosas integradas como sudo en lugar de iniciar sesión como root. Un buen whoami simple generalmente ayudará para la esquizofrenia o para múltiples personalidades.

Eso y anteponer eco a cualquier comando de intercambio de archivos, especialmente si desea asegurarse de que tiene una coincidencia glob o regex correcta.

Tener una conexión secundaria en la máquina en la que está trabajando puede ser útil en caso de que cierre su sesión principal o haga algo tonto que lo bloquee ... procesamiento pesado, etc.

De esa manera, todavía tiene acceso a la máquina y puede matar su sesión principal.

La mayoría de los comentarios anteriores se refieren a rm, pero también he hecho algunas cosas estúpidas con otros comandos ...

ifconfig para derribar la red: ay, eso requiere presencia física para solucionarlo.

En cuanto a las secuencias de comandos, generalmente trabajo en dos ventanas. El primero que uso para escribir el guión, el segundo para probar cada línea mientras la escribo. Yendo lenta y cuidadosamente, puedo asegurarme de que cada línea funcione como esperaba mientras escribo el código, cuidando de mantener las mismas variables, etc.

Personalmente, no encuentro las indicaciones adicionales para cosas como rm -i realmente ayudan. Cometo la mayoría de mis errores cuando estoy cansado, estresado, etc., que son los momentos en los que simplemente estaré golpeando e ignorando el aviso de todos modos. Mala práctica quizás.

Si usa bash, intente esto:

TMOUT=600

en tu /root/.bashrco similar. Te desconecta automáticamente después de 10 minutos, lo que reduce la posibilidad de que cambies a un terminal raíz que dejaste abierto accidentalmente y escribas algo estúpido.

Sí, sé que deberías usar sudo para ejecutar comandos raíz: esta es solo una red de seguridad adicional en caso de que decidas jugarlo de forma riesgosa algún día.

# Allow only UPDATE and DELETE statements that specify key values
alias mysql="mysql --safe-updates"`

Un alias muy recomendable para tener si alguna vez usa la CLI de mysql.

En lugar de ls, uso echo para poder ver el comando completo después de que el shell haya expandido todo. Además, siempre doble las variables de comillas que representan archivos para que sus cosas funcionen con nombres de archivos que pueden tener tabulaciones o espacios.

Evito el *pegote como su propio argumento siempre que sea posible. Incluso si realmente quiero decir "eliminar todo en este directorio", trato de ser más específico, es decir. rm *.php. Es un control preventivo de daños en caso de que accidentalmente ejecute el mismo comando fuera del historial en otro directorio.

Una excelente manera de hacerte pensar en lo que estás haciendo es agregar algo como esto al bashrc de la raíz (cshrc, lo que sea):

unset PATH

De esa manera, tienes que hacer / bin / rm en lugar de solo "rm". Esos personajes extra pueden hacerte pensar.

Para expresiones regulares complejas, especialmente los comandos 'buscar' ponen eco al frente y los capturan en un archivo. Luego puede verificar que realmente está eliminando / moviendo / etc. exactamente lo que cree que es antes de ejecutar el archivo con 'fuente'.

También es útil para agregar manualmente las mayúsculas y minúsculas que la expresión regular no detectó.

Un poco meta para algunas de las otras publicaciones: utilizo los pasos habituales echo / ls sugeridos primero, para asegurarme de que el comando está seleccionando el conjunto de archivos que quiero o que el shell está interpretando de otra manera según lo previsto.

Pero luego uso las funciones de edición del historial de comandos del shell para recuperar el comando anterior y modificar solo las partes que deben variar.

No ayuda en absoluto escribir cada uno de estos comandos de forma independiente ...

$ ls *.bak
$ echo rm *.bak
$ rm * .bak

... porque accidentalmente escribí un espacio en la última línea y eliminé todos los archivos. Siempre recuperaría la línea anterior y simplemente eliminaría el 'eco'.

usuario root:
no sea root a menos que sea necesario.
Si el proveedor dice que necesita ejecutarse como root, dígales que usted es el cliente y que desea ejecutarlo como no root.
¿Cuántos paquetes de software de la plataforma quieren rootear "solo porque es más fácil"?

hábito:
nunca use '*' con remove sin mirarlo tres veces. Es mejor construir el hábito de usar ls -l TargetPattern , luego use 'rm! $'. La mayor amenaza es no estar donde crees que estás. ¡ Casi escribo 'hostname' tan seguido como 'ls'!

muletas:
un indicador estándar ayuda mucho, al igual que los alias como "alias rm = 'rm -i'", pero a menudo no tengo control total sobre las máquinas en las que estoy, así que utilizo un script de contenedor de espera solo para establecer su ruta , prompt y alias con '-i'

encontrar problemas: el
uso de una ruta completa ayuda, pero en los casos en que eso no sea posible, cd en una ubicación más segura y TAMBIÉN use '&&' para asegurarse de que el 'cd' tenga éxito antes de hacer su búsqueda, eliminar, tar, untar, etc:
ejemplo: el cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
uso de '&&' puede evitar que un archivo tar se extraiga sobre sí mismo en este caso (aunque en este caso 'rsync' sería mejor)

elimina:
nunca elimine recursivamente si puede evitarlo, especialmente en un script. encontrar y eliminar con -type f y -name 'patrón' Todavía vivo con el miedo de alimentar 'nada' a xargs ... tar y untar para mover cosas (use rsync en su lugar)

Si utiliza múltiples variantes de un sistema operativo, ser muy conscientes de las diferencias en la sintaxis; Lo que es razonablemente seguro en una variante de Unix es extremadamente peligroso en otra.

Ejemplo: killall

Linux / FreeBSD / OSX: elimina todos los procesos que coinciden con el parámetro pasado. por ejemplo: "killall apache" mata a todos los apaches, dejando todos los demás procesos solos.

Solaris: mata todos los procesos. No realmente. Desde la página de manual : shutdown (1M) utiliza killall para eliminar todos los procesos activos que no están directamente relacionados con el procedimiento de apagado.

En lugar de

rm foo*

utilizar

rm -i foo*

Esto es práctico con un puñado de archivos, pero no con, digamos, un tarball completo. Es por eso que el alias rmse interpondrá en tu camino.

Ejecutar el comando con echo primero es una buena idea, pero aún es propenso a los errores tipográficos.

Intente usarlo con una expansión como! $.

echo foo*
rm -rf !$

El! $ Se expande hasta la última palabra del último comando, por lo que es equivalente a

echo foo*
rm -rf foo*

También existe! *, Que se expande a todos los argumentos hasta el último comando.

De hecho, podría hacerlo de esta manera si lo prefiere

echo rm -rf foo*
!*

(Si está utilizando ksh, no bash, puede escribir Esc + punto para insertar la última palabra).

En el caso de algo como:

ls * .php
echo rm * .php
rm * .php

Puede usar el operador de sustitución, de esta manera:
$ ls * .php
<directorio de directorios>

$ ^ ls ^ echo rm (esto reemplaza ls en el comando anterior con echo rm, manteniendo el resto de la línea de comando igual)

$ ^ echo rm ^ rm (reemplace echo rm con solo rm, por lo que no tiene que volver a escribir * .php y tirar un espacio en el momento incorrecto)

^ = shift-6, para aquellos que no están familiarizados con él.

Use bash y configure PS1 = '\ u @ \ h: \ w>'. Esto se expande a username @ hostname: / full / working / directory / path> Como se mencionó en otras respuestas, puede usar esperar para configurar el entorno cada vez que inicie sesión si no puede actualizar los archivos .profile o .bash_profile. Sin embargo, cambiar los colores de fondo es fácilmente la mejor respuesta :-)

Ah, sí. Ese viejo truco de enviarle a alguien un archivo a través de IRC llamado "-rf" para que termine en su directorio ~. Un pequeño "rm -rf" más tarde (en lugar de "rm -rr") y mucha risa se produjo cuando aprendieron una dura lección sobre no ejecutar IRC como root.

En lugar de utilizar rm -rf <dir>poner el -rfen el extremo de este modo: rm <dir> -rf. Piense en ello como quitar la seguridad después de apuntar y antes de disparar. De esa manera, estará protegido si tiene un deslizamiento de la tecla Intro mientras escribe el nombre del directorio (o usa la finalización de tabulación) y tiene directorios con nombres similares.