İstanbul'da iş ilanları

Author: Lallora

  • Помилка обробки пакета BGP призводить до тривалого простою мережі

    Помилка обробки пакета BGP призводить до тривалого простою мережі

    BGP – це магістральний протокол та «клей» Інтернету, який розсилає інформацію про маршрути між мережами провайдерів. Коротше кажучи, цей протокол BGP є дуже важливим елементом, необхідним для правильної роботи глобальної мережі в цілому.

    Програмне забезпечення маршрутизаторів, що реалізує BGP, не є ідеальним, оскільки як комерційні, так і версії з відкритим вихідним кодом мають проблеми в реалізації цього протоколу маршрутизації.

    У той час як багато недоліків незначні і пов’язані з проблемами маршрутизації, помилка обробки пакета BGP, що розглядається, викликає особливе занепокоєння, так як може поширюватися як комп’ютерний черв’як.

    Власник BGP[.] Бен Картрайт-Кокс виявив цей недолік; Це компанія, яка пропонує послуги моніторингу BGP для виявлення та вирішення проблем.

    Помилковий атрибут

    2 червня 2023 року невелика бразильська мережа повторно анонсувала маршрут із пошкодженим атрибутом у пакеті, що потенційно вплинуло на транзитні маршрутизатори.
    Багато маршрутизаторів ігнорували цей атрибут, але приймаючи його маршрутизатори Juniper, і відповідь на помилку в пакеті закривали сесії BGP, тим самим порушуючи пов’язаність своїх мереж з глобальною мережею Інтернет.
    Крім того, така помилка в пакеті BGP перериває сесію, припиняючи перетікання клієнтського трафіку доти, доки не буде виконано автоматичний перезапуск маршрутизатора, який зазвичай займає від декількох секунд до декількох хвилин.
    Завершення сесії BGP внаслідок отримання пакету з помилковим атрибутом
    Завершення сесії BGP внаслідок отримання пакету з помилковим атрибутом
    Це торкнулося багатьох операторів, таких як COLT, збій у роботі яких і привернув увагу до цієї проблеми.

    Помилка, пов’язана з обробкою помилок BGP

    Кожен атрибут пакета оновлень BGP починається з прапорів, включаючи ключовий ‘транзитивний біт’:
    Транзитивний біт у пакеті оновлень BGP
    Транзитивний біт у пакеті оновлень BGP
    Якщо транзитивний біт атрибута встановлений, а маршрутизатор його не розуміє, він копіюється на інший маршрутизатор, що може призвести до сліпого розповсюдження невідомої маршрутної інформації.
    Завершення роботи сесії BGP порушує перетікання трафіку між автономними системами і може поширюватися як черв’як. У той час як атрибути, невідомі однієї реалізації, можуть призвести до завершення роботи іншої, створений BGP UPDATE може бути націлений на постачальника певного обладнання та вивести мережу постачальника з ладу цілком.
    Поширення помилки в пакеті BGP через мережу
    Поширення помилки в пакеті BGP через мережу
    Ефект від атаки зберігається досить довгий час, оскільки анонсований маршрут все залишається в одноранговому маршрутизаторі, навіть після його перезапуску, при передачі нового пакета оновлень BGP він ініціює ще одне скидання сесії, що призводить до тривалих простоїв.
    Більше того, щоб перевірити, які реалізації протоколу BGP схильні до цієї вразливості можна використовувати просту утиліту для тестування.

    Незачеплені постачальники обладнання

    Далі наводимо список постачальників, які не торкнулися цієї вразливості:
    • MikroTik RouterOS 7+
    • Ubiquiti EdgeOS
    • Arista EOS
    • Huawei NE40
    • Cisco IOS-XE / “Classic” / XR
    • Bird 1.6, All versions of Bird 2.0
    • GoBGP

    Піддані версії обладнання або ПЗ

    • Juniper Networks Junos OS
    • Nokia’s SR-OS
    • Extreme Networks’ EXOS
    • OpenBSD’s OpenBGPd
    • OpenBSD’s FRRouting

    Питання та відповіді

    Раніше було повідомлено про ці вразливості всім схильним до неї постачальникам обладнання та програмного забезпечення. Після отримання повідомлення було отримано такі відповіді від порушених постачальників:
    • OpenBSD випустила патч
    • Компанії Juniper надали CVE
    • FRR також привласнив CVE
    • У Nokia проблему не вирішили
    • Extreme також не вирішив цієї проблеми
    Крім того, незважаючи на відсутність відповідей деяких постачальників обладнання, провайдери послуг інтернету самі можуть вжити заходів щодо запобігання потенційній експлуатації цієї вразливості.
  • Cyber war with Russia heating up

    Cyber war with Russia heating up

    If you think the crisis in the Ukraine is limited just to being on the ground, think again. A cyberwar is flaring up between Ukraine and Russia and it looks like this is only the beginning.

    The first blow came on 28 February when a group of unidentified men took control of several communications centres in Crimea, which are maintained by Ukraine’s telecom provider Ukrtelecom JSC. They wrecked cables and knocked out almost all landline, mobile and internet services in the region.

    Cyber War with Russia map

    It is now believed that the communications centres were attacked so that wireless equipment could be illegally installed in order to spy on the mobile phones of Ukrainian MPs.

    “I confirm that an IP-telephonic attack is under way on mobile phones of members of Ukrainian parliament for the second day in row,” Valentyn Nalivaichenko, the head of SBU, Ukraine’s’ security service, said.

    “At the entrance to [telecoms firm] Ukrtelecom in Crimea, illegally and in violation of all commercial contracts, was installed equipment that blocks my phone as well as the phones of other deputies, regardless of their political affiliation,” he said.

    Ukrainian hackers or sympathisers have been getting busy themselves, hacking the website of Russian state-funded news channel RT on Sunday and changing all references to “Russia” and “Russians” in headlines to “Nazi” and “Nazis”. The attack lasted only 20 minutes and the RT was quick to respond.

    A group of hackers in Ukraine who call themselves “Cyber-Berkut” have boasted about defacing at least 40 Russian news websites on their Facebook page with the image above, which shows a Nazi Swastika over Crimea.

    A post on the page (translated from Russian) warns: “Today, the “KiberBerkut” countdown begins. Traitors of Ukraine who have transgressed the laws of our homeland, you have nine days to voluntarily surrender to the prosecuting authorities or the Kharkov Simferopol.”

    The post states that the “imposters”, presumably the Russians, “have no right” to control Ukraine and must surrender to Ukraine.

    Censoring pro-Ukraine content

    On the Russian social network Vkontakte, 13 community groups set up in support of the new interim government in Kiev have had access to Russian IP addresses blocked. According to Moscow-based news website Lenta, a page appears when users try to access the groups, stating that the groups have been locked down by “the Russian Federation”.

    A press spokesperson for Vkontakte said that the blocking lasted only a few minutes and was due to an error made by moderators but the Federal Service for the Supervision of Communications, known as the Roskomnadzor, said it would continue to block Ukrainian community groups and any other IP addresses that might be displaying “extremist content”.

    While this is the extent of the cyber-attacks that we have learned of so far, the worry is that Russia could expand its military activity to include distributed-denial-of-service (DDoS) attacks to bring down crucial Ukrainian servers, the way they have done during other conflicts.

    In April 2007, Russian hackers from Nashi, Vladimir Putin’s political youth movement, targeted the websites of Estonia’s parliament, banks, ministries, newspapers and broadcasters amid a diplomatic row with Russia.

    During the 2008 South Ossetia war with Georgia, DDoS attacks were used to bring down numerous South Ossetian, Georgian, and Azerbaijani organisations.

  • Как отозвать платеж при помощи МТ192 SWIFT message

    Как отозвать платеж при помощи МТ192 SWIFT message

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

    Возвращать средства после МТ192 никто не будет, пока сам клиент не даст на то распоряжение, а распоряжения такого как вы понимаете может и не поступить. Блокировать средства на счете клиента на основании МТ192 ни один банк тоже не может.

    Обычно клиент сам распоряжается полученной суммой и банк дает ответ МТ196 банку плательщика, о том что отзыв по МТ192 противоречит условиям экспортного контракта…
  • Принципы защиты сетевого оборудования регионального уровня

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

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