GEK / Перечень вопросов 2014_ВКСС
.pdfможно настраивать, поэтому можно построить сеть Token Ring с большим количеством станций и с большей длиной кольца.
Технология FDDI
Технология FDDI (Fiber Distributed Data Interface)- оптоволоконный интерфейс распределенных данных - это первая технология локальных сетей, в которой средой передачи данных является волоконно-оптический кабель. Работы по созданию технологий и устройств для использования волоконно-оптических каналов в локальных сетях начались в 80-е годы, вскоре после начала промышленной эксплуатации подобных каналов в территориальных сетях. Проблемная группа ХЗТ9.5 института ANSI разработала в период с 1986 по 1988 гг. начальные версии стандарта FDDI, который обеспечивает передачу кадров со скоростью 100 Мбит/с по двойному волоконнооптическому кольцу длиной до 100 км.
Основные характеристики технологии
Технология FDDI во многом основывается на технологии Token Ring, развивая и совершенствуя ее основные идеи. Разработчики технологии FDDI ставили перед собой в качестве наиболее приоритетных следующие цели:
повысить битовую скорость передачи данных до 100 Мбит/с;
повысить отказоустойчивость сети за счет стандартных процедур восстановления ее после отказов различного рода - повреждения кабеля, некорректной работы узла, концентратора, возникновения высокого уровня помех на линии и т. п.;
максимально эффективно использовать потенциальную пропускную способность сети как для асинхронного, так и для синхронного (чувствительного к задержкам) трафиков.
Сеть FDDI строится на основе двух оптоволоконных колец, которые образуют основной и резервный пути передачи данных между узлами сети. Наличие двух колец - это основной способ повышения отказоустойчивости в сети FDDI, и узлы, которые хотят воспользоваться этим повышенным потенциалом надежности, должны быть подключены к обоим кольцам.
Внормальном режиме работы сети данные проходят через все узлы и все участки кабеля только первичного (Primary) кольца, этот режим назван режимом Thru - «сквозным» или «транзитным». Вторичное кольцо (Secondary) в этом режиме не используется.
Вслучае какого-либо вида отказа, когда часть первичного кольца не может передавать данные (например, обрыв кабеля или отказ узла), первичное кольцо объединяется со вторичным (рис. 2.42), вновь образуя единое кольцо. Этот режим работы сети называется Wrap, то есть «свертывание» или «сворачивание» колец. Операция свертывания производится средствами концентраторов и/или сетевых адаптеров FDDI. Для упрощения этой процедуры данные по первичному кольцу всегда передаются в одном направлении (на диаграммах это направление изображается против часовой стрелки), а по вторичному - в обратном (изображается по часовой стрелке). Поэтому при образовании общего кольца из двух колец передатчики станций по-прежнему остаются подключенными к приемникам соседних станций, что позволяет правильно передавать и принимать информацию соседними станциями.
Рис. 2.42 Реконфигурация колец FDDI при отказе
В стандартах FDDI много внимания отводится различным процедурам, которые позволяют определить наличие отказа в сети, а затем произвести необходимую реконфигурацию. Сеть FDDI может полностью восстанавливать свою работоспособность в случае единичных отказов ее элементов. При множественных отказах сеть распадается на несколько не связанных сетей. Технология FDDI дополняет механизмы обнаружения отказов технологии Token Ring механизмами реконфигурации пути передачи данных в сети, основанными на наличии резервных связей, обеспечиваемых вторым кольцом.
Кольца в сетях FDDI рассматриваются как общая разделяемая среда передачи данных, поэтому для нее определен специальный метод доступа. Этот метод очень близок к методу доступа сетей Token Ring и также называется методом маркерного кольца - token ring.
Отличия метода доступа заключаются в том, что время удержания маркера в сети FDDI не является постоянной величиной, как в сети Token Ring. Это время зависит от загрузки кольца - при небольшой загрузке оно увеличивается, а при больших перегрузках может уменьшаться до нуля. Эти изменения в методе доступа касаются только асинхронного трафика, который не критичен к небольшим задержкам передачи кадров. Для синхронного трафика время удержания маркера попрежнему остается фиксированной величиной. Механизм приоритетов кадров, аналогичный принятому в технологии Token Ring, в технологии FDDI отсутствует. Разработчики технологии решили, что деление трафика на 8 уровней приоритетов избыточно и достаточно разделить трафик на два класса - асинхронный и синхронный, последний из которых обслуживается всегда, даже при перегрузках кольца.
В остальном пересылка кадров между станциями кольца на уровне MAC полностью соответствует технологии Token Ring. Станции FDDI применяют алгоритм раннего освобождения маркера, как и сети Token Ring со скоростью 16 Мбит/с.
Адреса уровня MAC имеют стандартный для технологий IEEE 802 формат. Формат кадра FDDI близок к формату кадра Token Ring, основные отличия заключаются в отсутствии полей приоритетов. Признаки распознавания адреса, копирования кадра и ошибки позволяют сохранить имеющиеся в сетях Token Ring процедуры обработки кадров станцией-отправителем, промежуточными станциями и станцией-получателем.
Особенности метода доступа FDDI
Для передачи синхронных кадров станция всегда имеет право захватить маркер при его поступлении. При этом время удержания маркера имеет заранее заданную фиксированную величину.
Если же станции кольца FDDI нужно передать асинхронный кадр (тип кадра определяется протоколами верхних уровней), то для выяснения возможности захвата маркера при его очередном поступлении станция должна измерить интервал времени, который прошел с момента предыдущего прихода маркера. Этот интервал называется временем оборота маркера (Token Rotation Time, TRT). Интервал TRT сравнивается с другой величиной - максимально допустимым временем оборота маркера по кольцу Т_0рг. Если в технологии Token Ring максимально допустимое время оборота маркера является фиксированной величиной (2,6 с из расчета 260 станций в кольце), то в технологии FDDI станции договариваются о величине Т_0рг во время инициализации кольца. Каждая станция может предложить свое значение Т_0рг, в результате для кольца устанавливается минимальное из предложенных станциями времен. Это позволяет учитывать потребности приложений, работающих на станциях. Обычно синхронным приложениям (приложениям реального времени) нужно чаще передавать данные в сеть небольшими порциями, а асинхронным приложениям лучше получать доступ к сети реже, но большими порциями. Предпочтение отдается станциям, передающим синхронный трафик.
Таким образом, при очередном поступлении маркера для передачи асинхронного кадра сравнивается фактическое время оборота маркера TRT с максимально возможным Т_0рг. Если кольцо не перегружено, то маркер приходит раньше, чем истекает интервал Т_0рг, то есть TRT < Т_0рг. В этом случае станции разрешается захватить маркер и передать свой кадр (или кадры) в кольцо. Время удержания маркера ТНТ равно разности T_0pr - TRT, и в течение этого времени станция передает в кольцо столько асинхронных кадров, сколько успеет.
Если же кольцо перегружено и маркер опоздал, то интервал TRT будет больше Т_0рг. В этом случае станция не имеет права захватить маркер для асинхронного кадра. Если все станции в сети хотят передавать только асинхронные кадры, а маркер сделал оборот по кольцу слишком медленно, то все станции пропускают маркер в режиме повторения, маркер быстро делает очередной оборот и на следующем цикле работы станции уже имеют право захватить маркер и передать свои кадры.
Метод доступа FDDI для асинхронного трафика является адаптивным и хорошо регулирует временные перегрузки сети.
Физический уровень технологии FDDI
В технологии FDDI для передачи световых сигналов по оптическим волокнам реализовано логическое кодирование 4В/5В в сочетании с физическим кодированием NRZI. Эта схема приводит к передаче по линии связи сигналов с тактовой частотой 125 МГц.
Так как из 32 комбинаций 5-битных символов для кодирования исходных 4-битных символов нужно только 16 комбинаций, то из оставшихся 16 выбрано несколько кодов, которые используются как служебные. К наиболее важным служебным символам относится символ Idle - простой, который постоянно передается между портами в течение пауз между передачей кадров данных. За счет этого станции и концентраторы сети FDDI имеют постоянную информацию о состоянии физических соединений своих портов. В случае отсутствия потока символов Idle фиксируется отказ физической связи и производится реконфигурация внутреннего пути концентратора или станции, если это возможно.
При первоначальном соединении кабелем двух узлов их порты сначала выполняют процедуру установления физического соединения. В этой процедуре используются последовательности служебных символов кода 4В/5В, с помощью которых создается некоторый язык команд физического уровня. Эти команды позволяют портам выяснить друг у друга типы портов (А, В, М или S) и решить, корректно ли данное соединение (например, соединение S-S является некорректным и т. п.). Если соединение корректно, то далее выполняется тест качества канала при передаче символов кодов 4В/5В, а затем проверяется работоспособность уровня MAC соединенных устройств путем передачи нескольких кадров MAC. Если все тесты прошли успешно, то физическое
соединение считается установленным. Работу по установлению физического соединения контролирует протокол управления станцией SMT.
Физический уровень разделен на два подуровня: независимый от среды подуровень PHY (Physical) и зависящий от среды подуровень PMD (Physical Media Dependent).
Технология FDDI в настоящее время поддерживает два подуровня PMD: для волоконнооптического кабеля и для неэкранированной витой пары категории 5. Последний стандарт появился позже оптического и носит название TP-PMD.
Оптоволоконный подуровень PMD обеспечивает необходимые средства для передачи данных от одной станции к другой по оптическому волокну. Его спецификация определяет:
использование в качестве основной физической среды многомодового волоконнооптического кабеля 62,5/125 мкм;
требования к мощности оптических сигналов и максимальному затуханию между узлами сети. Для стандартного многомодового кабеля эти требования приводят к предельному расстоянию между узлами в 2 км, а для одномодового кабеля расстояние увеличивается до 10-40 км в зависимости от качества кабеля;
требования к оптическим обходным переключателям (optical bypass switches) и оптическим приемопередатчикам;
параметры оптических разъемов MIC (Media Interface Connector), их маркировку;
использование для передачи света с длиной волны в 1300 нм;
представление сигналов в оптических волокнах в соответствии с методом NRZI. Подуровень TP-PMD определяет возможность передачи данных между станциями по витой
паре в соответствии с методом физического кодирования MLT-3, использующего два уровня потенциала: +V и -V для представления данных в кабеле. Для получения равномерного по мощности спектра сигнала данные перед физическим кодированием проходят через скрэмблер. Максимальное расстояние между узлами в соответствии со стандартом TP-PMD равно 100 м.
Максимальная общая длина кольца FDDI составляет 100 километров, максимальное число станций с двойным подключением в кольце - 500.
11. DHCP. Распознавание имен в сетях на базе Windows NT.
11. Протокол динамической конфигурации хостов (DHCP).
Управление информацией об IP адресах - это очень сложная задача, стоящая перед сетевым администратором распределенной сети. Эта задача еще больше усложняется тем, что большинство пользователей не обладают знаниями, необходимыми для конфигурирования своих компьютеров для осуществления межсетевых коммуникаций.
Протокол Dynamic Host Configuration Protocol (DHCP) был разработан специально для облегчения задачи администратора по конфигурированию локальных компьютеров для пользователей. DHCP обеспечивает надежный гарантированный и простой способ конфигурирования TCP/IP сетей, исключающий возможность появления конфликтов в использовании IP адресов. Это достигается централизацией управления адресами и динамическим их конфигурированием. Системный администратор управляет методом присвоения IP адресов, указывая продолжительность их выделения, которая определяет интервал времени, в течении которого, компьютер может использовать выделенный ему IP адрес, по истечении которого сервер DHCP должен будет обновить этот адрес. IP адрес клиентского компьютера автоматически освобождается сервером DHCP, когда этот компьютер удаляется из подсети, А когда этот компьютер подключается к другому сегменту сети, то ему присваивается новый адрес. При этом ни пользователь, ни администратор сети не имеет права вмешиваться в этот процесс определения новой конфигурации сети.Эта возможность крайне важна для пользователей ноутбуков и других мобильных устройств.
Рисунок 1 иллюстрирует пример сервиса сервера DHCP обеспечивающего конфигурированием две подсети. Если, например, клиент перемещается с одной подсети в другую, то сервер DHCP автоматически будет предоставлять ему новую конфигурационную информацию о TCP/IP (после его перезагрузки).
Рисунок 1 Диаграмма состояний клиента DHCP
Клиенты и серверы DHCP в маршрутизируемой сети.
Для работы DHCP использует модель клиент сервер и работает по принципу выделения IP адресов во временное пользование. Во время инициализации системы, клиентский компьютер DHCP отправляет широковещательную разведывательную посылку по локальной сети, которая может быть принята всеми серверами DHCP в локальной сети. Каждый сервер DHCP который принимает эту посылку в свою очередь отправляет свою посылку с IP адресом и правильной конфигурацией сети для клиента отправившего запрос.
DHCP клиент принимает сообщения от всех серверов и переходит в состояние выбора предложения. Затем клиент переходит в состояние запроса и выбирает одну из предложенных конфигураций и отправляет посылку -запрос для идентификации сервера и выбранной конфигурации.
После этого выбранный DHCP сервер посылает DHCP подтверждение содержащие первичный адрес, время жизни этого адреса и конфигурационные параметры TCP/IP для клиента. После приема клиентом этого подтверждения клиент переходит в состояние привязки, после которого он становится членом сети и может закончить загрузку и стартовать. На клиентском компьютере может быть сохранен адрес для дальнейшего использования в дальнейшем. Если срок действия адреса заканчивается, то клиент пытается обновить выделение адреса через сервер DHCP, и если действие этого адреса не может быть продлено, то клиенту присваивается новый адрес.
Распознавание имен в сетях на базе Windows NT.
Конфигурирование Windows NT с TCP/IP требует задания уникальных идентификаторов - IP адреса и компьютерного имени для компьютера в сети. IP Адрес, как указано раньше в этой главе, - однозначный адрес, по которому все другие TCP/IP устройства в объединенной сети распознают этот компьютер. Для TCP/IP и Internet, компьютерное имя - глобально известный системный идентификатор плюс DNS доменное имя. (В локальной сети, компьютерное имя - имя NetBIOS, которое задано в течение Установки Windows NT.)
Компьютеры используют IP адреса, чтобы идентифицировать друг друга в сети IP, но пользователи обычно считают, что легче работать с компьютерными именами. Механизм должен быть определен в TCP/IP сети так, чтобы разрешить имена в IP адресах. Для того, чтобы гарантировать, что и адрес, и имя компьютера уникальные, Windows NT использует TCP/IP регистры для его имени и IP адрес в сети в течение системного запуска. Компьютер Windows NT может использовать один или более следующих методов, чтобы гарантировать точное решение имени в TCP/IP объединенной сети:
Windows Internet Name Service. Windows NT может использовать WINS если один или более WINS
серверов - доступен, чтобы поддерживать динамическую базу данных, отображающую имена компьютеров на IP адреса. WINS может использоваться вместе с разрешением широковещательного имени для объединенной сети где другие методы решения имени - неадекватны. Как указано в следующем разделе, WINS использует NetBIOS поверх TCP/IP режима работы, и определен в RFC 1001/1002 как p узел.
Broadcast name resolution. Компьютеры Windows NT могут использовать так же и широковещательное распознавание имен, как режим работы NetBIOS поверх TCP/IP, определенный в RFC 1001/1002 как режим b-узла. Этот метод основан на том, компьютер посылает широковещательные сообщения IPупровня и регистрирует свое имя, объявляя его по сети. Каждый компьютер в области широковещания отвечает за конкурирующие попытки зарегистрировать дублирующее имя и за ответы на запросы поступающие на его собственное зарегистрированное имя.
Система Domain Name System (DNS) обеспечивает способ просмотра таблиц соответствия имен при установлении соединения компьютера с внешними хостами при использовании NetBIOS поверх TCP/IP или приложений Windows Sockets таких как FTP. DNS является распределенной базой данных, разработанную для решения проблем с трафиком, из-за резкого роста размеров сети Internet в начале 1980-х годов.
Файл LMHOSTS идентифицирующий таблицу соответствия имен NetBIOS имени компьютера и IP адреса, или HOSTS файл для указания имен DNS и IP адресов.
На локальном компьютере файл HOSTS (используемый приложениями Windows Sockets для поиска TCP/IP хост имен) и файл LMHOSTS (используемый NetBIOS поверх TCP/IP для поиска имен компьютеров в сетях Microsoft) могут быть использованы для перечисления известных IP адресов, связанных со своими компьютерными именами. Файл LMHOSTS используется главным образом для распознавания имен в небольших сетях или удаленных подсетях где недоступен сервис WINS.
15. Протокол пересылки файлов FTP.
FTP (англ. File Transfer Protocol — протокол передачи файлов) — стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет). FTP часто используется для загрузки сетевых страниц и других документов с частного устройства разработки на открытые сервера хостинга.
Протокол построен на архитектуре "клиент-сервер" и использует разные сетевые соединения для передачи команд и данных между клиентом и сервером. Пользователи FTP могут пройти аутентификацию, передавая логин и пароль открытым текстом, или же, если это разрешено на сервере, они могут подключиться анонимно. Можно использовать протокол SSH для безопасной передачи, скрывающей (шифрующей) логин и пароль, а также шифрующей содержимое.
Достаточно яркая особенность протокола FTP в том, что он использует множественное (как минимум - двойное) подключение. При этом один канал является управляющим, через который поступают команды серверу и возвращаются его ответы (обычно через TCP-порт 21), а через остальные происходит собственно передача данных, по одному каналу на каждую передачу. Поэтому в рамках одной сессии по протоколу FTP можно передавать одновременно несколько файлов, причём в обоих направлениях. Для каждого канала данных открывается свой TCP порт, номер которого выбирается либо сервером, либо клиентом, в зависимости от режима передачи.[2]
Протокол FTP имеет двоичный режим передачи, что сокращает накладные расходы трафика и уменьшает время обмена данными при передаче больших файлов. Протокол же HTTP обязательно требует кодирования двоичной информации в текстовую форму, например при помощи алгоритма Base64.
Начиная работу через протокол FTP, клиент входит в сессию, и все операции проводятся в рамках этой сессии (проще говоря, сервер помнит текущее состояние). Протокол HTTP ничего не "помнит" - его задача - отдать данные и забыть, поэтому запоминание состояния при использовании HTTP осуществляется внешними по отношению к протоколу методами.
FTP работает на прикладном уровне модели OSI и используется для передачи файлов с помощью TCP/IP. Для этого должен быть запущен FTP-сервер, ожидающий входящих запросов. Компьютер-клиент может связаться с сервером по порту 21. Это соединение (поток управления) остаётся открытым на время сессии. Второе соединение (поток данных), может быть открыт как сервером из порта 20 к порту соответствующего клиента (активный режим), или же клиентом из любого порта к порту соответствующего сервера (пассивный режим), что необходимо для передачи файла данных. Поток управления используется для работы с сессией - например, обмен между клиентом и сервером командами и паролями с помощью telnet-подобного протокола. Например, "RETR имя файла" передаст указанный файл от сервера клиенту. Вследствие этой двухпортовой структуры, FTP считается внешнеполосным протоколом, в отличие от внутриполосного HTTP.
Соединение и передача данных
Протокол определен в RFC 959. Сервер отвечает по потоку управления трехзначными ASCII-кодами состояния с необязательным текстовым сообщением. Например, "200" (или "200 ОК") означает, что последняя команда была успешно выполнена. Цифры представляют код ответа, а текст - разъяснение или запрос. Текущая
передача по потоку данных может быть прервана с помощью прерывающего сообщения, посылаемого по потоку управления.
FTP может работать в активном или пассивном режиме, от выбора которого зависит способ установки соединения. В активном режиме клиент создаёт управляющее TCP-соединение с сервером и отправляет серверу свой IP-адрес и произвольный номер клиентского порта, после чего ждёт, пока сервер не запустит TCPсоединение с этим адресом и номером порта. В случае, если клиент находится за брандмауэром и не может принять входящее TCP-соединение, может быть использован пассивный режим. В этом режиме клиент использует поток управления, чтобы послать серверу команду PASV, и затем получает от сервера его IP-адрес и номер порта, которые затем используются клиентом для открытия потока данных с произвольного клиентского порта к полученному адресу и порту. Оба режима были обновлены в сентябре 1998 г. для поддержки IPv6. В это время были проведены дальнейшие изменения пассивного режима, обновившие его до расширенного пассивного режима.
При передаче данных по сети могут быть использованы четыре представления данных:
1)ASCII - используется для текста. Данные, если необходимо, до передачи конвертируются из символьного представления на хосте-отправителе в "восьмибитный ASCII", и (опять же, если необходимо) в символьное представление принимающего хоста. Как следствие, этот режим не подходит для файлов, содержащих не только обычный текст.
2)Режим изображения (обычно именуемый бинарным) - устройство-отправитель посылает каждый файл байт за байтом, а получатель сохраняет поток байтов при получении. Поддержка данного режима была рекомендована для всех реализаций FTP.
3)EBCDIC - используется для передачи обычного текста между хостами в кодировке EBCDIC. В остальном, этот режим аналогичен ASCII-режиму.
4)Локальный режим - позволяет двум компьютерам с идентичными установками посылать данные в собственном формате без конвертации в ASCII.
Для текстовых файлов предоставлены различные форматы управления и настройки структуры записи. Эти особенности были разработаны для работы с файлами, содержащими Telnet или ASA-форматирование.
Передача данных может осуществляться в любом из трёх режимов:
1)Поточный режим - данные посылаются в виде непрерывного потока, освобождая FTP от выполнения какой бы то ни было обработки. Вместо этого, вся обработка выполняется TCP. Индикатор конца файла не нужен, за исключением разделения данных на записи.
2)Блочный режим - FTP разбивает данные на несколько блоков (блок заголовка, количество байт, поле данных) и затем передаёт их TCP.
3)Режим сжатия - данные сжимаются единым алгоритмом (обыкновенно, кодированием длин серий).
Аутентификация
FTP-аутентификация использует обычную схему имя пользователя/пароль для предоставления доступа. Имя пользователя посылается серверу командой USER, а пароль - командой PASS. Если предоставленная клиентом информация принята сервером, то сервер отправит клиенту приглашение и начинается сессия. Пользователи могут, если сервер поддерживает эту особенность, войти в систему без предоставления учётных данных, но сервер может предоставить только ограниченный доступ для таких сессий.
Анонимный FTP
Хост, обеспечивающий FTP-сервис, может предоставить анонимный доступ к FTP. Пользователи обычно входят в систему как "anonymous" в качестве имени пользователя. Хотя обычно пользователей просят прислать адрес их электронной почты вместо пароля, никакой проверки фактически не производится. Многие FTP-хосты, предоставляющие обновления программного обеспечения, поддерживают анонимный доступ.
NAT-PT
Специально для работы FTP-протокола через межсетевые экраны было сделано расширение NAT, называемое NAT-PT (rfc2766), позволяющее транслировать входящие соединения от сервера к клиенту через NAT. В процессе такого соединения NAT подменяет передаваемые данные от клиента, указывая серверу истинный адрес и порт, с которым сможет соединиться сервер, а потом транслирует соединение от сервера от этого адреса клиенту на его адрес. Несмотря на все меры и нововведения, принятые для поддержки FTPпротокола, на практике функция NAT-PT обычно отключается во всех роутерах и маршрутизаторах с целью обеспечения дополнительной безопасности от вирусных угроз.
NAT и обход брандмауэров
FTP обычно передает данные при наличии соединения сервера с клиентом, после того как клиент отправил команду PORT. Это создает проблему как для NAT, так и для брандмауэров, которые не разрешают соединения из интернета к внутренним хостам. Для NAT дополнительной проблемой является то, что представление IP-адресов и номера порта в команде PORT относится к IP-адресу и порту внутреннего хоста, вместо публичного IP-адреса и NAT-порта. Существует два подхода к этой проблеме. Первый заключается в том,
что FTP-клиент и FTP-сервер используют команду PASV, которая вызывает соединение для передачи данных, установленное от клиента к серверу. Второй подход - изменение для NAT значений команды PORT с помощью шлюза на прикладном уровне.
Поддержка веб-браузерами
Большая часть обычных веб-браузеров может извлекать файлы, расположенные на FTP-серверах, хотя они могут не поддерживать расширения протоколов вроде FTPS. Когда указан FTP-адрес, а не HTTP-адрес, доступный контент на удалённом сервере представляется аналогично остальному веб-контенту. Полностью функциональный FTP-клиент может быть запущен в Firefox как расширение FireFTP.
Безопасность
FTP не разрабатывался как защищённый (особенно по нынешним меркам) протокол и имеет многочисленные уязвимости в защите. В мае 1999 авторы RFC 2577 свели уязвимости в следующий список проблем:
Скрытые атаки (bounce attacks)
Спуф-атаки (spoof attacks)
Атаки методом грубой силы (brute force attacks)
Перехват пакетов, сниффинг (packet capture, sniffing)
Защита имени пользователя
Захват портов (port stealing)
FTP не может зашифровать свой трафик, все передачи - открытый текст, поэтому имена пользователей, пароли, команды и данные могут быть прочитаны кем угодно, способным перехватить пакет по сети. Эта проблема характерна для многих спецификаций Интернет-протокола (в их числе SMTP, Telnet, POP, IMAP), разработанных до создания таких механизмов шифрования, как TLS и SSL. Обычное решение этой проблемы - использовать "безопасные", TLS-защищенные версии уязвимых протоколов (FTPS для FTP, TelnetS для Telnet и т.д.) или же другой, более защищённый протокол, вроде SFTP/SCP, предоставляемого с большинством реализаций протокола Secure Shell.
Безопасный FTP
Существует несколько методов безопасной передачи файлов, в одно или другое время называемых
"Безопасным FTP": FTPS, SFPS, FTP через SSH.
FTPS
Явный FTPS - расширение стандарта FTP, позволяющее клиентам требовать того, чтобы FTP-сессия была зашифрована. Это реализуется отправкой команды "AUTH TLS". Сервер обладает возможностью позволить или отклонить соединения, которые не запрашивают TLS. Это расширение протокола определено в спецификации RFC 4217. Неявный FTPS - устаревший стандарт для FTP, требующий использования SSLили TLS-соединения. Этот стандарт должен был использовать отличные от обычного FTP порты.
SFTP
SFTP, или «SSH File Transfer Protocol», не связан с FTP, за исключением того, что он тоже передаёт файлы и имеет аналогичный набор команд для пользователей. SFTP, или безопасный FTP, — это программа, использующая SSH (Secure Shell) для передачи файлов. В отличие от стандартного FTP он шифрует и команды, и данные, предохраняя пароли и конфиденциальную информацию от открытой передачи через сеть. По функциональности SFTP похож на FTP, но так как он использует другой протокол, клиенты стандартного FTP не могут связаться с SFTP-сервером и наоборот.
FTP через SSH (не SFTP)
FTP через SSH (не SFTP) относится к практике туннелирования обычной FTP-сессии через SSHсоединение. Поскольку FTP использует несколько TCP-соединений, туннелирование через SSH особенно затруднительно. Когда много SSH-клиентов пытаются установить туннель для канала управления (изначальное "клиент-сервер" соединение по порту 21), защищён будет только этот канал; при передаче данных программное обеспечение FTP на любом конце установит новые TCP-соединения (каналы данных), которые обойдут SSHсоединение и, таким образом, лишатся целостной защиты.
Иначе, для клиентского программного обеспечения SSH необходимо иметь определённые знания о FTP для отслеживания и перезаписи сообщений потока управления FTP и автономного открытия новых перенаправлений для потока данных FTP.
FTP через SSH иногда относят к безопасным FTP; но не стоит путать его с другими методами, такими как SSL/TLS (FTPS). Другие методы передачи файлов с помощью SSH и не связанные с FTP - SFTP и SCP; в каждом из них и учётные и файловые данные всегда защищены протоколом SSH.
FXP
FXP (англ. File eXchange Protocol — протокол обмена файлами) — способ передачи файлов между двумя FTP-серверами напрямую, не закачивая их на свой компьютер. При FXP-сессии клиент открывает два FTP-соединения к двум разным серверам, запрашивая файл на первом сервере, указывая в команде PORT IPадрес второго сервера.
Несомненным преимуществом поддержки стандарта FXP является то, что на конечных пользователей, желающих скопировать файлы с одного FTP-сервера на другой, уже не действует ограничение пропускной способности их собственного интернет-соединения. Нет необходимости скачивать себе файл, чтобы потом загрузить его на другой FTP-сервер. Таким образом, время передачи файлов будет зависеть только от скорости соединения между двумя удаленными FTP-серверами, которая в большинстве случаев заведомо больше «пользовательской».
FXP стал использоваться злоумышленниками для атак на другие серверы: в команде PORT указывается IP-адрес и порт атакуемого сервиса на компьютере жертвы, и командами RETR/STOR производится обращение на этот порт от лица FTP-сервера, а не атакующей машины, что позволяло устраивать масштабные DDoS-атаки с использованием сразу многих FTP-серверов, либо обходить систему безопасности компьютера жертвы, если он полагается только на проверку IP клиента и используемый для атаки FTP-сервер находится в доверенной сети или на шлюзе. В результате сейчас практически все серверы проверяют соответствие IP-адреса, указанного в команде PORT, IP-адресу FTP-клиента и по умолчанию запрещают использование там IP-адресов третьих сторон. Таким образом, использование FXP невозможно при работе с публичными FTP-серверами.
Основные команды
ABOR — Прервать передачу файла
CDUP — Сменить директорию на вышестоящую.
CWD — Сменить директорию.
DELE — Удалить файл (DELE filename).
EPSV — Войти в расширенный пассивный режим. Применяется вместо PASV.
HELP — Выводит список команд, принимаемых сервером.
LIST — Возвращает список файлов директории. Список передаётся через соединение данных.
MDTM — Возвращает время модификации файла.
MKD — Создать директорию.
NLST — Возвращает список файлов директории в более кратком формате, чем LIST. Список передаётся через соединение данных.
NOOP — Пустая операция
PASV — Войти в пассивный режим. Сервер вернёт адрес и порт, к которому нужно подключиться, чтобы забрать данные. Передача начнётся при введении следующих команд:
RETR, LIST и т.д.
PORT — Войти в активный режим. Например PORT 12,34,45,56,78,89. В отличие от пассивного режима для передачи данных сервер сам подключается к клиенту.
PWD — Возвращает текущую директорию.
QUIT — Отключиться
REIN — Реинициализировать подключение
RETR — Скачать файл. Перед RETR должна быть команда PASV или PORT.
RMD — Удалить директорию
RNFR и RNTO — Переименовать файл. RNFR — что переименовывать, RNTO — во что.
SIZE — Возвращает размер файла
STOR — Закачать файл. Перед STOR должна быть команда PASV или PORT.
SYST — Возвращает тип системы (UNIX, WIN, …)
TYPE — Установить тип передачи файла (бинарный, текстовый)
USER — Имя пользователя для входа на сервер
16 HTTP. Методы GET, HEAD, POST, PUT DELETE, TRACE.
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов в формате HTML). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как
SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно
благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
Преимущества
Данный протокол очень прост в реализации, хорошо расширяется благодаря внедрению собственных заголовков, добавляющие функциональности приложению, и которые будут игнорироваться другими приложениями, посчитавшими их неизвестными:
Простота. Протокол прост в реализации, что позволяет легко создавать клиентские приложения.
Расширяемость. Возможности протокола легко расширяются благодаря внедрению своих собственных заголовков, с помощью которых можно получить необходимую функциональность при решении специфической задачи. При этом сохраняется совместимость с другими клиентами и серверами: они будут просто игнорировать неизвестные им заголовки.
Распространённость. При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различной документации по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.
Структура протокола
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
Стартовая строка (англ. Starting line) — определяет тип сообщения;
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.
Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
GET URI — для версии протокола 0.9.
Метод URI HTTP/Версия — для остальных версий.
Здесь:
Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.
URI определяет путь к запрашиваемому документу.
Версия (англ. Version) — пара разделённых точкой цифр. Например: 1.0
Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение, где:
Версия — пара разделённых точкой цифр как в запросе.
Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.
Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:
HTTP/1.0 200 OK