Круглый стол: «Как и зачем мы выходили на багбаунти»

Когда и почему вы решили выйти на багбаунти?

Тимофей Черных: Ozon впервые вышел на багбаунти (платформу HackerOne) в 2021 г. Всего три года назад это казалось чем-то новым и необычным: далеко не каждый на рынке мог этим похвастаться. Для многих идея звучала дико: «Кто-то будет тебя ломать, а ты еще и должен за это платить?!»     

На HackerOne мы прожили до начала 2022 г. Далее был период тишины, во время которого российский бизнес адаптировался под новые реалии. Затем, осенью 2022-го, мы запустили программу на отечественной платформе, а еще через год вышли на Standoff Bug Bounty. Сейчас мы получаем много отчетов через Standoff Bug Bounty.

Александр Шилов: Когда Positive Technologies запустили Standoff Bug Bounty, мы решили сразу выходить туда. Нас интересовало направление багбаунти, потому что у нашей компании есть торчащие наружу сервисы, которые представляют потенциальную угрозу. У нас уже был опыт устранения уязвимостей по результатам пентестов, но мы понимали, что на багбаунти все будет иначе. К счастью, команда Standoff Bug Bounty быстро развеяла наши сомнения и оказала необходимую поддержку, в том числе в части триажа. Мы шагнули в неизвестность с закрытыми глазами, и оказалось, что бояться было нечего!

Елизавета Дудко: Все началось в 2018-м, когда мы открыли приватную программу, чтобы поощрять энтузиастов, присылающих информацию об уязвимостях. Исследователи узнавали о ней через нашу поддержку и сарафанное радио. Так банк прожил три года: все это время мы улучшали и дорабатывали внутренние процессы. В 2021-м мы поняли, что готовы к выходу на HackerOne в приватном режиме, а в 2023-м открыли публичную программу на Standoff Bug Bounty.

Сергей Мигалин: Однажды багхантеры написали нам об ошибке, но нормального способа отблагодарить их на тот момент не было. Кроме того, мы заметили, что традиционные тесты на проникновение уже не приносят серьезных результатов. Мы поняли, что находимся на том уровне ИБ-зрелости, когда нам требуется экспертиза сотен исследователей, чтобы найти труднодоступные уязвимости. К запуску готовились основательно: проанализировали возможности площадок, выяснили порядок цен, еще раз протестировали наши сервисы и договорились с командами разработки об оперативном взаимодействии.

Юлия Гайсина: Мы запустили свою программу в 2019 г. Это был логичный шаг, потому что к тому моменту компания достигла высокого уровня ИБ-зрелости, в том числе в части безопасной разработки. Мы начали с приватной программы, доступной только для участников ruCTF, а затем опубликовали багбаунти на нашем сайте. Поток исследователей был стабильным, поэтому обошлись без дополнительных рекламных активностей. Когда стало ясно, что зрелость ИБ-процессов и размер команды позволяют работать с большим количеством отчетов, мы запустили приватную программу на Standoff Bug Bounty.

Алексей Румак: В 2019 г. мы хотели с ноги зайти на рынок багбаунти: вели переговоры с HackerOne и Bugcrowd, но площадки запросили неадекватные деньги. Тогда мы запустили собственную программу и разместили ссылку на нее в специальном репозитории на GitHub. Благодаря этому нам удалось привлечь исследователей со всего мира, в первую очередь из Индии и Пакистана.

Вас не пугает, что уязвимости ищет неограниченное число багхантеров?

Александр Шилов: А что здесь страшного? Мы же платим за поиск, а не за эксплуатацию. Чем быстрее найдут, тем быстрее закроем — это лучше, чем если уязвимостью воспользуются злоумышленники. Такая вот простая философия.

Елизавета Дудко: Мы постепенно вкатывались в багбаунти: прежде чем запустить публичную программу, вышли на ограниченный круг исследователей. Соглашусь с Александром: бизнес и так постоянно подвергается атакам недоброжелателей, так что нам выгодно, чтобы нас проверяло как можно больше багхантеров — для обеспечения максимальной защищенности систем.

Тимофей Черных: Нет, к тому же у нас сильные команды application security, infrastructure security и security operations center, которые добавляют уверенности в себе. 

Юлия Гайсина: Мы не боялись: наоборот, я использовала багбаунти как дополнительную мотивацию для внутренних ИБ-команд. Ребята понимали, что теперь уязвимости ищут не только они, и оперативнее закрывали дыры в инфраструктуре. Никакого негатива в отношении багбаунти со стороны коллег я не заметила. 

Как вы встраивали багбаунти во внутренние процессы компании?

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

Тимофей Черных: Выход на багбаунти не оказал серьезного влияния на наши внутренние процессы. Для нас это просто новый инструмент для поиска уязвимостей, который позволяет находить их быстрее. 

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

Юлия Гайсина: У нас уже были налажены нужные процессы, на части репортов просто появилась отметка «пришло с багбаунти».

Алексей Румак: У нас уже была red team, так что изобретать ничего принципиально нового не пришлось. С тех пор наша ИБ-команда стала больше и взяла на себя триаж уязвимостей. Но если мы решим перейти с приватной программы на открытую, придется набирать дополнительных триажеров. 

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

Как у вас строится работа с репортами багхантеров?

Сергей Мигалин: Все начинается с верификации и оценки критичности уязвимостей. Если дефект действительно есть, мы проверяем его по базе: возможно, мы уже о нем знаем и работаем над устранением. Если нет, мы регистрируем баг и уведомляем об этом команду разработки. При необходимости устанавливаем виртуальный патч на WAF и ставим уязвимость на мониторинг в SOC. Если понимаем, что аналогичные уязвимости могут присутствовать и в других сервисах, также обновляем правила для сканеров DAST/SAST. 

Процесс устранения всех дефектов выглядит примерно одинаково, а вот их приоритет зависит от множества факторов. Например, флаги Internet-faced и exploit exists его повышают, поэтому уязвимости, выявленные в рамках багбаунти, мы обычно устраняем быстрее.

Тимофей Черных: Мой коллега Дмитрий Емельянов в апреле прошлого года опубликовал на Хабре подробный материал по теме. Сначала отчет багхантера попадает к одному из дежурных и отправляется на анализ на первую линию SOC. Далее мы заводим риск-тикет (внутренний процесс управления уязвимостями) и обогащаем информацию в репорте. Затем определяем severity (влияние дефекта на работоспособность сервиса) и решаем, согласны мы с оценкой автора отчета или нет. Отмечу, что первичную переписку с багхантером ведет первая линия SOC, потому что именно им нужно воспроизвести отчет. 

Затем следует скоринг репорта по CVSS 3.1. Если это крит, заводим инцидент, который требует немедленного решения. Также проверяем соседние сервисы на наличие аналогичных уязвимостей. 

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

Александр Шилов: Сначала репорты оценивает команда триажа Standoff Bug Bounty. Большинство отчетов отсеивается на этом этапе: зачастую уязвимости, которые присылают исследователи, либо не несут реальной угрозы, либо уже находятся в стадии исправления. Затем мы передаем отчеты в отдел разработки, анализируем и исправляем баги. 

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

Елизавета Дудко: Репорты попадают в нашу тикет-систему, каждому назначается внутренний триажер. Если уязвимость описана хорошо, проблем не возникает: заводим баг и пускаем его по VM-процессу. Далее триажер определяет сумму вознаграждения, которую должен одобрить один из ответственных за багбаунти. Если выставленная исследователем критичность не совпадает с нашей оценкой, мы собираем встречу, обсуждаем кейс и вместе определяем сумму вознаграждения. В процессе можем почелленджить друг друга, чтобы максимально точно и честно оценить репорт.

Часто ли случаются разногласия с исследователями?

Елизавета Дудко: Достаточно редко. Мы всегда подробно объясняем свою позицию и прислушиваемся к аргументам исследователей. Иногда пересматриваем свои решения в пользу багхантеров и признаем ошибки. Мне кажется, важно изначально строить доверительные отношения с исследователями и честно оценивать уязвимости, тогда в спорных ситуациях у вас будет определенный кредит доверия.

Тимофей Черных: Помню, однажды в нашей практике было долгое разбирательство с отчетом: багхантер не был согласен с назначенной нами выплатой. Я понимаю, что каждый хочет сдать критикал-репорт, получить внушительный гонорар и спокойно жить, но давайте откровенно: действительно интересные и сложные баги встречаются редко.

Александр Шилов: В этом плане нам очень помогает команда триажа: партнеры советуют, как лучше поступить в той или иной ситуации, а нам остается внимательно слушать. Если начинается конфликт, триажеры берут инициативу на себя и предлагают компромиссные варианты решения проблемы. 

Юлия Гайсина: Это единичные случаи, потому что мы уважительно относимся к багхантерам. Как правило, корректный и доброжелательный ответ сильно снижает вероятность конфликта. Мы сталкивались с багхантерами, которые, скажем так, специфически подавали свои отчеты: в грубой форме, порой даже матерились. Я объясняла, что лучше поддерживать другой тон общения, после чего исследователи извинялись, и конфликты угасали. Один из этих багхантеров впоследствии попросил написать ему благодарственное письмо от лица компании — это было трогательно :)

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

Расскажите о самых интересных и неожиданных уязвимостях, о которых вы узнали в рамках багбаунти.

Юлия Гайсина: За пять лет их было много: из интересного на ум приходит уязвимость, связанная со ссылками на сброс пароля. Идентификатор сброса пароля зависел от времени, злоумышленник мог это предугадать и подобрать его, чтобы скомпрометировать учетную запись произвольного пользователя. Через несколько дней тот же исследователь обнаружил Host Header Injection, которая тоже позволяла воровать ссылки на сброс пароля. 

Александр Шилов: В этом году мы получили отчет, который касался неожиданной zero-day-уязвимости в сервисе онлайн-конференций. Когда зарубежные вендоры ушли из России, мы перешли на отечественный продукт, в котором исследователи и нашли уязвимость. Руководство осознало, что хакеры могут подключиться к совещаниям и получить доступ к конфиденциальной информации — многих это повергло в шок. 

Если исследователи найдут у вас ряд критически опасных уязвимостей, полетят ли головы ваших безопасников? 

Тимофей Черных: Провокационный вопрос, так что я воздержусь :) 

Юлия Гайсина: За пять лет исследователи нашли у нас около десяти критических уязвимостей, но все головы на месте :) Для нас это зона роста.

Александр Шилов: Мы участвуем в багбаунти, чтобы находить уязвимости — это нужно поощрять, а не стучать за это по голове.

Алексей Румак: В первую очередь полетят головы разработчиков, а не безопасников, потому что ребята из ИБ придут к ним ругаться: как они это допустили? 

Сергей Мигалин: Все найденные уязвимости — это повод учиться и становиться лучше. Поэтому нет, головы не полетят.

Во сколько вам обошлась самая дорогая уязвимость? 

Сергей Мигалин: 350 тыс. руб., но выплаты зависят от влияния уязвимостей на конкретные сервисы, поэтому в теории мы готовы заплатить даже больше. Например, сейчас в нашей программе можно получить 750 тыс. руб.: для этого нужно найти RCE и при этом обойти WAF. 

Александр Шилов: Точную сумму назвать не готов, но сумасшедших бюджетов у нас нет — мы растем постепенно. Так, с момента запуска программы наш бюджет на багбаунти уже вырос на 20%.

Елизавета Дудко: Самую дорогую уязвимость нам сдали в рамках Standoff Hacks, когда мы повысили максимальную выплату за криты до 2,4 млн руб. Но это единичный случай — потолок наших вознаграждений прописан в политике программы. 

Тимофей Черных: На российских площадках сначала установили потолок в 250 тыс. руб., но недавно повысили до 500 тыс. руб. Пока что полмиллиона никто не забрал.

Юлия Гайсина: Сейчас мы оцениваем криты в несколько сотен тысяч рублей. По максимуму платим, только если уязвимость набирает 10 баллов по CVSS 3.1 либо несет действительно серьезный импакт на бизнес.

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

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

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

Елизавета Дудко: Это работает для критических уязвимостей, а баги низкого и среднего уровня обычно не несут существенной угрозы. Но мы все равно за них платим, потому что цепочка из низкоимпактных уязвимостей может привести к весомому ущербу.

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

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

Ваши ожидания от багбаунти оправдались? Чего пока не хватает?

Тимофей Черных: Ожидания оправдались: это относительно стабильный поток репортов, который помогает нам смотреть на компанию с разных сторон и своевременно выявлять уязвимости. При этом рынку в целом не хватает ИБ-исследователей: их мало, за них все борются, и из-за этого безумно растут цены.

Елизавета Дудко: Наши внутренние команды и СТО компании довольны результатами. Благодаря багбаунти мы находим уязвимости, которые почти невозможно выявить на тестовых стендах. Кроме того, программа позволяет нам оптимизировать ресурсы ИБ-подразделения, чтобы направить их на решение других важных задач.

Александр Шилов: Не оправдались только ожидания, что нас сломают, и компания не сможет работать — они оказались фантомным страхом :) Так что в нашем случае правильнее говорить не об ожиданиях, а об отличных результатах. 

Юлия Гайсина: Раз в полгода я оцениваю, сколько денег мы потратили на багбаунти и какую выгоду получили. Пока не было моментов, когда мы хотели бы свернуть программу: напротив, сейчас мы выходим на Standoff Bug Bounty и расширяем ее. В 2022 и 2023 гг. у нас существенно вырос поток репортов, а в 2024-м снизился. Тогда мы решили: раз можем обрабатывать больше, надо выходить на стороннюю платформу. 

Сергей Мигалин: Ожидания однозначно оправдались, особенно в части Standoff Hacks — огромное спасибо организаторам! Багбаунти, конечно, не заменяет другие способы проверки защиты, но отлично их дополняет. Единственное, чего этому инструменту на данный момент не хватает, — это популяризации среди российских исследователей. 

Как понять, что компании пора на багбаунти?

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

Елизавета Дудко: Во-первых, если пентесты начинают приносить меньше интересных или критических уязвимостей, и вам хочется подключить к процессу больше исследователей. Во-вторых, если вы понимаете, что в компании уже выстроены базовые ИБ-процессы и vulnerability management.

Какие ресурсы нужно выделить, чтобы почувствовать реальный эффект от багбаунти?

Александр Шилов: Бюджет может быть разным — все зависит от размера компании. К примеру, небольшой организации хватит миллиона рублей и одного ИБ-специалиста, который будет курировать программу. Также, чтобы привлечь больше исследователей, можно устраивать разные турниры и всячески подсвечивать присутствие вашей компании на платформе багбаунти. 

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

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

Тимофей Черных: Сначала необходимо провести пентест и посмотреть, что в компании нет вопиющих уязвимостей. Затем оценить внутренние ИБ-процессы, необходимые для выхода на багбаунти: вы должны понимать, кто будет править баги, как будет выстроено взаимодействие с разработчиками и т. д. Затем нужно определить бюджет, и только потом начинать переговоры с конкретной платформой. 

Суммы вознаграждений могут варьироваться в зависимости от бюджета и размера компании, золотой середины здесь нет. Важнее всего — заинтересовать багхантеров. 

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

Юлия Гайсина: Сейчас мы не можем выплачивать вознаграждения зарубежным багхантерам, но репорты от них принимаем и честно предупреждаем: заплатим сразу, как появится возможность. Несколько раз исследователи отвечали: «Деньги не так важны, но, если у вас будет зал славы, обязательно меня отметьте». 

В целом я рекомендую ориентироваться на рынок и уровень зрелости вашей компании: если вы давно не искали уязвимости, бюджет в 1 млн руб. может улететь за пару недель. Наш бюджет за последние пять лет вырос на 20%, но мы работаем в селфхост-режиме.

Как стать привлекательнее для багхантеров?

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

Александр Шилов: Мой совет: просите помощи у Positive Technologies. Если ребята публикуют закрытую программу, исследователи сразу включаются. Так что соглашусь с Тимофеем: деньги не всегда решают — гораздо важнее поддерживать интерес багхантеров и относиться к ним по-человечески.

Елизавета Дудко: Мы тоже заметили, что багхантеры любят соревноваться. Их мотивирует уникальность скоупа и доступ туда, куда не так просто попасть с улицы. Плюс важна миссия: когда исследователь видит, что он не просто принес уязвимость и заработал денег, а сделал мир чуточку безопаснее, он гораздо более мотивирован.

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

Как будет развиваться российский рынок багбаунти в ближайшие годы?

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

Александр Шилов: На мой взгляд, у рынка отличные перспективы! Он будет расти постепенно, как и все новые продукты, но спрос и интерес уже очень велики. С каждым годом все больше компаний будет выходить на платформы багбаунти. 

Сергей Мигалин: Я уверен, что российский рынок багбаунти будет расти, особенно с учетом возможного закрепления инструмента в законодательстве и все большего внимания государства к ИБ-отрасли. Надеюсь, что все компании, которые продают ИБ-продукты в России, запустят свои программы.

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

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

Юлия Гайсина: Я вижу, что рынок багбаунти интересен и бизнесу, и исследователям. Поэтому мне кажется, что количество багхантеров и их экспертиза в ближайшем будущем будут расти.

В чем преимущества багбаунти перед другими OffSec-инструментами?

Тимофей Черных: У меня встречный вопрос: почему бы в том числе не сделать из багбаунти площадку для найма пентестеров? Например, я хочу, чтобы меня проверяли определенные специалисты, которые работают на конкретной площадке. Было бы классно иметь возможность оперативно заказать на платформе пентест, чтобы тебе сразу подобрали подходящих исследователей.

Александр Шилов: Главное преимущество багбаунти в том, что твой периметр и сервисы 24/7 проверяют разные исследователи. В этом плане багбаунти обгоняет пентесты, которые обычно длятся всего пару недель. 

Елизавета Дудко: Если сравнивать с заказными пентестами, то из преимуществ багбаунти я бы выделила оплату за результат и высокую мотивацию багхантеров раскопать что-то интересное. Тем не менее мы считаем, что стоит использовать как можно разных больше OffSec-инструментов, чтобы изучать скоуп с разных сторон.

Алексей Румак: Коллеги перечислили все преимущества, поэтому я скажу другую важную мысль. Багбаунти — это не панацея, а еще один шаг в сторону SSDLC (Secure Software Development Life Cycle). Багбаунти не заменят ни внутренний аудит, ни внутренние сканеры, даже от red team отказаться не получится, потому что бизнесу нужны внутренние команды, которые будут валидировать отчеты и проверять баги по всей инфраструктуре.

Какие советы по работе с багхантерами вы можете дать коллегам? 

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

Елизавета Дудко: Совет будет универсальным: все мы люди и хотим, чтобы к нам относились по-человечески. Залог успеха — честная, уважительная коммуникация.

Тимофей Черных: Советы давать могут все, а вот следовать им... Скажу так: поддерживайте SLA и будьте строги к себе. Платите вовремя и поддерживайте хорошие отношения с исследователями. 

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