Обзор CentOS 7. Часть 1: контейнеры Linux. Centos обзор


оптимизации производительности сети / Блог компании Infobox / Хабр

В предыдущих статьях по CentOS 7 было рассмотрено:Часть 1: контейнеры LinuxЧасть 2: управление идентификациейЧасть 3: NFS, FedFS, pNFSЧасть 4: смягчение DDoS атак TCP SYN Flood

В этой статье мы поговорим об улучшениях сети в CentOS 7:

  • оптимизации производительности сети;
  • поддержки сокетов с низкими задержками;
  • высокоточной синхронизации времени.
  • улучшениях безопасности;

В конце статьи ссылки на бесплатное тестирование CentOS 7 в облаке InfoboxCloud и в VPS от Infobox. Использование полосы пропускания сети продолжает расти. Сеть может становиться потенциально узким местом приложения. В CentOS 7 добавлена поддержка 40-гигабитных сетей, что позволяет быстрее обмениваться данными между системами и приложениями. В CentOS 7 добавлен механизм Team Driver, позволяющий виртуально объединять набор сетевых устройств (портов) в единый логический интерфейс. Это полезно для достижения максимальной пропускной способности и обеспечения отказоустойчивости сетей.

Для упрощения управления сетью Network manager в CentOS 7 получил значительное обновление, исправляющее ряд недостатков, связанных с настройкой сетевых интерфейсов и услуг. Появилась новая утилита для управления сетью из командной строки (NM-CLI) для простой настройки и управления сетью. Этот инструмент должен быть востребован у системных администраторов для управления серверами из командной строки, для удаленного управления серверами и скриптинга.

Оптимизации производительности сети
Представленный примерно 40 лет назад протокол TCP был спроектирован для организации надежных коммуникаций между хостами. Несмотря на масштабные изменения сетей за это время, мы по-прежнему используем TCP.

В CentOS 7 появились оптимизации производительности TCP, уменьшающие задержки и уменьшающие время ответа приложений:

  • TCP Fast Open: экспериментальное расширение TCP, спроектированное для снижения накладных расходов при установке TCP соединения. Расширение полезно для ускорения HTTP соединений при рукопожатиях и может добавить производительности от 4% до 41% в скорости загрузки страниц сайтов.
  • TCP Tail Loss Probe (TLP) – экспериментальный алгоритм, улучшающий эффективность сетевого стека при потере пакетов в конце TCP соединения. Для коротких транзакций TLP должен уменьшить таймауты передачи на 15% и для коротких HTTP ответов — на 6%.
  • TCP Early Retransmit позволяет использовать быстрые повторные передачи для восстановления потерь в сегментах сети. Другими словами, при потере пакетов соединения восстанавливаются быстрее, что улучшает общие задержки.
  • TCP Proportional Rate Reduction (PRR) – экспериментальный алгоритм, спроектированный для адаптации скорости передачи к пропускной способности, возможной для получателя или маршрутизаторов в сети для предотвращения перегрузок. Алгоритм предназначен для того, чтобы вернуться к максимальной скорости передачи быстрее и может сократить время ответа HTTP на 3-10%.
Сокеты с низкими задержками
Несмотря на то, что сетевой стек Linux считается одним из самых быстрых и надежных, в ряде приложений нужны сверхнизкие задержки. Уменьшение задержки на одну миллисекунду для крупной брокерской фирмы может принести 100 миллионов долларов в год. Многие используют нестандартные подходы для обхода сетевого стека в пользовательском пространстве.

Сокеты с низкими задержками (Low latency sockets) — программная реализация в ядре, предназначенная для уменьшения сетевых задержек и джиттера. Эта функция позволяет приложению разрешить опрос новых пакетов напрямую у драйвера устройства, обеспечивая пакетам быстрый путь в сетевом стеке. Это изменение вызывает драйвер для проверки интерфейса на наличие новых пакетов и передает их, не вызывая блокировку.

Технология позволяет приложениям, чувствительным к непредсказуемым задержкам, использовать метод busy-wait polling вместо использования прерываний для входящих пакетов.

Высокоточная синхронизация времени
Точная синхронизация времени в микросекундах и наносекундах очень важна для критических приложений с высокими требованиями к скорости работы и задержкам, например при торговле на биржах. В CentOS 7 появилась новая имплементация протокола NTP – Chrony, позволяющая синхронизировать время быстрее и точнее, чем ntpd. Chrony также лучше работает в виртуальных машинах или на компьютерах с энергосберегающими технологиями, сохраняя время точным.

В дополнение к улучшениям NTP, в Cent OS 7 появилась поддержка стандарта IEEE 1588 версии 2 «Precision Time Protocol (PTP)». PTP обеспечивает точность меньше миллисекунды.

Безопасность
Iptables разрабатывался во времена, когда сети были простыми и пропускные способности измеряли мегабитами. Новые технологии (распределенные NAT, оверлейные сети и контейнеры) требуют расширенной функциональности и гибкости. В CentOS 7 добавленa новая динамическая служба FirewallD. Сервис предоставляет большую гибкость по сравнению с iptables, например поддерживает различные зоны доверия сетей. С FirewallD можно применять правила без перезагрузки сервиса, не теряя текущие соединения.

Использованные в подготовке статьи источники: Oфициальный блог RedHatБаза знаний RedHatОфициальный блог CentOS

Попробуйте CentOS 7 в облаке Специально для наших читателей мы обеспечили возможность попробовать CentOS 7 в облаке InfoboxCloud. Регистрируйте пробную версию облака по этой ссылке. Классическую VPS с CentOS 7 можно попробовать бесплатно, используя промо-код freevps на сайте Infobox. Если вам нужно больше ресурсов для тестирования, напишите.

Если вы не можете задавать вопросы на Хабре, можно задать их в комментариях к статье в Сообществе InfoboxCloud.

Успешного использования CentOS 7!

habr.com

   

CentOS - Обзоры - Каталог статей

Серьезное отличиние CentOS от выше расмотренных дистрибутивов в том, что его прародитель целиком и полностью ориентирован на корпоративного пользователя - RHEL создается (и продается) главным образом корпоративному клиенту - с ним работают в офисах фирм и на промышленных предприятиях. Отсюда крайне жесткие требования к стабильности и надежности этой операционной системы - сбои и непонятки в работе тут недопустимы. Как следствие - не самое свежее ядро и версии пакетов (хотя выбор на ваш страх и риск - никто не отменял), и понастоящему четкая работа системы в учерб модным штучкам. Платная версия RedHat Enterprise Linux подразумевает и гарантированную профессиональную техподдержку инженеров Red Hat - разумеется у пользователей CentOS таких прав нет, но зато у них есть активное сообщество на многочисленных форумах, а то что работает в RHEL работает и здесь.

Напомним, что RedHat Enterprise Linux состоит из свободного ПО с открытым кодом, но доступно в виде дисков с бинарными пакетами только для платных подписчиков. Как требуется в лицензии GPL и других, Red Hat предоставляет все исходные коды. Разработчики CentOS используют данный исходный код для создания окончательного продукта, очень близкого к Red Hat Enterprise Linux и доступного для скачивания. Существуют и другие клоны Red Hat Enterprise Linux, созданные на основе этого кода.

  • Свободная версия Red Hat Enterprise Linux (RHEL) от сообщества.
  • Высокая стабильность дистрибутива предназначенного для корпоративных польхзователей.
  • URL: www.centos.org

P.S. Свободный дистрибутив CentOS - это своего рода "расплата" RedHat за обязательную публикацию исходного кода согласно лицензии GPL. Это не мешает корпоративному бизнесу Red Hat, но дает пользователям качественную бесплатную альтернативу без платной техподдержки. Отличный выбор для тех, кто устал от вечного "бэта-теста", но не готов платить за англоязычную тех.поддержку из-за океана.

linuxos.ucoz.ru

Смягчение DDoS атак TCP SYN Flood. Тест в облаке бесплатно / Блог компании Infobox / Хабр

В первой части обзора CentOS 7 было рассказано о поддержке контейнеров Linux в Cent OS 7. Во второй части мы поговорили об управлении идентификацией. В третья части обзора мы коснулись сетевой файловой системы NFS и ее окружению. В этой статье поговорим о смягчении DDoS атак TCP SYN Flood. В конце поста ссылка на бесплатное тестирование CentOS 7 в облачной VPS от Infobox.

DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.

Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.

Почему SYN-flood — боль для ядра
Основная проблема масштабируемости TCP для ядра Linux связана с тем, как много новых соединений могут быть созданы за секунду. Это относится к блокировке на сокет в состоянии «listen» (прослушивания). «Estabilished» (Установленные) соединения масштабируются очень хорошо. Блокировка состояния «listen» встречается не только с SYN–пакетами, но и другими пакетами для первоначального подключения «SYN-ACK» и «ACK» (пакеты тройного рукопожатия в TCP). В сценарии атаки флудом нам необходим механизм фильтрации фейковых попыток подключения до того, как сокет войдет в состояние «listen» и блокирует новые входящие соединения.
Основы фильтрации conntrack
Используя систему отслеживания соединений в Netfilter (conntrack), мы можем начать фильтрацию ложных SYN-ACK и ACK пакетов до того, как они вызовут блокирующее состояние «listen». Это было возможно уже долгое время, но не было включено по умолчанию.

Вам помогут следующие две команды:

iptables -A INPUT -m state --state INVALID -j DROP /sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0 Правило для iptables будет отлавливать пакеты, которые система отслеживания соединений классифицировала как «INVALID» и не являющихся частью известных состояний соединения.

Настройка sysctl сделает систему отслеживания соединений более строгой в категоризации и поможет уклониться в том числе от атак ACK–flood.

Что с производительностью?
В результате мы в 20 раз уменьшим влияние атак, основанных на SYN–ACK и ACK.

Conntrack в Netfilter имеет плохую репутацию за низкую скорость работы, но так было в первое время после появления технологии. Сейчас она предлагает превосходную масштабируемость и работает очень быстро. Conntrack работает без локов, используя RCU (обновление через копирование) для существующих соединений.

По сути это предотвратит проблемы от всех флудящих пакетов TCP, кроме SYN.

Почему это не работает с SYN-flood?
В conntrack есть проблема масштабируемости (похожая на блокировку «listen»), возникающую, когда речь идет о создании (или удалении) соединений, которую вызывает SYN флуд.

Даже после настройки contrack SYN пакеты будут отправлены сокету вызывая блокировку «listen». Методика смягчения этой атаки — отправить SYN–куки и предотвратить создание любого статуса, пока SYN–ACK не будет виден.

К сожалению SYN–куки, отправляются под той же блокировкой «listen», поэтому такое смягчение не решит проблему масштабируемости. Чуть позже мы обсудим, как обойти это ограничение.

Что нового в CentOS 7
На Netfilter Workshop 2013 была предложена идея «сетевых контрмер». Это дало рождение модулю iptables «SYNPROXY» и соответствующим изменениям в ядре Netfilter. Теперь эта функциональность доступна в CentOS 7.

Модуль SYNPROXY предназначен для решения двух проблем с масштабируемостью. Во-первых работает с SYN–куками параллельно. Во-вторых, он не создает conntrack до получения пакета SYN–ACK, что позволяет conntrack не блокировать новые соединения.

SYNPROXY может быть использован на локальном хосте или может защищать другие хосты за файрволом. Как только первоначальное соединение установлено, conntrack возьмет на себя все необходимые трансляции (повторно использовав части кода NAT).

Тестирование на соединениях к localhost показали 10-и кратный рост производительности по смягчению SYN–атак.

Настройка SYNPROXY
Настройка SYNPROXY может быть достаточно сложной без руководства. В этой статье рассмотрены необходимые шаги, однако вы можете использоват0 и скрипт для упрощения настройки.

Этот пример может быть использован для защиты веб-сервера на 80 порту.

Шаг 1 Убедитесь, что соединения, которые мы защищаем, не создают conntrack для SYN пакетов.iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn --dport $PORT -j CT --notrack Шаг 2 Включим более строгий conntrack. Это необходимо чтобы иметь INVALID статус для плохих ACK пакетов./sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0 Шаг 3 Теперь нам необходимо обрабатывать эти пакеты и передавать их напрямую в модуль SYNPROXY. Чтобы это сделать, используйте правило обработки UNTRACKED SYN и INVALID пакетов, которые содержат ACK от тройного рукопожатия (и других, но они просто будут проходить через это правило):iptables -A INPUT -i $DEV -p tcp -m tcp --dport $PORT -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 Шаг 4 Поймайте пакеты с состоянием INVALID, которые попали в SYNPROXY и уничтожьте их. Это предотвратит флуд SYN–ACK.iptables -A INPUT -m state --state INVALID -j DROP Шаг 5 Не забудьте включить временные метки TCP. SYN–куки используют это поле TCP./sbin/sysctl -w net/ipv4/tcp_timestamps=1 Шаг 6 Если у вас нагруженный сайт, рекомендуется настроить conntrack для увеличения лимита в 64 тысячи подключений. Так же увелитьте размер хеша conntrack. Это очень важно для производительности.echo 1000000 > /sys/module/nf_conntrack/parameters/hashsize /sbin/sysctl -w net/netfilter/nf_conntrack_max=2000000 Необходимо устанавливать значение лимитов, актуальное для вашего сайта и посчитать использование памяти для него. Например, 2 000 000 записей за раз по 288 байт = максимум 576 Мб потенциального использования памяти. Для хеша, каждая голова хеш-таблицы занимает только 8 байт на миллион записей = 8 Мб фиксированной выделенной памяти (помните размер вашего кеша L3 у CPU, когда выбираете значение кеша). Узнать, какой процессор используется на хосте можно командой:cat /proc/cpuinfo
Соображения по использованию SYNPROXY
Включение SYNPROXY может не пройти незаметно. Установка соединений будет проходить медленнее в связи с дополнительной настройкой соединения, необходимого конечному хосту. Когда конечный хост локальный, все происходит очень быстро и практически не добавляет задержек.

Параметры модуля SYNPROXY должны соответствовать опциям TCP и должны поддерживаться конечным хостом, для которого TCP соединение проксируется. Обнаружение и настройка производится вручную на основе правил (полезный инструмент «nfsynproxy» – часть релиза iptables 1.4.21). К сожалению это означает, что модуль не может быть просто развернуть на DHCP файрволы.

В будущем есть планы по авто-обнаружению опций TCP конечных хостов. Голосуйте за фичу в баг-трекере Red Hat.

Использованные в подготовке статьи источники: Mitigate TCP SYN Flood AttacksOфициальный блог RedHatБаза знаний RedHatОфициальный блог CentOS

Попробуйте CentOS 7 в облаке Специально для наших читателей мы обеспечили возможность попробовать CentOS 7 на облачной VPS от Infobox в Амстердаме. Регистрируйте пробную версию на 15 дней по этой ссылке. Если вам нужно больше ресурсов для тестирования, чем в пробной версии — напишите на [email protected]

habr.com

оптимизации производительности сети / Производительность / Сообщество InfoboxCloud

В предыдущих статьях по CentOS 7 было рассмотрено:Часть 1: контейнеры LinuxЧасть 2: управление идентификациейЧасть 3: NFS, FedFS, pNFSЧасть 4: смягчение DDoS атак TCP SYN Flood

В этой статье мы поговорим об улучшениях сети в CentOS 7:

  • оптимизации производительности сети;
  • поддержки сокетов с низкими задержками;
  • высокоточной синхронизации времени.
  • улучшениях безопасности;
В конце статьи ссылки на бесплатное тестирование CentOS 7 в облаке InfoboxCloud и в VPS от Infobox. Использование полосы пропускания сети продолжает расти. Сеть может становиться потенциально узким местом приложения. В CentOS 7 добавлена поддержка 40-гигабитных сетей, что позволяет быстрее обмениваться данными между системами и приложениями. В CentOS 7 добавлен механизм Team Driver, позволяющий виртуально объединять набор сетевых устройств (портов) в единый логический интерфейс. Это полезно для достижения максимальной пропускной способности и обеспечения отказоустойчивости сетей.

Если посмотреть правде в глаза, настройка сети в Linux может быть непростой (особенно для тех, кто не знаком с ее особенностями). При настройке даже основных сетевых служб администраторы часто полагаются на набор разных утилит или пишут скрипты вручную. С точки зрения управляемости это может быть сложно и дорого. Эта проблема может негативно влиять на скорость внедрения Linux в компаниях.

Для упрощения управления сетью Network manager в CentOS 7 получил значительное обновление, исправляющее ряд недостатков, связанных с настройкой сетевых интерфейсов и услуг. Появилась новая утилита для управления сетью из командной строки (NM-CLI) для простой настройки и управления сетью. Этот инструмент должен быть востребован у системных администраторов для управления серверами из командной строки, для удаленного управления серверами и скриптинга.

Оптимизации производительности сети
Представленный примерно 40 лет назад протокол TCP был спроектирован для организации надежных коммуникаций между хостами. Несмотря на масштабные изменения сетей за это время, мы по-прежнему используем TCP.

В CentOS 7 появились оптимизации производительности TCP, уменьшающие задержки и уменьшающие время ответа приложений:

  • TCP Fast Open: экспериментальное расширение TCP, спроектированное для снижения накладных расходов при установке TCP соединения. Расширение полезно для ускорения HTTP соединений при рукопожатиях и может добавить производительности от 4% до 41% в скорости загрузки страниц сайтов.
  • TCP Tail Loss Probe (TLP) – экспериментальный алгоритм, улучшающий эффективность сетевого стека при потере пакетов в конце TCP соединения. Для коротких транзакций TLP должен уменьшить таймауты передачи на 15% и для коротких HTTP ответов — на 6%.
  • TCP Early Retransmit позволяет использовать быстрые повторные передачи для восстановления потерь в сегментах сети. Другими словами, при потере пакетов соединения восстанавливаются быстрее, что улучшает общие задержки.
  • TCP Proportional Rate Reduction (PRR) – экспериментальный алгоритм, спроектированный для адаптации скорости передачи к пропускной способности, возможной для получателя или маршрутизаторов в сети для предотвращения перегрузок. Алгоритм предназначен для того, чтобы вернуться к максимальной скорости передачи быстрее и может сократить время ответа HTTP на 3-10%.
Сокеты с низкими задержками
Несмотря на то, что сетевой стек Linux считается одним из самых быстрых и надежных, в ряде приложений нужны сверхнизкие задержки. Уменьшение задержки на одну миллисекунду для крупной брокерской фирмы может принести 100 миллионов долларов в год. Многие используют нестандартные подходы для обхода сетевого стека в пользовательском пространстве.

Сокеты с низкими задержками (Low latency sockets) — программная реализация в ядре, предназначенная для уменьшения сетевых задержек и джиттера. Эта функция позволяет приложению разрешить опрос новых пакетов напрямую у драйвера устройства, обеспечивая пакетам быстрый путь в сетевом стеке. Это изменение вызывает драйвер для проверки интерфейса на наличие новых пакетов и передает их, не вызывая блокировку.

Технология позволяет приложениям, чувствительным к непредсказуемым задержкам, использовать метод busy-wait pooling вместо использования прерываний для входящих пакетов.

Высокоточная синхронизация времени
Точная синхронизация времени в микросекундах и наносекундах очень важна для критических приложений с высокими требованиями к скорости работы и задержкам, например при торговле на биржах. В CentOS 7 появилась новая имплементация протокола NTP – Chrony, позволяющая синхронизировать время быстрее и точнее, чем ntpd. Chrony также лучше работает в виртуальных машинах или на компьютерах с энергосберегающими технологиями, сохраняя время точным.

В дополнение к улучшениям NTP, в Cent OS 7 появилась поддержка стандарта IEEE 1588 версии 2 «Precision Time Protocol (PTP)». PTP обеспечивает точность меньше миллисекунды.

Безопасность
Iptables разрабатывался во времена, когда сети были простыми и пропускные способности измеряли мегабитами. Новые технологии (распределенные NAT, оверлейные сети и контейнеры) требуют расширенной функциональности и гибкости. В CentOS 7 добавленa новая динамическая служба FirewallD. Сервис предоставляет большую гибкость по сравнению с iptables, например поддерживает различные зоны доверия сетей. С FirewallD можно применять правила без перезагрузки сервиса, не теряя текущие соединения.

Использованные в подготовке статьи источники: Oфициальный блог RedHatБаза знаний RedHatОфициальный блог CentOS

Попробуйте CentOS 7 в облакеСпециально для наших читателей мы обеспечили возможность попробовать CentOS 7 в облаке InfoboxCloud. Регистрируйте пробную версию облака по этой ссылке. Классическую VPS с CentOS 7 можно попробовать бесплатно, используя промо-код freevps на сайте Infobox. Если вам нужно больше ресурсов для тестирования, напишите.

Успешного использования CentOS 7!

infoboxcloud.ru

оптимизации производительности сети / Linux VPS / Сообщество InfoboxCloud

В предыдущих статьях по CentOS 7 было рассмотрено:Часть 1: контейнеры LinuxЧасть 2: управление идентификациейЧасть 3: NFS, FedFS, pNFSЧасть 4: смягчение DDoS атак TCP SYN Flood

В этой статье мы поговорим об улучшениях сети в CentOS 7:

  • оптимизации производительности сети;
  • поддержки сокетов с низкими задержками;
  • высокоточной синхронизации времени.
  • улучшениях безопасности;
В конце статьи ссылки на бесплатное тестирование CentOS 7 в облаке InfoboxCloud и в VPS от Infobox. Использование полосы пропускания сети продолжает расти. Сеть может становиться потенциально узким местом приложения. В CentOS 7 добавлена поддержка 40-гигабитных сетей, что позволяет быстрее обмениваться данными между системами и приложениями. В CentOS 7 добавлен механизм Team Driver, позволяющий виртуально объединять набор сетевых устройств (портов) в единый логический интерфейс. Это полезно для достижения максимальной пропускной способности и обеспечения отказоустойчивости сетей.

Если посмотреть правде в глаза, настройка сети в Linux может быть непростой (особенно для тех, кто не знаком с ее особенностями). При настройке даже основных сетевых служб администраторы часто полагаются на набор разных утилит или пишут скрипты вручную. С точки зрения управляемости это может быть сложно и дорого. Эта проблема может негативно влиять на скорость внедрения Linux в компаниях.

Для упрощения управления сетью Network manager в CentOS 7 получил значительное обновление, исправляющее ряд недостатков, связанных с настройкой сетевых интерфейсов и услуг. Появилась новая утилита для управления сетью из командной строки (NM-CLI) для простой настройки и управления сетью. Этот инструмент должен быть востребован у системных администраторов для управления серверами из командной строки, для удаленного управления серверами и скриптинга.

Оптимизации производительности сети
Представленный примерно 40 лет назад протокол TCP был спроектирован для организации надежных коммуникаций между хостами. Несмотря на масштабные изменения сетей за это время, мы по-прежнему используем TCP.

В CentOS 7 появились оптимизации производительности TCP, уменьшающие задержки и уменьшающие время ответа приложений:

  • TCP Fast Open: экспериментальное расширение TCP, спроектированное для снижения накладных расходов при установке TCP соединения. Расширение полезно для ускорения HTTP соединений при рукопожатиях и может добавить производительности от 4% до 41% в скорости загрузки страниц сайтов.
  • TCP Tail Loss Probe (TLP) – экспериментальный алгоритм, улучшающий эффективность сетевого стека при потере пакетов в конце TCP соединения. Для коротких транзакций TLP должен уменьшить таймауты передачи на 15% и для коротких HTTP ответов — на 6%.
  • TCP Early Retransmit позволяет использовать быстрые повторные передачи для восстановления потерь в сегментах сети. Другими словами, при потере пакетов соединения восстанавливаются быстрее, что улучшает общие задержки.
  • TCP Proportional Rate Reduction (PRR) – экспериментальный алгоритм, спроектированный для адаптации скорости передачи к пропускной способности, возможной для получателя или маршрутизаторов в сети для предотвращения перегрузок. Алгоритм предназначен для того, чтобы вернуться к максимальной скорости передачи быстрее и может сократить время ответа HTTP на 3-10%.
Сокеты с низкими задержками
Несмотря на то, что сетевой стек Linux считается одним из самых быстрых и надежных, в ряде приложений нужны сверхнизкие задержки. Уменьшение задержки на одну миллисекунду для крупной брокерской фирмы может принести 100 миллионов долларов в год. Многие используют нестандартные подходы для обхода сетевого стека в пользовательском пространстве.

Сокеты с низкими задержками (Low latency sockets) — программная реализация в ядре, предназначенная для уменьшения сетевых задержек и джиттера. Эта функция позволяет приложению разрешить опрос новых пакетов напрямую у драйвера устройства, обеспечивая пакетам быстрый путь в сетевом стеке. Это изменение вызывает драйвер для проверки интерфейса на наличие новых пакетов и передает их, не вызывая блокировку.

Технология позволяет приложениям, чувствительным к непредсказуемым задержкам, использовать метод busy-wait pooling вместо использования прерываний для входящих пакетов.

Высокоточная синхронизация времени
Точная синхронизация времени в микросекундах и наносекундах очень важна для критических приложений с высокими требованиями к скорости работы и задержкам, например при торговле на биржах. В CentOS 7 появилась новая имплементация протокола NTP – Chrony, позволяющая синхронизировать время быстрее и точнее, чем ntpd. Chrony также лучше работает в виртуальных машинах или на компьютерах с энергосберегающими технологиями, сохраняя время точным.

В дополнение к улучшениям NTP, в Cent OS 7 появилась поддержка стандарта IEEE 1588 версии 2 «Precision Time Protocol (PTP)». PTP обеспечивает точность меньше миллисекунды.

Безопасность
Iptables разрабатывался во времена, когда сети были простыми и пропускные способности измеряли мегабитами. Новые технологии (распределенные NAT, оверлейные сети и контейнеры) требуют расширенной функциональности и гибкости. В CentOS 7 добавленa новая динамическая служба FirewallD. Сервис предоставляет большую гибкость по сравнению с iptables, например поддерживает различные зоны доверия сетей. С FirewallD можно применять правила без перезагрузки сервиса, не теряя текущие соединения.

Использованные в подготовке статьи источники: Oфициальный блог RedHatБаза знаний RedHatОфициальный блог CentOS

Попробуйте CentOS 7 в облакеСпециально для наших читателей мы обеспечили возможность попробовать CentOS 7 в облаке InfoboxCloud. Регистрируйте пробную версию облака по этой ссылке. Классическую VPS с CentOS 7 можно попробовать бесплатно, используя промо-код freevps на сайте Infobox. Если вам нужно больше ресурсов для тестирования, напишите.

Успешного использования CentOS 7!

infoboxcloud.ru

Обзор CentOS 7. Часть 1: контейнеры Linux - 21 Июля 2014

Сегодня мы анонсируем доступность релиза операционной системы CentOS 7 в облаке InfoboxCloud, основанного на пакетной базе Red Hat Enterprise Linux 7 и полностью совместимого с ним. В конце поста ссылка на бесплатное тестирование в облаке.

CentOS 7 — первый релиз ОС, после перехода команды CentOS в RedHat. Данная ОС стабильна и готова к корпоративному использованию.

Мы начинаем обзор новой ОС, состоящий из серии теоретических и практических статей. В первой главе обзора будет рассказано о поддержке контейнеров Linux в CentOS 7.

В облаке по умолчанию устанавливается минимальная версия CentOS 7 для обеспечения максимальной безопасности через снижение поверхности атаки. Все необходимые компоненты ОС устанавливаются из стандартных репозиториев. 

Ключевые изменения CentOS 7

 

  • Поддержка контейнеров Linux (включая поддержку Docker). Контейнеры расширяют возможности по разработке, доставке и изоляции софта для тестовых и производственных задач. Так же контейнеризация увеличивает безопасность ПО, снижая поверхность атаки;
  • Интеграция Active Directory / Identity Management (IdM)
  • Использование systemd, стандарта управления процессами, сервисами, безопасностью и другими ресурсами;
  • Встроенные профили и инструменты для оптимизации производительности и простого масштабирования;
  • Унифицированные инструменты управления и фреймворк управления OpenLMI, являющийся фактически стандартом индустрии для администрирования и настройки системы;
  • Техническая предварительная версия технологии установки обновлений ядра без перезагрузки kpatch;
Поддержка контейнеров Linux

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

В InfoboxCloud контейнерная виртуализация используется уже несколько лет как один из вариантов виртуализации: более быстрый и экономичный, чем гипервизорная технология. Стандартный функционал InfoboxCloud позволяет быстро из панели управления создавать быстрые и эффективные контейнеры с необходимой ОС. Использование контейнеров внутри виртуальной машины InfoboxCloud (флаг "Разрешить управление ядром ОС" при создании сервера в облаке) приносит новые возможности:

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

Основные возможности контейнеров Linux:

  • Управление ресурсами;
  • Процесс изоляции;
  • Безопасность;
  • Инструменты управления из командной строки.

В контексте контейнеров Linux управление ресурсами организовано через cgroups. Cgroups позволяют пользователю выделять ресурсы, такие как процессорное время, системная память, пропускная способность сети, блок ввода-вывода или любую комбинацию из этих ресурсов для установки ограниченной пользователем группы задач или процессов, запущенных в данной системе. Пользователи могут заниматься мониторингом любых настроенных cgroups, запрещать cgroups доступ к определенным ресурсам, или даже динамически переконфигурировать cgroups на запущенной системе. Используя cgroups, системные администраторы имеют точный контроль за выделением, приоритизацией, уменьшением, управлением и мониторингом системных ресурсов. Аппаратные ресурсы (ресурсы гипервизора) могут быть легко поделены между задачами и пользователями, часто повышая общую эффективность системы. Cgroups – не новая концепция. Она появилась еще в Cent OS 6. В CentOS 7 стали лучше возможности управления контрольными группами через Systemd — менеджер ОС и сервисов.

Изоляция процессов, сердце архитектуры контейнеров Linux, представлена пространствами имен ядра (kernel namespaces) CentOS. Сейчас Linux реализовывает шесть различных типов пространств имен. Цель каждого — обернуть каждый глобальный ресурс системы в абстракции. Каждый ресурс предоставляется в качестве изолированного инстанса для процесса внутри пространства имен, что обеспечивает изоляцию — иллюзию того, что группа процессов одинока в системе. Пространства имен необходимы, потому что ядро Linux ничего не знает о контейнерах. Задача пространства имен — научить ядро понятию изолированного окружения.

CentOS 7 реализует следующие пространства имен:

  • PID пространство имен предоставляет изоляцию идентификаторов процессов, позволяя процессам в различных пространствах имен PID иметь одинаковые PID. Одно из главных преимуществ пространств имен PID – возможность контейнеров мигрировать между хостами с сохранением тех же идентификаторов процессов внутри контейнера. PID пространство имен позволяет каждому контейнеру иметь собственный процесс инициализации, который управляет различными задачами инициализации системы, и управлять жизненным циклом контейнера.
  • Сетевые пространства имен предоставляют изоляцию сетевых контроллеров, системных ресурсов, ассоциированных с сетями, файрволлов и таблиц маршрутизации. Сетевые пространства имен позволяют каждому контейнеру иметь собственный виртуальный сетевой стек, который ассоциирован с группами процессов. Каждое пространство имен имеет свое собственное loopback устройство и пространство процесса. Виртуальные или реальные устройства могут быть добавлены к каждому сетевому пространству имен, и IP адреса могут быть назначены на эти устройства и использованы как сетевая нода.
  • Пространства имен UTS изолируют два системных идентификатора: nodename и domainname, возвращаемые системным вызовом uname(). Пространства имен UTS позволяют каждому контейнеру иметь собственный hostname и NIS domain name. Это полезно для инициализации и конфигурационных скриптов, которые совершают свои действия на основе этих имен.
  • Пространства имен монтирования изолируют набор точек монтирования файловых систем подобно группе процессов и помогают созданию различных файловых систем только для чтения. Процессы в различных пространствах имен монтирования могут иметь различные видения иерархии файловой системы. В дополнение к пространствам имен монтирования, системные вызовы mount() и umount() перестают действовать в глобальном пространстве точек монтирования (видимом для всех процессов ОС). Вместо этого они действуют только в пределах пространства имен монтирования, ассоциированным с процессом контейнера.
  • IPC пространства имен изолируют определенные ресурсы межпроцессного взаимодействия (IPC), такие, как объекты System V IPC и очереди сообщений Posix. Каждое пространство имен IPC имеет свой собственный набор идентификаторов System V и свою собственную очередь сообщений POSIX файловой системы.
  • Пользовательские пространства имен изолируют идентификаторы пользователя и группы так, что пользовательские процессы и идентификаторы групп могут быть различными внутри и снаружи пользовательского пространства имен. Наиболее интересный случай — когда процесс обычный не привилегированный ID снаружи пользовательского пространства имен и в то же самое время иметь идентификатор пользователя 0 внутри пространства имен. Это означает, что процесс имеет полные root привилегии для операций внутри пользовательского пространства имен, но является непривилигерованным для операций снаружи пространства имен.

Для обеспечения безопасности так же используется SELinux, который, как и в случае с cgroups, не является новой концепцией и существует начиная с CentOS 4. SELinux применяет метки безопасности и политики для контейнеров Linux и их ресурсов, предоставляя дополнительный уровень безопасности поверх безопасности, предоставляемой пространствами имен ядра.

Команда RedHat (вы ведь знаете, кто все это разработал на самом деле) начала работать над Docker начиная с версии 0.7. Вкладом Red Hat был новый драйвер хранения, который позволил Docker запуститься на Cent OS 7. В течении дальнейшего сотрудничества и вклада Red Hat в Docker был разработан новый встроенный драйвер исполнения, основанный на libcontainer, разработанный для доступа к API ядра контейнера напрямую, без сторонних зависимостей. Этот нативный набор инструментов может управлять возможностями ядра системы, такими как cgroups, пространства имен, сетевые интерфейсы, файрвол и другие особенности ядра. Благодаря Red Hat в Cent OS 7 Docker сейчас готов для корпоративного применения.

Таким образом, контейнеры Linux — важная open source технология для упаковки и доставки приложений, сочетая легковесную изоляцию и гибкость методов развертывания, основанных на образах.

Использованные в подготовке статьи источники:База знаний RedHatOфициальный блог RedHatОфициальный блог CentOS

Специально для наших читателей мы обеспечили возможность попробовать CentOS 7 в облаке InfoboxCloud. Регистрируйте пробную версию на 15 дней по этой ссылке. Если вам нужно больше ресурсов для тестирования, чем в пробной версии — напишите на [email protected]

Успешного использования CentOS 7! Продолжение следует.

http://habrahabr.ru/company/infobox/blog/230513/

laptop.ucoz.ru

Обзор CentOS 7. Часть 4: Смягчение DDoS атак TCP SYN Flood. Тест в облаке бесплатно - 11 Августа 2014

В первой части обзора CentOS 7 было рассказано о поддержке контейнеров Linux в Cent OS 7. Во второй части мы поговорили об управлении идентификацией. В третья части обзора мы коснулись сетевой файловой системы NFS и ее окружению. В этой статье поговорим о смягчении DDoS атак TCP SYN Flood. В конце поста ссылка на бесплатное тестирование CentOS 7 в облачной VPS от Infobox.

DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.

Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.

Почему SYN-flood — боль для ядра

Основная проблема масштабируемости TCP для ядра Linux связана с тем, как много новых соединений могут быть созданы за секунду. Это относится к блокировке на сокет в состоянии «listen» (прослушивания). «Estabilished» (Установленные) соединения масштабируются очень хорошо. Блокировка состояния «listen» встречается не только с SYN–пакетами, но и другими пакетами для первоначального подключения «SYN-ACK» и «ACK» (пакеты тройного рукопожатия в TCP). В сценарии атаки флудом нам необходим механизм фильтрации фейковых попыток подключения до того, как сокет войдет в состояние «listen» и блокирует новые входящие соединения. 

Основы фильтрации conntrack

Используя систему отслеживания соединений в Netfilter (conntrack), мы можем начать фильтрацию ложных SYN-ACK и ACK пакетов до того, как они вызовут блокирующее состояние «listen». Это было возможно уже долгое время, но не было включено по умолчанию.

Вам помогут следующие две команды:

iptables -A INPUT -m state --state INVALID -j DROP /sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0

Правило для iptables будет отлавливать пакеты, которые система отслеживания соединений классифицировала как «INVALID» и не являющихся частью известных состояний соединения.

Настройка sysctl сделает систему отслеживания соединений более строгой в категоризации и поможет уклониться в том числе от атак ACK–flood. 

Что с производительностью?

В результате мы в 20 раз уменьшим влияние атак, основанных на SYN–ACK и ACK.

Conntrack в Netfilter имеет плохую репутацию за низкую скорость работы, но так было в первое время после появления технологии. Сейчас она предлагает превосходную масштабируемость и работает очень быстро. Conntrack работает без локов, используя RCU (обновление через копирование) для существующих соединений.

По сути это предотвратит проблемы от всех флудящих пакетов TCP, кроме SYN. 

Почему это не работает с SYN-flood?

В conntrack есть проблема масштабируемости (похожая на блокировку «listen»), возникающую, когда речь идет о создании (или удалении) соединений, которую вызывает SYN флуд.

Даже после настройки contrack SYN пакеты будут отправлены сокету вызывая блокировку «listen». Методика смягчения этой атаки — отправить SYN–куки и предотвратить создание любого статуса, пока SYN–ACK не будет виден.

К сожалению SYN–куки, отправляются под той же блокировкой «listen», поэтому такое смягчение не решит проблему масштабируемости. Чуть позже мы обсудим, как обойти это ограничение. 

Что нового в CentOS 7

На Netfilter Workshop 2013 была предложена идея «сетевых контрмер». Это дало рождение модулю iptables «SYNPROXY» и соответствующим изменениям в ядре Netfilter. Теперь эта функциональность доступна в CentOS 7.

Модуль SYNPROXY предназначен для решения двух проблем с масштабируемостью. Во-первых работает с SYN–куками параллельно. Во-вторых, он не создает conntrack до получения пакета SYN–ACK, что позволяет conntrack не блокировать новые соединения.

SYNPROXY может быть использован на локальном хосте или может защищать другие хосты за файрволом. Как только первоначальное соединение установлено, conntrack возьмет на себя все необходимые трансляции (повторно использовав части кода NAT).

Тестирование на соединениях к localhost показали 10-и кратный рост производительности по смягчению SYN–атак. 

Настройка SYNPROXY

Настройка SYNPROXY может быть достаточно сложной без руководства. В этой статье рассмотрены необходимые шаги, однако вы можете использоват0 и скрипт для упрощения настройки.

Этот пример может быть использован для защиты веб-сервера на 80 порту. 

Шаг 1

Убедитесь, что соединения, которые мы защищаем, не создают conntrack для SYN пакетов.

iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn --dport $PORT -j CT --notrack

 

Шаг 2

Включим более строгий conntrack. Это необходимо чтобы иметь INVALID статус для плохих ACK пакетов.

/sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0

 

Шаг 3

Теперь нам необходимо обрабатывать эти пакеты и передавать их напрямую в модуль SYNPROXY. Чтобы это сделать, используйте правило обработки UNTRACKED SYN и INVALID пакетов, которые содержат ACK от тройного рукопожатия (и других, но они просто будут проходить через это правило):

iptables -A INPUT -i $DEV -p tcp -m tcp --dport $PORT -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460

 

Шаг 4

Поймайте пакеты с состоянием INVALID, которые попали в SYNPROXY и уничтожьте их. Это предотвратит флуд SYN–ACK.

iptables -A INPUT -m state --state INVALID -j DROP

 

Шаг 5

Не забудьте включить временные метки TCP. SYN–куки используют это поле TCP.

/sbin/sysctl -w net/ipv4/tcp_timestamps=1

 

Шаг 6

Если у вас нагруженный сайт, рекомендуется настроить conntrack для увеличения лимита в 64 тысячи подключений. Так же увелитьте размер хеша conntrack. Это очень важно для производительности.

echo 1000000 > /sys/module/nf_conntrack/parameters/hashsize /sbin/sysctl -w net/netfilter/nf_conntrack_max=2000000

Необходимо устанавливать значение лимитов, актуальное для вашего сайта и посчитать использование памяти для него. Например, 2 000 000 записей за раз по 288 байт = максимум 576 Мб потенциального использования памяти. Для хеша, каждая голова хеш-таблицы занимает только 8 байт на миллион записей = 8 Мб фиксированной выделенной памяти (помните размер вашего кеша L3 у CPU, когда выбираете значение кеша). Узнать, какой процессор используется на хосте можно командой:

cat /proc/cpuinfo

 

Соображения по использованию SYNPROXY

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

Параметры модуля SYNPROXY должны соответствовать опциям TCP и должны поддерживаться конечным хостом, для которого TCP соединение проксируется. Обнаружение и настройка производится вручную на основе правил (полезный инструмент «nfsynproxy» – часть релиза iptables 1.4.21). К сожалению это означает, что модуль не может быть просто развернуть на DHCP файрволы.

В будущем есть планы по авто-обнаружению опций TCP конечных хостов. Голосуйте за фичу в баг-трекере Red Hat.

Использованные в подготовке статьи источники:Mitigate TCP SYN Flood AttacksOфициальный блог RedHatБаза знаний RedHatОфициальный блог CentOS 

Попробуйте CentOS 7 в облаке

Специально для наших читателей мы обеспечили возможность попробовать CentOS 7 на облачной VPS от Infobox в Амстердаме. Регистрируйте пробную версию на 15 дней по этой ссылке. Если вам нужно больше ресурсов для тестирования, чем в пробной версии — напишите на [email protected]

http://habrahabr.ru/company/infobox/blog/232227/

laptop.ucoz.ru