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

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

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

Так мы начали разбирать весь трафик сети.

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

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

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

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

Параллельно мы подняли Ethernet поверх IP (MAC по IP) и сделали ещё пару забавных и полезных фич.

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

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



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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Если заглянуть в практически любой канал связи между филиалом компании и дата-центром, то можно увидеть достаточно неоптимальную картину:

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

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