Краткая выдержка в картинках от исследователей о том, что такое bug bounty и с чем придётся столкнуться. Для общего развития.
Но запомните самое главное: bug bounty - вишенка на тортике. Выходить на него, когда у тебя не выстроен процесс управления уязвимостями и метрики не доведены до "зеленого" состояния - все равно, что гопнику выйти против Тайсона. Правила, база и техника здесь тоже лежат в основе.
Но запомните самое главное: bug bounty - вишенка на тортике. Выходить на него, когда у тебя не выстроен процесс управления уязвимостями и метрики не доведены до "зеленого" состояния - все равно, что гопнику выйти против Тайсона. Правила, база и техника здесь тоже лежат в основе.
Недавно прошла первая в России конференция по сетевой безопасности, по крайней мере, так анонсируемая, и так же незамысловато названная. Если не считать моновендорных и ENOG.
Конечно, там было немалое количество вендорского контента (ради чего и организовывалось), но и определенную толику знаний из материалов почерпнуть можно. На самой конференции я не был, но материалы есть в открытом доступе, почему бы и не ознакомиться.
В одном из чатиков я мельком заметил, как восхищались презентацией Евгения Олькова из TS Solution, и стало интересно, что именно людям понравилось. Ведь обычно интеграторские презы либо расхваливают какого-то вендора, либо рапортуют об успешном внедрении вендорского решения крупному заказчику. То есть, их даже открывать не всегда интересно.
Просто полистав презу, мне стало понятно, чем вызван интерес. Презентация была экспертной, но с интересными особенностями. В большинстве своем подобные экспертные выступления либо моновендорны, либо исключительно о технологиях, без упоминания производителей. Последним типом я сам частенько промышляю, пытаясь донести до аудитории суть технологии и своих изобретений, даже без намека на вендора, которым это реализовывать. И зачастую у зрителей остается чувство легкого голода, когда не хватает информации: а на чем же это все готовить?
В вышеупомянутой презе этого пресного послевкусия не оставалось, равно как и впечатления, что тебе впаривают нечто одно. Есть направление, и вот такими вендорскими продуктами его решай. Хочешь - сам, хочешь - с интегратором. Примеры заскринил. Если этот вектор подхватят все интеграторы - на такие конференции станет интересно ходить. Так что респект.
По ссылке выше вы сможете найти презентацию Олькова, как и остальные материалы.
Конечно, там было немалое количество вендорского контента (ради чего и организовывалось), но и определенную толику знаний из материалов почерпнуть можно. На самой конференции я не был, но материалы есть в открытом доступе, почему бы и не ознакомиться.
В одном из чатиков я мельком заметил, как восхищались презентацией Евгения Олькова из TS Solution, и стало интересно, что именно людям понравилось. Ведь обычно интеграторские презы либо расхваливают какого-то вендора, либо рапортуют об успешном внедрении вендорского решения крупному заказчику. То есть, их даже открывать не всегда интересно.
Просто полистав презу, мне стало понятно, чем вызван интерес. Презентация была экспертной, но с интересными особенностями. В большинстве своем подобные экспертные выступления либо моновендорны, либо исключительно о технологиях, без упоминания производителей. Последним типом я сам частенько промышляю, пытаясь донести до аудитории суть технологии и своих изобретений, даже без намека на вендора, которым это реализовывать. И зачастую у зрителей остается чувство легкого голода, когда не хватает информации: а на чем же это все готовить?
В вышеупомянутой презе этого пресного послевкусия не оставалось, равно как и впечатления, что тебе впаривают нечто одно. Есть направление, и вот такими вендорскими продуктами его решай. Хочешь - сам, хочешь - с интегратором. Примеры заскринил. Если этот вектор подхватят все интеграторы - на такие конференции станет интересно ходить. Так что респект.
По ссылке выше вы сможете найти презентацию Олькова, как и остальные материалы.
Скрин на днях завирусился. Не знаю, насколько он правдив и насколько существует этот человек, поэтому ФИО замазал. Если отсеять из сообщения шлак, есть над чем подумать:
- вакансий руководителей намного меньше, чем кандидатов на них
- интересно, какой процент откликнувшихся имеет релевантный опыт и соответствует требованиям
- не исключено, что многие из откликнувшихся сделали это только для того, чтобы у себя так же по 4 раза в месяц говорить, что уволятся, если к ним будут относиться без должного почтения; или хотя бы писать, что говорил
- человек склонен выделять себя в лучшую сторону по сравнению с остальными, независимо от ситуации и профиля деятельности, будь то слесарь или директор
Когда я собеседовал руководителей и CISO, меня тоже удивляло количество откликов по сравнению с экспертными должностями. Но процент отсеянных по резюме и не дошедших до скрининга, был тоже выше такового для экспертов.
Желание стать руководителем появляется у многих, даже задолго до фактической готовности им стать. И, что интересно, начинающий руководитель может вместо фокусировки на организации работы вверенного подразделения сфокусироваться на дальнейшем карьерном росте. Результат этого может быть разным...
Поэтому просто делай свою работу хорошо.
- вакансий руководителей намного меньше, чем кандидатов на них
- интересно, какой процент откликнувшихся имеет релевантный опыт и соответствует требованиям
- не исключено, что многие из откликнувшихся сделали это только для того, чтобы у себя так же по 4 раза в месяц говорить, что уволятся, если к ним будут относиться без должного почтения; или хотя бы писать, что говорил
- человек склонен выделять себя в лучшую сторону по сравнению с остальными, независимо от ситуации и профиля деятельности, будь то слесарь или директор
Когда я собеседовал руководителей и CISO, меня тоже удивляло количество откликов по сравнению с экспертными должностями. Но процент отсеянных по резюме и не дошедших до скрининга, был тоже выше такового для экспертов.
Желание стать руководителем появляется у многих, даже задолго до фактической готовности им стать. И, что интересно, начинающий руководитель может вместо фокусировки на организации работы вверенного подразделения сфокусироваться на дальнейшем карьерном росте. Результат этого может быть разным...
Поэтому просто делай свою работу хорошо.
Казалось бы, что значит "целевые" DDoS-атаки, если они и так целевые? Кроме случаев, когда дудосили одного, а рядом стоящего намотало на маховик вместе с остальными клиентами хостера или провайдера.
Но для того, чтобы более прицельно и эффективно провести DDoS-атаку, злоумышленник изучает:
- открытые порты, доступные из Интернет
- приклад, опубликованный на этих портах
- бизнес-логику приложений, реализуемую на этом прикладе
- наличие узких мест и центральных точек отказа
- возможный бизнес- и PR-эффект от недоступности того или иного онлайн-ресурса атакуемого
То есть, злоумышленник изучает для атаки то, что должен изучить ИБшник для защиты. При этом у ИБшника есть как преимущество в доступе к схемам и описанию систем, так и зависимость от актуальности и качества информации. Поэтому придется еще и верифицировать то, что описано в документации. И потом вместе с провайдером защиты от DDoS выстроить правильные профили защиты.
А ты знаешь свой внешний периметр лучше злоумышленника?
Если нет, то теперь есть, чем заняться с понедельника.
Но для того, чтобы более прицельно и эффективно провести DDoS-атаку, злоумышленник изучает:
- открытые порты, доступные из Интернет
- приклад, опубликованный на этих портах
- бизнес-логику приложений, реализуемую на этом прикладе
- наличие узких мест и центральных точек отказа
- возможный бизнес- и PR-эффект от недоступности того или иного онлайн-ресурса атакуемого
То есть, злоумышленник изучает для атаки то, что должен изучить ИБшник для защиты. При этом у ИБшника есть как преимущество в доступе к схемам и описанию систем, так и зависимость от актуальности и качества информации. Поэтому придется еще и верифицировать то, что описано в документации. И потом вместе с провайдером защиты от DDoS выстроить правильные профили защиты.
А ты знаешь свой внешний периметр лучше злоумышленника?
Если нет, то теперь есть, чем заняться с понедельника.
В сентябре я изобразил прохождение трафика из Интернет через средства обеспечения сетевой безопасности к защищаемому ресурсу. Там же описал функции каждого задействованного средства защиты. Был приятно удивлен тем, что картинка распространилась по профессиональному сообществу. Но она ограничивалась одним Интернет-провайдером, который являлся в том числе и поставщиком сервисов AntiDDoS/AntiBot/WAF.
Попробуем немного усложнить (см. картинку):
1. Provider Independent address space у клиента.
2. Подключение в Интернет с помощью более одного провайдера.
3. Часть web-ресурсов защищается сторонними облачными сервисами AntiDDoS(L7)/AntiBot/WAF.
Представим, что вы – новый CISO, которому это все досталось. Возможно, в будущем схему защиты предстоит перестроить, но обеспечить доступность ресурсов при DDoS нужно здесь и сейчас, чтобы отложить право использования «первого конверта».
ToDo:
1. В договоре с каждым Интернет-провайдером (ISP1 и ISP2) должна быть включена услуга защиты от DDoS.
2. Специалисты AntiDDoS ISP должны иметь информацию о защищаемых ресурсах для профилирования политик защиты (подсети, адреса, порты, нагрузка и т.п. – у Интернет-провайдера есть опросник, заполните его).
3. Облачные MSSP, терминируя на себе трафик защищаемых ресурсов, передают в сторону клиента пакеты с src IP-адресом своего сервиса, IP-адрес клиента передается в заголовке. Такие взаимодействия обозначены серой, желтой и рыжей стрелочками. В связи с этим:
a. Облачный MSSP сервисов WAF и AntiBot должен обеспечивать защиту от DDoS вверенных ему ресурсов.
b. Специалисты AntiDDoS ISP должны иметь актуальную информацию о веб-ресурсах, защищаемых облачными MSSP, и подсетях MSSP, из которых будут назначаться src IP, для добавления в белый список при профилировании.
Как вы понимаете, это будет крайне сложно выполнить без нормальной инвентаризации и совместной работы с владельцами защищаемых ресурсов, а также специалистами ISP/MSSP.
Удачи в защите онлайн-ресурсов от DDoS. Вышеописанная инструкция существенно повысит ваши шансы на успех.
Попробуем немного усложнить (см. картинку):
1. Provider Independent address space у клиента.
2. Подключение в Интернет с помощью более одного провайдера.
3. Часть web-ресурсов защищается сторонними облачными сервисами AntiDDoS(L7)/AntiBot/WAF.
Представим, что вы – новый CISO, которому это все досталось. Возможно, в будущем схему защиты предстоит перестроить, но обеспечить доступность ресурсов при DDoS нужно здесь и сейчас, чтобы отложить право использования «первого конверта».
ToDo:
1. В договоре с каждым Интернет-провайдером (ISP1 и ISP2) должна быть включена услуга защиты от DDoS.
2. Специалисты AntiDDoS ISP должны иметь информацию о защищаемых ресурсах для профилирования политик защиты (подсети, адреса, порты, нагрузка и т.п. – у Интернет-провайдера есть опросник, заполните его).
3. Облачные MSSP, терминируя на себе трафик защищаемых ресурсов, передают в сторону клиента пакеты с src IP-адресом своего сервиса, IP-адрес клиента передается в заголовке. Такие взаимодействия обозначены серой, желтой и рыжей стрелочками. В связи с этим:
a. Облачный MSSP сервисов WAF и AntiBot должен обеспечивать защиту от DDoS вверенных ему ресурсов.
b. Специалисты AntiDDoS ISP должны иметь актуальную информацию о веб-ресурсах, защищаемых облачными MSSP, и подсетях MSSP, из которых будут назначаться src IP, для добавления в белый список при профилировании.
Как вы понимаете, это будет крайне сложно выполнить без нормальной инвентаризации и совместной работы с владельцами защищаемых ресурсов, а также специалистами ISP/MSSP.
Удачи в защите онлайн-ресурсов от DDoS. Вышеописанная инструкция существенно повысит ваши шансы на успех.
Просматриваю на досуге презентации с конференции "Сетевая безопасность", и не могу не обратить внимание на некоторые моменты. Скрины одной из през показывают эволюцию контроля трафика и условную классификацию по уровням продвинутости. Но есть нюанс.
Контроль трафика восток-запад (внутри одного сегмента) не даст полной видимости взаимодействия между всеми хостами в одном VLAN без дополнительных телодвижений, не описанных в презентации. Только между разными VLAN в пределах одного VRF. Даже если снимать и копию трафика, и телеметрию.
Вспомним, почему.
1. Копия трафика снимается с коммутаторов, которые настроены как STP root и secondary root для VLAN, в котором живут хосты. То есть, внутри одного VLAN будет фиксироваться взаимодействие, только если хосты подключены к разным коммутаторам доступа, и трафик между ними вынужден проходить через STP root.
2. Телеметрия (NetFlow) снимается с L3-интерфейсов маршрутизаторов, на которых терминируются вышеописанные VLAN. Топологически к ним подключаются коммутаторы STP root. То есть, там же, где и п. 1.
Получается, взаимодействие двух хостов в одной подсети, подключенных к одному коммутатору доступа, не будет видно, если не снимать трафик именно на нем.
Какими технологиями можно запретить взаимодействие в одном VLAN (команды и терминология Cisco, приземляйте на свое оборудование самостоятельно):
- switchport protected - запретит взаимодействие внутри одного VLAN на одном коммутаторе; хосты из того же VLAN на другом будут видны, но трафик пройдет через STP root и будет зафиксирован
- private VLAN (isolated порты) - запрет распространяется на весь VLAN разных коммутаторов, но и настройки более комплексные
- микросегментация через overlay networks
Относительно использования возможностей NDR - тоже потребуется дополнительная интеграция с активным сетевым оборудованием:
- FW/NGFW
- AntiDDoS
- отправка TCP RST для обрыва сессии
- правила автоматизированного реагирования через SOAR
Учтите, когда будете использовать решения IDS/IPS/NTA/NAD/NDR, чтобы не возникало завышенных ожиданий.
Контроль трафика восток-запад (внутри одного сегмента) не даст полной видимости взаимодействия между всеми хостами в одном VLAN без дополнительных телодвижений, не описанных в презентации. Только между разными VLAN в пределах одного VRF. Даже если снимать и копию трафика, и телеметрию.
Вспомним, почему.
1. Копия трафика снимается с коммутаторов, которые настроены как STP root и secondary root для VLAN, в котором живут хосты. То есть, внутри одного VLAN будет фиксироваться взаимодействие, только если хосты подключены к разным коммутаторам доступа, и трафик между ними вынужден проходить через STP root.
2. Телеметрия (NetFlow) снимается с L3-интерфейсов маршрутизаторов, на которых терминируются вышеописанные VLAN. Топологически к ним подключаются коммутаторы STP root. То есть, там же, где и п. 1.
Получается, взаимодействие двух хостов в одной подсети, подключенных к одному коммутатору доступа, не будет видно, если не снимать трафик именно на нем.
Какими технологиями можно запретить взаимодействие в одном VLAN (команды и терминология Cisco, приземляйте на свое оборудование самостоятельно):
- switchport protected - запретит взаимодействие внутри одного VLAN на одном коммутаторе; хосты из того же VLAN на другом будут видны, но трафик пройдет через STP root и будет зафиксирован
- private VLAN (isolated порты) - запрет распространяется на весь VLAN разных коммутаторов, но и настройки более комплексные
- микросегментация через overlay networks
Относительно использования возможностей NDR - тоже потребуется дополнительная интеграция с активным сетевым оборудованием:
- FW/NGFW
- AntiDDoS
- отправка TCP RST для обрыва сессии
- правила автоматизированного реагирования через SOAR
Учтите, когда будете использовать решения IDS/IPS/NTA/NAD/NDR, чтобы не возникало завышенных ожиданий.
Стало понятно, что предыдущую заметку лучше обогатить картинками, чтобы было более наглядно. И вот, из презентаций той же конференции нашел картинку, чем отличается анализ копии трафика север-юг от комплексного север-юг + запад-восток. Даже самому рисовать не пришлось.
Порядок действий очевиден:
1. На том же коммутаторе (STP root) добавляем в source VLAN'ы, где живет конечное оборудование. Таким образом, получаем все, что в них влетает и вылетает, а также частично трафик внутри VLAN (объяснение в предыдущей заметке).
2. Учитываем рост трафика на destination SPAN-port, чтобы не забить его теоретический предел, что чревато потерей пакетов для IDS/NTA/NAD и потенциальной аварийной ситуацией для сетевого оборудования.
3. Как вы понимаете, если ловим трафик из VLAN A в VLAN B и обратно - он будет ловиться дважды, и дважды подаваться на SPAN-порт. Поэтому более-менее современные IDS/NTA/NAD должны уметь дедупликацию пакетов. Коммутатор этого не умеет, поэтому на нем придётся учитывать нагрузку линейно.
Теперь, будучи обогащенными новой информацией, идем работать.
Порядок действий очевиден:
1. На том же коммутаторе (STP root) добавляем в source VLAN'ы, где живет конечное оборудование. Таким образом, получаем все, что в них влетает и вылетает, а также частично трафик внутри VLAN (объяснение в предыдущей заметке).
2. Учитываем рост трафика на destination SPAN-port, чтобы не забить его теоретический предел, что чревато потерей пакетов для IDS/NTA/NAD и потенциальной аварийной ситуацией для сетевого оборудования.
3. Как вы понимаете, если ловим трафик из VLAN A в VLAN B и обратно - он будет ловиться дважды, и дважды подаваться на SPAN-порт. Поэтому более-менее современные IDS/NTA/NAD должны уметь дедупликацию пакетов. Коммутатор этого не умеет, поэтому на нем придётся учитывать нагрузку линейно.
Теперь, будучи обогащенными новой информацией, идем работать.
Картинка от Cisco, изображающая наглядно разницу между SPAN, RSPAN и ERSPAN.
- SPAN локально сбрасывает копируемый трафик на порт, к которому подключен анализатор трафика, IDS/NTA/NAD
- RSPAN отправляет копируемые пакеты через специальный VLAN на удаленный свич, где он отправляется на порт, к которому подключено устройство, нюхающее трафик
- ERSPAN умеет отправлять на удаленный маршрутизатор через L3-сеть, используя GRE для инкапсуляции передаваемого трафика
Вот и освежили знания.
- SPAN локально сбрасывает копируемый трафик на порт, к которому подключен анализатор трафика, IDS/NTA/NAD
- RSPAN отправляет копируемые пакеты через специальный VLAN на удаленный свич, где он отправляется на порт, к которому подключено устройство, нюхающее трафик
- ERSPAN умеет отправлять на удаленный маршрутизатор через L3-сеть, используя GRE для инкапсуляции передаваемого трафика
Вот и освежили знания.
Давайте вспомним, каким образом IPS (он же NDR) может активно противодействовать сетевым атакам. Речь пойдет не об алгоритмах обнаружения, а именно отражения атак.
1. Режим in-line. Как очень умный и очень дорогой кабель. В этом случае IPS может выполнять как silent block, так и отправку RST, имитируя инициацию окончания сессии любой из сторон (если TCP). Даже соседнее активное сетевое оборудование не поймёт, что IPS посередине в такой ситуации.
2. FW block. Анализировать копию трафика, и в случае обнаружения атаки отправлять команду на блокировку источника на firewall. Необходима соответствующая интеграция с FW/NGFW по управляющему протоколу.
3. RST mode. Анализировать копию трафика и отправлять TCP RST в обе стороны от IP-адреса второго участника. В зависимости от реализации производителем, отправлять RST может либо "слушающий" интерфейс IPS, либо управляющий.
Ограничение: работает только с TCP.
a. Через управляющий интерфейс. RST от имени участников сессии попадет в VLAN управления IPS, далее по таблице маршрутизации долетит до адресатов.
На интерфейсе, являющемся default gateway для этой подсети, необходимо отключить настройки защиты от спуфинга и включить ARP proxy.
Если сегмент управления защищен с помощью FW/NGFW - на соответствующем интерфейсе отключается защита от спуфинга и разрешаются RST-пакеты без проверки сессий (если софт еще позволит).
b. Через "слушающий". На активном сетевом оборудовании настраивается SPAN-порт с возможностью приема трафика в ingress VLAN.
Послабления безопасности аналогичны вышеописанному для управляющего.
Ограничения (кроме TCP only): не реализуемо, если на "слушающий" порт трафик подается с пакетного брокера, на который стекается с оптических съемников.
👍 - все понятно!
🤔 - лучше с картинкой!
🤯 - с картинкой и объяснениями всяких нерусских терминов
1. Режим in-line. Как очень умный и очень дорогой кабель. В этом случае IPS может выполнять как silent block, так и отправку RST, имитируя инициацию окончания сессии любой из сторон (если TCP). Даже соседнее активное сетевое оборудование не поймёт, что IPS посередине в такой ситуации.
2. FW block. Анализировать копию трафика, и в случае обнаружения атаки отправлять команду на блокировку источника на firewall. Необходима соответствующая интеграция с FW/NGFW по управляющему протоколу.
3. RST mode. Анализировать копию трафика и отправлять TCP RST в обе стороны от IP-адреса второго участника. В зависимости от реализации производителем, отправлять RST может либо "слушающий" интерфейс IPS, либо управляющий.
Ограничение: работает только с TCP.
a. Через управляющий интерфейс. RST от имени участников сессии попадет в VLAN управления IPS, далее по таблице маршрутизации долетит до адресатов.
На интерфейсе, являющемся default gateway для этой подсети, необходимо отключить настройки защиты от спуфинга и включить ARP proxy.
Если сегмент управления защищен с помощью FW/NGFW - на соответствующем интерфейсе отключается защита от спуфинга и разрешаются RST-пакеты без проверки сессий (если софт еще позволит).
b. Через "слушающий". На активном сетевом оборудовании настраивается SPAN-порт с возможностью приема трафика в ingress VLAN.
Послабления безопасности аналогичны вышеописанному для управляющего.
Ограничения (кроме TCP only): не реализуемо, если на "слушающий" порт трафик подается с пакетного брокера, на который стекается с оптических съемников.
👍 - все понятно!
🤔 - лучше с картинкой!
🤯 - с картинкой и объяснениями всяких нерусских терминов
На любой конференции есть вендорский контент, потому что кто-то должен за это платить. Иногда он бывает очень даже неплох. В этом особо преуспели в свое время Cisco и Juniper, когда их откровенно продуктовые выступления собирали экспертов в зале, и эксперты слушали, не морщась. Но не все до этого уровня доросли пока.
На конференции "Сетевая безопасность" Гарда ненавязчиво показывала свой набор решений сетевой безопасности. Суть была в том, чтобы клиенты брали не только провайдерскую защиту, а еще и приземленный у себя комплекс очистки трафика, который умеет cloud signalling для отстукивания провайдерскому центру очистки, что пора включать режим деликатной стирки. Идея правильная, (если клиент мощный и может себе позволить) но подводка хромает.
Возможно, ртом спикер вносил коррективы, но немая картинка 1 выглядит, как будто клиент берет у одного провайдера канал с защитой от DDoS, а у другого - без. И спасет от этого локальный центр очистки... Рисунок 2. Видел я на своей практике такие случаи. Канал второго провайдера зальют до краев, и даже самые совершенные алгоритмы локального центра очистки будут бессильны, потому что часть легитимного трафика умрет до входа в сеть клиента. А главная задача AntiDDoS - обеспечить беспрепятственную доставку легитимного трафика.
Поэтому конструкция, описанная на картинке 3, эффективна, если применить ее ко всем провайдерам. Либо на время DDoS оставлять только одного провайдера, а остальных глушить. Если справится, конечно.
И, чтобы было понятно: Гарда - не единственный игрок, кто так умеет. Да и локальный AntiDDoS - решение недешёвое, финансово целесообразнее может быть правильный тюнинг политик операторского центра очистки.
На конференции "Сетевая безопасность" Гарда ненавязчиво показывала свой набор решений сетевой безопасности. Суть была в том, чтобы клиенты брали не только провайдерскую защиту, а еще и приземленный у себя комплекс очистки трафика, который умеет cloud signalling для отстукивания провайдерскому центру очистки, что пора включать режим деликатной стирки. Идея правильная, (если клиент мощный и может себе позволить) но подводка хромает.
Возможно, ртом спикер вносил коррективы, но немая картинка 1 выглядит, как будто клиент берет у одного провайдера канал с защитой от DDoS, а у другого - без. И спасет от этого локальный центр очистки... Рисунок 2. Видел я на своей практике такие случаи. Канал второго провайдера зальют до краев, и даже самые совершенные алгоритмы локального центра очистки будут бессильны, потому что часть легитимного трафика умрет до входа в сеть клиента. А главная задача AntiDDoS - обеспечить беспрепятственную доставку легитимного трафика.
Поэтому конструкция, описанная на картинке 3, эффективна, если применить ее ко всем провайдерам. Либо на время DDoS оставлять только одного провайдера, а остальных глушить. Если справится, конечно.
И, чтобы было понятно: Гарда - не единственный игрок, кто так умеет. Да и локальный AntiDDoS - решение недешёвое, финансово целесообразнее может быть правильный тюнинг политик операторского центра очистки.
Legal DDoS маркетплейсов в реальной жизни и финансовые последствия.
Многие из нас заказали подарки к новому году на маркетплейсах Ozon, Wildberries, Яндекс Маркет и т.п., потому что там и цены зачастую ниже, и никуда ходить надо, чтобы выбрать. Есть, конечно, те, кто предпочитает пощупать руками, а не онлайн, но их с каждым годом становится все меньше. Я сужу по себе: будучи ярым сторонником выбора товара лично, я потихоньку привык к маркетплейсам. Подозреваю, что в целом по стране тенденция движется в том же направлении.
Но при чем здесь DDoS?
Выбираешь товар на маркетплейсе, он уверенно обещает доставить его в пункт выдачи заказа 31 декабря. А вот когда оформляешь - вариативность дат сильно возрастает. В середине года подобный сдвиг бывает не критичен, но 31 декабря есть нюанс...
С высокой вероятностью, большая часть заказов, обещанных к доставке 31 декабря, будет не нужна уже на следующий день. Просто потому, что их заказывали для того, чтобы торжественно подарить на новый год.
Теперь представим, что будет твориться 31 декабря:
- синие, фиолетовые и рыжие грузовички будут метаться от складов к пунктам выдачи, как бильярдные шары
- на пунктах выдачи будут очереди
- техподдержку будут тормошить пользователи, чьи товары еще не доехали
- с осознанием того, что уже не дождешься доставки, люди хлынут в ближайшие магазины, которые будут еще работать, вызывая там ажиотаж
- 1 января десятки тысяч отмен заказов по стране, миллионы рублей недополученной прибыли
Победит тот, кто заранее подготовился.
Будем надеяться, что все.
С наступающим!
Многие из нас заказали подарки к новому году на маркетплейсах Ozon, Wildberries, Яндекс Маркет и т.п., потому что там и цены зачастую ниже, и никуда ходить надо, чтобы выбрать. Есть, конечно, те, кто предпочитает пощупать руками, а не онлайн, но их с каждым годом становится все меньше. Я сужу по себе: будучи ярым сторонником выбора товара лично, я потихоньку привык к маркетплейсам. Подозреваю, что в целом по стране тенденция движется в том же направлении.
Но при чем здесь DDoS?
Выбираешь товар на маркетплейсе, он уверенно обещает доставить его в пункт выдачи заказа 31 декабря. А вот когда оформляешь - вариативность дат сильно возрастает. В середине года подобный сдвиг бывает не критичен, но 31 декабря есть нюанс...
С высокой вероятностью, большая часть заказов, обещанных к доставке 31 декабря, будет не нужна уже на следующий день. Просто потому, что их заказывали для того, чтобы торжественно подарить на новый год.
Теперь представим, что будет твориться 31 декабря:
- синие, фиолетовые и рыжие грузовички будут метаться от складов к пунктам выдачи, как бильярдные шары
- на пунктах выдачи будут очереди
- техподдержку будут тормошить пользователи, чьи товары еще не доехали
- с осознанием того, что уже не дождешься доставки, люди хлынут в ближайшие магазины, которые будут еще работать, вызывая там ажиотаж
- 1 января десятки тысяч отмен заказов по стране, миллионы рублей недополученной прибыли
Победит тот, кто заранее подготовился.
Будем надеяться, что все.
С наступающим!