Протоколы tcp/ip простым языком

2020

Сотни миллионов устройств под угрозой из-за «дыр» в разновидности TCP/IP

Эксперты компании JSOF выявили почти два десятка уязвимостей в высокоскоростном протоколе Treck TCP/IP, разработанном специально для встраиваемых устройств. В результате под угрозой оказывается колоссальное количество оборудования интернета вещей, включая то, что предназначено для использования в корпоративных средах.

Среди уязвимостей под общим названием Ripple20, есть несколько критических и высокоопасных, позволяющих захватывать контроль над устройствами. Они позволяют, среди прочего, запускать произвольный код удаленно, выводить данные или выводить устройства из строя.

В большинстве случаев для эксплуатации достаточно отправки IP-пакетов или DNS-запросов на целевые устройства.

Эксперты не уточнили, какое количество устройств может быть атаковано с помощью этих уязвимостей, но, по-видимому, речь идет о сотнях миллионов устройств самых разных производителей в диапазоне от безымянных мастерских до гигантов вроде HP, Schneider Electric, Intel, Rockwell и т. д. Treck TCP/IP активно используется в этой сфере.

Как отметили исследователи, вариантов эксплуатации этих уязвимостей может быть множество — от относительно безобидной кражи данных из принтера до смертоносных, например, удаленная перенастройка подключенного к Сети медицинского насоса или саботаж промышленных контроллеров. При этом спящий вредоносный код может скрываться в уязвимом устройстве интернета вещей на протяжении многих лет.

Европейский институт телекоммуникационных стандартов (ETSI) в апреле 2020 г. объявил о создании новой отраслевой рабочей группы для создания спецификаций сотовых сетей без протоколов TCP/IP — ISG NIN. Председателем группы был избран Джон Грант из Building Solution International (BSI), его заместителем — Кевин Смит из Vodafone.

Группа должна выпустить спецификации, применимые к сетям 5G, позволив им быть более простыми и эффективными в управлении. Ожидается, что первоначально работа ISG NIN будет применима к частным мобильным сетям, таким как сети автоматизации производства. Затем эти технологии должны будут распространиться на системы общего пользования и будут использоваться как на ядре сети, так и в элементах сети доступа.

Первым результатом работы группы должен стать отчет, в котором будут подробно описаны недостатки TCP/IP и то, как новая альтернативная система преодолеет эти недостатки. ISG NIN также будет работать над определением того, как требования, первоначально разработанные, ранее функционировавшей группой — ISG NGP, станут основой новых протоколов и над созданием основы для тестирования эффективности и действенности новых протоколов, в том числе на радио-интерфейсе.

Протокол TCP/IP не эффективен в сотовых сетях нового поколения.

Я очень рад, что мне доверили председательство в этой группе. Поиск новых протоколов для Интернета, более подходящих для эпохи 5G, был необходим. BIG DATA и критически важные системы, такие как промышленное управление, интеллектуальные транспортные средства и телемедицина не могут наилучшим образом работать при помощи современных сетей на основе TCP/IP
Джон Грант, председатель ISG NIN

Китай представил миру новый интернет-протокол New IP, облегчающий тотальную цензуру

Основная статья: New IP (интернет-протокол)

В конце марта 2020 года Китай представил Международному союзу электросвязи (International Telecommunication Union, ITU) новый интернет-протокол, который, по словам его создателей, имеет множество преимуществ. Однако стандарт открывает властям больше возможностей для тотальной цензуры в сети.

Протокол получил название New IP и призван заменить устаревший TCP/IP. Он презентован компанией Huawei и телекоммуникационными операторами из Поднебесной, передает издание Financial Times со ссылкой на материалы презентации.

Участок 1. Сенсорный узел – сенсорный узел

Обозначим отрезок сети между сенсорными узлами как участок 1. На данном участке выполняется ряд задач, например распределение информации между сенсорными узлами для временного хранения или перенаправления. Для обеспечения связи между сенсорными узлами/датчиками используется протокол DDS (Data Distribution Service). Проиллюстрируем его применение на отрезке сети (см. рис. 2).

Протокол DDS распределяет данные между устройствами . DDS реализует прямую шинную связь между устройствами на базе реляционной модели данных. Протокол DDS реализует многоадресную систему, используя UDP. Данный протокол ориентирован на шаблон «издатель-подписчик», при этом передача сообщений производится по шине с использованием метода «запрос-ответ». Операции, выполняемые протоколом, задаются тринадцатью классами (Entity Class, WaitSet Class, Condition Class, Publisher Class, DataWriter Class, Subscriber Class, DataReader Class, ReadCondition Class, QueryCondition Class и другими). Протокол DDS реализует две операции – чтения и записи, используя соответствующие классы

Операция записи является достаточно примитивной, поэтому остановим внимание на операции чтения

Операция чтения (Read) осуществляется на всех доступных устройствах. Данные не удаляются из локального кеша DDS в результате этой операции и могут быть прочтены снова при указании специальных параметров. Получение данных осуществляется тремя следующими способами .

Опрос (Polling) – приложение (обычно периодически) запрашивает DDS для получения новых данных или информирования о смене состояния. Интервал опроса зависит от приложения и от данных.
Списки ожидания (WaitSets) – приложение регистрирует в DDS списки ожидания и ждет, пока одно из переданных событий не произойдет.
Слушатели (Listeners) – приложение регистрирует в DDS (в классах, где события описаны) специальные классы-слушатели, которые будут информированы при наступлении этих событий.

Подводя итог обзора протокола DDS, необходимо отметить его назначение – для связи сенсорных узлов/датчиков, объединение их прямой шинной связью и обеспечение многоадресной системы. В общем случае DDS применяется в автоматизированных системах управления движением, а также в энергетике, военной и финансовой сфере.

bind()¶

См.также

http://unixhelp.ed.ac.uk/CGI/man-cgi?bind+2

Связывает сокет с конкретным адресом. Когда сокет создается при помощи socket(), он ассоциируется с некоторым семейством адресов, но не с конкретным адресом. До того как сокет сможет принять входящие соединения, он должен быть связан с адресом. bind() принимает три аргумента:

sockfd — дескриптор, представляющий сокет при привязке
serv_addr — указатель на структуру sockaddr, представляющую адрес, к которому привязываем.
addrlen — поле socklen_t, представляющее длину структуры sockaddr.

Примечание

Возвращает 0 при успехе и −1 при возникновении ошибки.

Пример на Си

#include <sys/types.h>
#include <sys/socket.h>

int bind(int sockfd, const struct sockaddr *my_addr, socklen_t addrlen);

Пример на Python

server_address = ('localhost', 8080)
sock_obj.bind(server_address)  # Привязка адреса и порта к сокету.

Автоматическое получение имени хоста.

Имя NetBIOS

Одной из основных целей разработки NetBIOS являлось создание простого интерфейса, который давал бы возможность пользователям назначать станциям символьные имена вида . Очевидно, что без подобных имен нам сложно обойтись, поскольку именно легкие имена позволяют человеку «узнать» (однозначно идентифицировать) ресурс, к которому он хочет обратиться по сети. Программам то всё-равно, вместо имен они могут использовать любые идентификаторы, однако человеку удобнее работать именно с фонетическими, понятными и легко запоминающимися маркерами — именами. В качестве имени NetBIOS используется простое одноранговое (“плоское”) имя, без какой-либо иерархической структуры (в противоположность DNS). Подобная простота и отсутствие иерархии имени имеют и оборотную сторону — имена должны быть уникальными.

Имя NetBIOS имеет длину 16 байт.

Первые 15 — собственно имя, 16й — тип ресурса или суффикс (значение в диапазоне 00-FF, шестнадцатеричное представление). NetBIOS имя и имя компьютера (hostname) совпадают по первым 15 символам. Хранится это имя в параметре реестра с именем , который располагается в ветке .
С развитием сетевых технологий логическая структура сетей усложнялась, и помимо станций появились такие понятия как «рабочая группа» и «домен». Пришло осознание того, что ресурсы бывают разнотипными, а имя может быть присвоено не только станции. Опираясь на новые данные, было введено понятие «тип ресурса», который предназначался для логического разделения ресурсов по назначению, это позволило присваивать одно и то же имя нескольким ресурсам одновременно.

NetBIOS имя закрепляется не за станцией, как многие привыкли думать, а за ресурсом и только за ним.

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

Уникальное (Unique, U) — к этому имени может быть привязан только один адрес IP;
Групповое (Group, G) — к этому имени не привязан единственный адрес, имя может содержать множественные IP-адреса; На запрос WINS-клиента об адресе всегда возвращается limited broadcast address 255.255.255.255;
Группа Интернет (Internet Group, Special Group, I) — к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL. Используется для управления именами домена в WinNT;
Доменное имя (Domain Name, D) — к этому имени может быть привязано множество адресов;

Поскольку NetBIOS не использует номера портов, как это делает TCP/IP, адресное пространство имен должно быть способно поддерживать множество имен для каждой системы. К примеру, если на одной станции реализованы файловый сервер, служба Exchange и сервер удаленного доступа, то каждый из этих сервисов должен иметь отличное от других имя, однозначно определяющее сам сервис. Для этой цели авторы NetBIOS придумали понятие суффикса, который фактически является аналогом порта в TCP/IP. Как было указано выше, он занимает последний, 16й байт в имени и однозначно идентифицирует сервис.

Хорошо, и что же все это означает?

Итак, по приведенному выше анализу мы знаем, что протокол полон и корректен. Аргумент в пользу корректности выстаивает всегда, когда мы знаем, что никто не манипулирует временем — т. е. что программа Проверяющего выполняется нормально и никто не перематывает его выполнение.

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

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

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

Как вычислить человека, способного перейти на личности

Но, тебе также и приходится коммуницировать с людьми вживую. Поэтому, неплохо было бы узнать того, с кем споры бесполезны, ещё до начала дискуссии.

Вот какие признаки могут на это указать:

Есть две точки зрения: его и неправильная.

Они всегда пытаются доказать что-то одно, не признавая существования другого мнения. Таким людям всегда не всё равно, как ты одеваешься, какой выбор делаешь, как себя ведёшь. Они способны лезть со своими советами даже тогда, когда их никто об этом не просил;

Создание бессмысленной полемики.

Эти люди всегда стараются в чём-то обвинить своего собеседника или всячески противоречат. Оглянуться не успеешь, как уже будешь втянута в бессмысленный спор, предмет которого останется загадкой;

Отсутствие воспитания.

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

Наблюдай за людьми и обращай внимание, как они ведут себя в обществе;. Крайне не сдержаны

Крайне не сдержаны.

Выдержка у таких спорщиков совершенно отсутствует. Любая конфронтация провоцирует в них желание сделать человеку больно. И если они не могут позволить себе физическую силу, то пустят в ход моральные страдания;

Стабильность.

Если ты знаешь, что человек, который перед тобой, часто переходит на личности в спорах и вне их, то постарайся его не провоцировать. Спонтанный переход – это скорее исключение. Человек, как правило, использует этот психологический приём регулярно, потому что знает заранее, что из спора ему победителем не выйти.

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

Топология сети

В качестве отправной точки исследования была взята следующая топология (см. рис. 1). Легко заметить, что такая сеть полностью подходит под описанную нами архитектуру Интернета вещей.

Представленная топология соответствует шаблону проектирования передачи сообщений , который носит название «издатель-подписчик» (Publisher-subscriber, или pub/sub) . В такой схеме вводится понятие издателя – источника информации – и подписчика – ее получателя. Термин «подписка» связан с определенной операцией, выполняемой участниками шаблона, с целью получения информации подписчиком от конкретного издателя, а также упорядочивания сбора информации – параметров периодичности получения и аналогичных (в зависимости от реализации) показателей.

В данном случае рассматривается ситуация, когда сенсорный узел (на рис. 1 – Node) объединяет информацию от нескольких датчиков (например, данные телеметрической системы) и направляет ее согласно параметрам подписки либо по запросу, либо самостоятельно с определенным интервалом времени или по происшествии какого-либо события на сервер. Обычно сами датчики достаточно примитивны, их задачи сводятся к постоянной передаче информации о контролируемом параметре. Поэтому появляется необходимость объединять датчики в узлы, оснащенные микроконтроллерами, которые будут отвечать за считывание измеряемых данных и отправку их по заранее определенным алгоритмам далее на сервер. Также чаще всего для взаимодействия клиента с системой необходимо клиентское приложение (на рис. 1 – Application), установленное на персональном устройстве, служащее для графического представления получаемой с датчиков или уже обработанной сервером информации и управления системой. Такая топология также рассчитана на включение брокера (на рис. 1 – Broker). Брокер – это сервер, который принимает информацию от издателей и передает ее соответствующим подписчикам, в сложных системах может выполнять, также различные операции, связанные с анализом и обработкой поступивших данных . Брокер может устанавливать приоритеты сообщениям и формировать очереди для передачи сообщений. Таким образом брокер организует пересылку сообщений, их хранение и фильтрацию. Под очередью сообщений понимается контейнер, или блок, в котором хранятся сообщения в процессе их пересылки. При недостаточном ресурсе канала связи или если получатель недоступен во время отправки сообщения, очередь хранит сообщение до тех пор, пока оно не будет доставлено.

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

2021: Уязвимости в стеках TCP/IP затрагивают миллионы промышленных и IoT-устройств

13 апреля 2021 года стало известно о том, что исследователи безопасности из компании ForeScout совместно с экспертами JSOF обнаружили ряд уязвимостей в стеках TCP/IP, затрагивающий миллионы серверов, промышленных и «умных» устройств.

Уязвимости, получившие название NAME:WRECK, связаны с тем, как стеки TCP/IP обрабатывают DNS-трафик. Эксплуатация уязвимостей позволяет вызвать состояние «отказа в обслуживании» (DoS) или удаленно выполнить код (RCE). Таким образом злоумышленники могут отключить целевые устройства или перехватить контроль.

В общей сложности эксперты выявили девять уязвимостей в семи из пятнадцати стеков TCP/IP. Результаты анализа других восьми стеков показали, что FNET, cycloneTCP, uC/TCP-IP, FreeRTOS+TCP, Zephyr и OpenThread безопасно реализуют сжатие сообщений, в то время как Nut/Net и lwIP вовсе не поддерживали сжатие сообщений, и по умолчанию не были уязвимы.

Эксперты сообщили о своих находках разработчикам стеков, однако только FreeBSD, Nucleus NET и NetX получили исправления. IPNet все еще содержит уязвимости NAME:WRECK.

По словам специалистов, хотя выпуск исправлений может показаться обнадеживающим, на самом деле ситуация нет проста. Установка исправлений для «умных» устройств и промышленного оборудования обычно влечет за собой длительный период ожидания, в течение которого производители устройств должны будут интегрировать исправления и выпускать собственные обновления прошивки.

Большая часть оборудования может находится в удаленных местах и не поддерживать механизм обновления прошивки по воздуху (firmware-over-the-air, FOTA). Многие устройства, использующие уязвимые стеки TCP/IP, скорее всего, останутся уязвимыми к атакам в течение многих лет, в то время как другое оборудование может оставаться уязвимым до тех пор, пока оно не будет выведено из эксплуатации, полагают эксперты.

Клиенты TCP: Hercules

Hercules — это удобная терминальная программа для работы как с последовательными интерфейсами, так и с UDP/IP и TCP/IP — соединениями в режиме «клиент», и в режиме «сервер». Это как раз то, что нам нужно! Найти программу можно в интернете.
Запустив программу, переходим во вкладку TCP Client, вводим наш IP и пробуем пинговать. Контроллер реагирует.

Теперь установим соединение по TCP/IP с нашим МК. Такое соединение в данном протоколе устанавливается с помощью «тройного рукопожатия»

Для соединения очень важно указать порт. Поскольку мы устанавливаем TELNET-соединение, номер порта определён в файле tcpip.h следующим параметром:

#define TCP_PORT_TELNET		 23

Задаём соответствующее значение в программе и подключаемся, оставив IP неизменным.

После установления соединения в нижнем поле вводим текст для посылки в контроллер и нажимаем Send. В основном окне программы Received/Send data видим отправленное сообщение, выделенное фиолетовым цветом, а то, что отвечает микроконтроллер — чёрным.

Как убрать предупреждение в Яндекс Браузере?

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

Если вы переживаете, что могли подхватить вирус, посетив незащищенные сайты, просканируйте свой компьютер на предмет вредоносных программ.

По сути, значок предупреждает вас о потенциальной опасности заражения или перехвата данных. Дальше вы уже должны проявить бдительность. Старайтесь посещать только защищенные ресурсы, где ваши данные надежно шифруются.

Обратите внимание:

Триколор ошибка 0: как исправить такое?

Образование подсетей

TCP/IP-сеть класса A, B или C может еще быть разбита на подсети системным администратором. Образование подсетей может быть необходимо при согласовании логической структуры адреса Интернета (абстрактный мир IP-адресов и подсетей) с физическими сетями, используемыми в реальном мире.

Возможно, системный администратор, которому был выделен блок IP-адресов, администрирует сети, организованные не соответствующим для них образом. Например, имеется глобальная сеть с 150 узлами в трех сетях (в разных городах), соединенных маршрутизатором TCP/IP. У каждой из этих трех сетей 50 узлов. Пользователю выделяется сеть класса C 192.168.123.0. (Пример, на самом деле диапазон, к которому принадлежит этот адрес, не выделяется в Интернете.) Это значит, что адреса с 192.168.123.1 по 192.168.123.254 можно использовать для своих 150 узлов.

Адреса 192.168.123.0 и 192.168.123.255 нельзя использовать в данном примере, так как двоичные адреса с составляющей узла из одних единиц и нолей недопустимы. Адрес, состоящий из нулей, недопустим, поскольку он используется для определения сети без указания узла. Адрес с числом 255 (в двоичном обозначении адрес узла, состоящий из одних единиц) используется для доставки сообщения на каждый узел сети. Достаточно запомнить, что первый и последний адрес любой сети и подсети нельзя присваивать отдельному узлу.

Теперь осталось дать IP-адреса 254 узлам. Это несложно, если все 150 компьютеров являются частью одной сети. Тем не менее 150 ваших компьютеров находятся в трех отдельных физических сетях. Вместо того, чтобы запрашивать дополнительные блоки адресов для каждой сети, вы делите сеть на подсети, которые позволяют использовать один блок адресов в нескольких физических сетях.

В этом случае вы делите сеть на четыре подсети, используя маску подсети, которая делает сетевой адрес больше, а возможный диапазон адресов хостов — меньше. Другими словами, вы «заимствуете» некоторые биты, которые используются для адреса хоста, и используете их для сетевой части адреса. Маска подсети 255.255.255.192 предоставляет четыре сети по 62 хостов каждая. Это работает, так как в двоичном представлении 255.255.255.192 — это то же самое, что и 11111111.1111111.110000000. Первые две цифры последнего октета становятся сетевыми адресами, поэтому вы получаете дополнительные сети 00000000 (0), 010000000 (64), 10000000 (128) и 110000000 (192). (Некоторые администраторы будут использовать только две подсети с использованием 255.255.255.192 в качестве маски подсети. Дополнительные сведения по этому вопросу см. в разделе RFC 1878.) В этих четырех сетях последние шесть двоичных цифр можно использовать для адресов хостов.

Используя маску подсети 255.255.255.192, ваша сеть 192.168.123.0 становится четырьмя сетями 192.168.123.0, 192.168.123.64, 192.168.123.128 и 192.168.123.192. Эти четыре сети будут иметь такие допустимые адреса хостов:

192.168.123.1-62 192.168.123.65-126 192.168.123.129-190 192.168.123.193-254

Помните, что двоичные адреса хостов со всеми единицами или всеми нулями являются недействительными, поэтому нельзя использовать адреса с последним октетом 0, 63, 64, 127, 128, 191, 192 или 255.

Вы можете увидеть, как это работает, взглянув на два адреса хостов, 192.168.123.71 и 192.168.123.133. Если используется маска подсети класса C по умолчанию 255.255.255.0, оба адреса находятся в сети 192.168.123.0. Однако, если вы используете маску подсети 255.255.255.192, они находятся в разных сетях; 192.168.123.71 — в сети 192.168.123.64, 192.168.123.133 — в сети 192.168.123.128.