Ist es möglich, SCP zu verhindern, während der SSH-Zugriff weiterhin zulässig ist?

Kann unter Verwendung von Solaris- und Linux-Servern und OpenSSH verhindert werden, dass Benutzer Dateien mit "scp" kopieren, während der Shell-Zugriff mit "ssh" weiterhin zulässig ist?

Mir ist klar, dass Dateizugriffe vom Typ 'ssh $ server "cat file" viel schwerer zu verhindern sind, aber ich muss zunächst einmal über das Stoppen von "scp" nachdenken.

Wenn dies nicht der Fall ist, gibt es eine Möglichkeit, den gesamten SCP-Zugriff auf der Serverseite zuverlässig zu protokollieren syslog?

Während Sie Ihre bearbeiten könnten, um ungefähr /etc/ssh/sshd_configso auszusehen:

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

Ich würde stattdessen bestimmen, wofür der Benutzer es wahrscheinlich verwenden wird. Denn wenn es nur wenige Befehle gibt, auf die sie Zugriff haben sollen, würde ich ihnen stattdessen die Möglichkeit nehmen, sogar eine normale sshShell aufzurufen .

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

Wenn Sie feststellen, dass Sie wirklich in der Lage sein müssen, eine normale Shell auszuführen, können Sie nur hoffen, dass Sie sie verlangsamen und schwieriger machen.

Wie andere angemerkt haben, können Sie scp nicht blockieren (nun, Sie könnten:, rm /usr/bin/scpaber das bringt Sie nicht wirklich weiter).

Das Beste, was Sie tun können, ist, die Benutzer-Shell in eine eingeschränkte Shell (rbash) zu ändern und nur dann bestimmte Befehle auszuführen.

Denken Sie daran, wenn sie Dateien lesen können, können sie diese vom Bildschirm kopieren / einfügen. Binärdateien? xxd / uuencode / mmencode umgehen alle diese.

Ich würde auch vorschlagen, die Prozessabrechnung zu verwenden, um die Aktivität zu verfolgen.

Sie gewinnen nichts, wenn Sie "scp" anhalten, während Sie buchstäblich unendlich viele zusätzliche Mechanismen für die Übertragung von Dateien zulassen. Scp zu verbieten, aber andere Mechanismen zum Kopieren von Dateien zuzulassen, ist eine Methode, um Auditoren zu belügen. Oft bitten Auditoren, belogen zu werden. Normalerweise sehe ich Auditoren, die mit Managern zusammenarbeiten, um gefälschte Korrekturen vorzunehmen, so dass sie so etwas wie "Der scp-Dateiübertragungsbefehl wurde deaktiviert, sodass Dateien nicht mit scp vom Server kopiert werden können" angeben können.

Nun wäre ein vernünftiger Protokollierungsmechanismus nett. Vielleicht funktioniert auditd endlich unter Linux. Vielleicht hat Solaris endlich einen Mechanismus hinzugefügt, oder dtrace könnte sicher verwendet werden. Es ist sinnvoll, dass das Betriebssystem jedes Mal protokolliert, wenn auf eine Datei zugegriffen wird. Natürlich gibt es keinen Unterschied zwischen "Lesen" und "Kopieren". Dies kann jedoch einen Prüfer zufriedenstellen und dem System erhebliche Sicherheit geben. Ihre Protokolle können so laut sein, dass die Daten unbrauchbar werden oder dass Sie sogar gezwungen sind, einen lächerlich kurzen Prüfpfad zu führen. (z. B. kann man nicht jeden Lesevorgang protokollieren () - und eine Anwendung, die etwas Überraschendes bewirkt, kann das Protokollieren jedes offenen Vorgangs () zu einer Katastrophe machen).

Abhängig davon, wofür SSH benötigt wird, können Sie dieses Ziel (für nicht triviale) Dateien möglicherweise erreichen, indem Sie IPTables zum Beenden von Sitzungen verwenden, wenn die Paketgröße größer als 1400 Byte ist. Dies bedeutet, dass interaktives ssh meistens funktioniert. Sobald jedoch versucht wird, ein 1500-Byte-Paket zu senden, wie es scp für eine Datei mit mehr als 1499 Bytes bei einer Standard-MTU von 1500 tun sollte, wird die Verbindung beendet.

Dadurch wird auch der von Ihnen erwähnte "Catting" -Angriff verhindert.

Leider bedeutet dies, dass Sie möglicherweise Probleme haben, einige Dateien mit einem Texteditor zu bearbeiten, wenn der Bildschirm mehr als 1400 Zeichen zeichnen muss oder wenn Sie eine lange Datei kategorisieren oder eine lange Verzeichnisliste erstellen müssen.

Im einfachsten Fall könnte ein entsprechender Befehl ungefähr so ​​aussehen

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

Wir können dies verbessern, indem wir die Paketlängenprüfungen mit ipt_recent kombinieren, sodass Sie innerhalb eines festgelegten Zeitrahmens (z. B. 8 Pakete pro 5 Sekunden) eine begrenzte Anzahl von Paketen zulassen, die größer als 1400 Bytes sind. Dadurch könnten Pakete mit einer Länge von bis zu 12 KB verrutschen Möglicherweise erhalten Sie jedoch die Interaktivität, die Sie zum Bearbeiten von Dateien usw. benötigen. Sie können natürlich die Anzahl der Pakete anpassen.

Das könnte ungefähr so ​​aussehen

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

Die obigen Regelbeispiele schützen nur vor scp-Uploads wie scp myfile.data remote.host:~. Um zusätzlich gegen scp Downloads zu schützen wie scp remote.host:~/myfile.data /local/path, wiederholen Sie die oben genannten Regeln aber ersetzen --dportmit --sport.

Ein aufmerksamer Hacker kann diese Einschränkungen umgehen, indem er auf seinem Computer eine MTU von weniger als 1400 einstellt (oder eine MTU oder ähnliches erzwingt). Auch wenn Sie dies nicht auf bestimmte Benutzer beschränken können, können Sie es durch Ändern der iptables-Zeilen nach IP einschränken !!

Prost, David Go

Am besten ist es nicht, scp zu sperren, sondern ein Dateisystem mit ACLs zu verwenden, um Lesezugriffe zu verhindern. Sie könnten wahrscheinlich mit SELinux etwas tun, um zu verhindern, dass bestimmte Anwendungen aus bestimmten Dateien lesen.

Nein scpund ssharbeiten auf den gleichen Ports und verwendet das gleiche Protokoll. Wenn Sie eine sshSitzung eröffnen , können Sie Ihre Verbindung mit Optionen wie beispielsweise für nachfolgende scp-Aufrufe freigeben ControlMaster.

Wenn Sie nicht möchten, dass Benutzer bestimmte Dateien von einem Computer kopieren, sollten Sie ihnen keinen Shell-Zugriff auf den Computer gewähren.

Es gibt eine Möglichkeit, 'scponly' als Shell zu verwenden, um interaktives ssh zu deaktivieren und scp zuzulassen, aber mir ist nichts bekannt, was in umgekehrter Weise funktioniert.

Möglicherweise können Sie das Hacken der Scponly-Shell untersuchen, um das Gegenteil zu erreichen.

Dies ist nach ein wenig googeln eigentlich nicht möglich.

Schauen Sie sich diese Diskussion an: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Für was es wert ist , das Handelsprodukt CryptoAuditor den Ansprüchen der Lage sein , Dateiübertragungen über SSH zu steuern, durch MITM die Verbindung ing und mit Deep Packet Inspection . Offensichtlich ist keine Lösung vor Kopieren + Einfügen, Neucode / Dekodieren, FISH usw. sicher . Das Schöne ist, dass sie transparent ist (abgesehen von wahrscheinlichen Zertifikatfehlern). Auf beiden Seiten der SSH-Verbindung muss keine Agentensoftware installiert und kein Portal / Proxy konfiguriert werden.

Ich habe das Produkt nicht benutzt, also YMMV.

Es ist unmöglich, die Dateiübertragung zu blockieren, ohne so viele Systemdienstprogramme zu entfernen, dass die Maschine völlig unbrauchbar wird. Sie müssten alles loswerden, was in der Lage ist, Dateiinhalte in stdout anzuzeigen, und alles, was in der Lage ist, seine stdin in stdout zu schreiben, und bis Sie all diese entfernt haben, ist so wenig mehr übrig, dass es keinen Grund mehr gibt, Shell-Zugriff zu gewähren überhaupt.

Ich werde mich stattdessen auf Ihre Protokollierungsalternative konzentrieren:

Es gibt ein Programm mit dem Namen "script", das in praktisch jeder Distribution enthalten ist und das auf denjenigen, auf denen es nicht vorhanden ist, leicht zu installieren sein sollte. Es handelt sich um einen Sitzungsprotokollierer, der alle Ein- und Ausgaben einer Shell aufzeichnet, optional mit Timing-Daten, damit sie wiedergegeben werden können und so aussehen, als würden Sie dem Benutzer bei der Ausführung über die Schulter schauen. (95% ohnehin, gelegentlich wird die Ausgabe verschoben, wenn ncurses involviert ist, aber nicht sehr oft.)

Die Manpage enthält Anweisungen zum Einrichten als Anmeldeshell des Systems. Stellen Sie sicher, dass die Protokolle an einem Ort gespeichert sind, an dem der Benutzer sie nicht einfach löschen kann (das Attribut "Nur anhängen" (einstellbar über chattr) kann hierfür hilfreich sein. Ebenso wie ACLs oder Inotify-Skripte).

Dies verhindert immer noch nicht, dass Benutzer Dateien aus dem System kopieren. Sie können jedoch überprüfen, was von welchen Benutzern wann getan wurde. Es ist wahrscheinlich nicht unmöglich zu umgehen, aber die Umgehung würde mit ziemlicher Sicherheit in den Protokollen enden, sodass Sie zumindest wissen würden, dass jemand nichts Gutes tut, selbst wenn er es schafft, genau zu verbergen, was es ist.

Ich glaube, Sie können openssh-clients (oder gleichwertige) auf dem Server deinstallieren.

Ich denke, dass der scp-Client scp auf dem Server aufruft, wenn Daten kopiert werden. Wenn Sie also scp auf dem Server loswerden, sollten Sie in Ordnung sein.

$ 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