Вы развертываете или передаете файлы с использованием FTP? Учитывая возраст протокола и его дикую популярность среди множества хостинговых компаний, можно сказать, что вы могли бы.
Но знаете ли вы о проблемах безопасности, которые могут возникнуть для вас и вашего бизнеса? Давайте рассмотрим ситуацию более подробно.
Такие программы, как FileZilla , CyberDuck , Transmit или Captain FTP, могут быть безопасными. Они могут применять такие меры, как скрытие паролей от окружающих. Но если вы передаете данные по FTP, эти меры будут эффективно смягчены.
Я перейду к погоне; причина, по которой я пишу это из-за интересной дискуссии на SitePoint в августе. Обсуждение было сосредоточено на FileZilla, делая ряд утверждений о том, насколько небезопасно (или нет).
Ключевой аспект дискуссии касался того, стоит ли хранить пароли в FileZilla. Один из комментариев связан с довольно описательной статьей, которая показала, что, несмотря на то, что вы скрываете свои учетные данные при использовании программного обеспечения, если вы сохраняете свои учетные данные, их довольно легко получить.
Если вы не читали статью, FileZilla сохраняет данные о соединении в простом XML-файле, пример которого вы можете увидеть ниже.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<FileZilla3>
<Servers>
<Server>
<Host>localhost</Host>
<Port>21</Port>
<Protocol>0</Protocol>
<Type>0</Type>
<User>anonymous</User>
<Pass>user</Pass>
<Logontype>1</Logontype>
<TimezoneOffset>0</TimezoneOffset>
<PasvMode>MODE_DEFAULT</PasvMode>
<MaximumMultipleConnections>0</MaximumMultipleConnections>
<EncodingType>Auto</EncodingType>
<BypassProxy>0</BypassProxy>
<Name>test site</Name>
<Comments />
<LocalDir />
<RemoteDir />
<SyncBrowsing>0</SyncBrowsing>test site
</Server>
</Servers>
</FileZilla3>
Вы можете видеть, что в нем хранится много информации о соединении, поэтому вам не нужно ее запоминать. Но обратите внимание, как он хранит ваш пароль в открытом виде тоже?
Конечно, когда вы используете программу, она скрывает пароль, как показано на скриншотах выше, так что его нельзя прочитать через плечо.
Но нет особого смысла, когда вы можете просто снять его с компьютера, если у вас есть доступ. Если честно, в последней версии FileZilla хранение паролей по умолчанию запрещено.
Как насчет зашифрованных файлов конфигурации?
Люди предположили, что, по крайней мере, файлы конфигурации должны быть зашифрованы или настроены таким образом, чтобы запрашивать мастер-пароль перед предоставлением доступа, как это делают 1Password и KeePassX .
Затем Луи Лазарис связался с дискуссией об обмене стека , которая пыталась противостоять позиции. Вот суть поста:
Видите ли, для шифрования учетных данных требуется ключ шифрования, который необходимо где-то хранить. Если в вашей учетной записи пользователя запущено вредоносное ПО, у него такой же доступ к тому, что у вас (или любого другого приложения, работающего на том же уровне). Это означает, что они также будут иметь доступ к ключам шифрования или ключам, шифрующим ключи шифрования, и так далее.
Я считаю, что приведенное выше утверждение не в полной мере учитывает конструктивные соображения таких программ, как две, перечисленные выше. Приложения, специально разработанные для безопасного хранения паролей и другой защищенной информации, вероятно, не будут так легко взломать, как предполагает этот ответ.
Например, недавнее сообщение в блоге от 1Password перечисляет ряд ключевых механизмов, используемых в борьбе с взломщиками.
Они включают в себя 128- и 256-битные симметричные ключи , шифрование SHA512 и PBKDF2, а также ряд других функций, используемых для защиты файлов данных, к которым осуществляется доступ, при сохранении простоты использования и простоты их использования.
Поэтому вывод о том, что использование безопасных хранилищ шифрования на самом деле не является более безопасным, является неправильным, особенно с учетом всех этих доступных методов.
Это FTP, а не ваше приложение!
Но аргументы о том, должны ли учетные данные сохранять или не сохранять, спорны, поскольку есть ключевой момент, который в первую очередь игнорирует использование FTP — ваши учетные данные и данные отправляются в открытом виде . Не веришь мне? Прочитайте, почему FTP небезопасен , в блоге Deccanhosts.
Если вы не знали об этом, с помощью простого анализатора пакетов, такого как Wireshark , вы можете получить не только имя пользователя и пароль, но и любые другие учетные данные, хранящиеся в отправляемых файлах, а также алгоритмы, структуры базы данных, и все остальное хранится там.
Учитывая тот факт, что в течение достаточно долгого времени обычной практикой было хранить эту информацию в INI-файлах и файлах конфигурации, я бы посоветовал разработать довольно большое количество легко загружаемых программ, таких как WordPress, Joomla и т. Д. таким образом.
FTP никогда не был разработан с учетом безопасности; это было разработано как общественная служба. Этому проекту был присущи ряд дополнительных предположений, которые также не учитывали безопасность. Энрико Зимуэль , старший инженер-программист Zend , даже заявляет : никогда не используйте FTP — никогда!
Да, изменения безопасности произошли позже, но они были добавлены, а не встроены. Нет защиты от атак методом перебора, и хотя SSH-туннелирование возможно, это сложно, так как вам необходимо зашифровать как командный канал, так и канал данных. В результате ваши возможности ограничены. И когда вы пытаетесь их реализовать, фактор сложности не всегда тривиален.
Вы вебмастер? Вы включаете chroot-тюрьму для своих пользователей FTP? Если вы не знакомы с термином chroot, это способ ограничения перемещения и доступа пользователей. Из каталога, в который они входят, они могут перейти в любой подкаталог, но не могут выйти за его пределы.
Альтернативные опции для FTP
Прежде чем убедить вас, что все это мрак и мрак — это не так. Ряд современных программ FTP, особенно те, на которые ссылались ранее, также поддерживают некоторые более безопасные производные и альтернативы FTP. Давайте посмотрим на них.
FTPS и SFTP
FTPS — это безопасный FTP, так же, как HTTPS — это безопасный HTTP, и он работает через SSL (Secure Sockets Layer) и TLS (Transport Layer Security) . Учетные данные пользователя и данные больше не отправляются в открытом виде; вместо этого они зашифрованы перед передачей.
Клиентское программное обеспечение также обладает гибкостью, если это разрешено сервером, для шифрования только части сообщения, а не всей. Это может показаться нелогичным, основываясь на обсуждении до сих пор.
Но если передаваемые файлы уже зашифрованы, или если не передается информация чувствительного характера, то вполне вероятно, что не придется нести накладные расходы, необходимые для шифрования.
Тем не менее, переход на FTPS имеет свою цену (и цену). Использование FTPS включает в себя создание либо самоподписанного сертификата SSL , либо его приобретение в доверенном центре сертификации . Так что лучшая безопасность доступна, но это требует больших усилий и затрат.
Но прежде чем уклоняться, спросите себя, сколько ваша информация стоит для вашего бизнеса? Это может убедить вас сохранить.
Теперь давайте посмотрим на SFTP. SFTP, или SSH File Transfer Protocol, работает не так, как FTPS. Разработанный как расширение SSH 2.0 , SFTP создает обычное FTP-соединение, но выполняет его по уже зашифрованному соединению. Сам поток данных FTP не более безопасен, чем обычный FTP, однако соединение, по которому он работает, более безопасно.
SSH, SCP и другие логины
Если вы собираетесь отойти от FTP, зачем принимать полумеры? Зачем вообще использовать FTP? Если вы установили SFTP, вы установили инструменты SSH; они дают вам доступ к широкому спектру функций.
Начиная сверху с самого SSH, это обеспечивает полный доступ пользователей к удаленной системе, позволяя им делать больше, чем когда-либо мог бы сделать стандартный FTP. Соединение защищено, и данные могут быть легко скопированы из одной системы в другую.
Если вы немного гуру командной строки, вы даже можете использовать такой инструмент, как Rsync поверх SSH .
В простом случае его можно использовать для рекурсивного копирования всех файлов из локального каталога в каталог на удаленном компьютере. При первом запуске все файлы копируются.
Во второй и последующий раз он проверяет различия в файлах, передавая только различия, новые файлы и, при необходимости, удаляя файлы и каталоги на удаленном компьютере, которые больше не присутствуют локально.
Проблема в том, что предоставление такого доступа само по себе является проблемой безопасности, ожидающей своего появления. Но последствия могут быть смягчены. OpenSSH допускает несколько вариантов конфигурации, таких как запрещение корневого доступа, ограничение пользователей, которые могут входить удаленно, и привязка пользователей к определенным каталогам.
Возможно, пользователям не нужно быть на удаленной машине, или им не нужно много привилегий, пока они там. Если это так, и, вероятно, так и есть, вы можете выбрать из нескольких оболочек, предназначенных для таких ситуаций.
Два из лучших — это scponly и rssh . Scponly позволяет только пользователю копировать файлы на удаленный компьютер.
Пользователь не может войти, перемещаться, просматривать или изменять файлы. Что замечательно, так это то, что он все еще работает с rsync (и другими инструментами). rssh идет немного дальше, предоставляя доступ к SCP, SFTP, rdist, rsync и CVS.
Чтобы реализовать это, системному администратору нужно всего лишь изменить оболочку пользователя с выбранным им инструментом, а затем отредактировать /etc/rssh.conf
Вот пример конфигурации:
allowscp
allowsftp
Эта конфигурация позволяет пользователям использовать только SCP и SFTP.
SSH ключи
Далее давайте рассмотрим ключи SSH . Процесс требует небольшого объяснения, но я постараюсь сделать его быстрым и кратким, перефразируя этот ответ на Stack Exchange :
Во-первых, открытый ключ сервера используется для создания безопасного канала SSH, позволяя согласовать симметричный ключ, который будет использоваться для защиты оставшегося сеанса, обеспечения конфиденциальности канала, защиты целостности и аутентификации сервера. После того, как канал функционирует и защищен, происходит аутентификация пользователя.
Затем сервер создает случайное значение, шифрует его с помощью открытого ключа пользователя и отправляет его им. Если пользователь является тем, кем он должен быть, он может расшифровать запрос и отправить его обратно на сервер, который затем подтверждает личность пользователя. Это классическая модель «вызов-ответ».
Ключевым преимуществом этого является то, что закрытый ключ никогда не покидает клиента, и никакие имя пользователя или пароль никогда не отправляются. Если кто-то перехватывает трафик SSL и может расшифровать его (используя скомпрометированный закрытый ключ сервера или если вы примете неверный открытый ключ при подключении к серверу) — ваши личные данные никогда не попадут в руки злоумышленника.
При использовании с SCP или SFTP это дополнительно уменьшает усилия, необходимые для их использования, одновременно повышая безопасность. Для ключей SSH может потребоваться фраза-пароль для разблокировки закрытого ключа, что может затруднить их использование.
Но есть инструменты, которые могут связать это с вашим пользовательским сеансом, когда вы входите в систему на своем компьютере. При правильной настройке парольная фраза автоматически предоставляется вам, так что вы в полной мере можете воспользоваться системой.
Как насчет непрерывной доставки?
Возможно, вы не слышали этот термин раньше, но он плавает в течение некоторого времени. Мы писали об этом в SitePoint раньше, совсем недавно, на прошлой неделе . Непрерывная доставка, созданная Мартином Фаулером, определяется как :
Дисциплина разработки программного обеспечения, при которой вы создаете программное обеспечение таким образом, что программное обеспечение может быть выпущено в производство в любое время.
Есть много способов реализовать это, но такие сервисы, как Codeship и Beanstalk, помогают избавиться от боли.
Вот грубая аналогия того, как они работают. Вы настраиваете свой программный проект, включая код тестирования и сценарии развертывания, и сохраняете все это под контролем версий. Я предполагаю, что вы используете онлайн-сервис, такой как GitHub или Bitbucket.
Когда выполняется принудительная отправка для любой из этих служб, после того, как в вашей ветке кода сделан коммит или релиз, служба запускает тесты вашего приложения. Если тесты пройдены, то выполняется развертывание вашего приложения, будь то для тестирования или производства.
Предполагая, что все прошло хорошо, он автоматически позаботится о развертывании для вас. После этого вы будете уведомлены о том, что развертывание прошло успешно или не удалось.
Если это удалось, вы можете продолжить со следующей функцией или исправлением ошибки. Если что-то пошло не так, вы можете проверить это, чтобы найти причину проблемы. Посмотрите короткое видео ниже, демонстрирующее развертывание тестового репозитория в действии с Codeship.
Что ты должен был сделать? Вставить коммит в репозиторий Github — вот и все! Вам не нужно помнить, чтобы запускать сценарии, где они находятся, какие опции и переключатели передавать им (особенно не поздно вечером в пятницу, когда вы предпочитаете быть где угодно, но не работаете).
Я ценю, что это довольно упрощенно и не охватывает все варианты и нюансы, но вы поняли идею.
Проблема человеческой ошибки
Давайте закончим, перейдя от основных проблем безопасности использования FTP к эффективности повседневной работы. Допустим, например, что вы разрабатываете веб-сайт, скажем, интернет-магазин, и в процессе развертывания используется FTP, в частности FileZilla.
Здесь есть ряд проблем, связанных с человеческими ошибками:
- Будут ли все файлы загружены в нужные места?
- Сохранят ли файлы или получат необходимые разрешения?
- Один или два файла будут забыты?
- Есть ли название разработки, которое нужно изменить в производстве?
- Существуют ли сценарии после развертывания, которые необходимо запустить?
Все это действительные проблемы, но все они легко смягчаются при использовании инструментов непрерывной доставки. Если уже поздно, если есть давление, если вовлеченное лицо либо уходит из компании, либо хочет уехать в отпуск, ручная передача файлов по FTP вызывает проблемы.
Хорошо, передача файлов вручную, точка, напрашивается на неприятности. Человеческую ошибку слишком сложно устранить.
Быстрое извинение перед FileZilla
Я не хочу казаться, что я выбираю FileZilla. Это действительно хорошее приложение, которое я использовал на протяжении многих лет. И были методы, используемые, чтобы попытаться сделать его более безопасным .
Ключевой момент, который я имею, касается самого FTP, не обязательно только с FileZilla.
Завершение
Так что это был мой взгляд на дебаты безопасности FTP. Моя рекомендация — просто не используйте ее; Более того, при управлении развертыванием помните о безопасности. В конце концов, это ваши данные.
Но что ты думаешь? Вы все еще используете FTP? Вы планируете уехать? Поделитесь своим опытом в комментариях и какими решениями вы опробовали, чтобы мы все могли найти практичное и простое в использовании решение.