SSHアクセスを許可しながら、SCPを防ぐことは可能ですか？

SolarisおよびLinuxサーバーとOpenSSHを使用して、ユーザーが「ssh」を使用してシェルアクセスを許可しながら、「scp」を使用してファイルをコピーできないようにすることは可能ですか？

'ssh $ server "cat file"'タイプのファイルアクセスを防止するのははるかに難しいことを認識していますが、初心者向けに "scp"を停止することを確認する必要があります。

それに失敗すると、サーバー側のすべてのSCPアクセスを確実に記録する方法はありますsyslogか？

を編集して/etc/ssh/sshd_config、次のように表示できます。

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

代わりに、ユーザーが何に使用するのかを判断します。アクセスしたいコマンドが数個しかない場合は、代わりに通常のsshシェルを呼び出すことさえできないようにするためです。

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

通常のシェルを実行できる必要があることがわかった場合、本当に期待できるのは、それらを遅くし、さらに難しくすることです。

他の人が指摘しているとして、あなたは（：まあ、あなたは可能性がscpコマンドをブロックすることはできませんrm /usr/bin/scpが、それは本当にどこにでもあなたを取得していません）。

最善の方法は、ユーザーのシェルを制限付きシェル（rbash）に変更してから、特定のコマンドを実行することです。

ファイルを読み取れる場合は、画面からコピー/貼り付けできることを忘れないでください。バイナリファイル？xxd / uuencode / mmencodeはすべてこれを回避します。

プロセスアカウンティングを使用してアクティビティを追跡することもお勧めします。

ファイル転送の文字通り無限の追加メカニズムをまだ許可している場合、「scp」を停止しても何も得られません。scpを許可しないが、ファイルをコピーする他のメカニズムを許可することは、監査人に嘘をつく方法です。多くの場合、監査人は嘘をつきます。通常、監査人がマネージャーと協力して偽の修正を行い、「scpファイル転送コマンドが無効になっているため、scpを使用してサーバーからファイルをコピーできない」などと述べることができます。

これで、適切なロギングメカニズムが得られます。たぶん、監査されたものがLinuxでうまく動くかもしれません。たぶん、Solarisが最終的に何らかのメカニズムを追加したか、dtraceを安全に使用できる可能性があります。ファイルにアクセスするたびにOSにログを記録させることは合理的です。もちろん、「読む」と「コピーする」の間に違いはありません。しかし、これは監査員を満足させ、システムに重要なセキュリティを与えることができます。ログが非常にうるさく、データが役に立たない場合や、監査証跡を途方もなく短いものにせざるを得ない場合もあります。（たとえば、すべてのread（）をログに記録することはできません-驚くべきことを行う1つのアプリケーションは、すべてのopen（）をログに記録することができます）。

SSHの用途に応じて、パケットサイズが1400バイトを超える場合にIPTablesを使用してセッションを終了することにより、この目標（自明ではない）ファイルを達成できる場合があります。これは、インタラクティブsshがほとんど機能することを意味しますが、何かが1500バイトのパケットを送信しようとするとすぐに-scpのように1500の標準MTUを想定して1499バイトを超えるファイルの場合、接続を終了します。

これはまた、あなたが言及する「キャッチ」攻撃を防ぎます。

残念なことに、これは、画面で1400文字を超える文字を描画する必要がある場合、または長いファイルをキャットしたり、長いディレクトリリストを作成したりする必要がある場合、テキストエディターで一部のファイルを編集する際に問題が発生する可能性があることを意味します。

最も単純な場合、これを行うコマンドは次のようになります

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

パケットの長さのチェックをipt_recentと組み合わせることにより、これを改善できます。これにより、設定された時間枠内で1400バイトを超える限られた数のパケットを許可できます（たとえば、5秒あたり8パケット）。ただし、ファイルの編集などに必要な対話機能が提供される場合があります。もちろん、パケット数を微調整できます。

これは次のようになります

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

上記のルール例は、などのscpアップロードに対してのみ保護しscp myfile.data remote.host:~ます。さらにといったSCPのダウンロードから保護するためにscp remote.host:~/myfile.data /local/path、上記の規則を繰り返しますが、交換してください--dportと--sport。

賢明なハッカーは、自分のマシンで1400未満のMTUを設定する（または強制的にmtuなど）ことにより、これらの制限を回避できます。また、これを特定のユーザーに制限することはできませんが、必要に応じてiptables行を変更することにより、IPによって制限することができます!!

乾杯、デビッド・ゴー

最善の策は、scpをロックダウンするのではなく、ACLでファイルシステムを使用して読み取りアクセスを防ぐことです。特定のアプリケーションが特定のファイルから読み取れないようにするために、おそらくSELinuxで何かを行うことができます。

号 scpとssh同一のポート上で動作し、同じプロトコルを使用します。sshセッションを開くと、などのオプションを使用して、接続を後続のscp呼び出しと共有することもできますControlMaster。

マシンから特定のファイルをコピーしたくない場合は、そのマシンへのシェルアクセスを許可しないでください。

シェルとして「scponly」を使用して対話型sshを無効にし、scpを許可する方法がありますが、逆の方法で動作する既存のものは認識していません。

あなたはその逆を成し遂げるためにscponlyシェルをハッキングすることを探ることができるかもしれません。

これは、実際に少しグーグルした後は不可能です。

このディスカッションをご覧ください：http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

価値のあるものとして、商用製品CryptoAuditorは、接続をMITMし、ディープパケットインスペクションを使用することにより、SSHを介したファイル転送を制御できると主張しています。明らかに、コピー+貼り付け、uuencode / decode、FISHなどから安全なソリューションはありません。良い点は、（証明書エラーの可能性を除いて）透過的であることです。SSH接続の両端にインストールするエージェントソフトウェアはなく、設定するポータル/プロキシもありません。

私は製品を使用していませんので、YMMV。

多くのシステムユーティリティを削除せずにファイル転送をブロックして、マシンを完全に役に立たなくすることは不可能です。ファイルの内容をstdoutに表示できるすべてのもの、およびstdinをstdoutに書き込むことができるすべてのものを削除する必要があり、それらすべてを削除するまでに、シェルアクセスを許可する意味がないほど残っているものはほとんどありませんまったく。

そのため、代わりにロギングの代替に焦点を当てます。

実際にはすべてのディストリビューションに含まれている「スクリプト」と呼ばれるプログラムがあり、そうでないものには簡単にインストールできるはずです。シェルからのすべての入力と出力を記録するセッションロガーであり、オプションでタイミングデータを使用して再生することができ、ユーザーの肩越しに見ているように見えます。（とにかく95％、それはncursesが関係しているとき時々出力を揺らしますが、あまり頻繁ではありません。）

そのマニュアルページには、システムのログインシェルとして設定するための指示が含まれています。ユーザーがログを削除できないだけの場所にログが置かれていることを確認してください（追加専用のファイルシステム属性（chattrを介して設定可能）はこれに役立ちます。ACLまたはinotifyスクリプトも同様です）

それでも、ユーザーがシステムからファイルをコピーすることを防ぐことはできませんが、どのユーザーがいつ何をしたかを確認できます。バイパスすることはおそらく不可能ではありませんが、バイパスがほぼ確実にログに記録されるため、少なくとも誰かがそれが何であるかを隠していたとしても、あなたは少なくとも誰かが役に立たなかったことを知っています。

サーバー上のopenssh-clients（または同等のもの）をアンインストールできると思います。

scpクライアントはデータをコピーするときにサーバーでscpを呼び出すので、サーバーでscpを削除する場合は問題ないはずです。

$ 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