• Рефакторинг банковской ИТ-инфраструктуры и как мы дружили ИТ-команду с ИБ-командой



      Один банк, российский филиал крупной европейской банковской группы, поставил перед нами задачу сегментировать сеть. Его серверы были расположены в наших дата-центрах. На момент начала работ у заказчика была отдельная инфраструктура для собственно финансовых операций и физически отделённая от неё большая одноранговая сеть пользователей на пару крупных узлов и множество филиалов. Первая работала как часы, а со второй были сложности. Кроме того, как раз начиналась внутренняя реорганизация под требования 152-ФЗ о персональных данных.

      Чтобы понять, как лучше организовать новую сеть, мы запросили соответствие IP-адресов и сервисов на них. Точнее, в конечном итоге нам нужна была карта с тем, что и куда гоняет трафик, чтобы было понятно, что разрешать, а что запрещать.

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

      Так мы начали разбирать весь трафик сети.
      Читать дальше →
    • Как мы переделали сеть «Аэроэкспресса»: интересный пример скачка на уровень вверх



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

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

        Следующей задачей стало обеспечение возможности продавать билеты, даже если метеориты попадут в два любых случайных объекта инфраструктуры (включая дата-центр «Аэроэкспресса» и коммутаторы ядра М9).

        И ещё — сделать IP-телефонию внутри компании, способной работать даже при физическом отключении от интернета.

        Параллельно мы подняли Ethernet поверх IP (MAC по IP) и сделали ещё пару забавных и полезных фич.
        Читать дальше →
        • +43
        • 23.7k
        • 9
      • Комплексная инфобезопасность: блиц-обзор линейки Fortinet

          Привет! Ниже будет ликбез по одной конкретной линейке оборудования, позволяющий понять, что это, зачем нужно (и нужно ли) и какие задачи при этом решаются (общая защита ИКТ-инфраструктуры, реализация блокировок, соответствие ФЗ о ПД).

          Итак, на сегодняшний день компоненты защиты обычно выглядят как настоящий «зоопарк»:



          Это потоковый антивирус, файрвол, антиспам и антидидос, а также системы обнаружения вторжений и т. п., стоящие на входе в ваш дата-центр. Фортинет (как и ряд других производителей) объединяет эти устройства в одну железку, плюс пересматривает концепцию защиты в принципе. Они уже 7 лет лидируют по Гартнеру в сегменте UTM (FW + IPS + VPN + Application Control + WebFiltering + Antispam + Antivirus и другие функции).

          Их идея в том, что периметр находится не на границе с публичным Интернетом. Если раньше защитное железо ставили на выходе, то эти парни считают, что надо ставить устройства ближе к локальной сети — работать с WLAN и в дата-центре прямо между машинами. Естественно, это требует совершенно других потоковых мощностей, но, с другой стороны, даёт и пару огромных плюсов.
          Читать дальше →
          • +13
          • 13.2k
          • 1
        • Как мы перенесли дисковое пространство сотен филиалов банка в одну СХД в Москве без потери LAN-скоростей на местах

            Дано: банк с дата-центром в Москве и множеством филиалов.

            В дата-центре стоит куча x86-машин и серьёзная хайэндовая система хранения данных (СХД). В филиалах реализована сеть с центральным сервером или мини-кластером (+ резервным сервером и low-end хранилищем), с дисковой корзиной. Бекап общих данных делается на ленте (и вечером в сейф) или же на другой сервак рядом с первым. Критичные данные (финансовые транзакции, например), асинхронно реплицируются в центр. На сервере работает Exchange, AD, антивирус, файловый сервер и так далее. Есть ещё данные, которые не являются критичными для банковской сети (это не прямые транзакции), но всё ещё очень важны — например, документы. Они не реплицируются, но иногда бекапятся по ночам, когда филиал не работает. Через полчаса после окончания рабочего дня все сессии гасятся, и начинается большое копирование.


            Вот примерно так это было устроено до начала работ

            Проблема, конечно, в том, что всё это начинает медленно увеличивать технологический долг. Хорошим решением было бы сделать VDI-доступ (это избавило бы от необходимости держать огромную сервисную команду и сильно облегчило бы администрирование), но VDI требует широких каналов и малых задержек. А это в России не всегда получается элементарно из-за отсутствия магистральной оптики в ряде городов. С каждым месяцем увеличивается количество неприятных «предаварийных» инцидентов, постоянно мешают ограничения железа.

            И вот банк решил сделать то, что, вроде бы, дороже по внедрению, если считать напрямую, но сильно упрощает обслуживание серверной инфраструктуры в филиалах и гарантирует сохранность данных филиала: консолидировать все данные в одну центральную СХД. Только не простую, а ещё с умным локальным кэшем.
            Читать дальше →
          • Оптимизация каналов связи для добычи полезных ископаемых на севере России


              Когда мы ехали на монтаж, рядом доставали трактор из оврага

              Есть такие суровые русские мужики, которые добывают разные полезные ископаемые, которые подло сгруппировались в труднодоступных местах. Часто просто добраться и вытащить их из-под земли бывает очень и очень дорого. Поэтому развитая инфраструктура на месте добычи — явление редкое. Так вот, на Дальнем Востоке во многих местах оптоволокно — всё ещё раздел научной фантастики, а провод встречается в дикой природе только если принести его с собой в руках.

              Связь там сделана через спутник. Соответственно, требования по каналу растут, но расширяться очень больно и дорого — спутниковый ресурс не самый масштабируемый, и гигабайты через него гонять не получится.

              Мы решали задачу оптимизации канала за счёт сжатия трафика и приоритезации приложений в каналах, чтобы самое важное всегда ходило первым. Получился целый сетевой детектив.
              Читать дальше →
            • Особенности отражения DDoS атак и история атаки на один крупный банк



                Раньше DDoS-атаки могли успешно отбиваться на стороне ЦОДа атакуемой компании. Быстрые умные действия админа и хорошее фильтрующее железо гарантировали достаточную защиту от атак. Сегодня услуги ботнетов стремительно дешевеют, и DDoS становится доступен чуть ли не в малом бизнесе.

                Около половины атак идут на интернет-магазины или коммерческие сайты компаний в духе «завалить конкурента», почти всегда атакуют сайты СМИ, особенно после «горячих» публикаций, намного чаще, чем кажется, бьют по госсервисам. В России главные цели – банки, розница, СМИ и тендерные площадки. Один из крупных российских банков, например, периодически блокирует трафик из Китая – атаки оттуда приходят с завидной регулярностью, одна из последних была больше 100 Гб/с.

                Соответственно, когда атака переваливает, скажем, за 10 Гб/с, отражать её на своей стороне становится проблематично из-за банального забивания канала. Именно в этот момент нужно делать переключение на центр очистки данных, чтобы весь «плохой» трафик отсеивался ещё где-то около магистральных каналов, а не шёл к вам. Сейчас расскажу, как это работает у одного из наших вендоров защитных средств – Arbor, мониторящего около 90 Тбит/сек (45% мирового трафика Интернета).
                Читать дальше →
              • Сетевые детективы: ищем причины скачков трафика и нагрузки

                • Tutorial
                Предположим, у нас есть вот такая картина загрузки канала связи:


                Что вызвало всплеск трафика? Что происходило в канале связи?

                Действие происходит в крупном ЦОДе, например, банка. И в канале может оказаться как что угодно из тестовых сервисов, так и один из десятка бизнес-сервисов, а также — с равным успехом — бекап базы данных.

                Если админ не совсем криворукий, а ситуация не очень хитрая, то минут за 10 можно будет выделить конкретные причины, создающие проблемы, и ещё минут за 15–20 проанализировать проблему. Если же ситуация сложнее (мы рассмотрим ещё пример ниже), то искать аномалии в поведении трафика можно сутками. С инструментарием обнаружения таких аномалий у нас на поиск проблемы в этом примере уйдёт 1 минута.
                Читать дальше →
                • +24
                • 27.2k
                • 6
              • Как делается оптимизация трафика

                • Tutorial

                «КПД» стандартного WAN – всего около 10%

                Если заглянуть в практически любой канал связи между филиалом компании и дата-центром, то можно увидеть достаточно неоптимальную картину:
                • Во-первых, передается очень много (до 60–70% канала) избыточной информации, которая так или иначе уже запрашивалась.
                • Во-вторых, канал загружен «болтливыми» приложениями, рассчитанными на работу в локальной сети, — они обмениваются короткими сообщениями, что негативно сказывается на их производительности в канале связи.
                • В-третьих, сам протокол TCP изначально создавался для локальных сетей и отлично подходит для малых задержек RTT и при отсутствии потерь пакетов в сети. В реальных каналах при потерях пакетов скорость сильно деградирует и медленно восстанавливается за счет больших RTT.

                Я работаю руководителем инженерной команды департамента телекоммуникаций КРОК и регулярно оптимизирую каналы связи дата-центров как наших, так и энергетических компаний, банков и других организаций. Ниже расскажу основы и приведу наиболее интересное, на мой взгляд, решение.
                Читать дальше →