Русский
Русский
English
Статистика
Реклама

Network engineering

Исследование сетевого трафика

02.02.2021 18:09:11 | Автор: admin

Специально для будущих студентов курса Network engineer. Basic наш эксперт - Александр Колесников подготовил интересный авторский материал.

Также приглашаем принять участие в открытом онлайн-уроке на тему STP. Что? Зачем? Почему?. Участники урока вместе с экспертом рассмотрят протокол STP, разберут логику его работы, разберут его преимущества и недостатки.


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

Инструментарий и методика исследования

Для разбора трафиков будем использовать следующее программное обеспечение:

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

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

Disclamer: Все файлы трафиков взяты из различных соревнований CTF, все права на задания принадлежат их авторам.

Для исследования трафиков будем придерживаться минимальной стратегии:

  1. Определить количество участников сети;

  2. Определить стек используемых протоколов;

  3. На основании пункта 2 принять решение искать данные по убыванию популярности использования трафика;

  4. Если выясняется, что данные, которые передаются в трафике, не были обработаны дополнительным кодированием, то применять фильтр по тексту.

Примеры разбора трафика

Первое задание для разбора:

1.pcap(9cd84b46fee506dae818ecdca76607d1). Задача найти данные, которые будут содержать информацию вида "FLAG-???????????". Приступим к разбору. Пройдемся по методике, которую описали в прошлом пункте:

Количество участников в сети очень просто определить при помощи WireShark (Всё, что описано для этого инструмента, можно повторить и на tshark. Автор использует WireShark для наглядности). В опциях WireShrak выбираем "Statistics->Endpoints":

Итого у нас 8 уникальных IP адресов, которые участвовали во взаимодействии. Определим стек протоколов. Сделать это можно в том же самом меню "Statistics->Protocol Hierarchy":

Итак, самый популярный протокол взаимодействия http. Этот протокол внутри файла pcap хранится в текстовом представлении поэтому можно попробовать показать все данные из body пересылаемых данных и отфильтровать данные по формату искомой строки. Попробуем это сделать с помощью tshark. Команда для фильтра будет выглядеть так:

```  tshark -r ./1.pcap -Y http -Tfields -e http.file_data | grep "FLAG"```

В результате получаем результат:

Второй файл для исследования 2.pcap (9a67e1fb9e529b7acfc6e91db6e1b092). Проведем этапы исследования. Количество участников взаимодействия:

В этом случае участников 13 задание усложняется. Какие протоколы используются:

К сожалению, в этот раз всё не так просто с используемыми протоколами для передачи данных. Среди информации пересылаемой через tcp протокол ничего интересного для нашего задания не встретилось. В udp же попалось кое-что интересное:

``` tshark -r ./2.pcap -Y 'dns' ```

Однако, если обратить внимание на резолв локальных адресов через dns, то мы можем обнаружить вот такую картину:

Странная часть ip адреса, которая очень похожа на какие-то кодированные шестнадцатеричные символы. Попробуем их провести через кодировку:

```tshark -r ./2.pcap -Y '!icmp.code && dns.qry.name contains 192.168' -Tfields -e dns.qry.name | tr '.' ' ' |awk '{print $1}' |xxd -r```

Полученная строка очень похожа на base64 кодировку, раскодируем:

``` base64 -D <<< "VGhpcyBpcyBhIHNlY3JldCB0Y3JldCB0cmFuc21pdHRlZCB0aHJvdWdoaHJvdWdoIGRucyBxdWVyeSA6KSBGTEFHKSBGTEFHLUZUNDdjTVgyNnBXeUZTSTZSeUZTSTZSUFdhU3I1WVJ3"```

В итоге:

В качестве целевого сетевого трафика будем использовать 3.pcap(0e66830db52ad51971d40c77fa5b02c0). Проанализируем количество участников взаимодействия и статистику используемых протоколов:

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

``` tshark -r ./3.pcap -Y http```

Самые интересные строки находятся в конце записанного трафика, это запросы http к файлам "flag.zip" и "secret.txt". Сдампим их через Wireshark и попробуем открыть:

Попробуем сдампить файл, который называется flag.zip через WireShark. Стандартным интерфейсом это сделать не получится, поэтому придется сделать небольшой хак сохранить данные в Raw формате:

Открываем с уже найденным паролем:

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

Сохраним дамп этого потока и вырежем с помощью простой программы фрагмент архива:

```python  data = [] with open('dump') as f:     data = f.read()     with open('tesst.zip','w') as w:    w.write(data[1010788:])```

Пробуем распаковать:

``` 7z x ./test.zip ```

Похоже, что часть данных недоступна, но мы смогли восстановить файл flag.txt

Описанная методика может позволить извлекать информацию из записанных сетевых данных. В качестве закрепления материала, предлагаем читателю найти данные в трафике 4.pcap(604bbac867a6e197972230019fb34b2e).


Узнать подробнее о курсе Network engineer. Basic.

Зарегистрироваться на вебинар по теме STP. Что? Зачем? Почему?.


Читать ещё:

Подробнее..

Исследование вредоносного трафика

09.02.2021 16:13:11 | Автор: admin

Статья подготовлена экспертом OTUS - Александром Колесниковым для будущих студентов курса Network engineer. Basic.

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


Статья расскажет о способах разбора и детектирования вредоносного сетевого взаимодействия в сети. Информация предоставляется для ознакомления. Здесь будут рассмотрены основные инструменты для анализа сетевого трафика и рассмотрены источники примеров для практики.

Анализ сетевого взаимодействия

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

Что в большинстве случаев генерирует в сети вредоносное программное обеспечение:

  • отчет о инфицировании системы;

  • собранные в системе учетные данные;

  • принимаемые команды от управляющего сервера;

  • загружаемые модули обновления вредоноса;

  • сетевой трафик, который используется для атак DDoS

Для обнаружения вредоносного сетевого взаимодействия нужно:

  1. Иметь возможность записывать фрагменты сетевого взаимодействия;

  2. Знать основные шаблоны передачи зловредами данных по сети и способы сокрытия информации в сетевом взаимодействии.

Первый пункт решить достаточно просто с помощью снифферов типа WireShark или tcpdump. Второй пункт решается для начинающих аналитиков только большим количеством проанализированных фрагментов трафиков. Где найти такие фрагменты?

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

ВНИМАНИЕ: Никакие файлы и команды, найденные в записанном сетевом взаимодействии, нельзя запускать на вашей рабочей машине анализировать эти данные нужно в виртуальной машине.

Выбранный файл сетевого взаимодействия представляет собой сетевую активность вредоносного программного обеспечения Trickbot. Так как мы не знаем, как построена сеть, где было записано сетевое взаимодействие, то выясним, какие машины вообще взаимодействуют в сети:

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

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

Интересным выглядит взаимодействие с ip адресом, который начинается с 149.28. Создадим фильтр:

``` ip.addr==172.16.1.101 && tcp.port==65483 && ip.addr==149.28.140.9 && tcp.port==80```

В итоге видим такую картину:

Похоже, что на машине был открыт документ, который подгружает файл шаблона для документа MS Office. Далее находится обфусцированный скрипт на VBA:

Очевидно, что в записанное взаимодействие попал этап инфицирования ОС вредоносным программным обеспечением. Если взглянуть на вот такой фильтр:

tls

Обнаруживаем, что сетевое взаимодействие зловреда также зашифровано. Что же делать? Ключей шифрования нет, прочесть информацию внутри пакетов не получится.

Анализ сетевого взаимодействия: сегодня и в будущем

Любые навыки анализа сетевого взаимодействия разбиваются об использование шифрования трафика. Современным стандартом шифрования в сети на прикладном уровне модели OSI является использование HTTP over TLS. Зачастую это "Game Over" любого анализа, если недоступны ключи шифрования. Как же поступить в этом случае?

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

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

Классификация осуществляется на базе следующих данных:

  • передаваемых с сообщением ClientHello TLS взаимодействия

  • длины передаваемых данных

  • временных таймаутов между отправкой данных

Заключение

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


Узнать подробнее о курсе Network engineer. Basic.

Участвовать в открытом вебинаре по теме Ethernet. От рождения до наших дней.

Подробнее..

Актуальные методы расшифрования TLSSSL

10.02.2021 16:11:31 | Автор: admin

Привет, Хабр. В рамках курса Network engineer подготовили авторскую статью.

Также приглашаем всех желающих смотреть
открытый вебинар на тему NAT не Firewall. На нем участники вместе с экспертом рассмотрят NAT и его использование, разберут, почему NAT != firewall. Дополнительно рассмотрят различные виды конфигураций для разных ситуаций.


Шифрование это наиболее популярный способ для защиты сетевого взаимодействия. Статья расскажет об актуальных методах расшифровки данных, которые передаются во время взаимодействия с web-приложениями. Будут рассмотрены примеры расшифровки в зависимости от стартовых условий (наличие ключей шифрования, сертификатов и уязвимостей в схеме передачи информации).

Проблематика и история

Разберемся немного с проблематикой и терминологией. На сегодняшний день наиболее популярными технологиями, которые применяются для шифрования данных, передаваемых по сети, являются SSL и TLS. Последняя сейчас является стандартом дефакто для взаимодействия по протоколу HTTPS. Кстати, именно в расшифровке этого протокола и будет заключаться практическая часть данной статьи. Для понимания процесса расшифровки данных мы должны знать такие понятия как:

  • Симметричная криптография

  • Ассиметричная криптография

  • Сертификат

  • Хранилище сертификатов

  • HSTS или Strict Transport Security технология, которая включена в современных браузерах для контроля над обязательным использованием HTTPS для взаимодействия с сервером.

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

Практика

Практику будем проводить с использованием виртуальной лаборатории. Состав лаборатории:

  • Virtual Box;

  • Windows 8.1;

  • Ubuntu Server 20.04

Также для тестирования способов расшифровки трафика будем использовать устройство iPhonе SE.

Все машины должны быть подключены к сети "NAT Network". Именно этот тип подключения позволяет моделировать близкую к реальной топологию сети. В схеме есть хосты, которые могут взаимодействовать друг с другом, и есть хост, который используется как точка доступа в сеть Интернет. Приступим к практике.

Расшифровка трафика с использованием SQUID

Squid программное обеспечение, которая эмулирует функцию кэширующего сервера. Может быть использована для распределения нагрузки и логирования действий пользователей по протоколу HTTP в сети, кстати, и с HTTPS это ПО работать тоже умеет. Воспользуемся этой его функцией. К сожалению, использовать squid из репозитория не получится, необходимо собрать его самостоятельно:

```sh wget http://www.squid-cache.org/Versions/v4/squid-4.5.tar.gztar -xvzf squid-4.5.tar.gzcd squid-4.5./configure --with-openssl --enable-ssl-crtd --prefix=/usr/local/squidmakemake allmake install```

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

```sh cd /etc/squidmkdir ssl_certchown squid:squid -R ssl_certchmod 700 ssl_certcd ssl_certopenssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -extensions v3_ca -keyout myCA.pem  -out myCA.pemopenssl x509 -in myCA.pem -outform DER -out myCA.der```

Файл сертификата myCA.der можно использовать для браузера. Устанавливаем его в локальное хранилище и прописываем в качестве прокси сервер squid.

Настроим ссылку на вновь скомпилированный файл squid:

```shln -s /usr/local/squid/sbin/squid /usr/local/bin/squid```

Проинициализируем директорию для кэша:

```/usr/local/squid/libexec/security_file_certgen -c -s /var/lib/ssl_db -M 4MBchown squid:squid -R /var/lib/ssl_db```

Модифицируем конфиг:

```shnano /usr/local/squid/etc/squid.conf```

Должен получить следующий листинг:

```shacl SSL_ports port 443acl CONNECT method CONNECTacl manager proto cache_objecthttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow localhost managerhttp_access deny managerhttp_access allow localnethttp_access allow localhosthttp_access deny allhttp_port 3128cache_dir ufs /usr/local/squid/var/cache/squid 100 16 256coredump_dir /usr/local/squid/var/cache/squidrefresh_pattern ^ftp:144020%10080refresh_pattern ^gopher:14400%1440refresh_pattern -i (/cgi-bin/|\?) 00%0refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% 432000 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.index.(html|htm)$ 0 40% 10080refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320refresh_pattern -i youtube.com/.* 10080 90% 43200refresh_pattern (/cgi-bin/|\?) 0 0% 0refresh_pattern .020%4320http_port 3128 ssl-bump \  cert=/etc/squid/ssl_cert/myCA.pem \  generate-host-certificates=on dynamic_cert_mem_cache_size=4MBsslcrtd_program /usr/local/squid/libexec/security_file_certgen -s /var/lib/ssl_db -M 4MBacl step1 at_step SslBump1ssl_bump peek allssl_bump stare allssl_bump bump allcache allow allaccess_log stdio:/usr/local/squid/var/logs/access.log combinedcache_store_log stdio:/usr/local/squid/var/logs/store.logcache_log stdio:/usr/local/squid/var/logs/cache.log```

Запускаем squid:

```shsquid -d 10 && tail -f /usr/local/squid/var/logs/access.log```

Результат проксирования:

Расшифровка взаимодействия с использованием CharlesProxy

В этом эксперименте будем использовать настоящую WiFi сеть с подключенным к нему устройством iPhone SE. Для расшифровки сетевого взаимодействия будем использовать специализированные программные продукты. Например charlesProxy. Продукт платный, но предоставляет бесплатный период использования. После запуска нужно выбрать опцию "Proxy > Start SSL Proxying":

После этого станет доступна ссылка на корневой сертификат для браузера или другого сетевого устройства. Установим сертификат на устройство:

После установки в в качестве доверенного в браузере или на устройстве, можно увидеть следующий результат:

Вывод

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


Узнать подробнее о курсе Network engineer.

Смотреть открытый вебинар на тему NAT не Firewall.

Подробнее..

Перевод Azure Active Directory Gateway теперь на .NET Core 3.1

08.06.2021 18:13:14 | Автор: admin

*Gateway шлюз

Azure Active Directory Gateway это обратный прокси-сервер, который работает с сотнями служб, входящих в Azure Active Directory (Azure AD). Если вы пользовались такими службами, как office.com, outlook.com, azure.com или xbox.live.com, то вы использовали шлюз Azure AD. Шлюз присутствует в более чем 53 центрах обработки данных Azure по всему миру и обслуживает ~115 миллиардов запросов ежедневно. До недавнего времени шлюз Azure AD работал на платформе .NET Framework 4.6.2. С сентября 2020 года он работает на .NET Core 3.1.

Мотивация для перехода на .NET Core

Масштаб результатов шлюза приводит к значительному потреблению вычислительных ресурсов, что, в свою очередь, стоит денег. Поиск путей снижения стоимости работы сервиса был ключевой целью для команды, стоящей за ней. Шумиха вокруг производительности .NET Core привлекла наше внимание, тем более что TechEmpower назвал ASP.NET Core одним из самых быстрых веб-фреймворков на планете. Мы провели собственные тесты прототипов шлюза на .NET Core, и результаты позволили нам принять очень простое решение: мы должны перенести наш сервис на .NET Core.

Обеспечивает ли .NET Core реальную экономию средств?

Безусловно, обеспечивает. Благодаря шлюзу Azure AD мы смогли сократить затраты на CPU (ЦП) на 50%.

Раньше шлюз работал на IIS с .NET Framework 4.6.2. Сегодня он работает на IIS с .NET Core 3.1. На изображении ниже показано, что использование ЦП сократилось вдвое на .NET Core 3.1 по сравнению с .NET Framework 4.6.2 (фактически удвоив пропускную способность).

В результате увеличения пропускной способности мы смогли уменьшить размер нашего сервера с ~40 тыс. до ~20 тыс. ядер (сокращение на 50%).

Как произошел переход к .NET Core?

Он происходил в 3 этапа.

Этап 1: Выбор пограничного сервера

Когда мы начали работу по переходу, первый вопрос, который мы должны были задать себе, был: какой из трех серверов в .NET Core мы выберем?

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

Kestrel:

Когда мы инициировали наш переход (ноябрь 2019 года), Kestrel не поддерживал ни согласование клиентских сертификатов, ни их аннулирование для каждого имени хоста. В .NET 5.0 поддержка этих функций была добавлена.

Как и в .NET 5.0, Kestrel (благодаря использованию SslStream) не поддерживает CTL-хранилища для каждого имени хоста. Поддержка ожидается в .NET 6.0.

HTTP.sys:

Сервер HTTP.sys столкнулся с несоответствием между конфигурацией TLS на Http.Sys и имплементацией .NET: Даже если привязка настроена так, чтобы не согласовывать клиентские сертификаты, обращение к свойству Client certificate в .NET Core вызывает нежелательное повторное согласование TLS.

Например, выполнение простого null check в C# приводит к повторному согласованию TLS handshake (рукопожатия TLS):

if (HttpContext.Connection.ClientCertificate != null)

Это показано в https://github.com/dotnet/aspnetcore/issues/14806 в ASP.NET Core 3.1. В то время, когда мы делали переход в ноябре 2019 года, мы были на ASP.NET Core 2.2 и поэтому не выбрали этот сервер.

IIS:

IIS отвечал всем нашим требованиям к TLS, поэтому мы выбрали именно этот сервер.

Этап 2: Миграция приложения и зависимостей

Как и многие крупные службы и приложения, шлюз Azure AD имеет множество зависимостей. Некоторые из них были написаны специально для этой службы, а некоторые другими специалистами внутри и вне Microsoft. В некоторых случаях эти библиотеки уже были нацелены на .NET Standard 2.0. В других случаях мы обновили их для поддержки .NET Standard 2.0 или нашли альтернативные имплементации, например, удалили нашу устаревшую библиотеку Dependency Injection и вместо нее использовали встроенную в .NET Core поддержку для внедрения зависимостей. На этом этапе большую помощь оказал .NET Portability Analyzer.

Для самого приложения:

  • Шлюз Azure AD имел зависимость от IHttpModule и IHttpHandler из классического ASP.NET, которой нет в ASP.NET Core. Поэтому мы переработали приложение, используя конструкции промежуточного ПО в ASP.NET Core.

  • Одной из вещей, которая действительно помогла в процессе миграции, является Azure Profiler (служба, которая собирает трассировки производительности на виртуальных машинах Azure). Мы развертывали наши ночные сборки на тестовых площадках, использовали wrk2 в качестве агента нагрузки для тестирования сценариев под нагрузкой и собирали трассы Azure Profiler. Эти трассировки затем информировали нас о следующей настройке, необходимой для получения пиковой производительности нашего приложения.

Этап 3: Постепенное развертывание

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

  • Мы развернули наши первоначальные версии в тестовом, интеграционном и DogFood средах. Это привело к раннему обнаружению ошибок и помогло исправить их до того, как они попали в работу.

  • После завершения кода мы развернули сборку .NET Core на одной производственной системе в единице масштабирования. Единица масштабирования это пул виртуальных машин с балансировкой нагрузки.

  • В единице масштабирования ~100 машин, где на 99 машинах все еще работала наша существующая сборка .NET Framework и только на 1 машине была установлена новая сборка .NET Core.

  • Все ~100 машин в этом масштабном блоке получают точный тип и количество трафика. Затем мы сравнили коды состояния, количество ошибок, функциональные сценарии и производительность одной машины с остальными 99 машинами, чтобы обнаружить аномалии.

  • Мы хотели, чтобы эта единственная машина вела себя функционально так же, как и остальные 99 машин, но имела гораздо более высокую производительность/пропускную способность, что мы и наблюдали.

  • Мы также "перенаправили" трафик с действующих производственных устройств (работающих с .NET Framework build) на устройства с .NET Core, чтобы сравнить и сопоставить их, как указано выше.

  • Как только мы достигли функциональной эквивалентности, мы начали увеличивать количество единиц масштаба, работающих на .NET Core, и постепенно расширили их до целого центра данных.

  • После миграции всего центра обработки данных последним шагом было постепенное распространение по всему миру на все центры обработки данных Azure, где присутствует служба шлюза Azure AD. Миграция завершена!

Полученные знания

  • ASP.NET Core внимателен к RFC. Это очень хорошая особенность, так как она способствует распространению передовой практики. Однако классические ASP.NET и .NET Framework были более снисходительны, что вызывает некоторые проблемы с обратной совместимостью:

  • Веб-сервер по умолчанию разрешает только значения ASCII в заголовках HTTP. По нашей просьбе поддержка Latin1 была добавлена в IISHttpServer: https://github.com/dotnet/aspnetcore/pull/22798

  • HttpClient на .NET Core раньше поддерживал только значения ASCII в HTTP-заголовках.

  • Формы и cookies, не соответствующие RFC, приводят к исключениям при проверке. Поэтому мы создали "запасные" парсеры, используя классический исходный код ASP.NET, чтобы сохранить обратную совместимость для клиентов.

  • В методе FileBufferingReadStreams CopyToAsync() наблюдалось снижение производительности из-за нескольких 1-байтовых копий n-байтового потока. Эта проблема решена в .NET 5.0 путем выбора размера буфера по умолчанию в 4K: https://github.com/dotnet/aspnetcore/issues/24032.

  • Помните о классических причудах ASP.NET:

    • Автоматически тримятся (auto-trimmed) символы пробелов:

foo.com/oauth ?client=abc тримятся до foo.com/oauth?client=abc в классическом ASP.NET.

  • С течением времени клиенты/даунстрим сервисы стали зависеть от этих тримов, а ASP.NET Core не выполняет автоматическтий триминг.

Поэтому нам пришлось убрать пробельные символы (auto-trim), чтобы имитировать классическое поведение ASP.NET.

  • Заголовок Content-Type автоматически генерируется, если отсутствует тому:

Когда размер ответа больше нуля байт, но заголовок Content-Type отсутствует, классический ASP.NET генерирует стандартный заголовок Content-Type:text/html. ASP.NET Core не генерирует заголовок Content-Type по умолчанию принудительно, и клиенты, которые полагают, что заголовок Content-Type всегда появляется в ответе, начинают испытывать проблемы. Мы имитировали классическое поведение ASP.NET, добавив Content-Type по умолчанию, когда он отсутствует в нижестоящих службах.

Будущее

Переход на .NET Core привел к удвоению пропускной способности нашего сервиса, и это было отличное решение. Наше путешествие по .NET Core не закончится после перехода. В будущем мы рассматриваем следующие варианты:

  • Обновление до .NET 5.0 для повышения производительности.

  • Переход на Kestrel, чтобы мы могли перехватывать соединения на уровне TLS для повышения отказоустойчивости.

  • Использовать компоненты/лучшие практики YARP (https://microsoft.github.io/reverse-proxy/) в нашем собственном обратном прокси и также внести свой вклад.


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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru