Tag: MPLS

  • Обзор внутренней инфраструктуры безопасности Google

    Обзор внутренней инфраструктуры безопасности Google

    Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности.

    На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей.

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

    Следующий уровень защиты – железо. Согласно документу, Google категорически не допускает использования устаревшего оборудования в своих дата-центрах. Более того, компания применяет кастомное оборудование от производителей, которые предварительно проходят тщательный аудит и валидацию. Также Google создает собственные средства аппаратной защиты: «Также мы создаем кастомные чипы, в том числе, чипы, являющиеся аппаратными средствами безопасности, которые в настоящий момент используются нашими серверами и периферийным оборудованием. Эти чипы позволяют нам производить аутентификацию и идентифицировать легитимные устройства Google на аппаратном уровне».

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

    Работа внутренних систем service identity и access management

    Также Google уделяет особое внимание защите накопителей и имеет системы, призванные максимально осложнить «жизнь» потенциальной вредоносной прошивке и не позволить ей получить доступ к данным. «Мы применяем аппаратное шифрование для наших жестких дисков и SSD, и тщательно отслеживаем жизненный цикл каждого накопителя. Прежде чем зашифрованное устройство хранения будет списано и физически выйдет из-под нашего надзора, оно пройдет многоступенчатый процесс очистки, который включает две независимые проверки. Не прошедшие данную процедуру очистки устройства уничтожаются физически (измельчаются), это происходит локально».

    Кроме того, документ описывает меры безопасности, которые Google применяет для защиты своих исходных кодов и поиска багов в них. Так, проверки кода разделены на проверки, осуществляющиеся вручную, и автоматические. Вручную код проверяет «команда, в которой присутствуют эксперты в областях веб-безопасности, криптографии и безопасности операционных систем». Зачастую в результате таких анализов на свет появляются новые фаззеры и библиотеки безопасности, которые затем используются в других продуктах.

    Что касается исходных кодов, к их защите тоже подходят с большой ответственностью: «Исходные коды Google хранятся в центральном репозитории, где можно провести аудит как текущих, так и прошлых версий сервисов. Дополнительно инфраструктура может быть сконфигурирована таким образом, чтобы запрашивать бинарники сервиса из конкретного, проверенного и протестированного исходного кода. Такие проверки кода должны быть рассмотрены и одобрены по крайней мере еще одним инженером, помимо автора кода. Кроме того, система требует, чтобы модификации кода любых систем были одобрены владельцем данной системы. Эти требования ограничивают возможности инсайдера или нарушителя, не позволяя внести вредоносные изменения в исходные коды, а также создают криминалистический след, который можно отследить от сервиса к его источнику».

    В документе можно найти еще много интересного. К примеру, оказалось, что виртуальные машины в облаках Google работают с кастомной версией гипервизора KVM. Разработчики Google даже похвастались  и сообщили, что сотрудники Google обнаружили больше всех CVE и багов в Linux KVM гипервизоре.

  • Типовий час автономної роботи телекомунікаційної компанії «остання миля»

    Типовий час автономної роботи телекомунікаційної компанії «остання миля»

    Для обладнання в великих центрах обробки даних вам підійде. Але для обладнання в комерційних будівлях, вуличних шафах тощо час безперебійної роботи буде прямо пов’язаний з тим, скільки вірних операторів вклали в національну мережу, що означає деякі ДБЖ, і чи обслуговується будівля чи шафа добре обслуговуваним генератором.

    Я живу в Південній Африці, де з кінця минулого року (і продовжуватиметься протягом наступних 2 років, якщо не більше), я можу сказати вам, що операторам мереж доводиться мати справу з це, вони погано підготовлені.

    Деякий досвід останньої милі допоможе з деякими змаганнями цифри

    Що стосується дому, ДБЖ не дуже гарна ідея для підтримки «wi-fi»… типові ДБЖ використовують свинцево-кислотні батареї з дрібним циклом

    батареї, які не призначені для розряду нижче 50%. Це звичайна відмова від відповідальності: ДБЖ призначені для того, щоб дати вам час, щоб зберегти вашу роботу та відключитися, а не забезпечувати розширене резервне копіювання.

    Якщо клієнти очікують, що електроенергія відключатиметься більше ніж на 3 години, кілька разів на день, я рекомендую придбати дешевий інвертор потужністю 1,6 кВт, який може живити літій-іонну батарею 24 В 100 Аг (або 1x 24V, або 2x 12V послідовно). ). Це небагато енергії, але якщо ви живите CPE + ONU + IP-телефон, цього більш ніж достатньо (ви можете легко втиснути 9 годин безперервної роботи на одному заряді, можливо навіть більше). Хоча ці інвертори повільно заряджають літій-іонні акумулятори (приблизно 10 А струму заряду), навантаження настільки мінімальне, що акумулятор розряджається ще повільніше. Тож це працює навіть із тривалими, кількома відключеннями протягом 24-годинного циклу.

    Оператори, які працюють за межами великих центрів обробки даних, захочуть інвестувати у великі літій-іонні блоки, розроблені для навантаження та частоти відключень мережі. Інвестиції в свинцево-кислотні батареї, хоча вони спочатку дешевші, будуть? стають дорогими в експлуатації, оскільки вони погано справляються з високими циклами, навіть із глибоким розрядом. Не кажучи вже про досить низьку щільність енергії, яку вони мають для ваги, яку вони несуть.

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

    У густонаселених містах мобільні сайти будуть вигідними інвестиціями. Це починає ставати складним, коли ви виходите в палки.

    Крім того, коли вимикається електрика, вимикається і Wi-Fi. Це означає, що всі переміщують свій трафік від домашнього Wi-Fi до найближчої вежі стільникового зв’язку. Хоча пропускна здатність радіозв’язку та покриття сигналу не так сильно страждають, це сильно впливає на зворотний зв’язок між вежею та ядром мобільного оператора. Настільки приємне блимання сигналів LTE/4G/5G на вашому телефоні перетворюється на продуктивність GPRS. У деяких випадках ми спостерігали, як оператори мобільного зв’язку знижували рівень радіопокриття до 3G, щоб впоратися з цим. Хто знав, що у 2023 році 3G показав погану роботу, ніж GPRS чи EDGE :-)?

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

    В абсолютно екстремальних випадках (як ми бачимо тут, наприклад, у Південній Африці), сайти стільникового зв’язку можна атакувати та викрадати батареї, особливо якщо навколо темно. Я б не очікував, що це буде так у Великій Британії, особливо якщо відключення електроенергії не є нормою і люди живуть досить середнім класом, але якби я був Vodafone, наприклад, мій відділ ризиків планував би таке вже ймовірність.

  • Employing a BGP hijack against BitCoin miners

    Employing a BGP hijack against BitCoin miners

    A few days ago researchers at Dell SecureWorks published the details of an attacker repeatedly hijacking BGP prefixes for numerous large providers such as Amazon, OVH, Digital Ocean, LeaseWeb, Alibaba and more. The goal of the operation was to intercept data between Bitcoin miners and Bitcoin mining pools. They estimated that $83,000 was made with this attack in just four months. Let’s take a closer look at  the BGP details of this specific attack.

    BGP hijack details
    Our friends at Dell SecureWorks decided not to name the network from which the hijacks originated. As a result we won’t name the exact Autonomous System either, instead we will suffice by saying that the originator of this hijack is a network operating in Eastern Canada.

    BGP hijack against BitCoin market
    Initial experiment
    BGPmon detected the first BGP attack by this Canadian Autonomous System on October 8th 2013. For about 14 minutes a more specific /24 IP prefix for a Palestinian network was hijacked. Looking at geographical scope of the announcements and the probes that saw this route, we believe that in this case the route was only announced over the Toronto Internet Exchange.

    Bitcoin hijack
    On Feb 3rd 2014, the first targeted Bitcoin hijacks took place, this affected more specific prefixes for AS 16509 (Amazon). Starting Feb 4th the BGP attack appears to be originating from one of the downstream customers of the attacker. We believe this may have been an attempt to hide the actual Origin AS.

    As of February 6th the finger print changes slightly again and the same more specific announcement for Amazon now appears to be announced by Amazon directly; i.e. the most right AS in the AS path is the Amazon AS. Looking at the data we believe that part of the ASpath is spoofed and that Amazon did not actually announce this prefix, instead it was announced by the Canadian attacker who tried to hide itself using AS path prepending. 

    Interestingly this specific case looks a lot like the ‘stealing the Internet’ attack as presented at Defcon a few years ago, including ASpath poisoning where some of the attackers upstream providers were included in the spoofed part of the ASpath.

    We then observe a large gap between February 8th and March 22 where we don’t see any attacks involving this particular AS. On March the 22nd the BGP attacks return. In this case largely with the same fingerprint: mostly more specific (/24) announcements with the same spoofed ASpaths.
    Finally May 13, 2014 is the last day these BGP attacks have been observed and it’s been quiet since.

    Filters to limit the Scope and impact
    It appears that all the BGP announcements related to the Bitcoin hijack attacks were only visible via peers of this Canadian network via the Internet Exchange. This means that the attacker either did not announce these hijacked blocks to their transit providers, or the transit providers did a good job in filtering these announcements.

    Most network operators do not have prefix filters on BGP peering sessions at Internet Exchanges. Instead they often only have Max-Prefix filters in place. These Max-Prefix filters are intended to protect against large leaks, or a sudden increase in announced prefixes by these peers. In this scenario the BGP attacker would only announce a few new prefixes at any given time, this prevented Max-Prefix filters to trip.

    Collateral damage
    The BGP attacker appears to have known exactly what IP addresses are Bitcoin miners and as a result knew who to target. However, because many network operators filter out prefixes longer than a /24, the BGP attacker chose to announce a /24 in order to increase the chances of the prefix being accepted. This means that other machines in the same hijacked /24 prefix that have nothing to do with Bitcoin mining were also affected. Because of the nature of the providers affected, primarily cloud providers offering VM hosting (AWS, OVH, Digital Ocean, ServerStack, Choopa, LeaseWeb and more), it is not unlikely that traffic for machines (VMs) of hundreds of organizations worldwide may have been redirection to the BGP attacker.

    Not the first time
    This incident follows numerous similar BGP hijacks that happened recently. Just last year networks of several Credit Card companies were attacked

    Another example is the hijack of multiple Government departments of one specific European country. More recently Turkey hijacked the IP addresses of several well-known DNS providers

    These recent examples demonstrate that BGP attack is indeed being used for financial gain, Intelligence collection as well as Censorship.
  • С чего начать работу на площадке процессинга

    С чего начать работу на площадке процессинга

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

    С чего начать работу или как грамотно лить крипту на зарубежный пластик

    И тут сразу возникает вопрос о покупке банковского трояна. В этом месте позвольте задать извечный китайский вопрос: а нахуа его покупать? Банковские трояны ZeUS и CarberP давно уже выложены на торрентах грамотными людьми и их можно просто так скачать. На самом деле по функционалу у них небольшая разница и CarberP отличается от ZeUS наличием загрузчика, который способен отключить антивирус, установленной на банковской машине, перед загрузкой основного тела программы банковского трояна.

    Как мне рассказал один очень грамотный человек, все эти белые, серые или чёрные с зелёным треугольники – полная чепуха, и надо двигаться совершенно в другом направлении.

    Однако, и это всё ещё только начало… чтобы что-либо слить с помощью этих или каких-либо других инструментов, их нужно ещё и установить на какой-нибудь абузный хостинг, написать инжекты под выбранный вами банк или криптосервис, и только после этого можно приступать к основной части работы. Во Львое и Ивано-Франковске я разговаривал со многими людми в теме, и все мне рассказывали об одной и той же проблеме – сейчас практически стало невозможно достать качественный целевой трафик, где бы присутствовало много жирных пользователей дистанционных банковских услуг и криптовалютных площадок и сервисов.

    Утечки маршрутов и трафик ASIC аппаратов

    Утечки маршрутов по bgp происходят, когда маршруты, объявленные одной автономным системой (Automomous System), неожиданно становятся доступными для других AS. Причём не обязательно эти две автономные системы могут быть транзитными. Это может произойти из-за ошибок при конфигурировании оборудования Cisco или Juniper, не обязательно их конечно, в этой роли может выступать любой маршрутизатор с поддержкой протокола bgp, преднамеренных действий или уязвимостей в самом протоколе bgp.

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

    • Перехват данных транзакций криптовалюты – нарушитель может перехватить трафик, собирая конфиденциальные данные, а также подменить данные на лету при помощи простейших средств, в том числе используя Ettercap NG или Loki (Insinuator)
    • Замедление или полное прекращение работы целевого сервиса в глобальной сети –  неправильная маршрутизация может замедлить доступ к любому интернет-ресурсу или сделать его вовсе недоступным на какое-то время

    Поэтому основное вложение в этом бизнесе приходится делать не в программное обеспечение (его и так можно бесплатно скачать), а в покупку качественного трафика. Самый хороший трафик, это тот, который идет с лома в одни руки, либо снимается с multihomed или транзитной AS какого-нибудь крупного телекоммуникационного провайдера напрямую, методами bgp mitm с реализацией bgp spoofing по сценариям bgp hijacking, провоцируя при этом всевозможные утечки маршрутов.

    Но увы, такого трафика на рынке практически нет и его приходится добывать самому. На добыче крипты такими методами при наличии хорошего трафика, в месяц можно зарабатывать до 1 млн. Евро и даже больше.

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