Можно ли предотвратить SCP, оставляя доступ к SSH?

Используя серверы Solaris и Linux и OpenSSH, возможно ли запретить пользователям копировать файлы, используя «scp», и в то же время разрешить доступ оболочки с помощью «ssh»?

Я понимаю, что доступ к файлам типа '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».

Теперь разумный механизм регистрации был бы хорош. Может быть, audit наконец работает на Linux. Возможно, Solaris, наконец, добавил какой-то механизм, или dtrace можно было бы безопасно использовать. Разумно хотеть, чтобы ОС регистрировала каждый раз, когда к файлу обращаются. Конечно, нет разницы между «чтением» и «копированием». Но это может удовлетворить аудитора и обеспечить значительную безопасность системы. Ваши журналы могут быть настолько шумными, что данные бесполезны, или даже вы вынуждены вести смехотворно короткий контрольный журнал. (например, вы не можете регистрировать каждое чтение () - и одно приложение, которое делает что-то удивительное, может сделать регистрацию каждого open () катастрофой).

В зависимости от того, для чего нужен SSH, вы можете достичь этой цели (для нетривиальных) файлов, используя IPTables для завершения сеансов, если размер пакета больше, например, 1400 байт. Это означает, что интерактивный ssh ​​в основном будет работать, но как только что-то попытается отправить 1500-байтовый пакет - как scp должен для файла, превышающего 1499 байт, при условии стандартного MTU 1500, он прервет соединение.

Это также предотвратит упомянутую вами атаку «кошачья».

К сожалению, это означает, что у вас могут возникнуть проблемы при редактировании некоторых файлов с помощью текстового редактора, если на экране нужно нарисовать более 1400 символов, или если вам нужно отследить длинный файл или сделать длинный список каталогов.

В простейшем случае команда для этого может выглядеть примерно так:

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

Мы можем сделать эту работу лучше, комбинируя проверки длины пакета с ipt_recent, так что вы разрешаете ограниченное количество пакетов, превышающее 1400 байт в течение установленного периода времени (скажем, 8 пакетов за 5 секунд) - это позволит пакетам до 12 КБ проскальзывать через, но может дать вам интерактивность, которая вам понадобится для редактирования файлов и т. д. Вы, конечно, можете настроить количество пакетов.

Это может выглядеть примерно так

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 .

Хитрый хакер может обойти эти ограничения, установив MTU менее 1400 на своем компьютере (или принудительно установив mtu или подобное). Кроме того, хотя вы не можете ограничить это для определенных пользователей, вы можете ограничить это по IP, изменив соответствующие строки iptables !!

Ура, Дэвид Го

Лучше всего не блокировать scp, а использовать файловую систему с ACL для предотвращения доступа для чтения. Вероятно, вы могли бы что-то сделать с SELinux, чтобы некоторые приложения не читали определенные файлы.

Нет, scpи sshработать на тех же портах и ​​использовать тот же протокол. Если вы открываете sshсеанс, вы можете даже поделиться своим подключением с последующими вызовами scp, используя такие параметры, какControlMaster .

Если вы не хотите, чтобы люди копировали определенные файлы с компьютера, вы не должны предоставлять им какой-либо доступ к компьютеру через оболочку.

Есть способ использовать 'scponly' в качестве оболочки для отключения интерактивного ssh и разрешения scp, но я не знаю ничего существующего, которое работает в обратном порядке.

Возможно, вы сможете исследовать хакерскую оболочку scponly, чтобы выполнить обратное.

Это невозможно на самом деле после небольшого поиска в Google.

Проверьте это обсуждение: http://www.mydatabaseupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Как бы то ни было, коммерческий продукт CryptoAuditor утверждает, что он может контролировать передачу файлов по SSH, используя MITM -соединение и используя глубокую проверку пакетов . Очевидно, что ни одно решение не является безопасным от копирования + вставки, uuencode / decode, FISH и т. Д. Приятно то, что оно прозрачное (кроме возможных ошибок сертификата); на обоих концах SSH-соединения отсутствует агентское программное обеспечение, и нет портала / прокси для настройки.

Я не использовал продукт, поэтому YMMV.

Невозможно заблокировать передачу файлов, не удалив столько системных утилит, чтобы оставить машину совершенно бесполезной. Вам придется избавиться от всего, что может отображать содержимое файла на стандартный вывод, и от всего, что может записать свой стандартный вывод на стандартный вывод, и к тому времени, как вы удалите все эти, их так мало, что нет смысла разрешать доступ к оболочке. совсем.

Поэтому я сосредоточусь на вашей альтернативе регистрации:

Есть программа под названием «скрипт», которая включена практически в каждый дистрибутив, и которую легко установить в тех местах, где ее нет. Это регистратор сеансов, который записывает весь ввод и вывод из оболочки, опционально с данными синхронизации, так что он может быть воспроизведен и выглядеть так же, как вы смотрели через плечо пользователя, когда они это делали. (В любом случае, 95%, иногда, когда речь идет о ncurses, производительность меняется, но не очень часто.)

Его страница руководства содержит инструкции по настройке в качестве оболочки входа в систему. Убедитесь, что журналы куда-то идут, и пользователь не может просто удалить их (для этого может быть полезен атрибут файловой системы append-only (устанавливается через chattr). Как и ACL или сценарии inotify)

Это по-прежнему не мешает пользователям копировать файлы из системы, но позволяет просматривать, что было сделано, какими пользователями и когда. Это, вероятно, не невозможно обойти, но обход почти наверняка окажется в журналах, так что вы, по крайней мере, будете знать, что кому-то это не помогло, даже если ему удастся скрыть, что именно.

Я считаю, что вы можете удалить openssh-клиентов (или эквивалент) на сервере.

Я думаю, что клиент 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