SSHアクセスを許可しながらSCPを防止することは可能ですか？
SolarisおよびLinuxサーバーとOpenSSHを使用して、ユーザーが "scp"を使用してファイルをコピーするのを防ぎながら、 "ssh"によるシェルアクセスを許可することはできますか？
「ssh $ server "cat file"」タイプのファイルアクセスは防ぐのがはるかに難しいことを理解していますが、最初に「scp」を停止することについて確認する必要があります。
それが失敗した場合、syslogを介してサーバー側のすべてのSCPアクセスを確実に記録する方法はありますか？
/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を使用してサーバーからファイルをコピーできない」などの状態を示すことができます。
これで、適切なロギングメカニズムが実現します。多分、audiddはついにLinuxで動作します。たぶん、Solarisがようやく何らかのメカニズムを追加したか、dtraceを安全に使用できるようになります。ファイルにアクセスするたびにOSがログを記録するようにするのが妥当です。もちろん、「読むこと」と「コピーすること」の間に違いはありません。しかし、これは監査人を満足させ、システムに重要なセキュリティを与えることができます。ログが非常に騒々しいため、データが役に立たない場合や、途方もなく短い監査証跡を残さざるを得ない場合もあります。 （たとえば、すべてのread（）をログに記録することはできません-そして、驚くべきことを行う1つのアプリケーションが、すべてのopen（）のログを記録するのは大変なことです）。
必要なSSHによっては、パケットサイズが1400バイトよりも大きい場合に、IPTablesを使用してセッションを終了することにより、（重要ではない）ファイルの目的を達成できる場合があります。これは、対話型のsshがほとんど機能することを意味しますが、何かが1500バイトのパケットを送信しようとするとすぐに-標準のMTUが1500であると想定したscpが1499バイトを超えるファイルに対しては、接続が終了します。
これにより、あなたが言及する「キャッティング」攻撃も防止されます。
残念ながら、これは、画面が1400文字以上を描画する必要がある場合、または長いファイルをカタログ化したり、長いディレクトリ一覧を作成したりする必要がある場合、テキストエディターで一部のファイルを編集するときに問題が発生する可能性があることを意味します。
最も単純なケースでは、これを行うコマンドは次のようになります。
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP
パケット長チェックをipt_recentと組み合わせることで、これをより適切に機能させることができるため、設定されたタイムフレーム内で1400バイトを超える限られた数のパケットを許可できます（たとえば、5秒あたり8パケット）。これにより、最大12kのパケットがスリップします。を介して、ただし、ファイルの編集などに必要な対話性が得られる場合があります。もちろん、パケット数を微調整できます。
これは次のようになります
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 myfile.data remote.Host:~などのscpアップロードに対してのみ保護します。 scp remote.Host:~/myfile.data /local/pathなどのscpダウンロードからさらに保護するには、上記のルールを繰り返しますが、--dportを--sportに置き換えます。
巧妙なハッカーは、自分のマシンで1400未満のMTUを設定する（または、mtuを強制するなど）ことで、これらの制限を回避できます。また、これを特定のユーザーに制限することはできませんが、iptablesの行を適切に変更することでIPで制限できます。
乾杯、デビッド・ゴー
あなたの最善の策は、scpをロックダウンすることではなく、ACLを持つファイルシステムを使用して読み取りアクセスを防ぐことです。 SELinuxを使用して、特定のアプリケーションが特定のファイルから読み取れないようにすることができます。
いいえ。scpとsshは同じポートで動作し、同じプロトコルを使用します。 sshセッションを開くと、ControlMasterなどのオプションを使用して、後続のscp呼び出しと接続を共有することもできます。
特定のファイルをマシンからコピーしたくない場合は、マシンへのシェルアクセスを一切許可しないでください。
サーバー上の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 [email protected] reply 0
lost connection
多くのシステムユーティリティを削除せずにファイル転送をブロックして、マシンを完全に使用不能にすることは不可能です。ファイルの内容をstdoutに表示できるすべての機能、およびそのstdinをstdoutに書き込むことができるすべての機能を削除する必要があります。これらをすべて削除するまでには、シェルアクセスを許可する意味がほとんどないため、残りはほとんどありません。まったく。
そのため、代わりにロギングの代替方法に焦点を当てます。
ほとんどすべてのディストリビューションに含まれている「スクリプト」と呼ばれるプログラムがあり、そうでないプログラムへのインストールは簡単です。シェルからのすべての入力と出力を記録するセッションロガーであり、オプションでタイミングデータを使用して再生できるため、ユーザーが肩越しに見ているように再生できます。 （とにかく95％、それは時々ncursesが含まれているとき出力を混乱させますが、それほど頻繁ではありません。）
そのmanページには、システムのログインシェルとして設定する手順が含まれています。ログがユーザーが削除できない場所にあることを確認します（追加専用のファイルシステム属性（chatrtで設定可能）がこれに役立ちます。ACLやinotifyスクリプトも同様です）。
これにより、ユーザーがシステムからファイルをコピーすることは妨げられませんが、どのユーザーがいつ何を行ったかを確認できます。バイパスすることはおそらく不可能ではありませんが、バイパスはほぼ確実にログに記録されるので、たとえ誰かが何をしていたかを正確に隠すことができたとしても、少なくとも誰かがダメだとわかっていたはずです。
シェルとして「scponly」を使用してインタラクティブなsshを無効にし、scpを許可する方法がありますが、逆の方法で動作するものが存在することは知りません。
あなたはscponly Shellをハッキングしてその逆を達成する方法を探ることができるかもしれません。
これは実際には少しググリングした後は不可能です。
このディスカッションを確認してください：http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html
価値のあるものとして、商用製品 CryptoAuditor は [〜＃〜] mitm [〜＃〜] 接続を行うことでSSHを介したファイル転送を制御できると主張し、 ディープパケットインスペクション を使用します。明らかに、copy + paste、uuencode/decode、 [〜＃〜] fish [〜＃〜] などから安全な解決策はありません。良い点は、それが透過的であることです（証明書エラーの可能性があることを除けば）。 SSH接続の両端にインストールするエージェントソフトウェアや、構成するポータル/プロキシはありません。
まだ使ってないのでYMMV。