Работа в Стамбуле

Метка: mpls mitm

  • Download Cisco Works • Cisco Prime LAN Management Solution 4.1

    Download Cisco Works • Cisco Prime LAN Management Solution 4.1

    Cisco Prime LAN Management Solution (LMS) delivers powerful network security management by simplifying the configuration, administration, monitoring, and troubleshooting of Cisco networks. 

    Cisco Prime 4.1

    This innovative solution offers end-to-end security management for business critical technologies and services, such as, medianet, TrustSec, and EnergyWise. Cisco Prime LMS 4.1 improves the overall user experience, providing new workflows that are built on functional partitioning and that align the product with the way network operators do their jobs.

    Once installed, prepackaged security and troubleshooting dashboards provide actionable information to quickly isolate and fix network problems before they affect services.

    Configuring and deploying updates to the network has never been easier with the Template Center, which now incorporates Cisco Smart Business Architecture (SBA) templates that are based upon Cisco Validated Designs, simplifying platform and technology rollout and reducing the chance for errors.

    Work Centers provide a single area where guided workflows give step-by-step instructions to help operators quickly provision, monitor, and manage new Cisco value-added technologies and solutions, such as medianet, EnergyWise, TrustSec/Identity, Auto Smartports, and Smart Install.

    Download Cisco Prime 4.1 
  • Принципы защиты сетевого оборудования регионального уровня

    Принципы защиты сетевого оборудования регионального уровня

     Оборудование регионального уровня непосредственно связано с оборудованием сетей клиентов сети IP/MPLS ПАО «Ростелеком» и, следовательно, подвергается максимальному риску атак из сетей клиентов ПАО «Ростелеком».

    Принципы защиты оборудования регионального уровня

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

          В основном защита от несанкционированного доступа производится аналогично защите для маршрутизаторов ядра.

          Поскольку пиринг с сетями клиентов и с сетями других операторов происходит с использованием протокола BGP, то необходима, прежде всего, фильтрация префиксов, приходящих от BGP маршрутизаторов сторонних сетей с целью недопущения попадания некорректной маршрутной информации, анонсируемой маршрутизаторами сторонних сетей в результате ошибки или умышленно. Фильтрация префиксов IPv4 осуществляется на базе списка, приведённого в [RFC6890]. Данный список содержит адреса следующих зарезервированных IETF и не подлежащих выделению сетей:

    • 0.0.0.0/8;
    • 0.0.0.0/1 – 0.0.0.0/32;
    • 10.0.0.0/8;
    • 172.16.0.0/12;
    • 192.168.0.0/16;
    • 127.0.0.0/8;
    • 192.0.0.0/24;
    • 192.0.2.0/24;
    • 169.254.0.0/16;
    • 100.64.0.0/10;
    • 192.88.99.0/24;
    • 198.18.0.0/15;
    • 198.51.100.0/24;
    • 203.0.113.0/24;
    • 224.0.0.0/4;
    • 240.0.0.0/4;

          Фильтрация префиксов IPv6 осуществляется на базе списка, указанного в [RFC6890] следующие префиксы:

    • ::/128;
    • ::1/128;
    • FE80::/10;
    • FC00::/7;
    • 2001::/23;
    • 2002::/16;
    • 64:ff9b::/96;
    • ::ffff:0:0/96;
    • 100::/64;

          С целью уменьшения общего числа префиксов фильтруются все префиксы с маской, длина которой превышает 24 бита для IPv4 и 48 бит для IPv6.
          Такая же фильтрация применяется и при передаче префиксов за пределы автономной системы Ростелеком.

          Пример политики для фильтрации неиспользуемых в сети Internet префиксов на маршрутизаторах Juniper:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import sanity-check;

                    export sanity-check;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    import v6-sanity-check;

                    export v6-sanity-check;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement sanity-check {

            term reject-bogons {

                from policy bogons;

                then reject;

            }

            term accept-blackhole {

                from community type_blackhole_route;

                then next policy;

            }

            term reject-long-prefixes {

                from {

                    route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;

                }

            }

        }

        policy-statement bogons {

            term match-rfc6890-networks {

                from {

                    route-filter 10.0.0.0/8 orlonger accept;

                    route-filter 172.16.0.0/12 orlonger accept;

                    route-filter 192.168.0.0/16 orlonger accept;

                    route-filter 0.0.0.0/1 through 0.0.0.0/32 accept;

                    route-filter 0.0.0.0/8 orlonger accept;

                    route-filter 127.0.0.0/8 orlonger accept;

                    route-filter 192.0.0.0/24 orlonger accept;

                    route-filter 192.0.2.0/24 orlonger accept;

                    route-filter 169.254.0.0/16 orlonger accept;

                    route-filter 192.88.99.0/24 orlonger accept;

                    route-filter 224.0.0.0/4 orlonger accept;

                    route-filter 240.0.0.0/4 orlonger accept;

                    route-filter 198.18.0.0/15 orlonger accept;

                    route-filter 198.51.100.0/24 orlonger accept;

                    route-filter 203.0.113.0/24 orlonger accept;

                    route-filter 100.64.0.0/10 orlonger accept;           

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement v6-sanity-check {

            term reject-bogons {

                from policy v6-bogons;

                then reject;

            }

            term reject-long-prefixes {

                from {

                    route-filter ::/0 prefix-length-range /48-/128 reject;

                }

            }

        }

        policy-statement v6-bogons {

            term match-rfc6890-networks {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

                    route-filter ::/1 through ::/128 accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FC00::/7 orlonger accept;

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2002::/16 orlonger accept;

                    route-filter 64:ff9b::/96 orlonger accept;

                    route-filter ::ffff:0:0/96 orlonger accept;

                    route-filter 100::/64 orlonger accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

    }

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

          Пример контроля количества AS в принимаемых анонсах на маршрутизаторах Juniper Networks:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import restrict-long-as;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    import restrict-long-as;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement restrict-long-as {

            term reject-long-as_path {

                from as-path too_long_as_path;

                then reject;

            }

        }

        as-path too_long_as_path «.{50,}»;

    }

          Пример контроля количества AS в принимаемых анонсах на маршрутизаторах Cisco Systems:

    router bgp 12389

     bgp maxas-limit 50

    !


          Также необходимо запретить приём от клиентов префиксов Ростелеком и маршрута по умолчанию. Значения BGP Community, не предназначенные для использования клиентами (раздел «3.2.1 Маркировка маршрутов»), должны быть удалены.

          Пример запрета приёма префиксов Ростелеком и маршрута по умолчанию:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    local-address 1.1.1.1;

                    import INET_CUSTOMER_in;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    local-address 1::1;

                    import INET__v6_CUSTOMER_in;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement INET_CUSTOMER_in {

            term reject-RT-aggregate {

                from policy RT-aggregate;

                then reject;

            }

            term reject-RT-longer-prefixes {

                from policy RT-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            }

        }

        policy-statement RT-aggregate {

            term match-RT-aggregate-networks {

                from {

                    route-filter 87.226.128.0/17 exact accept;

                    route-filter 79.133.64.0/19 exact accept;

                    route-filter 92.50.192.0/18 exact accept;

                    route-filter 94.25.0.0/17 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-longer-prefixes {

            term match-RT-longer-prefixes {

                from {

                    route-filter 87.226.128.0/17 longer accept;

                    route-filter 79.133.64.0/19 longer accept;

                    route-filter 92.50.192.0/18 longer accept;

                    route-filter 94.25.0.0/17 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_in {

            term reject-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then reject;

            }

            term reject-RT-v6-longer-prefixes {

                from policy RT-v6-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            }

        }

        policy-statement RT-v6-aggregate {

            term match-RT-v6-aggregate-networks {

                from {

                    route-filter 2A01:620::/32 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-v6-longer-prefixes {

            term match-RT-v6-longer-prefixes {

                from {

                    route-filter 2A01:620::/32 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        community 12389 members 12389:*;

        community 12389:1-3X members «^12389:.{1,3}$»;

        community 12389:1UZZ members «^12389:1…$»;

    }

          В целях уменьшения влияния анонсов отдельных клиентов на ресурсы маршрутизаторов Сети ограничивается количество префиксов, получаемых от клиентов, значением 1000 для префиксов IPv4 и 100 для IPv6 (это значение может быть изменено для отдельного клиента или пересмотрено для всей Сети при изменении общей ситуации в сети Internet). При превышении 80% от этого значения генерируется сообщение в журнале событий (syslog), а при превышении 100% сессия BGP разрывается и может быть установлена вновь через 30 минут.

          Пример ограничения количества принимаемых префиксов на маршрутизаторах доступа:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast {

                        prefix-limit {

                            maximum 1000;

                            teardown 80 idle-timeout 30;

                        }

                    }

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast {

                        prefix-limit {

                            maximum 100;

                            teardown 80 idle-timeout 30;

                        }

                    }

                }

            }

        }

    }

          В существующей сети ПАО «Ростелеком» для защиты от некорректных маршрутов применяется фильтрация на основе информации Routing Arbiter Database, являющейся одной из наиболее полных на сегодняшний день баз информации о зарегистрированных в региональных центрах регистрации (Regional Internet Registry, RIR) объектах (автономные системы, префиксы, принципы взаимодействия с соседями). Такая фильтрация является очень мощным средством обеспечения безопасности и стабильности.    Кроме того, процесс получения информации и настройки маршрутизаторов автоматизируется с помощью специализированных программных средств. Если номер автономной системы клиента двухбайтный, для формирования имени фильтра на сети IP/MPLS ПАО «Ростелеком» используется форма CUSTOMER:<ASN>, где <ASN> – номер автономной системы клиента или название AS-SET, AS-NUM или AUT-NUM, зарегистрированные в RIR.

          Пример фильтра при приёме маршрутов от клиента:

    protocols {

        bgp {

            group INET_Customers {

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import CUSTOMER:65432;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement CUSTOMER:65432 {

            term rtbh {

                from {

                    community type_blackhole_route;

                    route-filter 2.1.0.0/16 orlonger;

                    route-filter 1.2.3.0/24 orlonger;

                }

                then {

                    community add NO_EXPORT;

                    next-hop discard;

                    accept;        

                }

            }

            term prefixes {

                from {

                    route-filter 2.1.0.0/16 upto /24;

                    route-filter 1.2.3.0/24 exact;

                }

                then next policy;

            }

            then reject;

        }

        community NO_EXPORT members no-export;

        community type_blackhole_route members 12389:55555;

    }

          Необходимо отметить, что фильтрация префиксов, получаемых от BGP-маршрутизаторов сторонних сетей, не гарантирует отсутствие входящих пакетов с адресами источников из запрещённых сетей. Как и в случае маршрутизаторов магистрального уровня, необходима настройка списков доступа на внутреннем интерфейсе маршрутизатора, связывающем подсистему управления маршрутизатором с подсистемой коммутации пакетов. Также необходимо запретить возможность записывания данных по протоколу SNMP для всех устройств уровня доступа, кроме маршрутизаторов с функциональностью IP SLA, оставив лишь возможность чтения некоторых параметров необходимых для систем мониторинга и управления, а также для систем биллинга. Для маршрутизаторов с функциональностью IP SLA остается возможность записи по протоколу SNMP в CISCO-RTTMON MIB.
          Таким образом, политика безопасности маршрутизаторов доступа в основном совпадает с политикой безопасности маршрутизаторов ядра. Для организации второго рубежа защиты, ориентированного на защиту не отдельного устройства, а сети от несанкционированного доступа и возможности проведения атак типа отказ в обслуживании необходима настройка фильтрации пакетов на клиентских интерфейсах. Универсальный фильтр, запрещающий прохождение пакетов, в адресах назначения которых указаны адреса интерфейсов внутренних устройств сети IP/MPLS ПАО «Ростелеком», кроме тех, которые обеспечивают функционирование публичных сервисов. Для клиентов, использующих только услуги передачи голосового трафика через устройства голосовых сегментов сети IP/MPLS ПАО «Ростелеком», настраиваются списки доступа, разрешающие доступ только к пограничным контроллерам сессий (SBC) на интерфейсах, посредством которых эти клиенты подключаются к сети.

          Пример настройки фильтрации на клиентских интерфейсах маршрутизаторов доступа:

    interfaces {

        ge-2/0/0 {

            unit 2 {

                family inet {

                    filter {

                        input Prohibited_Destinations;

                    }

                }

            }

        }

    }

    firewall {

        filter Prohibited_Destinations {

            term RTK_IPMPLS_internal {

                from {

                    address {

                        87.226.133.0/24;

                        87.226.134.0/24;

                        87.226.135.0/24;

                        87.226.136.0/24;

                        87.226.137.0/24;

                        87.226.138.0/24;

                        87.226.139.0/24;

                    }

                }

                then { 

                    discard;

                }

            }

            term RTK_IPMPLS_MGMT {

                from {

                    address {

                        87.226.129.0/24;

                        87.226.131.128/27;

                        10.0.0.0/8;

                    }

                }

                then {

                    discard;

                }

            }

            term default-action {

                then accept;

            }

        }

    }

          С целью защиты коммутирующих устройств узла:

    • протокол VTP (VLAN Trunking Protocol) на коммутаторах переводится в режим transparent;
    • приём и передача пакетов Spanning Tree Protocol (STP) запрещается на портах, к которым подключены клиенты;
    • защита от перегрузки интерфейса между маршрутизатором и коммутатором излишним трафиком осуществляется путём ограничения скорости входящего трафика на порту подключения клиента;
    • для предотвращения перегрузки таблицы MAC адресов коммутатора на интерфейсах подключения клиентов настраивается механизм Port Security, позволяющий коммутатору заучить не более определённого количества MAC адресов на этом порту;
    • производится ограничение трафика broadcast/multicast/unknown unicast на интерфейсах подключения клиентов (storm control);
    • не применяются протоколы автоматического обнаружения на уровне 2 (CDP, LLDP, LLDP-MED).

          Соответствующие настройки коммутаторов описаны в разделе «8 Принципы настройки агрегирующих коммутаторов».

  • Скачать CiscoWorks • Скачать Cisco Prime LAN Management Solution 4.1 для Windows

    Скачать CiscoWorks • Скачать Cisco Prime LAN Management Solution 4.1 для Windows

    Пакет CiscoWorks LAN Management Solution (LMS) содержит набор средств управления, необходимых для упрощения развертывания, администрирования, мониторинга и диагностики различных кампусных инфраструктур от Cisco.

    CiscoWorks LAN Management Solution

    Используя общие централизованные системы и сведения о сети, CiscoWorks LAN Management Solution предоставляет уникальный набор функций, позволяющих снизить время развертывания сети и расходы на администрирование.

    Основные свойства Cisco LMS:

    • Надежный набор средств уровня 2 для обнаружения устройств и подключений, детализированной визуализации топологии, настройки услуг уровня 2 и отслеживание оконечных станций, облегчающее настройку, управление и понимание физической и логической сетевой инфраструктуры.
    • Представление сетевых устройств на основе графического пользовательского интерфейса с отображением в реальном времени динамических данных о состоянии позволяет упростить диагностику и устранение неисправностей устройств.
    • Обнаружение неисправностей в реальном времени, функции анализа и отчета, использующие подробные сведения об устройствах и правила поиска неисправностей, основанных на лучших методах компании Cisco.
    • Упрощенные задачи администрирования, требующие меньших затрат времени, и централизованное управление сетью с помощью управления заменой устройств, сетевой конфигурацией и образами программного обеспечения, доступность сети и анализ неисправностей.
    Cisco prime

    CiscoWorks LMS состоит из следующих программных компонентов:

    • CiscoWorks Common Services — базовая платформа, осуществляющая общее управление интеграцией со сторонними системами сетевого управления, контроль административного доступа и сервисами для всего семейства решений CiscoWorks.
    • CiscoWorks LMS Portal — собственно, CMS сайта.
    • CiscoWorks Assistant — появился с версии 3.0, представляет собой набор визардов для первичной настройки компонентов.
    • Resource Manager Essentials (RME) — для управления критичными сетевыми ресурсами через Интернет с использованием web-интерфейса. Предоставляет набор инструментов для поиска и устранения неисправностей в сети, сбора детализированных отчетов, централизованного обновления программного обеспечения и конфигураций устройств, управления и конфигурации VPN, CallManager и др.
    • Internet Performance Monitor (IPM) — для анализа, оптимизации производительности и отладки неисправностей сетевых соединений на основе Cisco IP SLA.
    • CiscoView — графическое средство управления устройствами.
    • MiniRMON — инструмент для работы с RMON и RMON2.
    • Campus Manager (CM) — для обнаружения и управления L2/L3 устройствми, конфигурирования и управления VLAN и ATM LANE, а также определения подключения пользователей и IP телефонов.
    • Device Fault Manager (DFM) — обеспечивает обнаружение и определение причин сбоев сетевого оборудования в режиме реального времени.
    • Virtual Network Management (VNM) — появился с версии 3.2, занимается визуализацией топологии виртуальных сетей и их диагностикой, VRF.
    • Health and Utilization Monitor (HUM) — появился с версии 3.0.1, идёт как Add-On, требует отдельной лицензии. занимается сбором, отображением и мониторингом параметров производительности, уведомлением о превышении пороговых значений. Поддерживает только cisco-устройства, может мониторить до 1000 устройств.

    Все эти компоненты имеют свою нумерацию в рамках конкретной версии LMS, скачать Cisco Prime LAN Management Solution 4.1 для Windows

  • Как работают криптовалютные боты для процессинга на кошельки

    Как работают криптовалютные боты для процессинга на кошельки

    Большинство биткойнеров и криптовалютчиков считают наличие посторонних инжектов для процессинга  крипты или «человека в браузере» самой большой угрозой криптокошелькам, обменникам и онлайн биржам, причем процессоры крипты используют эту тактику все чаще

    Сценарии bgp mitm процессинга крипты с майнинга
    Последние статистические данные, предоставленные ведущими антивирусными компаниями подтверждают, что процессинг крипты с онлайн биржи или майнинга считается наиболее прибыльным бизнесом у кибернегодяев.
    Широкое распространение платформ онлайн торговли криптовалютой, их открытость для мобильных платформ и социальных сетей, привлекают внимание все большего количества комбинаторов. Самым простым методом процессинга крипты на кошелёк своего дропа считается фишинг, использующий приемы социальной инженерии, которые позволяют получить учётные данные криптокошелька или закрытые ключи ничего не подозревающих наивных держателей криптовалюты. О более продвинутых техниках процессинга крипты через mitm с майнинга с использованием сценариев bgp spoofing и реализаций техники bgp hijacking мы поговорим позже.
    Дроповоды и тафогоны также концентрируют свои усилия на создании все новых и новых инжектов и схем процессинга, способных заполучить закрытые ключи или учётные данные криптокошельков клиентов, включая кейлогеры (key-loggers) и грабберы экранов.
    Ответом криптовалютного сообщества стало усовершенствование процесса аутентификации, классическим примером которого является введение многофакторной аутентификации (переменные пароли, СМС-подтверждение, аппаратные токены). На сегодняшний день практически все криптобиржи уже перешли на двухфакторную аутентификацию при входе в свою учётную запись.
    Чтобы обойти системы двухфакторной защиты, ботоводы и тафогоны широко используют метод «человек в браузере». По данным многочисленных исследований, большинство участников криптовалютного рынка считают процессинг крипты  методом «человек в браузере» самой серьезной угрозой облачному майнингу. В классической схеме «человек посередине» дроповоды находятся между жертвой и криптовалютным мостом.
    В схеме «человек в браузере» ботоводы используют инжекты и процессинг, которые инфицируют браузер клиентов криптовалютной биржи. Обычно «человек в браузере» появляется в образе объектов модулей поддержки (Browser Helper Object), управляющих элементов ActiveX, расширений для браузера, дополнений, плагинов или перехвате API функций операционной системы.
    Такой тип нелегальных переводов криптовалюты основан на присутствии на устройстве клиента криптовалютной биржи инжекта или процессинга, который внедряется в его браузер. Такие дополнительные браузерные плагины способны изменять параметры транзакции крипты или проводить операции незаметно для клиента биржи. Эти программы обычно способны «прятать» транзакции, проведенные дроповодами от имени владельца кошелька, подменяя содержимое самого браузера.

    Подобные инжекты и процессинг могут обойти многофакторную аутентификацию — как только веб-сайт биржи или обменника подтвердит правильность введенных клиентом логина и пароля, троян тут же подменит данные о проводимой транзакции. 
    Дополнительный криптовалютный плагин также способен обеспечить видимость успешного завершения транзакции, подменяя содержимое, отображаемое браузером. «Человек в браузере» — очень коварный тип процессинга крипты, потому что ни биржа, ни пользователь не могут обнаружить его, несмотря на многофакторную аутентификацию, капчи или применение других способов аутентификации. Эксперты по безопасности обнаружили, что большинство интернет-пользователей (73%) не может различить реальные и поддельные всплывающие предупреждения, а также не способны распознать контент, созданный инжектами и процессингом.
    По результатам опроса, большинство криптовалютных профессионалов считают «человека в браузере» самой серьезной угрозой онлайн-биржам. На этом принципе работают такие программы, используемые дроповодами и трафогонами, как Zeus, Carberp, Sinowal или Clampi.
    В настоящее время клиенты криптовалютных бирж и обменников все ещё подвержены воздействию типа «человек посередине», но в их силах попытаться уменьшить вероятность быть вовлеченным в них (например, фишинг), что могло бы помочь избежать инфицирования системы. Наиболее эффективной контрмерой считается аутентификация по внешнему каналу (Out-Of-Band, OOB), поскольку ботовод, применяющий метод MiTM («человек посередине»), протоколирует лишь один канал связи. ООВ предусматривает отдельный канал для аутентификации, чтобы верифицировать и авторизовать транзакции криптовалюты с высоким риском. Система ООВ передает пользователю информацию о транзакции, например, по электронной почте, SMS или телефону, и для подтверждения получения требует ввода прилагаемого одноразового пароля.
    Однако, меры противодействия дроповодам и их реальная эффективность постоянно снижаются.