Метка: BGP hijacking

  • Как работает криптовалютный майнинг-пул

    Как работает криптовалютный майнинг-пул

    Все, что я говорил выше о майнерах (например, про системное время), не относится к майнерам, объединяющимся в вычислительный пул, за исключением децентрализованного пула P2Pool. В случае майнинга на централизованном пуле непосредственным поиском блоков занимается сам пул, платя своим пользователям за предоставление ему вычислительных мощностей. В настоящее время в одиночку майнингом могут заниматься только специальные дата-центры.

    Текущее распределение вычислительных мощностей между BitCoin mining пулами

    Как же пул узнает о том, что пользователь ищет для него блок? Доказательством усиленного поиска блока служат присылаемые пользователем шары. Шара — это блок, хеш которого отвечает пониженному требованию сложности. Сеть, конечно же, такой блок не примет, и в блокчейн он не войдет. Шары требуются только пулу, чтобы удостовериться, что требуемый nonce в блоке действительно ищется.

    Почему криптосфера все еще в серой зоне?

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

    Можно продавать электричество из Сибири в Европу

    Майнинг криптовалюты — это действительно удобная возможность экспортировать энергию из удаленных уголков России фактически в любую точку мира и получать прибыль. «Можно из Сибири продавать электричество американцам или европейцам, обходить все возможные границы и при этом не терять на логистике энергии. Я думаю, эта отрасль будет одной из лидирующих в среднесрочной перспективе, потому что это выгодно всем. Прежде всего, в эту сферу довольно дешевый и простой вход. Устройство может позволить себе среднестатистический офисный сотрудник. Если мы говорим про предпринимателей, то вход тоже невысокий. В то же время в России есть энергетические компании, у них проблема в том, что потребление идет неровно — есть пиковые часы нагрузки, а есть пустые. Это приносит им довольно большие затраты. Майнинг позволяет эту историю сгладить», — рассказывает предприниматель из России.

    Мировые тренды майнинга криптовалют

    Сейчас мир смотрит на Россию и всё постсоветское пространство как на регион повышенного риска. Но при этом, это открывает большие возможности для россиян и граждан стран БРИКС по ведеднию криптобизнеса. С точки зрения майнинга криптовалют, в России представители компаний четко понимают все те риски, которые их ждут, в отличие, например, от новых регионов, где проблемы предсказать сложнее. 
    Что касается отрасли за рубежом, то можно отметить уход майнеров из Китая в США. Также растет регион майнинга криптовалют Ближнего Востока, появляются большие объекты в Африке и Латинской Америке. Иран и Венесуэла также начинают сильно набирать обороты по добыче крипты. Причина этого — проблемы с доступом на мировые рынки, однако, во всех этих странах есть проблемы с регуляцией, «потому что сама мысль майнинга и крипты иногда противоречат авторитарным установкам».

    Что ждет майнинг в текущем году

    «Сейчас доходность от майнинга на уровне скама или финансовой пирамиды, — говорит предприниматель из Сухуми. — То, что происходит сейчас, это феноменально. Во-первых, курс биткоина подрос, рубль ослаб, но все это играет на пользу майнеров в России». Однако найти довольно тяжело найти хостинг (платформа, которая предоставляет пользователям услуги по развертыванию и бесперебойной работе узлов в различных блокчейнах), свободных мест почти нет — в этом предприниматель видит основу для бизнеса.
    Что касается оборудования для майнинга, то мы считаем, что сейчас мы находимся в том моменте, когда все обновляют парк майнеров криптовалют, производители выпускают новые более эффективные и более экономичные машины. Однако с учетом того, что в России дешевое электричество, переходить на самое последнее оборудование мы не советуем — это актуально скорее для регионов с большими затратами на добычу.
  • Реализация сценариев bgp spoofing и bgp hijacking с помощью Loki

    Реализация сценариев bgp spoofing и bgp hijacking с помощью Loki

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

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

    Некоторые из представленных утилит нацелены на внедрение ложных маршрутов технологии MPLS (многопротокольная коммутация на основе признаков), которую провайдеры типа Ростелеком, Транстелеком, Вымпелком, Мегафон, Укртелеком, Level 3, Verizon, AT&T, Vodafone и Sprint используют для отделения трафика одних корпоративных пользователей от других во время его передачи из одного географического региона в другой. Утилита позволяет без труда перенаправлять такой трафик и подменять в нем данные всем, кто имеет доступ к сети определенного провайдера.

    Заниматься пробивкой в Ростелекоме очень выгодно
    Метод работает из-за того, что MPLS не имеет встроенного механизма защиты целостности заголовков пакетов, определяющих, куда должен быть доставлен поток. По словам Рея, обнаружить подмену абсолютно невозможно.

    Еще несколько приложений нацелены на использование уязвимостей в протоколе BGP (пограничный шлюзовый протокол). Помимо всего прочего, они позволяют взламывать криптографические ключи MD5, используемые для предотвращения манипуляции данными маршрутизации. Кроме этого можно прописывать в таблицы BGP несанкционированные пути, что позволяет контролировать огромные объемы сетевого транзитного трафика.

    Оставшиеся программы предназначены для использования вышеописанных дыр в Ethernet. Все они находятся в свободном доступе. В последней версии добавлена функция перехвата и расшифровки ключей сервера аутентификации и авторизации пользователей tacacs+.

  • Обработка bgp маршрутов при подключении клиентов Internet

    Обработка bgp маршрутов при подключении клиентов Internet

    Соединения с клиентами по протоколу BGP описываются в блоке конфигурации protocols bgp group INET_Customers, если соединение производится по протоколу IPv4 и в блоке конфигурации protocols bgp group IPv6_Customers.
       
      

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

          С целью использования нескольких равноценных маршрутов в настройки добавляется команда multipath.

          Пример настройки bgp group для подключения клиентов:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast {

                        prefix-limit {

                            maximum 1000;

                            teardown 80 idle-timeout 30;

                        }

                    }

                }

                multipath;

            }

            group IPv6_Customers {

                type external;

                family inet6 {

                    unicast {

                        prefix-limit {

                            maximum 100;

                            teardown 80 idle-timeout 30;

    strong>                    }

                    }

                }

                multipath;

            }

        }

    }

          Для клиентов, подключающихся к услугам доступа в Internet, необходимо исключить анонс так называемых приватных автономных систем из атрибута AS_PATH. 

    Список приватных AS приведен по адресу: http://www.iana.org/assignments/as-numbers и составляет диапазон: AS64512 AS65535. 

    Несмотря на то, что архитектура сети IP/MPLS ПАО «Ростелеком» не подразумевает использование приватных номеров автономных систем, фильтрация таких AS при передаче маршрута в другие AS позволит избежать их анонсирования вследствие ошибки в настройке или злонамеренных действий внутри Сети.

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

    protocols {

        bgp {

            group INET_Customers {

                neighbor 4.3.2.1 {

                    remove-private;

                }

            }

        }

    }

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

    • 0.0.0.0/8;
    • 0.0.0.0/1 – 0.0.0.0/32;
    • 10.0.0.0/8;
    • 100.64.0.0/10;
    • 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;
    • 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;
    • 64:ff9b::/96;
    • ::ffff:0:0/96;
    • 100::/64;
    • 2001::/23;
    • 2001:2::/48;
    • 2001:10::/28;
    • 2001:DB8::/32;
    • 2002::/16;
    • FF00::/8;
    • FE80::/10;
    • FEC0::/10;
    • FC00::/7;

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

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

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast;

                }

                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 rfc6890 {

                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 100.64.0.0/10 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;            

                }

            }

            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 rfc6890 {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

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

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

                    route-filter 100::/64 orlonger accept;           

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2001:2::/48 orlonger accept;           

                    route-filter 2001:DB8::/32 orlonger accept;

                    route-filter 2001:10::/28 orlonger accept; 

                    route-filter 2002::/16 orlonger accept;

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

                    route-filter FC00::/7 orlonger accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FEC0::/10 orlonger accept;

                    route-filter FF00::/8 orlonger accept;

                 }

            }

            term reject-others {

                then reject;

            }

        }

    }

          После проверки разрешённой длины префиксов и принадлежности публичным диапазонам адресов производятся следующие операции с полученными от клиента маршрутами:

    • запрет приёма префиксов Ростелеком;
    • запрет приёма маршрута по умолчанию;
    • запрет приёма служебных и зарезервированных BGP Community;
    • установка параметров по умолчанию;
    • установка BGP Community, соответствующих данному региональному филиалу и МРФ;
    • проверка наличия BGP Community для сброса, назначение нового BGP NextHop;
    • проверка наличия BGP Community, изменяющих Local Preference, установка запрошенного значения.

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

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast;

                }

                neighbor 1.1.1.2 {

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

                    local-address  1.1.1.1;

                    import [ sanity-check INET_CUSTOMER_in mark-routes-sib mark-region-routes-NVSK ];

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

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

                    import [ v6-sanity-check INET_v6_CUSTOMER_in mark-routes-sib mark-region-routes-NVSK ];

                    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 rfc6890 {

                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 100.64.0.0/10 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;           

                }

            }

            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 rfc6890 {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

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

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

                    route-filter 100::/64 orlonger accept;           

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2001:2::/48 orlonger accept;           

                    route-filter 2001:DB8::/32 orlonger accept;

                    route-filter 2001:10::/28 orlonger accept; 

                    route-filter 2002::/16 orlonger accept;

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

                    route-filter FC00::/7 orlonger accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FEC0::/10 orlonger accept;

                    route-filter FF00::/8 orlonger accept;

                 }

            }

            term reject-others {

                then reject;

            }

        }

        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;

                }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 850;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then {

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }

            }

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        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;

                }

            }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 850;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then { 

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }      

            }   

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        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;

            }

        }

        policy-statement mark-routes-sib {

            term 1 {

                then {

                    community add routes-SIB;

                    next policy;

                }

            }

        }

        policy-statement mark-region-routes-NVSK {

            term 1 {

                then {

                    community add routes-region-NVSK;

                    next policy;

                }

            }

        }

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

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

        community type_Customer members 12389:1;

        community type_Upstream members 12389:6;

        community type_blackhole_route members 12389:55555;

        community type_customer_backup_route members 12389:2800;

        community type_full_backup_route members 12389:2100;

        community NO_EXPORT members no-export;

        community WellKnown0 members ^0:*;

        community WellKnown65535 members 65535:*;

        community routes-SIB members «12389:1101$»;

        community routes-region-NVSK members 12389:1254;

    }

          Для корректной реализации пиринговой политики в сети при приёме маршрутов от клиентов на сервисных маршрутизаторах BPE устанавливается значение Local Pereference, равное 950. Для сервисных маршрутизаторов Juniper вместо политики INET_CUSTOMER_in можно использовать политику INET_BPE_CUSTOMER_in, пример которой приведён далее.

          Пример политики INET_BPE_CUSTOMER_in:

    policy-options {

        policy-statement INET_BPE_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;

                }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 950;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then {

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }

            }

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        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_BPE_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;

                }

            }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 950;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then { 

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }      

            }   

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        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:1-3X members «^12389:.{1,3}$»;

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

        community type_Customer members 12389:1;

        community type_Upstream members 12389:6;

        community type_blackhole_route members 12389:55555;

        community type_customer_backup_route members 12389:2800;

        community type_full_backup_route members 12389:2100;

        community NO_EXPORT members no-export;

        community WellKnown0 members ^0:*;

        community WellKnown65535 members 65535:*;

    }

          В сети ПАО «Ростелеком» для защиты от некорректных маршрутов применяется фильтрация на основе информации Routing Arbiter Database (раздел «Принципы защиты оборудования регионального уровня»). Для формирования имени фильтра используется форма CUSTOMER:<ASN>, где <ASN> – номер автономной системы клиента или название AS-SET, AS-NUM или AUT-NUM, зарегистрированные в RIR. Такой фильтр добавляется в настройки после фильтра INET_CUSTOMER_in (или INET_BPE_CUSTOMER_in).

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

    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 Community Ростелеком удаляются, за исключением 12389:X.

          Пример политики анонсирования маршрутов клиенту для маршрутизаторов Juniper:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

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

                    local-address  1.1.1.1;

                    export [ sanity-check INET_CUSTOMER_RT_and_default_out remove-communities ];

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

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

                    local-address 1::1;

                    export [ v6-sanity-check INET_v6_CUSTOMER_RT_and_default_out remove-communities ];

                    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 rfc6890 {

                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 100.64.0.0/10 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;           

                }

            }

            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 rfc6890 {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

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

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

                    route-filter 100::/64 orlonger accept;           

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2001:2::/48 orlonger accept;           

                    route-filter 2001:DB8::/32 orlonger accept;

                    route-filter 2001:10::/28 orlonger accept; 

                    route-filter 2002::/16 orlonger accept;

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

                    route-filter FC00::/7 orlonger accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FEC0::/10 orlonger accept;

                    route-filter FF00::/8 orlonger accept;

                 }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_RT_and_default_out {

            term accept-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_RT_only_out {

            term accept-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_default_out {

            term accept-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_full_out {

            term reject-RT-longer-prefixes {

                from policy RT-v6-longer-prefixes;

                then reject;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-routes {

                from { 

                    protocol bgp;

                    community [ to_INET_Customer from_FED_Peer type_REG_Peer type_MRF_Peer ];

                }

                then next policy;

            }

            term reject-others {

                then reject;

            }

        }

        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;

            }

        }

        policy-statement INET_CUSTOMER_RT_and_default_out {

            term accept-RT-aggregate {

                from policy RT-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_RT_only_out {

            term accept-RT-aggregate {

                from policy RT-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_default_out {

            term accept-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_full_out {

            term reject-RT-longer-prefixes {

                from policy RT-longer-prefixes;

                then reject;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-routes {

                from {

                    protocol bgp;

                    community [ to_INET_Customer from_FED_Peer type_REG_Peer type_MRF_Peer ];

                }

                then next policy;

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement remove-communities {

            term Clients {

                from community 12389:1X;

                then {

                    community delete 12389:2-5X;

                    next policy;

                }

            }

            term Community_12389 {

                from community 12389;

                then {

                    community delete 12389;

                }

            }

        }

        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;

            }

        }

        community 12389 members 12389:*;

        community to_Upstream members «^12389:1$»;

        community 12389:1X members «^12389:.$»;

        community 12389:2-5X members «^12389:.{2,5}$»;

        community to_INET_Customer members «^12389:[16]$»;

        community from_FED_Peer members «^12389:[57]$»;

        community type_REG_Peer members 12389:9;

        community type_MRF_Peer members 12389:8;

        community from_static_tag_1002 members «12389:1 12389:4»;

    }

          В ряде случаев необходимо передавать маршрут по умолчанию клиентам, которым передаётся полная таблица маршрутизации. В этом случае вместе с политиками INET_CUSTOMER_full_out и INET_v6_CUSTOMER_full_out применяются политики announce-default и announce-v6-default соответственно.

    Обработка маршрутов при подключении клиентов Internet

          Пример политики анонсирования маршрута по умолчанию:

    policy-options {
        policy-statement {
            announce-default {
                term accept-default-route {
                    from {
                        route-filter 0.0.0.0/0 exact;
                    }
                    then {
                        metric 0;
                        accept;
                   }
                }
        }
            announce-v6-default {
                term accept-default-route {
                    from {
                        route-filter ::/0 exact;
                    }
                    then {
                        metric 0;
                        accept;
                   }
                }
        }
    }
    }

          При подключении некоторых клиентов может потребоваться передача им community, описывающих источник маршрута (номер upstream или peer: 12389:15ZZ, 12389:16ZZ и 12389:17ZZ. 

    В этом случае вместо policy-statement remove-communities применяется policy-statement remove-communities-except-sources.

          Пример политики анонсирования маршрутов клиенту для маршрутизаторов Juniper:

    policy-options {   

        policy-statement remove-communities-except-sources {

            term Delete_Community_12389 {

                then community delete 12389_Except_1X_and_Sources;

            }

        }

        community 12389_Except_1X_and_Sources {

            invert-match;

            members «^12389:((.)|(1[567]..))$»;

        }

    }

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

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

     Оборудование регионального уровня непосредственно связано с оборудованием сетей клиентов сети 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 Принципы настройки агрегирующих коммутаторов».

  • BGP Incidents in July — September 2022

    BGP Incidents in July — September 2022

    Looking at the number of unique BGP route leakers and unique BGP hijackers, it seems that nothing is happening — what is far from the truth. 

    Although the number of unique leakers is almost the same as in the previous quarter — with the difference of only 116 leaking ASes, and the number of unique BGP hijackers grew ⅓ QoQ, we’re getting back to the reality of BGP incidents.

    Remember, here, we are counting the total number and not the unique routing incidents — if one AS originates a route leak, that is distinguished as a separate one by our model — we put it in.

    During July — September 2021 we have recorded 12103554 individual BGP route leaks — the number as high as it was in Jan — March 2022. And the reality is that the number of route leaks jumped back to where it was before the previous, somewhat anomalous quarter. 

    The total BGP hijacks in July — September 2022 were 2545562 — less than 5% of Q2’s astonishing 61M+ hijacks, but as we mentioned, in the previous quarter, the total hijack count was heavily affected by exclusively individual autonomous systems.

    Now, let us look at the global incidents that are part of these statistics through each quarter month.

    Reminder note: our team has a set of certain thresholds that separate global incidents from the rest. They include affected prefixes, affected autonomous systems, and the incident’s distribution among routing tables.

    Global BGP Route Leaks / BGP Hijacks in Q3 2022:

    July: 0 / 1

    August: 3 / 2

    September: 3 / 0

    We analyzes BGP paths data collected from more than 800 sessions, providing analytics and real-time incident monitoring to the registered and authenticated owners of Autonomous Systems. Our team  provides a user with historical data on AS connectivity (links), BGP routing anomalies, and network-related security issues.