Come limitare gli utenti SSH a un set predefinito di comandi dopo il login?

StackOverflow https://stackoverflow.com/questions/402615

  •  03-07-2019
  •  | 
  •  

Domanda

Questa è un'idea per una sicurezza. I nostri dipendenti devono avere accesso ad alcuni comandi su un server Linux ma non tutti. Devono ad es. avere la possibilità di accedere a un file di registro (less logfile) o avviare comandi diversi (shutdown.sh / run.sh).

Informazioni di base:

Tutti i dipendenti accedono al server con lo stesso nome utente: il nostro prodotto funziona con " normale " permessi utente, no " installazione " è necessario. Basta decomprimerlo nel dir utente ed eseguirlo. Gestiamo diversi server in cui la nostra applicazione è & Quot; installata & Quot ;. Su ogni macchina c'è un utente johndoe. I nostri dipendenti a volte hanno bisogno di accedere all'applicazione dalla riga di comando per accedere e controllare i file di registro o per riavviare l'applicazione manualmente. Solo alcune persone devono avere accesso completo alla riga di comando.

Stiamo usando l'autenticazione ppk sul server.

Sarebbe bello se employee1 possa accedere solo al file di log e employee2 può anche fare X ecc ...

Soluzione: Come soluzione userò l'opzione command come indicato nella risposta accettata . Creerò il mio piccolo script di shell che sarà l'unico file che può essere eseguito per alcuni dipendenti. Lo script offrirà diversi comandi che possono essere eseguiti, ma nessun altro. Userò i seguenti parametri tra authorized_keys come indicato qui : 

command="/bin/myscript.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-dss AAAAB3....o9M9qz4xqGCqGXoJw= user@host

Questa è abbastanza sicurezza per noi. Grazie, community!

È stato utile?

Soluzione

Puoi anche limitare le chiavi ai comandi consentiti (nel file authorized_keys).

vale a dire. l'utente non accederà tramite ssh e quindi disporrà di un set limitato di comandi, ma sarebbe autorizzato a eseguire tali comandi solo tramite ssh (ad es. " ssh somehost bin / showlogfile ")

Altri suggerimenti

ssh segue la tradizione rsh usando il programma shell dell'utente dal file delle password per eseguire i comandi.

Ciò significa che possiamo risolverlo senza coinvolgere /etc/passwd la configurazione in alcun modo.

Se non si desidera che l'utente abbia accesso alla shell, è sufficiente sostituire la shell dell'utente con uno script. Se guardi ssh user@host noterai che esiste un campo che assegna un interprete di comandi shell a ciascun utente. Lo script viene utilizzato come shell sia per il loro accesso interattivo ssh user@host command arg ... sia per i comandi foo.

Ecco un esempio. Ho creato un utente my arguments are: la cui shell è uno script. Lo script stampa il messaggio -c seguito dai suoi argomenti (ciascuno su una linea separata e tra parentesi angolari) e termina. Nel caso di accesso, non ci sono argomenti. Ecco cosa succede: 

webserver:~# ssh foo@localhost
foo@localhost's password:
Linux webserver [ snip ]
[ snip ]
my arguments are:
Connection to localhost closed.

Se l'utente tenta di eseguire un comando, è simile al seguente: 

webserver:~# ssh foo@localhost cat /etc/passwd
foo@localhost's password:
my arguments are:
<-c>
<cat /etc/passwd>

Il nostro " shell " riceve un'invocazione di stile /bin/sh, con l'intero comando come argomento, esattamente come /bin/bash -c <string> lo riceverebbe.

Come puoi vedere, quello che possiamo fare ora è sviluppare ulteriormente lo script in modo che riconosca il caso quando è stato invocato con un argomento root, e quindi analizza la stringa (diciamo per corrispondenza del modello). Le stringhe consentite possono essere passate alla shell reale invocando ricorsivamente su. Il caso di rifiuto può stampare un messaggio di errore e terminare (incluso il caso in cui su -s /bin/bash foo manca).

Devi stare attento a come scrivi questo. Consiglio di scrivere solo corrispondenze positive che consentano solo cose molto specifiche e non consentano tutto il resto.

Nota: se sei git, puoi comunque accedere a questo account sovrascrivendo la shell nel comando /git, in questo modo git-upload-pack. (Sostituisce la shell di scelta.) Non-root non può farlo.

Ecco uno script di esempio: limita l'utente a utilizzare git-receive-pack solo per vim l'accesso ai repository in :!sh[Enter]. 

#!/bin/sh

if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then
  printf "interactive login not permitted\n"
  exit 1
fi

set -- $2

if [ $# != 2 ] ; then
  printf "wrong number of arguments\n"
  exit 1
fi

case "$1" in
  ( git-upload-pack | git-receive-pack )
    ;; # continue execution
  ( * )
    printf "command not allowed\n"
    exit 1
    ;;
esac

# Canonicalize the path name: we don't want escape out of
# git via ../ path components.

gitpath=$(readlink -f "$2")  # GNU Coreutils specific

case "$gitpath" in
  ( /git/* )
     ;; # continue execution
  ( * )
    printf "access denied outside of /git\n"
    exit 1
    ;;
esac

if ! [ -e "$gitpath" ] ; then
   printf "that git repo doesn't exist\n"
   exit 1
fi

"$1" "$gitpath"

Naturalmente, confidiamo che questi programmi Git <=> e <=> non abbiano buchi o tratteggi di fuga che consentano agli utenti di accedere al sistema.

Ciò è inerente a questo tipo di schema di restrizione. L'utente è autenticato per eseguire il codice in un determinato dominio di sicurezza e stiamo applicando una restrizione per limitare quel dominio a un sottodominio. Ad esempio, se si consente a un utente di eseguire il comando <=> su un file specifico per modificarlo, l'utente può semplicemente ottenere una shell con <=>.

Quello che stai cercando si chiama Shell con restrizioni . Bash offre una tale modalità in cui gli utenti possono eseguire solo i comandi presenti nelle loro directory home (e non possono spostarsi in altre directory), il che potrebbe essere abbastanza buono per te.

Ho trovato questa discussione per essere molto illustrativo, se un po 'datato.

Dovresti acquisire `rssh ', la shell limitata

Puoi seguire le guide alle restrizioni sopra menzionate, sono tutte piuttosto autoesplicative e semplici da seguire. Comprendi i termini "chroot jail", e come implementare efficacemente le configurazioni sshd / terminal e così via.

Dato che la maggior parte dei tuoi utenti accede ai tuoi terminali tramite sshd, dovresti probabilmente esaminare sshd_conifg, il file di configurazione del demone SSH, per applicare alcune restrizioni tramite SSH. Stai attento, comunque. Comprendi correttamente cosa cerchi di implementare, poiché le ramificazioni di configurazioni errate sono probabilmente piuttosto terribili.

Perché non scrivi la tua shell di login? Per questo sarebbe abbastanza semplice usare Bash, ma puoi usare qualsiasi lingua.

Esempio in Bash

Usa il tuo editor preferito per creare il file /root/rbash.sh (può essere qualsiasi nome o percorso, ma dovrebbe essere chown root:root e chmod 700): 

#!/bin/bash

commands=("man" "pwd" "ls" "whoami")
timestamp(){ date +'%Y-%m-%s %H:%M:%S'; }
log(){ echo -e "$(timestamp)\t$1\t$(whoami)\t$2" > /var/log/rbash.log; }
trycmd()
{
    # Provide an option to exit the shell
    if [[ "$ln" == "exit" ]] || [[ "$ln" == "q" ]]
    then
        exit

    # You can do exact string matching for some alias:
    elif [[ "$ln" == "help" ]]
    then
        echo "Type exit or q to quit."
        echo "Commands you can use:"
        echo "  help"
        echo "  echo"
        echo "${commands[@]}" | tr ' ' '\n' | awk '{print "  " $0}'

    # You can use custom regular expression matching:
    elif [[ "$ln" =~ ^echo\ .*$ ]]
    then
        ln="${ln:5}"
        echo "$ln" # Beware, these double quotes are important to prevent malicious injection

        # For example, optionally you can log this command
        log COMMAND "echo $ln"

    # Or you could even check an array of commands:
    else
        ok=false
        for cmd in "${commands[@]}"
        do
            if [[ "$cmd" == "$ln" ]]
            then
                ok=true
            fi
        done
        if $ok
        then
            $ln
        else
            log DENIED "$cmd"
        fi
    fi
}

# Optionally show a friendly welcome-message with instructions since it is a custom shell
echo "$(timestamp) Welcome, $(whoami). Type 'help' for information."

# Optionally log the login
log LOGIN "$@"

# Optionally log the logout
trap "trap=\"\";log LOGOUT;exit" EXIT

# Optionally check for '-c custom_command' arguments passed directly to shell
# Then you can also use ssh user@host custom_command, which will execute /root/rbash.sh
if [[ "$1" == "-c" ]]
then
    shift
    trycmd "$@"
else
    while echo -n "> " && read ln
    do
        trycmd "$ln"
    done
fi

Tutto quello che devi fare è impostare questo eseguibile come shell di accesso. Ad esempio, modifica il tuo /etc/passwd file e sostituisci l'attuale shell di accesso dell'utente /bin/bash con su -s /root/rbash.sh.

Questo è solo un semplice esempio, ma puoi renderlo avanzato quanto vuoi, l'idea è lì. Fare attenzione a non bloccarsi modificando la shell di accesso del proprio e unico utente. E prova sempre strani simboli e comandi per vedere se è effettivamente sicuro.

Puoi provarlo con: ;.

Attenzione , assicurati di abbinare l'intero comando e fai attenzione con i caratteri jolly! Meglio escludere simboli Bash come &, &&, ||, $, <=> e backtick per essere sicuri.

A seconda della libertà che offri all'utente, non sarà molto più sicuro di così. Ho scoperto che spesso avevo solo bisogno di creare un utente che avesse accesso solo a pochi comandi pertinenti, e in tal caso questa è davvero la soluzione migliore. Tuttavia, desideri dare più libertà, una prigione e le autorizzazioni potrebbero essere più appropriate. Gli errori si realizzano facilmente e si notano solo quando è già troppo tardi.

Potresti voler dare un'occhiata alla creazione di una jail .

Un altro modo di vedere questo è usare gli ACL POSIX, deve essere supportato dal tuo file system, tuttavia puoi avere una messa a punto fine di tutti i comandi in Linux allo stesso modo in cui hai lo stesso controllo su Windows (solo senza l'interfaccia utente più bella). link

Un'altra cosa da esaminare è PolicyKit .

Dovrai fare un po 'di ricerche su Google per far funzionare tutto, dato che al momento questo non è sicuramente un punto di forza di Linux.

[Divulgazione: ho scritto sshdo che è descritto di seguito]

Se vuoi che il login sia interattivo, impostare una shell con restrizioni è probabilmente la risposta giusta. Ma se esiste un set effettivo di comandi che si desidera consentire (e nient'altro) ed è ok che questi comandi vengano eseguiti singolarmente tramite ssh (ad es. Utente ssh @ host cmd arg blah blah), allora un comando generico che consente il controllo whitelisting per ssh potrebbe essere quello che ti serve. Ciò è utile quando i comandi sono in qualche modo scriptati dalla parte del client e non richiede all'utente di digitare effettivamente il comando ssh.

C'è un programma chiamato sshdo per farlo. Controlla quali comandi possono essere eseguiti tramite connessioni ssh in entrata. È disponibile per il download all'indirizzo:

http://raf.org/sshdo/ (leggi le pagine del manuale qui) https://github.com/raforg/sshdo/

Ha una modalità di addestramento per consentire tutti i comandi che vengono tentati, e un'opzione --learn per produrre la configurazione necessaria per consentire permanentemente i comandi appresi. Quindi la modalità allenamento può essere disattivata e tutti gli altri comandi non verranno eseguiti.

Ha anche un'opzione --unlearn per smettere di consentire comandi che non sono più in uso in modo da mantenere il minimo privilegio quando i requisiti cambiano nel tempo.

È molto esigente riguardo a ciò che consente. Non consentirà un comando con alcun argomento. Solo i comandi di shell completi possono essere consentiti.

Ma supporta semplici schemi per rappresentare comandi simili che variano solo nelle cifre che compaiono sulla riga di comando (ad es. numeri di sequenza o data / ora).

È come un firewall o un controllo whitelisting per i comandi ssh.

E supporta diversi comandi consentiti per utenti diversi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top