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

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