Наш хостинг-провайдер поддерживает только использование FTP, а не sFTP. Насколько это безопасно?

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

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

Что мне делать? Следовать указаниям и использовать FTP или выбрать другой подход?

FTP – один из самых ранних интернет-протоколов. RFC 765, который впервые определил его, появился в 1980 году, более чем за десятилетие до HTTP, который поддерживает всемирную паутину.

С тех пор он значительно эволюционировал, чтобы адаптироваться к меняющемуся интернету. Как HTTPS был введен для добавления шифрования и аутентификации в HTTP через SSL/TLS, то же было сделано для FTP с FTPS (RFC 4217 из 2005 года).

Как и SMTP (передача почты), POP3, IMAP (доступ к почтовому ящику) и многие другие протоколы, TLS также может запрашиваться в-band (также называемое Opportunistic TLS или STARTTLS, даже если команда в протоколе FTP AUTH TLS вместо STARTTLS) в протоколе FTP.

Таким образом, шифрование возможно в FTP и может быть настолько же безопасным, как и другие зашифрованные протоколы.

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

Эти отдельные соединения несколько усложняют шифрование, поскольку необходимо обмениваться ключевым материалом между ними, поэтому это сложнее правильно реализовать, и известны некоторые FTP-клиенты, которые этого не делают. Также возможно отправить команды (включая имя пользователя и пароль) зашифрованными, в то время как данные передаются в открытом виде, поэтому важно настроить FTP-клиент так, чтобы он требовал шифрования как для соединения команд (либо явно с FTPS на TCP порту 990 по умолчанию, либо с оппортунистическим шифрованием, с AUTH TLS на обычном FTP-соединении (порт 21 по умолчанию)), так и для данных соединений (списки каталогов также извлекаются через соединения данных).

Некоторые FTP-клиенты также известны тем, что не проверяют сертификаты сервера должным образом, что может значительно снизить конфиденциальность передачи, так как позволяет MiTM перехватывать трафик.

В общем, FTP может быть безопасным, но

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

С командным клиентом lftp, например, обратите внимание на эти параметры конфигурации:

• ssl:verify-certificate (логический)
  если установлено в yes, то проверьте, что сертификат сервера подписан известным центром сертификации и не находится в списке отозванных сертификатов. Вы можете указать либо имя хоста, либо отпечаток сертификата в закрытии.

• ftp:ssl-force (логический)
  если true, откажитесь отправлять пароль в явном виде, когда сервер не поддерживает SSL. По умолчанию false.

• ftp:ssl-protect-data (логический)
  если true, запросите SSL-соединение для передачи данных. Это обеспечивает конфиденциальность и исправление ошибок передачи. Было ресурсоемким на старых процессорах. По умолчанию true.

• ftp:ssl-protect-list (логический)
  если true, запросите SSL-соединение для передачи файловых списков. По умолчанию true.

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

Не обязательно, нужно еще иметь доступ к любой части канала от клиента до сервера, чтобы можно было перехватить этот трафик и получить доступ к паролю FTP пользователя, так что если только вы не подключены к сомнительной wifi-сети, это должно в основном ограничиваться операторами сетей и правительствами или государственными хакерами. Утечка этого пароля обычно не приведет к компрометации вашей системы. Однако MiTM может заставить вас скачать вредоносное ПО вместо файлов, которые вы должны скачать. То же самое может произойти с HTTPS, если вы игнорировали предупреждения о сертификатах, или с SFTP, если вы не проверили SSH-ключ хоста.

Использование FTP для передачи файлов, особенно таких конфиденциальных данных, как административные учетные данные, обычно не считается безопасным!

Я бы исследовал, есть ли альтернативы, такие как SSH/SSHFS, WebDAV, Samba, или загрузка непосредственно через CMS/management систему через браузер, если эти опции доступны, или, возможно, вы могли бы создать форму загрузки с использованием PHP при возможности, которая бы затем выгодно использовала защиту SSL/https, но не с чистым FTP.

Что ж, ваши учетные данные, отправленные по электронной почте, следует считать скомпрометированными. Измените пароль немедленно.

Если вы используете учетные данные для FTP, они тоже скомпрометированы. Убедитесь, что это все, к чему у них есть доступ, и что сервер усилен. Например, если можете, создайте второй набор учетных данных только для использования FTP … и, возможно, отключите/удалите его сразу после.

Идеально, используйте что-то зашифрованное и с сильной аутентификацией, например, ssh (и sftp и scp) с публичными/приватными ключами, или rsync через ssh для передачи файлов. Если это невозможно, используйте что-то с шифрованием и паролями, как указал @ReflectYourCharacter.

Я бы обратил внимание, что если что-то пойдет не так, серверная сторона будет скомпрометирована, а не ваша система. Поэтому вы можете захотеть безопасно зашифровать любые конфиденциальные данные, которые вы туда размещаете. Рассмотрите PGP/OpenPGP/GnuPG. Если вы хотите, чтобы они были полностью читаемы другими, используйте криптографические опции подписи и выясните, как безопасно распространить ваш публичный ключ.

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

“Что мне делать?” – это очень субъективный вопрос, на который по правде говоря, можете ответить только вы сами. Однако, если бы я был на вашем месте и мне бы предложили такое, как описываете вы, я бы немедленно перевел все свои дела в другое место.

“Хостинг” компания, которая использует только FTP для передачи файлов, подобна банку, который использует только HTTP для своего веб-сайта вместо HTTPS, и, на мой взгляд, ее следует воспринимать с такой же долей презрения.

Согласно ftp протоколу, ВСЕ данные должны передаваться в открытом виде (незашифрованно), ваш FTP идентификатор и пароль (который не должен использоваться в других местах) и все данные, которые вы обмениваете.

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

Логин идентификатор И пароль в одном E-mail? Измените пароль НЕМЕДЛЕННО.

Этот “хостинг-провайдер” кажется застрял в отношении компьютерной безопасности интернет-девственников 1978 года. BTDT. Небезопасно! Бегите прочь!