Действительно ли возможно предотвратить SCP при тихом предоставлении доступа SSH?

В то время как Вы могли отредактировать Ваш /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" при тихом разрешении буквально бесконечных дополнительных механизмов передачи файлов. Запрещение scp, но разрешение других механизмов копирования файлов является методом лжи об аудиторах. Часто аудиторы просят лгаться. Обычно я вижу, что аудиторы работать с менеджерами для создания фальшивки фиксируют, так, чтобы они могли заявить, что что-то как "scp команда передачи файлов было отключено, так, чтобы файлы не могли быть скопированы с сервера с помощью scp".

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

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

Как другие отметили, Вы не можете заблокировать scp (хорошо, Вы могли: rm /usr/bin/scp, но это действительно не получает Вас нигде).

Лучшее, которое можно сделать, должно изменить оболочку пользователей на ограниченную оболочку (rbash) и только затем выполнять определенные команды.

Помните, если они могут считать файлы, они могут скопировать/вставить их от экрана. Двоичные файлы? xxd/uuencode/mmencode все обходят это.

Я также предложил бы использовать процесс, считающий, чтобы помочь Вам отследить действие.

Нет. 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, Вы можете достигать этой цели (для нетривиального) файлы при помощи IPTables для завершения сессий, если размер пакета больше затем, скажите 1 400 байтов. Это означает, что интерактивный ssh будет главным образом работать, но как только что-то пытается отправить, 1 500-байтовый пакет - как scp должен для файла, больше затем 1 499 байтов, принимающих стандартный MTU 1500, он завершит соединение.

Это также предотвратит нападение "catting", которое Вы упоминаете.

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

В самом простом случае команда, чтобы сделать это могло бы посмотреть что-то как

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

Мы можем сделать эту работу лучше путем объединения длины пакета, сверяется с ipt_recent, так, чтобы Вы позволили ограниченное количество пакетов, больше затем 1 400 байтов в установленном сроке (скажите, что 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.

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

С наилучшими пожеланиями, David идет

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

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

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

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

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

Его справочная страница содержит инструкции по настройке его в качестве системной оболочки входа в систему. Убедитесь, что журналы находятся куда-то, что пользователь не может просто удалить их (для этого может быть полезен атрибут файловой системы только для добавления (настраиваемый через chattr). Как и списки управления доступом или сценарии 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

Я не уверен, почему удаление или переименование /usr/bin/scp не считается правильным ответом, поскольку он напрямую касается исходного вопроса.

У нас есть ограниченные серверы, которые существуют для интерактивных сеансов оболочки, но должны экспортировать файлы по утвержденным каналам, и удаление очевидных протоколов передачи имеет большое значение для достижения этой цели. В частности, клиенты Windows, использующие MobaXterm, по умолчанию получат удаленный файловый браузер с использованием SFTP, но пробуют использовать SCP в качестве запасного варианта, и не очень очевидно, что для конечного пользователя что-то отличается.

Решение, данное @Tomas, отлично работает, так как удаление/переименование /usr/bin/scp предотвращает входящую и исходящую scp передачу файлов. Однако вы также должны заблокировать все остальные порты от сервера к клиенту и от клиента к серверу. В противном случае ваши хакерские пользователи могут запустить nc -l для прослушивания на одной стороне и запустить nc для установления соединения TCP/IP и напрямую. передавать данные.

Даже при этом вам все равно необходимо отключить переадресацию X11, иначе продвинутый хакерский пользователь может создать приложение X11 и передавать данные через туннель X11.

scp нуждается в bash of sh или ограниченной версии оболочки. Ограниченные оболочки, rbash или rsh, не позволит пользователям оставить там собственный домашний реж, чтобы они могли рыться в своем содержимом тепла без вреда. Когда пользователям не нужен запрос, вы можете запустить меню из /etc/passwd в качестве их оболочки. Когда вам нужна подсказка и доступ к els, то собственный дом вы можете использовать «экран» для запуска bash. Например: экранный баш. Просто создайте скрипт и поместите скрипт в виде оболочки в /etc/passwd. Scp не может справиться с этим и не будет работать.

Таким образом, вы можете точно определить, кто может и не может использовать scp простым способом.