Можно ли с помощью серверов 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».
Было бы неплохо иметь разумный механизм регистрации. Может быть, auditd наконец-то заработал в Linux. Может быть, в Solaris наконец-то добавлен какой-то механизм или можно будет безопасно использовать dtrace. Разумно хотеть, чтобы ОС регистрировала каждый раз доступ к файлу. Конечно, нет разницы между «чтением» и «копированием». Но это может удовлетворить аудитора и обеспечить значительную безопасность системы. Ваши журналы могут быть настолько шумными, что данные станут бесполезными, или даже вам придется вести до смешного короткий контрольный журнал. (например, вы не можете регистрировать каждый read () - и одно приложение, которое делает что-то неожиданное, может сделать регистрацию каждого 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 секунд) - это позволит пакетам размером до 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, таких как 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.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html
Как бы то ни было, коммерческий продукт КриптоАудитор утверждает, что может контролировать передачу файлов по SSH, MITMподключение и использование глубокая проверка пакетов. Очевидно, что ни одно решение не защищено от копирования + вставки, uuencode / decode, РЫБЫи т. д. Приятно то, что он прозрачен (не считая возможных ошибок сертификата); нет программного агента для установки на обоих концах соединения SSH и нет портала / прокси для настройки.
Я не использовал продукт, так что YMMV.
Блокировать передачу файлов без удаления такого количества системных утилит, чтобы оставить машину совершенно бесполезной, невозможно. Вам нужно будет избавиться от всего, что может отображать содержимое файла в stdout, и от всего, что может записывать свой stdin в stdout, и к тому времени, когда вы удалите все это, осталось так мало, что нет смысла разрешать доступ к оболочке вообще.
Поэтому я сосредоточусь на вашей альтернативе ведения журнала:
Есть программа под названием «скрипт», которая включена практически в каждый дистрибутив, и ее должно быть легко установить там, где ее нет. Это регистратор сеансов, который записывает весь ввод и вывод из оболочки, опционально с данными о времени, чтобы его можно было воспроизвести, и он выглядел так, как будто вы наблюдали через плечо пользователя, когда он это делал. (Во всяком случае, 95%, при использовании ncurses он иногда делает вывод, но не очень часто.)
Его справочная страница содержит инструкции по настройке в качестве оболочки входа в систему. Убедитесь, что журналы находятся куда-то, что пользователь не может просто удалить их (для этого может быть полезен атрибут файловой системы только для добавления (настраиваемый через chattr). Как и ACL или сценарии inotify)
Это по-прежнему не мешает пользователям копировать файлы из системы, но позволяет просматривать, что и когда было сделано какими пользователями. Вероятно, это не невозможно обойти, но обход почти наверняка попадет в журналы, так что вы, по крайней мере, будете знать, что кто-то сделал ничего хорошего, даже если им удастся точно скрыть, что это было.
Я считаю, что вы можете удалить openssh-client (или эквивалент) на сервере.
Я думаю, что клиент 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
Я не уверен, почему удаление или переименование / usr / bin / scp не считается правильным ответом, поскольку оно напрямую касается исходного вопроса.
У нас есть ограниченные серверы, которые существуют для интерактивных сеансов оболочки, но должны экспортировать файлы по утвержденным каналам, и удаление очевидных протоколов передачи имеет большое значение для достижения этой цели. В частности, клиенты Windows, использующие MobaXterm, по умолчанию получат удаленный файловый браузер, использующий SFTP, но попробуют SCP в качестве запасного варианта, и не очень очевидно, что что-то отличается от конечного пользователя.