По моему глубокому убеждению, в особенности в сфере IT, важнейшим качеством любого из специалистов является способность к самообучению. Именно потому в нашей небольшой компании стало хорошей традицией уделять ежедневно время этому процессу, собственному развитию. Даже менеджер должен понимать, как устроена и функционирует сеть. Не давнее, как вчера, обсуждая проблему с BGP, коллега сказал «Вот не был бы я лентяем — прошел бы в студенческие годы курс CCNA и знал бы ответ на твой вопрос». И я задался задачей помочь коллеге, найти способ получить знания в этой области самому, хотя бы начального уровня, чтоб лучше понимать с чем мы работаем. На Хабре, введя в поиск CCNA, можно встретить массу рекомендаций, но все же, англоязычный Интернет — основной источник знаний в области IT-коммуникаций.



Я просто обожаю YouTube! Ведь он предоставляет волшебную возможность удаленного «посещения» тематических конференций и семинаров, причем абсолютно бесплатно. В этот раз, как оказалось, там уже месяца 2 существует бесплатный канал, на котором лектор Imran Rafai, четко и доступно излагает материал из 30-дневного CCNA-курса, весьма доступно и увлекательно!

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

Сейчас, наверное, один из признаков нового явления — отсутствие нормальных статей в википедии. Если посмотреть статьи «Эскейп-рум» и Escape room, то ясно видно, что это направление имеет большой потенциал для популяризации. Предлагаю вашему вниманию небольшой рассказ об этом жанре и немного впечатлений (без спойлеров) от посещения уфимского квеста «Западня Говарда».

Набор скриптов ConfigServer Security & Firewall (CSF) изначально обладает достаточно богатыми возможностями по организации защиты сервера хостинга Web с помощью фильтра пакетов iptables. В частности с его помощью можно противостоять затоплению атакуемого хоста пакетами TCP SYN, UDP и ICMP слабой и средней силы. Дополняет CSF встроенный Login Failure Daemon (lfd), который осуществляет мониторинг журналов на предмет наличия многочисленных неудачных попыток авторизации в различных сетевых сервисах с целью подбора пароля. Такие попытки блокируются путем внесения адреса IP злоумышленника в черный список CSF.

В предыдущей cтатье мы описали базовые принципы работы с API и консольными утилитами, управляющими отдельными компонентами платформы Openstack (nova, cinder, glance, neutron). Сегодня мы рассмотрим, как с помощью модуля оркестрации Heat можно построить готовую инфраструктуру из виртуальных устройств.

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

Довольно часто требуется балансировать нагрузку между несколькими веб-серверами. При этом, как правило, необходимо, чтобы веб-приложения получали реальные IP-адреса клиентов, а не IP балансировщика.

В случае балансировки и терминации HTTP(S)-трафика на HAProxy (Layer 7 [1]) данная задача легко решается добавлением заголовка “X-Real-IP” и его обработкой на Nginx при помощи модуля ngx_http_realip_module [2]. При балансировке TCP-трафика от HTTPS-клиентов и передаче его на веб-сервера напрямую без модификации или терминации (Layer 4 [3]) добавить данный заголовок невозможно, поэтому требуется воспользоваться возможностями, предоставляемыми Proxy Protocol [4, 5, 6].

Рассмотрим оба варианта (балансировка L7 и L4) на примере выдержек из конфигурационных файлов haproxy 1.5.9 и nginx 1.6.2

Взломать Tor, PGP и OTR спецслужбам не под силу

Только благодаря утечкам Эдварда Сноудена и похожим событиям у нас появляется уникальная возможность посмотреть на «внутреннюю кухню» американских спецслужб. Сами они никаких конкретных цифр выдавать не могут по определению.

«Шпигель» опубликовал статью о том, как у Агентства национальной безопасности США обстоят дела со взломом криптографических алгоритмов. Это очередная утечка материалов Сноудена.

Самым полезным из этой информации является то, что на момент создания документов (2012 год) некоторые чаты и программы для пересылки электронной почты всё ещё представляли сложность для АНБ.

Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.

Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN — userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC'и. Абсурд!

Немного истории

На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых — 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек.

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

В этой небольшой статье (ещё раз) объясняется, зачем в IPv6 адреса генерируются таким странным, на первый взгляд, образом.



Тех, кто понимает смысл процедуры EUI-48 -> EUI-64 -> Modified EUI-64, статья вряд ли обогатит новыми знаниями. Остальные – добро пожаловать под кат.

Казалось бы, зачем сейчас вообще вспоминать про IPv6? Ведь несмотря на то, что последние блоки IPv4-адресов были розданы региональным регистраторам, интернет работает без каких-либо изменений. Дело в том, что IPv6 впервые появился в 1995 году, а полностью его заголовок описали в RFC в 1998 году. Почему это важно? Да по той причине, что разрабатывался он без учета угроз, с той же доверительной схемой, что и IPv4. И в процессе разработки стояли задачи сделать более быстрый протокол и с большим количеством адресов, а не более безопасный и защищенный.

В OpenVPN < 2.3.6 обнаружена уязвимость, которая позволяет аутентифицированным клиентам удаленно уронить VPN-сервер, т.е. выполнить атаку отказа в обслуживании.
Уязвимость заключается в некорректном использовании assert(): сервер проверяет минимальный размер control-пакета от клиента именно этой функцией, из-за чего сервер аварийно завершится, если получит от клиента control-пакет длиной менее 4 байт.
Следует отметить, что для совершения атаки достаточно установить коммуникацию через control channel, т.е. в случае с TLS, сам TLS-обмен. VPN-провайдеры, которые реализуют аутентификацию с использованием логина/пароля и общего TLS-ключа, подвержены уязвимости еще до стадии проверки логина и пароля.

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

Продолжение перевода статьи «Virtualization Security» за авторством Terry Komperda.

Безопасность Виртуализации. Часть 1

7. РЕКОМЕНДАЦИИ И ОПТИМАЛЬНЫЕ МЕТОДЫ ПО БЕЗОПАСНОЙ ВИРТУАЛИЗАЦИИ

7.1 Доступ Администратора и Разделение Обязанностей

• Предоставьте администраторам серверов права на включение/выключение только своего сервера.
• Возможно вы захотите дать администраторам права на развертывание новых ВМ, а не на редактирование уже существующих виртуальных машин. Другие администраторы, в свою очередь, будут иметь права только на изменение уже существующих ВМ, а не на создание новых.
• Отдельная аутентификация должна присутствовать для каждой гостевой ОС, если только нет веских оснований, чтобы два или более гостей могли использовать одни и те же данные.
• Это может показаться противоречащим общей мысли, но чем больше среда, тем проще разделять права по функциям. Один администратор не может одновременно управлять и хранением, и доменами, и виртуализированной инфраструктурой и сетями.

После обновления линейки серверов у Hetzner я решил не отставать от прогресса и обновить свой.

Естественно XenServer обновить тоже бы не помешало, тем более что Hetzner в своей wiki разместил статью по установке XenServer 6.2, но как оказалось эта инструкция была копией мануала по установке версии 6.0.2 и для установки последнего XenServer'а она не годилась.

Вооружившись документацией к XenServer 6.2 я выяснил отличия в установке.

На хабре не раз было упомянуто приложение под названием rkhunter. Хотелось бы остановиться на нем по подробней.

Rkhunter — это сканер различных видов локальных (потенциальных) уязвимостей (бэкдоров, эксплоитов и руткитов) со своей регулярно обновляемой базой.
Он написан на bash и perl, поэтому будет работать под любой серверной ОС на базе unix без каких-либо проблем.

Как известно, бэкапы нужно делать, мало того, нужно делать их так, чтобы потом с них можно было развернуться. Особенно это касается виртуальных машин (ВМ). Рассмотрим, как можно сделать бэкап виртуальных дисков машины в среде QCOW/KVM. Основных проблем здесь две: во-первых, нужно получить консистентый (целостный) бэкап, т.е. если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те, и при восстановлении СУБД может не понять такой финт. Второй вопрос — производительность ВМ в режиме снэпшота, неплохо было бы, что бы ВМ не слишком тормозила, когда мы снимаем копию, и не зависала бы, когда мы удаляем снэпшот.

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

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

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

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

Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.

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

Так получается, что я провожу в консоли (терминале) достаточно времени, порой даже больше, чем хотелось бы. Порой даже исполняю там какие-то команды и внимательно изучаю их вывод. Часто случается, что к выводу той или иной команды приходится возвращаться, а он постоянно теряется: то терминалы захлопываются, то в tmux окно закрываешь, то выводы прочих команд уже давным-давно забили и похоронили ту самую полезную строчку.

Для того, чтобы сохранить вывод какой-либо утилиты я, как и многие, пользовался tee. Это работало, но постоянная суета среди бесконечных error.log, out.log, output.log, err.log log.log, lll.txt и тп если не сводила с ума, то безумно раздражала; вместо того, чтобы вести какой-то порядок, постоянно подмывало создать Новую Папку (1), где и похоронить эти самые логи, периодически бэкапя могильничек: порядок предполагал какую-то систематизацию, а в разгаре работы вспоминать как назвать свой файл крайне не хотелось.

Тогда я написал ah, крохотную утилитку, которая сильно-сильно улучшила мою жизнь.

RouterOS — сетевая операционная система на базе Linux. Данная операционная система предназначена для установки на аппаратные маршрутизаторы Mikrotik RouterBoard. Также данная система может быть установлена на ПК (или виртуальную машину), превращая его в маршрутизатор. Изначально довольно богатая функционалом ОС нет нет да и удивит отсутствием какой-нибудь нужной фишки из коробки. К сожалению, доступ к Linux-окружению очень сильно ограничен, поэтому, «это есть под Linux» абсолютно не равнозначно «это есть в RouterOS». Но не надо отчаиваться! Эта система предоставляет несколько возможностей для расширения своего функционала. Первая — самая простая и нативная — это возможность писать скрипты на встроенном языке.
В данной статье, в качестве примера будет рассмотрен скрипт, преобразующий DNS-имена в списки IP-адресов (address lists).
Зачем он может быть нужен? Многие сайты используют Round Robin DNS для распределения нагрузки (а некоторые и не только для этого). Чтобы управлять доступом к такому сайту (создать правило маршрутизации или фаервола) нам потребуются все IP-адреса, соответствующие этому доменному имени. Более того список IP-адресов по истечении времени жизни данной DNS-записи (в данном случае речь идёт об A-записи) может быть выдан абсолютно новый, поэтому информацию придётся периодически обновлять. К сожалению в RouterOS нельзя создать правило

блокировать все TCP соединения на порт 80 по адресу example.com

на месте example.com должен быть IP-адрес, но как мы уже поняли, example.com соответствует не один, а несколько IP-адресов. Чтобы избавить нас от мучения создания и поддержки кучи однотипных правил, разработчики RouterOS дали возможность создавать правило так:

блокировать все TCP соединения на порт 80 по любому адресу из списка с именем DenyThis

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

Firefox Sync, это служба, которая позволяет пользователям переносить полностью свою историю, пароли, закладки, открытые вкладки и даже дополнения между различными устройствами, на которых установлен браузер Firefox, как для десктопной версии, так и для Android.

Firefox Sync реализуется двумя сущностями — сервисом авторизации (Firefox account API) и сервером синхронизации (Firefox Sync).

Давно возникла идея настроить свой сервер для синхронизации паролей, закладок и прочих радостей жизни. По роду деятельности, не очень доверяю публичным сервисам, таким, как LastPass или Google Account. На мой взгляд, приватные данные должны храниться на своем сервере.

Ну да хватит лирики, приступим к настройке.