вторник, 13 августа 2019 г.

HTTP smuggling

         Иногда диву даешься как люди способны находить дырки даже в реализациях  относительно простых и очень хорошо изученных протоколах вроде HTTP.  Текстовый протокол, вроде все четко и понятно. Но нет, и тут есть просто куча проблем. Как говорится было гладко на бумаге да забыли про овраги. 
                 Что делать если в запросе два одинаковых заголовка Content-length ? Что если присутствуют взаимоисключающие заголовки типа Content-length и Transfer-encoding ? Кому из них верить ? А что если между названием заголовка и ":" добавить пробел ? Эту и многие другие ситуации разные реализации обрабатывают по разному. В результате до сих пор даже в самых казалось бы известных решениях по защите веб приложений находятся дыры(не буду раскрывать имен раньше времени).  

пятница, 2 августа 2019 г.

Arista EOS (Arista Extensible Operating System)

          Иногда разбираешь как работает та или иная технология - и в голове только одна мысль - "что за дерьмо, и они это еще людям продают!"(луч позора в сторону Microsoft). А иногда читаешь  и думаешь - "блин, вот это ребята молодцы, вот это отлично придумали!". И это про компанию Arista. Мне решительно нравится все что делают эти ребята! 
         На мой взгляд эти парни совершили революцию в на рынке сетевого железа. Взяли x86 процессоры, взяли обычный линукс (fedora), написали обвязку вокруг этого - и сделали самые быстрые в мире свитчи/маршрутизаторы! Обставили всех этих бородатых дядек из контролируют рынок и распродают свои свитчи/маршрутизаторы как горячие пирожки. Казалось бы у Cisco есть все - специализированная OS, специально написанная для подобных вещей, экспертиза в создании специализированных чипов для обработки сетевого траффика. И тут оказывается что балалайка на обычных интеловских процессорах и не модифицированном линукс ядре может обставить их по скорости! Короче я стал фанатом Arista. Ну и плюс ко всему эти ребята очень любят Golang, у них даже в EOS (Arista Extensible Operating System) есть поддержка Golang из коробки.   
            Ну и конечно им на роду поддерживать всякие OpenConfig, OpenFlow и другие элементы SDN. В общем если ребята не продадутcя Cisco то у них есть все шансы захватить мир.

среда, 31 июля 2019 г.

GetHeapCodeAndMetadataStatistics()

  После месяца ожидания, мой третий пул реквест был принят в node.js - https://github.com/nodejs/node/pull/27978 Теперь в node.js появится новый метод который позволит посмотреть сколько памяти нода выделяет под хранения кода и метаданных.

пятница, 19 июля 2019 г.

Microsoft SLB (Software Load Balancing)

      Кроме довольно убого NLB про которого я писал в прошлый раз, Microsoft сейчас предлагает SLB - Software Load Balancer. На мой взгляд этот балансер сделан гораздо более продумано. Но в данном случае название(Software) не отображает принципов работы этого балансировщика. В основе работы SLB лежат сетевые технологии, хотя некоторое количество серверного ПО конечно используется. 
Если кратко то SLB использует  BGP для балансировки запросов между несколькими MUX-ами (ECMP - Equal Cost Multi Path). Далее каждый MUX инкапсулирует клиентский IP пакетик в UDP пакетик (VXLAN) и отправляет их на железный сервер на котором запущена нужная виртуалка(виртуалки с нужным DIP - destinition IP). Далее железный сервер открывает пакет,  в оригинальном IP пакете заменяет Destinition IP на DIP и передает его на сетевой интерфейс виртуалки.   Виртуалка обрабатывает IP пакет, отвечает на него. И хост машина снова перехватывает IP пакет,  и заменяет source IP на VIP (IP балансера). Таким образом клиент не знает истинного IP сервера, и следующий IP пакет тоже прийдет на балансер (VIP). 
        Еще из интересного - Microsoft научила MUX-ы пирится со свичами по BGP протоколу, так что они сами себя анонсируют. В общем из минусов на вскидку вижу только оверхед на VXLAN инкапсуляцию и расходы на NAT. Но от этого никуда не денешься.   

четверг, 18 июля 2019 г.

Microsoft NLB

      Я тут внезапно осознал еще одну особенность которая меня выбешивает в продуктах компании Microsoft. Они всегда используют общие термины для обозначения своих продуктов. К примеру- как называется MS SQL ? В документации Microsoft он всегда называется просто SQL Server. Как будто других SQL серверов вовсе нет. Поэтому когда говоришь о MS SQL всегда приходится уточнять - ты говоришь именно о Microsoft SQL Server, а не в общем обо всех серверах. Этим они убивают двух зайцев, во первых они  "приватизируют" общие термины, во вторых они повышают упоминаемость своего брэнда. Ты как идиот вынужден всегда повторять название компании. С именованием балансировщика они придерживались такой же схемы. Я как идиот требовал от админов название софта который используется для балансировки - а они как попугаи повторяли - NLB, NLB. Я раза с третьего понял что NLB - это не какой-то абстрактный сетевой балансер, а прям вот такая "технология" microsoft. 
         На мой взгляд NLB это такой образец софта который круто выглядит с точки зрения маркетинга и презентации - а с точки зрения сетевых технологий и того как он реализуется - это просто жесть. Собственно принцип работы NLB состоит в том что все IP пакеты идущие от клиента к серверам дублируются на L2  уровне. Как будто вместо свитчей у нас тупые хабы. Для тех кто не так стар поясню что hub - это примитивная версия свитча, которая каждый пакет поступающий на любой из его портов рассылает на все другие порты. Современный свитчи знают к какому порту у них подключен какой mac адрес и посылают пакет именно туда. Таким образом каждый подключенный к свитчу сервер может пользоваться физическим носителем (оптика/витая пара) так как будто других серверов нет. В общем microsoft придумала технологию которая превращает свитч обратно в тупой повторитель. Для этого они придумали три способа которые собственно называются режимами работы NLB:
  • Unicast - в этом режиме они просто генерируют новый mac адрес и присваивают его сразу всем сетевым интерфейсам участвующим в балансировке. Похеру что люди писавшие стандарты прилагали столько усилий чтобы сделать mac адреса уникальными. В такой ситуации свитч понимает что мак адрес соответсвующий виртуальному IP балансера привязан к нескольким портам и при поступлении пакета отправляет его на все порты.  
  • Multicast - это уже более стандартизированная штука. Есть пул mac адресов начинающихся с 03-BF (возможно есть и другие префиксы, я оригинал стандарта не читал)
  • Multicast + IGMP  - это более продвинутая версия предыдущего варианта, которая как вы можете догадаться использует Internet Group Management Protocol. Если в кратце - хосты сами подписываются на широковещательные сообщения по определенному мак адресу. 
Итак, NLB добился того что все пакеты дублируются на все интерфейсы одним из перечисленных выше способов. После этого у вас есть возможность отфильтровать какую-то часть из этих пакетов на уровне сетевого стэка, а какую-то оставить на обработку другим хостам.  Примерно тоже самое но на английском описано вот в этой статье: The NLB Deployment Reference – All you need to know to implement and deploy Microsoft Network Load Balancing К сожалению нормальной документации по NLB у Microsoft нет. Есть только статьи описывающие структуру меню и дискламеры. 

среда, 17 июля 2019 г.

Плёс

         В последнее время я в основном все пишу на профессиональные или около профессиональные темы. Думаю самое время смахнуть пыль с рубрики "Путешествия". Так сложилось что в последнее время путешествовать получается все больше по России. Но и в России можно найти очень красивые места. 
                 Сегодня речь пойдет о маленьком (примерно полторы тысячи жителей) городке в Ивановской области, который называется Плёс. 
Этот городок покорил меня своеобразным шармом провинциального приволжского городка. Думаю мой родной Ульяновск/Симбирск когда-то был примерно таким же. Но к сожалению сейчас Ульяновск уже совсем другой, а вот Плёс все тот же. 
Не смотря на то что Плёс это довольно древний город, сейчас он известен широкому кругу людей не своей историей уходящей в века, а тем что в 19 веке там жил знаменитый художник Исаак Левитан. Кстати жил он там совсем не долго, всего 3 лета. Уже в то время Плёс был "дачным" местом.   Сейчас все стало еще хуже - практически все дома на берегу выкуплены москвичами под "дачи". Люди которые бывали в Плесе лет 20 назад говорят что сейчас это совсем другой, туристический город. Хотя я сам находясь там этого не чувствовал. 
Я наслаждался этим сочетанием волжских просторов и деревенских пейзажей,
В общем Плёс сейчас занимает одно из первых мест в моем личном рейтинге городов Подмосковья. Всем рекомендую хоть разок туда съездить.

Prox mox

          Давеча решил разобраться с prox mox - это вроде open source, должно быть довольно понятно.  В общем хер там был - prox mox оказался только формально open source, а на самом деле по духу это microsoft.  Формально ребята выложили исходники в репозитории - https://git.proxmox.com/,  но кроме самих исходников больше ничего и нету. Есть документация из разряда - маркетинговый булшит, есть документация типа - "руководство начинающего пользователя".  И на этом все. Ребята решили - раз уж мы зарабатываем на консалтинге и саппорте - надо предоставить минимум информации.  В общем никакого описания внутренней архитектуры, ни каких-то открытых интерфейсов ожидать не приходится.  Установка ТОЛЬКО через ISO образы (нет даже элементарных deb/rpm пакетов). Внутри себя он собирает довольно много метрик, и кладет их в RRDTool. Какого-то нормального интерфейса для экспорта этих метрик в Prometheus не предусмотрено. Короче печаль и разочарование. Open source который мы заслужили. 
             Из хорошего - я нашел довольно годную презентацию  от Stefan HajnocziKVM Architecture Overview. После прочтения этой презентации и смежных статей "магии" в моей голове относительно того как работает виртуализация и KVM стало меньше, а понимания больше.