Определяем места, где стоит подстелить соломку

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

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

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

Предисловие

Проснулся я сегодня с мыслью, что огромное количество инструкций по настройке NAT советуют использовать строку вида:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Многие понимают проблемы этой конструкции, и советуют добавлять:

iptables -A FORWARD -i ppp0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Но, зачастую, забывают задать таблице FORWARD действие DROP по умолчанию, или добавить правило REJECT в конец таблицы.
На первый взгляд, вроде бы, все кажется нормальным. Однако, это далеко не так. Дело в том, что если не запретить маршрутизировать трафик из WAN-порта в WAN-порт, кто-нибудь из вашей WAN-сети (предположим, что провайдер садит весь подъезд в одну /24) может маршрутизировать трафик через вас, просто прописав ваш IP в качестве шлюза. Все современные SOHO роутеры это учитывают, а вот неопытный администратор, который делает роутер под обычным linux, может не знать или забыть об этом. В подсети моего провайдера таких роутеров не оказалось, и мой план по захвату мира провалился. Однако, статья совсем не об этом.

Магические двоеточия

Как вы, может быть, знаете, многие современные программы и сервисы биндятся на IP :: (два двоеточия), а не на 0.0.0.0, как было раньше. IPv6 адрес :: значит то же самое, что и IPv4 0.0.0.0, т.е. «слушаем все интерфейсы». Многие считают, что если программа слушает ::, то этот сокет может принимать только IPv6-соединения, однако это далеко не так.
В IPv6 есть так называемое отображение IPv4-адресов в IPv6 диапазон. Если программа слушает сокет ::, а к ней обращаются из IPv4-адреса 1.2.3.4, то программа получит соединение с адреса ::ffff:1.2.3.4. Этого можно избежать, сделав:

sysctl -w net.ipv6.bindv6only=1

Но это нужно далеко не всегда, т.к. обычно удобно, что программа слушает один сокет, а получать соединения может по двум протоколам сразу. Практически во всех дистрибутивах, IPv6-сокеты ведут себя именно так, т.е. bindv6only=0.

Доброго времени суток всем!

Я уже писал о своем опыте работы с WebRTC тут, но учитывая то, что в последнее время всё больше статей на эту тему появляется на хабре и то, что я давно хотел написать о том, как мы добились стабильной работы SIP телефонии через WebRTC на продакшне, я решил написать через что мы прошли.

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

Кому интересно, прошу под кат.

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

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

В этой статье мы расскажем о том, как можно получить спецификацию Linux-сервера в командной строке.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

Традиционно, приложение, запускающееся даже с правами пользователя, имеет полный доступ в сеть. Оно может использовать любой сетевой адрес, существующий в системе для отправки пакетов.

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

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

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Некоторое время поработав с Zabbix, я подумал, почему бы не попробовать использовать его в качестве решения для мониторинга событий информационной безопасности. Как известно, в ИТ инфраструктуре предприятия множество самых разных систем, генерирующих такой поток событий информационной безопасности, что просмотреть их все просто невозможно. Сейчас в нашей корпоративной системе мониторинга сотни сервисов, которые мы наблюдаем с большой степенью детализации. В данной статье, я рассматриваю особенности использования Zabbix в качестве решения по мониторингу событий ИБ.

В течение минуты думал над заголовком, так ничего и не придумал…
Strace. Наверное нет того человека, который бы не слышал про strace. Если кто не слышал, то strace — это утилита, отслеживающая системные вызовы, которые представляют собой механизм трансляции, обеспечивающий интерфейс между процессом и операционной системой (ядром). Эти вызовы могут быть перехвачены и прочитаны. Это позволяет лучше понять, что процесс пытается сделать в заданное время. Перехватывая эти вызовы, мы можем добиться лучшего понимания поведения процессов, особенно если что-то идет не так. Функциональность операционной системы, позволяющая отслеживать системные вызовы, называется ptrace. Strace вызывает ptrace и читает данные о поведении процесса, возвращая отчет. Детали можно прочитать в вики или официальном man. Собственно вот, ну и речь конечно же о Linux. В других ОС свои аналоги.
Так вот, лично для меня strace это как последняя инстанция. Когда уже все логи просмотрены, все debug и verbose ключи включены, а причина проблем так и не обнаружена, я достаю из широких штанин запускаю strace. Есть одно но, strace это такой инструмент который вовсе не является серебряной пулей, которая тут же все покажет и расскажет. Для работы с strace требуется наличие определенных знаний и чем шире и глубже эти знания тем больше вероятность обнаружения проблемы.
В интернетах полно вводных статей, где описываются примеры запуска strace. Я же в этой статье покажу частные проблемы и их решение с помощью strace.

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

Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

Создание пакетов или packet crafting — это техника, которая позволяет сетевым инженерам или пентестерам исследовать сети, проверять правила фаерволлов и находить уязвимые места.
Делается это обычно вручную, отправляя пакеты на различные устройства в сети.
В качестве цели может быть брандмауэр, системы обнаружения вторжений (IDS), маршрутизаторы и любые другие участники сети.
Создание пакетов вручную не означает, что нужно писать код на каком-либо высокоуровневом языке программирования, можно воспользоваться готовым инструментом, например, Scapy.

Scapy — это один из лучших, если не самый лучший, инструмент для создания пакетов вручную.
Утилита написана с использованием языка Python, автором является Philippe Biondi.
Возможности утилиты практически безграничны — это и сборка пакетов с последующей отправкой их в сеть, и захват пакетов, и чтение их из сохраненного ранее дампа, и исследование сети, и многое другое.
Всё это можно делать как в интерактивном режиме, так и создавая скрипты.
С помощью Scapy можно проводить сканирование, трассировку, исследования, атаки и обнаружение хостов в сети.
Scapy предоставляет среду или даже фреймворк, чем-то похожий на Wireshark, только без красивой графической оболочки.
Утилита разрабатывается под UNIX-подобные операционные системы, но тем не менее, некоторым удается запустить ее и в среде Windows.
Эта утилита так же может взаимодействовать и с другими программами: для наглядного декодирования пакетов можно подключать тот же Wireshark, для рисования графиков — GnuPlot и Vpython.
Для работы потребуется права суперпользователя (root, UID 0), так как это достаточно низкоуровневая утилита и работает напрямую с сетевой картой.
И что важно, для работы с этой утилитой не потребуются глубокие знания программирования на Python.

Доброго времени суток, уважаемые пользователи Хабра.

После очередной вспышки вирусной активности в сетевой папке нашей организации я задумался об ее антивирусной защите. Речь идет о сетевой папке, за которую отвечает Samba, работающая на Debian Wheezy.

Обратившись в гугл за информацией, я нашел 2 актуальных на текущий момент способа:

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем плаванье

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?

Жил да был у меня роутер одной хорошей фирмы на букву «Dead». Ну, это с ним, собственно, и случилось.
Посмотрел я на цены новых, на кучу компьютерного хлама в углу, на список подключений на домашнем компе… И понял, что не нужен мне роутер. Соберу свой, с нормальной маршрутизацией, DNS, WINS, i2p, блекджеком и так далее.

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

Рассмотрим управляемые свичи. Классический пример с ними — опрашивать состояние каждого порта, а также объём и состав прошедшего трафика. Делается это средствами самого zabbix, как именно смотрите здесь. Только мне мониторинг этих параметров не нужен. Гораздо интереснее отслеживать, какие устройства подключены к коммутатору. Он ведь хранит и обновляет таблицу привязки mac адресов к портам, надо её только достать и красиво оформить. Однажды я нашёл на хабре, как получить эту таблицу. Двумя snmp запросами извлекаем списки портов и mac адресов, а потом по суффиксам значений OID-ов устанавливаем соответствие. Подробности смотрите в исходном посте, а здесь рассказывается, как улучшить такой мониторинг.

Давно хотел написать этот пост с подборкой полезных ссылок, так как очень часто спрашивают подобное (думаю, у многих, кто в этой (да и в других) сфере). Ссылки разбиты на категории.

Спасибо Хабру, много полезного тут для себя нашел. Думаю, пора «отдавать долги».
Хочу описать алгоритм, который работает больше года на моем шлюзе для балансировки каналов (Гбит трафика, 8k клиентов, 2 провайдера, AS на 1k адресов, большинство клиентов за NAT). Возможно, кому-то пригодится. Во всяком случае, ничего похожего не встречал и когда специально искал — не нашел. Так что полностью мое детище.
Все, что попадалось на просторах Интернета, позволяло резервировать один из каналов. И исходящий регулировать — описаний много. А вот регулировать входящий трафик (т.е. обеспечить равномерную загрузку нескольких каналов) — не попадалось.
Конечно, указанный алгоритм нельзя считать универсальным, подойдет только в подходящих условиях.

Итак, исходные:
— Шлюз на Linux (Debian 6). Используется пакет quagga (бывший zebra).
— Два провайдера (пусть будут ТТК и РТК). Каждый дает канал определенной толщины, «лишнее» режет.
— AS на 1k адресов (пусть будет 1.1.144.0/22). AS0000.
— Большинство клиентов имеют серые адреса (пусть будет 192.168.0.0/16), «клиентские» сети 192.168.1-99.0/24, на шлюзе натятся.
— Небольшая часть клиентов имеют белые адреса в пространстве моей AS.

Задача:
Обеспечить равномерную загрузку каналов ТТК и РТК входящим трафиком для исключения перегрузки каналов.

На Хабре я недавно (чуть меньше месяца), до этого Хабр практически не читал. Пришёл, огляделся, походил по тематическим «хабам», почитал «Лучшее за всё время», просмотрел статьи отдельных, заинтересовавших меня персонажей и понял, что для того, чтобы получше понять, как живёт и чем дышит это замечательное сообщество, мне придётся Хабр распарсить и позадавать ему разные вопросы. К тому же, раз уж в своих статьях я писал в основном об автореферентности в разных её проявлениях, как не написать на Хабре статью о Хабре?

Посмотрю, интересно ли это всё кому-либо кроме меня. Если интересно, напишу ещё несколько постов, идей и материала для этого более чем достаточно.

Если я ничего не пропустил в интерфейсе сайта, единственные списки самых-самых, которые можно посмотреть — это общий рейтинг пользователей и список статей, т.н. «Лучшее за всё время». Оба списка отсортированы по рейтингу (пользователей и статей, соответственно). Между тем, существует ещё куча параметров, по которым было бы интересно всё отранжировать.

С практической точки зрения было бы удобно управлять Wi-Fi сетями, выдавая пароль каждому пользователю. Это облегчает задачу с доступом к вашей беспроводной сети. Используя так называемую WPA2 PSK авторизацию, чтобы предотвратить доступ случайному пользователю, нужно менять ключ, а также заново проходить процесс авторизации на каждом отдельном Wi-Fi устройстве. Кроме того, если вы имеете несколько точек доступа, ключ нужно менять на всех из них. А если Вам надо скрыть пароль от кого-нибудь, придется раздать всем сотрудникам новый.

Представим ситуацию — к вам в офис зашел кто-то посторонний (клиент, контрагент?), и нужно дать ему доступ в интернет. Вместо того, чтобы давать ему WPA2 — ключ, можно сделать для него отдельный аккаунт, который потом, после его ухода, можно удалить заблокировать. Это даст вам гибкость в управлении учетками, а пользователи будут очень довольны.

Мы сделаем удобную схему, применяемую в корпоративных сетях, но полностью из подручных средств с минимальными финансовыми и аппаратными вложениями. Ее одобрит служба безопасности и руководство.