Блог

  • Google AdSense полностью отключил монетизацию всем российским пользователям

    Сервис таргетированной рекламы Google AdSense полностью деактивировал аккаунты пользователей из России. «Это означает, что получать доход от монетизации блогов и YouTube через такие аккаунты на счета в российских банках будет нельзя», — говорится в заявлении компании. Там уточнили, что заработок пользователей за июль сервис выплатит между 21 и 26 августа.

    Ютуберы из России активно переезжают в другие страны на постсоветском пространстве

    Рекламный сервис Google AdSense деактивировал аккаунты пользователей из России, следует из рассылки компании пользователям. Скриншот письма опубликовал портал 3dnews. «Мы деактивируем все аккаунты AdSense, страной местоположения которых указана Россия. Это означает, что получать доход от монетизации через такие аккаунты будет нельзя», — говорится в сообщении. Заработок за июль сервис выплатит между 21 и 26 августа, если в аккаунте не приостановлено получение платежей и достигнуты пороги оплаты, уточнили там. Остаток по балансу российским пользователям Google планирует выплатить в течение 60 дней. 

    В марте 2022-го Google запретила продажи любой онлайн-рекламы в России «в свете чрезвычайных обстоятельств». До этого, в феврале того же года, Роскомнадзор потребовал от компании прекратить показывать рекламу, содержащую неточную информацию о ходе СВО на Украине. Позже он потребовал от Google прекратить показывать рекламу YouTube с «ложной политической информацией» об Украине, которая направлена на «дезинформацию российской аудитории». 

    В июле глава думского комитета по информационной политике Александр Хинштейн заявил, что скорость работы YouTube в России снизится сначала на 40%, а затем — на 70%. По его словам, эта мера направлена не против российских пользователей, «а против администрации иностранного ресурса, который по-прежнему считает, что может безнаказанно нарушать и игнорировать наше законодательство». Ухудшение качества загрузки видео на YouTube связано с действиями российских властей и является следствием того, что хостинг удаляет каналы российских журналистов, артистов и блогеров, пояснил он.

    До этого Роскомнадзор направил гендиректору Google Сундару Пичаи требование разблокировать более 200 YouTube-аккаунтов российских СМИ, органов власти и общественных деятелей. С 2020 года видеохостинг ограничил 207 российских ресурсов, при этом 83 из них — в 2024 году, отметили тогда в ведомстве. 

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

    Однако, после «замедления» YouTube 8 августа операторы связи отметили скачок общего объема трафика на 5-10%. В сетях региональных операторов он достигает и 20%. Они объясняют это использованием VPN для получения доступа к популярному видеосервису, а также активным копированием видео из YouTube на конкурирующие с ним российские ресурсы. Это грозит операторам, особенно региональным, дополнительными затратами на приобретение трафика у магистральных операторов, так как отечественные замены YouTube не имеют достаточно кеширующих серверов, особенно в регионах, поясняют операторы.

    Скачок трафика

    В пресс-службе крупнейшей российской точки обмена интернет-трафиком MSK-IX нам рассказали, что зафиксировали рост трафика за последнюю неделю на 5,6%, если сравнивать с обычными значениями, — до 3509 Гбит/с. В компании отметили, что мобильный трафик отдельно от общего не отслеживают. Генеральный директор оператора IT-решений «Обит» Андрей Гук оценил рост общего трафика российских операторов на 5-10% за последнюю неделю. 

    Напомним, что 8 августа в работе YouTube произошел масштабный «сбой», который длится до сих пор, хотя проблемы с доступом к видеосервису наблюдаются уже месяц. Российские власти, в том числе Роскомнадзор, поясняли ухудшение качества работы YouTube прекращением поддержки инфраструктуры кеширующих серверов Google в России. Хотя эксперты не сомневаются, что это дело рук Роскомнадзора, который блокирует видеосервис с помощью технических средств противодействия угрозам (ТСПУ), установленных на сетях всех российских операторов связи. В одном из своих постов глава комитета по информполитике Госдумы Александр Хинштейн туманно отмечал, что «деградация» YouTube — «вынужденный шаг, направленный не против российских пользователей, а против администрации иностранного ресурса». 

    Под инфраструктурой кеширующих серверов имеют в виду собственную CDN-сеть американской компании, так называемую Google Global Cache (GGC). Google развивает её во многих странах присутствия, в том числе и в России. Сервис позволяет загружать востребованный контент не с центрального сервера, который может быть расположен за тысячи километров, а с ближайшего сервера CDN (content delivery network, сеть распределенных по стране серверов, установленных на сетях операторов связи). В данный момент российская «дочка» Google в России проходит процедуру банкротства и CDN-сеть не поддерживает. Свои CDN-сети имеют и российские видеосервисы, например «VK Видео». 

    Поиск альтернатив 

    По словам президента ассоциации «Ростелесеть» Олега Грищенко, за последнюю неделю трафик в сетях российских региональных операторов вырос примерно на 10-20%. «Если говорить точнее, то, в целом, уровень трафика сохранился, но раньше его часть проходила через кеш-сервера и была во внутренней сети оператора. Теперь абоненты уходят искать информацию на внешние каналы связи, увеличивая закупаемый трафик», — пояснил он. 

    «Абоненты начинают больше искать нужную им информацию на альтернативных YouTube платформах. Однако наблюдается недостаток кеширующих серверов у отечественных видеоплатформ. Они поставили кеш-сервера у федеральных операторов, а у региональных провайдеров кеш-серверов установлено существенно меньше», — разъяснил Олег Грищенко. По его словам, операторы готовы к подобным скачкам с технической точки зрения. Но возрастают затраты на трафик, хотя пока рано судить, в какие суммы они выльются, добавил глава ассоциации «Ростелесеть».

    По данным «ТМТ Консалтинг» за I квартал этого года, первая пятерка федеральных провайдеров («Ростелеком», МТС, «ЭР-Телеком» (бренд «Дом.ру»), «Вымпелком» (бренд билайн) и ТТК) занимают 71%, еще 29% приходится на локальных игроков рынка. Президент ассоциации операторов кабельного телевидения «Макател» Алексей Амелькин рассказал, что, исходя из статистики одного из операторов, входящих в ассоциацию, за 5-11 августа трафик вырос на 5,5%, если сравнивать с неделей 22-27 июля. «Ростелеком», «Мегафон», МТС, «Вымпелком» и «ЭР-Телеком» отказались от комментариев. В пресс-службах Минцифры и ТТК не ответили на наш запрос. 

    Оди источник одного из крупных региональных операторов не зафиксировал аномального роста общего трафика, хотя и отмечает, что наблюдается увеличение трансграничного трафика. Очевидно, это результат более активного использования VPN-сервисов, пояснил он. При этом он отметил, что трафик YouTube с 1 августа просел примерно в полтора-два раза, а VK — вырос на треть в тот же день. «Можно наблюдать тенденцию перетока аудитории YouTube в «VK Видео», однако только части трафика», — сделал вывод он. В пресс-службе VK сообщили, что объем загрузок видеоконтента на сервис «VK Видео» за неделю с 5 по 11 августа вырос в 1,5 раза в сравнении со среднемесячными показателями июля. А количество авторов, впервые загрузивших видео на платформу, за эту же неделю увеличилось в 1,7 раза.

    YouTube на дисках

    Рост трафика может быть связан с тем, что ряд пользователей воспользовались опциями скачивания видео из YouTube на российские видеоплатформы, пояснил автор Telegram-канала abloud62 Алексей Бойко. Некоторые скачивают ценные для них видео и на жесткие диски, добавил он. Кто-то использует VPN-сервисы, чтобы получить доступ к YouTube, а такого рода шифрование формирует трафик повышенного объема, отметил эксперт. «Кроме того, десятки миллионов людей периодически пробуют получить доступ к сервису в обычном режиме, надеясь, что «замедления» наконец прекратили. Все это создает основания для роста трафика», — пояснил Бойко.

    Если ситуация с «замедлением» YouTube сохранится или ухудшится, то, по самым негативным прогнозам, от трафика видеосервиса останется не более 10%, которые будут ходить через VPN-сервисы. Это в свою очередь приведет к общему падению трафика в сетях операторов на 15-20%, рассказал наш источник в одном из крупных операторов связи, добавив, что нужно не меньше шести месяцев, чтобы увидеть картину целиком и понять последствия «замедления». Также, по его словам, многое будет зависеть от того, какие альтернативные YouTube видеосервисы смогут предложить российские ресурсы. «Если будет достойная замена YouTube, то трафик просто перераспределится в её пользу и месяцев через шесть про американский видеосервис забудут. Если достойной альтернативы не будет, нужно будет смотреть на трафик: он либо упадет, либо действительно перераспределится через VPN. Будет ли замещен чем-нибудь трафик YouTube, чем, как и когда, сейчас предсказать невозможно», — заключил он.

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

  • Как отозвать платеж при помощи МТ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 Принципы настройки агрегирующих коммутаторов».

  • Софт для угона IP трафика через BGP

    Софт для угона IP трафика через BGP

     

    Специалисты по IT-безопасности Антон Капела и Алекс Пилосов разработали методику, с помощью которой можно тайно перехватывать интернет-трафик и даже модифицировать его на пути к адресату.

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

    В результате этого многие IT-эксперты уже называют обнаруженную дыру одной из самых крупных в интернете, которая, наверное, даже более серьезная чем обнаруженная ранее DNS-уязвимость.

    Возможность перехвата BGP-сессии присутствует на любом роутере
    Специалисты Капела и Пилосов показали на конференции DefCon, каким образом можно перехватить трафик, направляющийся в сеть конференции, и переправить его в контролируемую ими систему в Нью-Йорке, а затем доставить обратно.
    Необходимо отметить, что ранее перехватывать интернет-трафик, используя уязвимость BGP, были способны только разведывательные агентства.

    В настоящее время технология угона ip трафика через bgp стала доступна всем благодаря использованию пакета Loki, который работает на платформе Windows x64.

  • Модель сетевого взаимодействия OSI — Open Systems Interconnection

    Модель сетевого взаимодействия OSI — Open Systems Interconnection

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

    Open Systems Interconnection - Модель OSI

    Теоретически, каждый уровень должен взаимодействовать с аналогичным уровнем удаленного компьютера. На практике каждый из них, за исключением физического, взаимодействует с выше – и нижележащими уровнями – представляет услуги вышележащему и пользуется услугами нижележащего. В реальной ситуации на одном компьютере независимо друг от друга иногда выполняется несколько реализаций одного уровня. Например, компьютер может иметь несколько сетевых адаптеров стандарта Ethernet или адаптеры стандартов Ethernet и Token-Ring и.т.д.

    Физический уровень
    Физический уровень описывает физические свойства (например, электромеханические характеристики) среды и сигналов, переносящих информацию. Это физические характеристики кабелей и разъемов, уровни напряжений и электрического сопротивления и.т.д., в том числе, например, спецификация кабеля «неэкранированная витая пара» (unshielded twisted pairUTP)
      
    Канальный уровень
    Канальный уровень обеспечивает перенос данных по физической среде. Он поделен на два подуровня: управления логическим каналом (logical link controlLLC) и управления доступом к среде (media access controlMAC). Такое деление позволяет одному уровнюLLC использовать различные реализации уровня MAC. Уровень MAC работает с применяемым в Ethernet и TokenRing физическими адресами, которые «вшиты» в сетевые адаптеры их производителями. Следует различать физические и логические (например, IP) адреса. С последним работает сетевой уровень.
    Сетевой уровень
    В отличии от канального уровня, имеющего дело с физическими адресами, сетевой уровень работает с логическими адресами. Он обеспечивает подключение и маршрутизацию между двумя узлами сети. Сетевой уровень предоставляет транспортному уровню услуги с установлением соединения (connectionoriented), например Х.25, или без установления такового (connectionless) например IP (internetprotocol). Одна из основных функций сетевого уровня – маршрутизация.
    К протоколам сетевого уровня относиться IP и ICMP (Internet Control Massage Protocol).
    Транспортный уровень
    Транспортный уровень предоставляет услуги, аналогично услугам сетевого уровня. Надежность гарантируют лишь некоторые (не все) реализации сетевых уровней, поэтому ее относят к числу функций, выполняемых транспортным уровнем. Транспортный уровень должен существовать хотя бы потому, что иногда все три нижних уровня (физический, канальный и сетевой) предоставляет оператор услуг связи. В этом случае, используя соответствующий протокол транспортного уровня, потребитель услуг может обеспечить требуемую надежность услуг. TCP (Transmission Control Protocol) – широко распространенный протокол транспортного уровня.
    Сеансовый уровень
    Сеансовый уровень обеспечивает установление и разрыв сеансов, и управление ими. Сеанс – это логическое соединение между двумя конечными пунктами. Наилучший пример этой модели – телефонный звонок. При наборе номера Вы устанавливаете логическое соединение, в результате на другом конце провода звонит телефон. Когда один из собеседников говорит «аллё», начинается передача данных. После того как один из абонентов вешает трубку, телефонная компания выполняет некоторые действия для разрыва соединения. Сеансовый уровень следит также за очередностью передачи данных. Эту функцию называют «управление диалогом» (dialog management). Вот примеры протоколов сеансового, представительного и прикладного уровней –SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) и Telnet.
    Представительный уровень
    Представительный уровень позволяет двум стекам протоколов «договариваться» о синтаксисе (представлении) передаваемых друг другу данных. Поскольку гарантий одинакового представления информации нет, то этот уровень при необходимости переводит данные из одного вида в другой.
      
    Прикладной уровень
    Прикладной уровень – высший в модели ISOOSI. На этом уровне выполняться конкретные приложения, которые пользуются услугами представительного уровня (и косвенно – всех остальных). Это может быть обмен электронной почтой, пересылка файлов и любое другое сетевое приложение.
    Таблица 1. модель ISOOSI и некоторые протоколы соответствующих уровней.
    ПРИКЛАДНОЙ УРОВЕНЬ
    SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol)
    ПРЕДСТАВИТЕЛЬНЫЙ УРОВЕНЬ
    СЕАНСОВЫ УРОВЕНЬ
    ТРАНСПОРТНЫЙ УРОВЕНЬ
    TCP AND UDP
    СЕТЕВОЙ УРОВЕНЬ
    IP, ICMP, ARP
    КАНАЛЬНЫЙ УРОВЕНЬ
    IEEE 802.3
    Ethernet
    ФИЗИЧЕСКИЙ УРОВЕНЬ