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

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

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

Короткий ответ таков: если ЛЮБОЙ имеет доступ и права доступа к конечной точке (системе, из которой вы работаете scpили откуда scp), он может видеть, что происходит. Если они не имеют доступа ни к одной из конечных точек, они, скорее всего, не будут иметь доступа или не смогут расшифровать то, что вы делаете (кроме потенциального знания приложения по номерам протоколов).

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

Как упомянул @SimonRichter : если кто-то может выполнить команду в вашей системе (например, admin или другие), он может проверить ваш список процессов и увидеть командную строку scp -args /filepath/. Однако для этого требуется, чтобы они либо регистрировали всю активность процесса, либо проверяли ее во время передачи. Кроме того, если вы делаете это из своей собственной системы на работе в другую систему (скажем, дома или в другом месте), они не обязательно будут иметь такую ​​видимость.

Кроме того, как упомянул @ alex.forencich: можно также регистрировать все системные вызовы (включая вызовы открытия и чтения файлов), поэтому даже если ваша копирующая программа (scp, sftp и т. Д.) Ничего не регистрирует и не пропускает (аргументы командной строки ), все еще можно выяснить, какие файлы были прочитаны или записаны. Смотрите систему аудита Linux. -

Не только админ.

Для тестирования я просто скопировал /binсо своего сервера во временный каталог на своем ноутбуке. psна сервере показывает

$ ps 24096
  PID TTY      STAT   TIME COMMAND
24096 ?        Ss     0:00 scp -r -f /bin

Эта информация общедоступна для всех пользователей.

scpработает с помощью кода, работающего на сервере ( sshdи scpсам по себе). Этот код сервера теоретически полностью контролируется администратором сервера, и версия scpзапуска на сервере для записи файла для подключения к вам отличается от версии scpзапуска на вашем компьютере для выдачи запроса.

Администратор сервера может, для примера, заменить scpна сервере версию, которая регистрирует все запросы, подобно тому, как веб-сервер может записывать журналы. Тогда они могли видеть из этих журналов именно то, что вы скопировали.

Имеют ли они опыт и мотивацию на самом деле сделать это, менее определенно, но если они хотят, то в принципе ничто их не остановит.

Я думаю, что эти вопросы являются вашими компаньонами: /security/14782/is-there-an-easy-way-to-see-a-log-of-scp-activity-on-a -server-ala-var-log-secu , /ubuntu/659896/where-would-you-find-scp-logs

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

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

Имена запущенных процессов и командная строка, используемая для их запуска, доступны любому вошедшему в систему пользователю в Linux. (Это не относится к Windows, для любопытных.) Поэтому администратор или кто-либо еще, кто оказывается рядом, мог видеть, какие файлы вы скопировали. Кроме того, администратор может полностью настроить регистрацию доступа к файлам или заменить scpпрограмму на одном конце, чтобы выполнить дополнительную регистрацию.

scpпросто защищает вас от сетевых снифферов. Очевидно, что оба конца должны знать дешифрованные данные, поэтому у опытного администратора на любой из конечных точек есть возможность высосать данные из scpпамяти. Другие решения, даже те, в которых не используются командные строки, также открыты для этого: оба конца sftpзнают, что происходит, поэтому с помощью проверки памяти можно определить, что sftpдумает / переносит.

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

во время действия scpоткрывается процесс на удаленной стороне, который может быть просмотрен любым человеком, просто вызвав его ps. Если вам удастся скрыть командную строку, отображаемую в списке процессов, то lsof(список открытых файлов) может показать, какие файлы были затронуты. Это так просто, я на самом деле делаю это, чтобы увидеть, насколько далеко зашёл какой-то процесс копирования, если я запустил процесс на терминале, который я не могу просмотреть в данный момент (где выводится список файлов).

после действия быстрое сканирование findможет найти самые новые файлы (если временные метки не были сохранены во время копирования). Если к файлам обращались или касались каким-либо образом через sshсеанс, вы .bash_historyпоказываете, что вы делали (но вы можете удалить это, если хотите).

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

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