Хабрахабр в гостях у Александра Лямина, QRATOR
Полная версия видео доступна в конце публикации и по ссылке
Это была лишь середина жаркого московского июля, который вот-вот подойдёт к концу. Договорившись с Александром о записи, мы все немного волновались — никогда ещё никто в Хабрахабре не пытался вести предметный диалог с известным техническим специалистом на видео. Не были мы оба уверены и в ходе диалога — в первую очередь потому что, оба Александры, мы никогда не встречались до этого лично. Тем не менее, наша небольшая съёмочная группа прибыла на место назначения, где-то между Беговой и Полежаевской.
Герой сегодняшнего рассказа и диалога родился в городе Ногинск Московской области. Как он рассказал нам, вся его семья по маминой линии из этого региона — на Клязьме деревня была еще несколько веков назад.
Но мама увлеклась романтикой севера и переехала в город Мурманск — это самый большой город за полярным кругом. И так получилось, что Александр родился там же. Отец был моряком, мама — бухгалтером.
Ключевых отправных точек в жизни сегодняшнего героя было две. Первая — это когда в 10 лет он увидел «Роботрон-1820», немецкий компьютер: «Меня сильно удивило, что можно рисовать в телевизоре. Мне стало интересно, что это такое, как можно программировать, что такое операционная система. Так получилось, что семья у меня была не сильно богатая…».
Своего компьютера у Саши не было — он занимался в кружке программирования, в областном Дворце Пионеров. Ездил на Олимпиады по программированию, так же, как и по многим другим естественно-научным предметам.
Зато, хватается он, у одного из первых в городе появился модем — подарили старый-старый терминал DEC VT-220. Так он познакомился с миром сетей.
Второй такой wow-момент был, когда Александр понял, что может разговаривать с человеком, который находится вообще в другом полушарии. Это подвигло его к увлечению сетями — Х25, IP. Он стал сетевым инженером.
Первым местом работы Александра стала компания Инкома (сеть Х25). Там он проработал буквально одно лето, а потом устроился в компанию ComStar, где строил первую в России ISDN-ку. На тот момент (1996 год) считалось, что скорость в 128 Килобит в интернете — это очень круто.
Параллельно занимался консультациями, поучаствовал в создании dial-up пула в Ситилайн — самой большой компании такого рода и на тот момент в Москве. Немножко позанимался спутниковым интернетом. И в 1998 году, в разгар кризиса, Александра пригласили на работу в Московский государственный университет. По его словам, это было существенной потерей денег, но на тот момент сети круче, чем в МГУ, в России не было ни у кого. Поэтому наш герой, не сомневаясь, ушел туда и проработал до 2012 года.
Естественно, жить на университетскую зарплату сложно. Параллельно, как уже говорилось, Саша занимался консультациями, поработал в команде Ханса Райзера, который делал файловую систему Razer FS. И в этот момент ощутил, что для того, чтобы заниматься сетями, нужно еще заниматься операционными системами, которые в этих сетях живут.
Далее работал в разовых проектах, но было несколько крупных и среди них. Можно отметить его сотрудничество с Игорем Мацанюком (IT-Territory), где Александр оказался как консультант и работал part-time. Это была интересная история: «Пришел в гости к своему другу, который там работал. Сидели и обсуждали какие-то технические проблемы у них в офисе на кухне. Заходит какой-то мужик и говорит: «Ты у меня работаешь». Я удивляюсь и говорю: «Да нет, у меня в принципе все хорошо…». Он говорит: «Мне все равно, ты у меня работаешь». Так я и познакомился с Игорем Мацанюком.»
В какой-то момент герой нашего рассказа решил, что можно попробовать адаптировать веб-игрушки для вывода на мировой рынок. К моменту, когда в России только появилась Zynga, у компании, в которой трудился Александр, уже были 4 игры, которые зарабатывали больше $1 миллиона в год, и был отработан технологический стек: «Без ложного стеснения могу сказать: идея того, что можно играть не из нативного клиента, появилась в России».
В 2007 году Александр ушел из IT-Territory, чтобы создать свою консалтинговую компанию. Проработал в таком формате ровно два месяца: «Первый мой заказчик из поисковой системы по товарам предложил стать партнером и техдиректором. Это был короткий период увлечения поисковыми алгоритмами и товарным поиском. Ну, и с 2008 года я занимаюсь Qrator и системами фильтрации трафика».
Именно историю возникновения Qrator и технический подробностей защиты от DDoS и посвящён данный материал, по совместительству — первое видео, сделанной командой «Хабра».
Давайте начнем с момента, который был до Qrator. Я консультировал людей и организации по поводу того, как строить распределенные сетевые приложения. И в 2008 году так получилось, что тот проект, которым я занимался (это был товарный поиск), был продан Microsoft.
По своему предыдущему опыту знаю, что кризис — это всегда время, когда можно заняться тем, что интересно тебе — для души. Потому что все равно большой бизнес делать в этот момент — не совсем удачная идея. В 2008 году мы решили позаниматься исследованием проблематики DDoS, потому что к тому моменту у меня уже была накоплена некоторая база, был опыт. До того с этой проблемой сталкивались регулярно, хотелось изучить её фундаментально. Поэтому я пришел к своему руководству в Московский государственный университет и сказал: «Смотрите, есть такая штука Электронное правительство. И это значит, что в интернет идет критическая инфраструктура».
Если вы не сможете посмотреть почту — это одна история. Если вы не можете обратиться в налоговую со своей проблемой — совсем другая история. У правительственных ресурсов в этом смысле дела обстоят крайне плохо. И я продемонстрировал это. У меня был наладонник Nokia 900 и самописный код на С. Прямо по GPRS-связи зашел на тестовый сайт, который сделал мой знакомый, и вывел его из строя за несколько секунд. Руководство согласилось.
Я притащил в университет свое оборудование, команда была университетская. Университет предоставил инфраструктуру сетевую, за что им огромное спасибо. Изначальный план был — наработать подходы для решения проблемы. Следом университет должен был получить федеральное финансирование и заниматься темой профессионально. Это было начало.
— А в какой момент произошло обособление Qrator? Если говорить юридическим языком, в какой момент вы зарегистрировали ООО, поняв, что это будущий бизнес? Все тот же 2008 год?Нет. Могу даже назвать дату — это было 22 июня 2010 года. Мы приняли на университетскую сеть атаку, которая превышала возможности магистрали сети. И университетское начальство сказало: «Это все очень интересно…, но хорошо, что это 22 июня произошло, потому что учебный процесс закончен, каникулы. А в семестровый период мы не можем такого себе позволить, поэтому нужно что-то делать с проектом: или находить финансирование, или закрывать его».
Это был переломный момент. Я понял, что с этим нужно что-то делать. И плюс ко всему — интересный фактор: производительности сети не хватало. Перенести оборудование с университетской сети без федерального финансирования было невозможно, поэтому я инвестировал собственные накопленные средства в то, чтобы построить распределенную. На первом этапе было три площадки — все они находились в России. Уже 1 сентября 2010 года мы запустили эти площадки в эксплуатацию.
— Насколько вообще математикоемкая и алгоритмоемкая эта задача — защита от DDoS? Я разговаривал со специалистами различного профиля для того, чтобы глубже понять это. И в целом, я слышу, что якобы никакой нетривиальной задачи там нет: это вопрос протоколов, точек в распределенной сети, ширины канала и так далее. Что вы можете сказать по этому поводу?Я тут улыбнусь и прокомментирую это следующим образом. У меня есть слайд, который «гуляет» почти по всем презентациям, на котором мы пытаемся сформулировать, как мы классифицируем DDoS-атаки. Это 4 уровня:
1. транспортный;Начнем с самого первого уровня. Переполнение канала — самый простой и тривиальный способ для того, чтобы и атаковать, и защищаться. Казалось бы, просто достаточно иметь эту полосу. В качестве контрпримера (потому что это задача тривиальная) приведу следующую ситуацию, это реальная история. Заказчик располагается в крупном российском дата-центре. Дата-центр декларирует, что у него 600 гигабит. Это действительно так: набор физических интерфейсов емкостью 600 гигабит. Но на самом деле это не что-то единое, это дискретные интерфейсы, по которым трафик распределяется по каким-то алгоритмам. Что контролируют эту алгоритмы?
2. TCP/IP уровень;
3. уровень инфраструктуры сети;
4. уровень приложений.
Это низкоуровневые механики типа LACP и высокоуровневые типа маршрутизации, например, BGP. И тут, как обычно, дьявол в деталях: самые важные межоператорские стыки у этого центра — самые загруженные. Поэтому хватило атаки, слегка превышающей 30 гигабит в секунду, для того, чтобы сделать нашего заказчика и все остальные ресурсы в этом дата-центре недоступными для большинства аудитории.
Люблю приводить такой пример: атака на полосу — это как удар кулаком в лицо. Больно, ощутимо сразу. Но стоит кулак «распылить», и это уже не настолько ощутимо. Не будет нокдауна. Но как именно распределить трафик — задача не такая тривиальная.
Внутри сети, там, где вы контролируете свои стыки, там, где вы контролируете механику посева по физике, — там все просто. Если мы выходим на уровень магистральной межоператорской связности (тот самый протокол BGP — Border Gateway Protocol), в текущей своей имплементации он больше похож на черный ящик, у которого есть только один метод управления, и он работает совершенно не очевидным способом.
Почему? Потому что так устроен дизайн протокола BGP. Попытаюсь объяснить просто. BGP — стандартный distant-selector протокол, казалось бы. Но на самом деле он отражает в себе не столько топологию сети, сколько материальные отношения между участниками сети. Так называемый local pref — это и есть синтетическая метрика, которую операторы используют для того, чтобы банально заработать больше денег (что естественно для любого бизнеса). Local pref имеет более высокий приоритет, чем ваш единственный метод управления. Соответственно, если вы не знаете, что вы делаете, у вас нет шансов построить сеть, которую можно будет сбалансировать и грамотно распылить большие объемы трафика.
Мы это прекрасно понимали еще в 2008 году, поэтому у нас появилась крайне интересная машинка, которую мы называли между собой «радаром Азимова». Машинка являет собой ни много ни мало очередную модель интернета, которая моделирует связность сети на межоператорском уровне. Грубо говоря, она в состоянии решать задачу предсказания пути трафика из любой точки интернета до любой точки интернета. И это позволяет нам строить нашу сеть не эмпирически, как делает сейчас большинство операторов связи, а используя математическое моделирование. Мы точно знаем, где нам надо поставить следующую точку на карте так, чтобы она была эффективна и с технической точки зрения, и с точки зрения бизнеса.
Это только первый, самый базовый уровень. Дальше, если двигаться вверх, — стейт-машина TCP/IP. Стейт-машина устаревшая, при разработке которой использовался неформальный подход, сдизайненный эмпирически. Даже тот самый знаменитый алгоритм Нагля — растем линейно, падаем экспоненциально по скорости передачи — тоже был выведен на кончике пера, чисто эмпирически. Наглю казалось, что так будет хорошо, и так было хорошо достаточно долгое время. Стейт-машина устаревшая, имеющая кучу уязвимостей, которые тоже можно проэксплуатировать. Поэтому мы переизобрели для себя TCP/IP. Наша версия наиболее устойчива к различным видам сетевых атак.
Следующий уровень — инфраструктура сети. Инфраструктура сети — тот интеллект, который принимает решение о том, как именно обрабатывается и направляется пакет. Сюда относятся и протоколы маршрутизации, и само оборудование. Он тоже может быть атакован, потому что и алгоритм маршрутизации, и алгоритм кеширования маршрутизации могут быть, в свою очередь, подвергнуты атаке на отказ в обслуживании, либо подвергнуты обычной атаке с подменой аутентичной информации. Это тоже может привести к печальному финалу, отказу в обслуживании для конечных пользователей.
Если вы можете отправить пакет сетевому оборудованию, которое его должно принять и как-то обработать, наверняка вы можете найти частный случай, который заставит это оборудование потратить все свободное процессорное время на обработку ваших данных. Это наиболее перспективная в ближайшие несколько лет техника проведения DDoS-атак. Помимо того, чтобы просто выводить сетевое оборудование из строя, можно еще подвергнуть таблицы маршрутизации несанкционированному воздействию, то есть поменять их непредусмотренным способом.
И тут опять смотрим… Протокол BGP, версия 4, изобретен в позапрошлом десятилетии. Устаревший, крайне уязвимый. Нам это было очевидно еще в 2008 году. Но, к сожалению, в отличие от предыдущего уровня, здесь невозможно этот протокол переписать, потому что, переписав только свою часть, мы изменим и обеспечим устойчивость только своей сети (что мы, собственно говоря, и сделали). Но весь остальной интернет нам неподконтролен. Его мы можем либо мониторить на предмет злонамеренного воздействия (что мы и делаем для всех наших заказчиков, используя тот же самый Qrator.Radar), либо изменить его (что мы тоже сейчас делаем).
Здесь есть единственный способ, которого я лично дико боялся и продолжаю бояться. Потому что если вы хотите сделать новый интернет-стандарт, у вас есть только одна дорога: вы должны написать драфт этого стандарта, податься с ним в IETF (Internet Engineering Task Force) и убедить IETF, свою орг. группу, всех операторов связи и инженеров, которые в ней работают, что вы делаете правильное дело, которое а) решает проблему, б) делает это эффективно. И это то путешествие, в котором мы сейчас находимся.
Тот стандарт, с которым мы работаем сейчас, — это самая простая и маленькая идея из тех, которые витают у нас в голове на данный момент. Потому что даже с тривиальными идеями, особенно новичкам (а мы именно новички в ИТ, несмотря на многолетний опыт), бывает очень непросто. Думаю, что как только мы получим какую-то обратную связь (любую: позитивную или негативную, например, выход другого конкурирующего предложения), для нас это будет хорошо. Потому что нам было важно заварить эту кашу, обозначить, то здесь есть проблемы, надо их решать, и в конечном итоге сделать BGP безопасней. Неважно, произойдет ли это с помощью наших идей или идей конкурирующей команды.
Конкурирующая команда — более, чем достойная. Это люди, которые работают в NIST, Американском институте стандартов и времени. У них тоже есть идеи, они не плохие — они просто другие.
И последний уровень, самый верхний, — уровень приложений. Как правило, на данный момент большинство приложений, существующих в сети, — это HTTP-based, то, что мы привыкли называть «Web«ом». Там тоже очень интересная проблематика. Но это не только Web.
И здесь я приведу историю, которая позволяет легко понять масштаб проблемы.
В 2008 году у меня была очень простая и понятная идея: чем отличается робот от неробота? ККапча — очень грубый инструмент. В Советском Cоюзе роботы решают капчу гораздо лучше, чем люди. Она раздражает меня лично, и ее можно легко обойти, причем в автоматическом формате. То, что такие методы прохода капчи возникнут, было очевидно еще в 2008 году.
Поэтому в качестве основной я выбрал простую идею: роботы видят веб-страницу
иначе, чем люди. Когда вы открываете веб-страницу,
1. вам требуется время на то, чтобы обработать ее содержимое;Я собрал данные на тех веб-приложениях, которые были мне доступны, и гипотеза подтвердилась: люди ведут себя совершенно предсказуемо.
2. вы реагируете вполне определенно эмоциональным образом на ее оформление;
3. вы совершаете какие-то действия с этим приложением.
Если вы представите себе веб-сайт как вершино-ориентированный граф, циклический, огромный, где каждая страничка — узел графа, каждый элемент — лепесток, и заложите в переходы две величины (время для того, чтобы совершить переход, и вероятность перехода), то вы обнаружите, что люди ведут себя предсказуемо. Они явно отличаются от ботов. Причем, неважно, каких. Даже если вы напишете робота, который совершает случайные переходы, либо какие-то другие переходы. Это будет отличаться от человека ровно потому, что в основе лежит простая идея: роботы видят веб-страницу иначе, чем люди. Этот подход мы использовали как самый первый алгоритм для обнаружения аномалий и их купирования.
Почему так легко о нем можно рассказывать… Если вы представите себе современный веб-сайт (это сотни тысяч веб-страниц), построите карту для каждого пользователя, получите объем данных, который сейчас невозможно уместить в коммерчески доступные объемы памяти.
Естественно, мы как-то научились этот граф схлопывать, не теряя при этом существенных данных. Это было в 2008 году. С тех пор у нас появилась отдельная команда математиков — 4 человека, которые занимаются конкретно алгоритмикой обнаружения аномалий и выделения аномального трафика.
Могу уже с гордостью сказать, что тот алгоритм, про который сейчас рассказал, в ретроспективе кажется чрезвычайно примитивным и неэффективным. К счастью, в нашей команде с математикой у меня, наверное, хуже всех.
С полосой все просто, казалось бы: как только вы научились распылять атаку, она перестает представлять для вас существенную сложность, потому что, как правило, в этих атаках все необходимые данные, на основе которых вы можете принять решение по трафику (хороший он или плохой), содержатся в теле одного пакета. Этот класс атак — самый тривиальный если вы решили задачу о том, как грамотно распылить трафик. Но для того, чтобы грамотно его распылять, нам пришлось построить модель интернета.
На мой взгляд, задача крайне интересная… Кстати, вы можете познакомиться с этой моделью интернета. В какой-то момент человек, который занимается PR нашей компании, сказал: «Саша, у вашей компании должен появиться блог». Я подумал и сказал: «Знаете, мы в принципе можем писать блог… Но есть такое дело: либо ты пишешь блог, либо ты пишешь код. Мне милее второе, потому что нас мало и нужно писать код. Поэтому давайте мы что-нибудь придумаем. Вот у нас есть модель интернета, давайте мы ее сделаем в виде блога».
И так мы сделали то, что сейчас можно найти на сайте radar.qrator.net. Это, в принципе, модель интернета.
Основная часть наших программистов — это не веб-программисты. Веб-программистов у нас немного — до прошлой недели было трое, ейчас стало четверо. Ресурсы крайне ограничены, за них идет постоянная борьба, но, тем не менее, мы выделили часть людей и выложили эту модель в свободный доступ.
Дальше было, кстати, очень интересно. Первый фидбэк, который я получил про нее, — это обратная связь от коллег из Renesis, которые уточнили: «Александр, а как вы видите вашу компанию: как scientific-лабораторию крупной американской компании или как самостоятельную?». На что я рассмеялся и сказал: «Ребят, это даже не наш продукт, мы на этом деньги не зарабатываем».
На каждом уровне есть свои математические вызовы. Задача может казаться простой только на первый взгляд. Я встречал много коллег, которые считают, что стоит научиться быстро обрабатывать пакеты, и проблема DDoS для вас решена. На самом деле, нет.
— Мы поговорили про способы защиты, потому что вы этим занимаетесь, и это классно. А какие способы атаки наиболее распространены сегодня? От каких угроз ваши продукты, в частности, защищают веб-сайты, приложения, дата-центры?Ботнет был самым популярным инструментом для проведения атаки 5 лет назад. По моей классификации — это первый уровень. То есть, основная ваша задача — научиться распылять трафик по периметру вашей сети. Как только вы научились этому жесту, отражение таких атак не представляет никакого труда, потому что, как я уже говорил, для отражения атаки на транспортном уровне достаточно данных в одном пакете. Никаких сложных моделей для эффективного противодействия строить не нужно.
Но даже тот тренд, который мы сейчас наблюдаем, — уже в прошлом. Он пошел на спад с начала 2016 года. Это объясняется тем, что атаки, превышающие сотни гигабит, создают проблемы не только жертвам, но и всем окружающим, в том числе операторам связи. Операторы связи, сильно озаботившись этой проблемой, начали купировать у себя в сетях такие сервисы, которые можно использовать для проведения атак.
Имеем классическую картину: конечный ресурс, количество которого с каждым днем снижается, и растущий спрос на него — скрипт-кидди, которые используют его технику для проведения атаки. Сейчас количество атак растет, максимальная их амплитуда падает.
На мой взгляд, прямо сейчас идет разворот тренда, и великолепно это иллюстрирует недавняя успешная атака на Blizzard. И это несмотря на то, что Blizzard считали, что у них суперготовность Blizzard, в свою очередь, прикрывал TNT. Атака была проведена с использованием того, что сейчас журналисты называют интернетом вещей (IoT). Это на самом деле, «сборная солянка» мелких устройств с дырявыми прошивками, которые атакующая сторона собрала в кулак и провела успешную атаку. Так что, тренды постоянно меняются.
— Какого склада ума должен быть человек, чтобы ему было интересно этим заниматься? Какие люди занимаются этим у вас? Насколько я понимаю, ваша работа сильно завязана на программно-аппаратном комплексе. Какие люди являются критически важными для вас, для того, чтобы все работало хорошо?
Одно только могу сказать, что мы — компания инженерная. Для нас важны инженеры и математики. А еще лучше, если человек совмещает в себе и то, и другое. Минимальное требование — человек не должен бояться математики. Если ты не боишься математики — это уже неплохо.Могу выделить несколько групп, которые у нас работают:
1. Математики решают задачи кластеризации, анализа данных. Часто приходится делать что-то в реал-тайме или близко к реал-тайму.
2. Низкоуровневое программирование и программирование PLIS. Это инженеры, которые могут писать эффективный код быстро и качественно. У нас, как правило, приживаются люди с опытом спортивного программирования.
3. Команда, которая пишет то, что мы называем инфраструктурой. Это, собственно говоря, и есть движок Qrator«а. Здесь важен подход прагматичный, deutsch-инжиниринг с пониманием того, что мы с этим кодом будем делать дальше. Модульные инфраструктуры способны заглянуть в терминах развития своего кода не в «завтра», но и в «послезавтра».
В отличие от многих других решений, мы стоим инлайн. Мы обрабатываем трафик наших заказчиков постоянно, каждую секунду. Если где-то у нас возникают проблемы, заказчики это непременно почувствуют и это выльется, в конечном итоге, в потери. Поэтому требования к архитектуре, качеству кода и инфраструктуре, конечно, космические. То есть, оперировать Qrator«ом — это сродни полету в космосе: ничего не должно отказывать. Если какой-то из модулей выходит из строя, система, как правило, автоматически диагностирует его и выводит из обслуживания. По крайней мере, к этому мы стремимся. Это инфраструктура.
4. Есть еще группа сетевиков-математиков, которые разрабатывают и строят модель Radar«а. По сути, это такой внутренний продукт, у которого мы являемся единственным заказчиком, потому что именно эти люди говорят, где и когда зажжется следующая точка на глобусе, где мы запустим следующий центр очистки трафика.
5. Я говорил уже, что у нас очень мало веб-программистов. Сейчас их стало четверо — это уже полноценный отдел. И вся эта математика, «колокольчики» и «свисточки» не имеют смысла, если вы не можете это представить в конечном виде пользователю. Достаточно посмотреть на тот же Radar или Qrator, где объем данных, которые нужно представить пользователю, составляет более 6 Тбайт метаданных в сутки. Их можно и нужно представлять в виде пользовательского интерфейса так, чтобы конечный человек с самым разным уровнем технологической подготовки мог это воспринять. Или графы связности в том же самом Radar«е — не самая простая визуализация.
Кстати, буквально в следующем месяце у нас будет очередной итерационный релиз. Большая его часть — новый метод визуализации. Я надеюсь, что в этот раз мы все-таки эту задачу взяли, но взяли только с четвертой попытки. Это не самая простая задача.
6. Группа эксплуатации — это наш интерфейс ко всем организациям: к партнерам, операторам связи, к заказчикам. Это те люди, на которых выпадает, наверное, больше всего стресса, которые оперируют в формате 24/7, решая иногда сложнейшие задачи по траблшутингу. Поэтому обычно люди, приходящие на должность инженера NOC, несколько удивлены уровнем задач, которые мы им даем на собеседовании. Нужно понимать, что это траблшутинг не только нашей собственной сети, но и окружения, всего того зоопарка оборудования, который реально может встретиться в энтерпрайзе у заказчиков.
— Насколько я понимаю, вообще для оператора связи и, в частности, для дата-центра, который позволяет арендовать у себя оборудование для предоставления услуги потребителю, данная услуга не была обычной изначально. Она появилась в их пуле, потому что возникала проблема, которую кто-то другой решал эффективно. Как вы вообще между этих двух огней существуете?С одной стороны, они — ваш партнер, на точках которого вы работаете и взаимодействуете на площадках. С другой стороны, они — ваши рыночные конкуренты, которые имеют больше возможностей продавать свои услуги собственным потребителям. Но их услуги в целом дороже, потому что они без глубокого понимания используют сторонние коробочные решения, покупая их или лицензируя. Как, на ваш взгляд, выглядит этот ландшафт, и насколько эффективно вам удается совмещать эти две роли?
Хостинги и телекоммуникационные компании для нас при текущем положении дел — однозначно партнеры. Мы просто не рассматриваем их как конкурентов. И, как я уже говорил, сама проблематика динамична в поле игры. Давайте посмотрим на ситуацию в ретроспективе…
Вот появилась проблема DDoS, появилась эффективная механика SYN-flood, направленная на TCP/IP стек. Как отреагировала индустрия? Бернштайн придумал SYN cookies. Их можно включить прямо на хосте и эффективно решить проблему. Скорости SYN flag росли. Обычные сервера перестали справляться. Появились коробочные решения, которые вставали в стойку к заказчику. И к коробке, которая моргает лампочками (Firewall), добавилась коробка DDoS-mitigation. Это тоже решило проблему, но только на какой-то период.
Скорости, packet rate атак продолжали расти, и тот канал, который приходил в дата-центр или в стойку заказчика, перестал справляться. Рынок отреагировал на это следующим образом: устройства, услуга, оборудование мигрировали в сеть операторов связи. Поставщиком услуги стали операторы связи, сеть которых, как правило (не берем в расчет таких гигантов, как Google или Яндекс), мощнее сетей заказчиков.
Это то состояние дел, когда мы с операторами связи, как вы говорите, являемся и партнерами, и конкурентами. Это уже ретроспектива.
Скорости атак продолжали расти, и за последнее десятилетие они выросли на порядок, или даже порядки. Для примера можно сказать, что та атака, которая была произведена на нашу площадку в университете, едва превышала 14 Гигабит в секунду. На данный момент мы сталкиваемся регулярно с атаками, которые превышают 100 Гбит, 140 Гбит, 300 Гбит.
Недавно наши коллеги из Микапсулы предоставили данные об атаках, превышающих 500 Гбит. В принципе, на мой взгляд, операторам связи становится экономически невыгодно строить сети, способные выдерживать такие атаки. Логика развития сети оператора связи так выглядит: «У меня есть заказчики (например, в городе Одинцово). Протяну-ка я туда волокно». Заказчиков становится больше, туда тянется ядро сети, и оттуда выходят лучи следующего access-level. Оператор связи всегда тянется за своей клиентской базой и обязательно строит магистраль. Это очень дорого.
Как развивается Qrator? Он ставит точки туда, где можно перехватить паразитный трафик как можно раньше. Как взлет баллистической ракеты: на момент разгона мы ее перехватили, купировали трафик атаки в том регионе, откуда он происходит. Таким образом мы создаем меньше нагрузки на инфраструктуру сети и можем получить получше цены от операторов в регионе. Потому что, приходя в регион, мы говорим: «Дорогие операторы связи, мы любим держать наш трафик локально даже больше, чем вы. Это не шутка. Трафик, имеющий происхождение в регионе, останется в регионе». И это касается не только трафика атаки, но и легитимного трафика.
Логика развития сети диаметрально противоположная, поэтому никаких пересечений у нас нет.
С точки зрения бизнеса наши затраты на развитие сети существенно ниже затрат любого оператора связи. А эффективность ее работы — выше.
— Как много сегодня у вас точек присутствия? Какие планы до конца 2016 года?В любом деле главное — не расшибить лоб. Точка должна себя оправдывать и быть расположена оптимально. У нас есть коллеги, которые гонятся за количеством этих точек по миру. Нужно четко понимать, что это не больше, чем маркетинг. На самом деле, имея меньше количество точек, покрытие сети мы имеем сравнимое. Расходы на эксплуатацию существенно ниже.
В том же Radar«е вы можете сделать запрос про Qrator и увидеть все наши точки присутствия по операторам связи, по географии: Сан-Хосе, Даллас, Эшборн, Амстердам, Стокгольм, Россия, Казахстан, Гонконг. В планах — до конца года обязательно открыть точки присутствия в Токио и Сингапуре. Без них, к сожалению, наше присутствие в Юго-Восточной Азии не является полным. На следующий год, наверное, будем смотреть в сторону Южной Америки.
— Насколько хорошо сегодня этот рынок растет?Рынок растет. Рынок растет динамично. Мы в последние пять лет росли, несмотря на кризис, минимум на 100% в год. Но в этом году мы почувствовали, что российский рынок близится к заполнению. Это было предсказуемое событие. Поэтому мы начали экспансию. Мы стараемся двигаться на Запад и настраиваемся на Восток.— Про атаку на российские СМИ в 2011 году… Как вы поучаствовали в этой истории? Каково было ваше место в ней? Я могу ошибаться, но мне кажется, про вас тогда широко услышали многие…
Я, наверное, не сказал бы, что 2011 год был поворотным с точки зрения бизнеса. Мы, когда стартовали, сделали все ошибки, которые только можно было. В частности, традиционная ошибка любого стартапа — переоценка рынка. Я считал, что рынок уже сформировался. Мы стартовали с планами, нацеленными на mass market, и просто промахнулись.
Потом пересобрались, переориентировались на средний сегмент, потому что компания была совсем молодая: не было ни имени, ни административных ресурсов, ни каких-то связей. Да и ресурсов на пиар и маркетинг у нас тоже не было. В течение первых четырех лет жизни компании бюджет на маркетинг и пиар стабильно составлял ноль.
В 2011 году приключилось интересное событие, которое наделало много шума в прессе, но на бизнесе, на самом деле, не сильно сказалось. Это были парламентские выборы в России. В принципе, мы понимали, что общество идет к выборам в достаточно «нагретом» состоянии, будут возмущения и выступления.
Мы живем в информационном обществе. Возможность заблокировать распространение какой-либо информации, пусть даже и временно, когда общество проходит через свои критические точки, может сказаться на результате.
Выборы — отличный пример, поэтому мы к ним готовились. Мы понимали, что что-то будет. За месяц до выборов у нас были отменены выходные, было организовано 24-часовое дежурство. Но все прошло крайне спокойно, было все тихо. И в день выборов я решил, что все закончилось, и пошел с семьей в театр. В первые 15 минут у меня начинает звонить телефон. Я его поднимаю и понимаю, что для меня на сегодня там театр закончился и начался в другом месте. Я взял ноутбук и побежал в ближайший Старбакс.
24 часами позже мы собрали у себя в сети фильтрации все, какие только можно российские СМИ, которые принято называть независимыми.
На мой взгляд, журналисты — это очень плотное, единое сообщество: о нас они узнали (как это работает, кому нужно звонить), просто общаясь друг с другом.
Отработали мы отлично. Мы к этому событию были готовы технически. Все было вполне предсказуемо: каких-то хайлайтов я бы не привел.
Интересно, что в тот же момент к нам пришел человек, который представился корреспондентом The Wall Street Journal. Он два часа задавал мне очень въедливые вопросы. Я сначала не поверил, думал, что это какая-то разведка индустриальная. Когда статья не вышла на следующей неделе, я про это и забыл. Но через неделю про нас вышла заметка. У меня бумажная версия этой газеты где-то дома лежит.
Мне позвонили друзья и сказали: «Саша, поздравляю, отличная джинса». На что я удивился и сказал: «У ме
