È possibile prevenire SCP pur consentendo l'accesso a SSH?

Utilizzando i server Solaris e Linux e OpenSSH, è possibile impedire agli utenti di copiare i file usando "scp" pur consentendo l'accesso alla shell con "ssh"?

Mi rendo conto che gli accessi ai file di tipo "ssh $ server" cat file "sono molto più difficili da prevenire, ma ho bisogno di vedere di interrompere" scp "per i principianti.

In caso contrario, c'è un modo per registrare in modo affidabile tutto l'accesso SCP sul lato server syslog?

Mentre potresti modificarlo /etc/ssh/sshd_configper assomigliare a questo:

ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

Vorrei invece determinare per cosa è probabile che l'utente lo utilizzi. Perché se ci sono solo alcuni comandi a cui si desidera che abbiano accesso, rimuoverei invece la possibilità per loro di invocare persino una sshshell normale .

AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

Se scopri che hai davvero bisogno di essere in grado di eseguire una shell normale, il massimo che puoi davvero sperare è rallentarlo e renderlo più difficile.

Come altri hanno notato, non puoi bloccare scp (beh, potresti:, rm /usr/bin/scpma questo non ti porta da nessuna parte).

Il meglio che puoi fare è cambiare la shell degli utenti in una shell ristretta (rbash) e solo allora eseguire determinati comandi.

Ricorda, se sono in grado di leggere i file, possono copiarli / incollarli dallo schermo. File binari? xxd / uuencode / mmencode riescono a aggirare il problema.

Suggerirei anche di utilizzare la contabilità di processo per aiutarti a tenere traccia dell'attività.

Non ottieni nulla fermando "scp" quando permetti ancora meccanismi aggiuntivi letteralmente infiniti di trasferimento di file. Non consentire scp ma consentire altri meccanismi di copia dei file è un metodo per mentire ai revisori. Spesso i revisori chiedono di essere mentiti. Di solito vedo i revisori che lavorano con i manager per fare correzioni false, in modo che possano dichiarare qualcosa come "il comando di trasferimento file scp è stato disabilitato, in modo che i file non possano essere copiati dal server usando scp".

Ora un meccanismo di registrazione ragionevole sarebbe carino. Forse auditd finalmente funziona su Linux. Forse Solaris ha finalmente aggiunto qualche meccanismo o dtrace potrebbe essere usato in sicurezza. È ragionevole volere che il sistema operativo si registri ogni volta che si accede a un file. Naturalmente non c'è differenza tra "lettura" e "copia". Ma questo può soddisfare un revisore e fornire una sicurezza significativa al sistema. I tuoi registri potrebbero essere così rumorosi che i dati sono inutili o addirittura che sei costretto a tenere una pista di controllo ridicolmente breve. (ad es. non puoi registrare ogni read () - e un'applicazione che fa qualcosa di sorprendente può rendere la registrazione di ogni open () un disastro).

A seconda di quale SSH è necessario, potresti essere in grado di raggiungere questo obiettivo (per scopi non banali) usando IPTables per terminare le sessioni se la dimensione del pacchetto è maggiore, diciamo 1400 byte. Ciò significa che ssh interattivo funzionerà principalmente, ma non appena qualcosa tenta di inviare un pacchetto di 1500 byte - come scp dovrebbe per un file più grande di 1499 byte assumendo un MTU standard di 1500, terminerà la connessione.

Ciò impedirà anche l'attacco "catting" di cui parli.

Sfortunatamente questo significa che potresti avere problemi a modificare alcuni file con un editor di testo, se lo schermo deve disegnare più di 1400 caratteri, o se devi inserire un file lungo o fare un lungo elenco di directory.

Nel caso più semplice, un comando per eseguire questa operazione potrebbe assomigliare a qualcosa del genere

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP

Possiamo migliorare il funzionamento combinando i controlli di lunghezza dei pacchetti con ipt_recent, in modo da consentire un numero limitato di pacchetti superiore a 1400 byte in un intervallo di tempo prestabilito (diciamo 8 pacchetti per 5 secondi) - ciò consentirebbe lo scorrimento di pacchetti fino a 12k attraverso, ma può darti l'interattività di cui hai bisogno per modificare i file, ecc. Puoi ovviamente modificare il numero di pacchetti.

Questo potrebbe assomigliare a qualcosa

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --set 
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
         -j REJECT --reject-with tcp-reset

Gli esempi di regole precedenti proteggono solo da upload scp come scp myfile.data remote.host:~. Per proteggere ulteriormente dai download di scp come scp remote.host:~/myfile.data /local/path, ripetere le regole precedenti ma sostituirle --dportcon --sport.

Un hacker indizio può aggirare queste limitazioni impostando un MTU inferiore a 1400 sul suo computer (o forzando mtu o simili). Inoltre, anche se non puoi limitarlo a determinati utenti, puoi limitarlo tramite IP modificando le linee iptables come appropriato !!

Saluti, David Go

La soluzione migliore non è bloccare SCP, ma usare un file system con ACL per impedire l'accesso in lettura. Probabilmente potresti fare qualcosa con SELinux per impedire a determinate applicazioni di leggere da determinati file.

No. scpe sshoperano sulle stesse porte e utilizzano lo stesso protocollo. Se apri una sshsessione, puoi persino condividere la tua connessione con le successive chiamate scp usando opzioni come ControlMaster.

Se non si desidera che le persone copino determinati file da una macchina, non si dovrebbe dare loro alcun tipo di accesso shell alla macchina.

C'è un modo di usare 'scponly' come shell per disabilitare ssh interattivo e consentire scp, ma non sono a conoscenza di nulla di esistente che funzioni al contrario.

Potresti essere in grado di esplorare l'hacking della shell scponly per realizzare il contrario.

Questo non è possibile in realtà dopo un po 'di googling.

Dai un'occhiata a questa discussione: http://www.myd Databaseupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Per quello che vale, il prodotto commerciale CryptoAuditor afferma di essere in grado di controllare i trasferimenti di file su SSH, MITM tramite la connessione e usando l'ispezione di pacchetti profondi . Ovviamente nessuna soluzione è al sicuro da copia + incolla, uuencode / decode, FISH , ecc. La cosa bella è che è trasparente (a parte probabili errori di certificato); non esiste alcun software agente da installare su entrambe le estremità della connessione SSH e nessun portale / proxy da configurare.

Non ho usato il prodotto, quindi YMMV.

È impossibile bloccare il trasferimento di file senza rimuovere così tante utility di sistema da lasciare la macchina completamente inutile. Dovresti sbarazzarti di tutto ciò che è in grado di visualizzare il contenuto del file su stdout e di tutto ciò che è in grado di scrivere il suo stdin su stdout, e quando hai rimosso tutti quelli che sono rimasti così poco che non ha senso permettere l'accesso alla shell affatto.

Quindi mi concentrerò invece sulla tua alternativa di registrazione:

C'è un programma chiamato "script" che è incluso praticamente in ogni distro e che dovrebbe essere facile da installare su quelli in cui non lo è. È un registratore di sessione che registra tutto l'input e l'output di una shell, facoltativamente con i dati di temporizzazione in modo che possano essere riprodotti e assomigliare a te mentre guardavi da sopra l'utente quando lo hanno fatto. (Il 95% comunque, occasionalmente riduce l'output quando è coinvolto ncurses, ma non molto spesso.)

La sua pagina man include le istruzioni per configurarlo come shell di login del sistema. Assicurati che i log vadano da qualche parte in modo che l'utente non possa semplicemente eliminarli (l'attributo filesystem solo accodamento (impostabile tramite chattr) può essere utile per questo. Altrettanto ACL o inotify script)

Ciò non impedisce agli utenti di copiare i file dal sistema, ma consente di rivedere cosa è stato fatto da quali utenti e quando. Probabilmente non è impossibile bypassare, ma il bypass sarebbe quasi sicuramente finito nei registri, quindi almeno sapresti che qualcuno non ha funzionato bene, anche se riusciranno a nascondere esattamente quello che era.

Credo che tu possa disinstallare openssh-client (o equivalente) sul server.

Penso che il client scp invochi scp sul server quando si copiano i dati, quindi se si elimina scp sul server, allora si dovrebbe andare bene.

$ scp bla server:/tmp/
...
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.utf8
debug1: Sending env XMODIFIERS = @im=ibus
debug1: Sending env LANGUAGE = en_US.utf8
debug1: Sending command: scp -v -t /tmp/
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
lost connection