Спойлер: Open vSwitch версий меньше 1.11 уязвим перед атакой вида «flow flood», позволяющей злоумышленнику прервать работу сети отправкой относительно небольшого потока пакетов в адрес любой виртуальной машины. Версии 1.11 и старше проблеме не подвержены. Большинство серверов с OVS до сих пор используют OVS 1.4 или 1.9 (LTS-версии). Администраторам таких систем настоятельно рекомендуется обновить систему на более новую версию OVS.

Лирика: Прошло уже больше полутора лет с момента, когда я впервые сумел воспроизвести эту проблему. В рассылке OVS на жалобу сказали, что «в следующих версиях исправят» — и исправили, пол-года спустя. Однако, это исправление не коснулось LTS-версии, а значит, большинство систем, использующих OVS, всё так же уязвимо. Я пытался несколько раз связаться с Citrix'ом (т.к. он использует самую уязвимую версию OVS в составе Xen Server — в тот момент это был мой основной продукт для эксплуатации), но никакой внятной реакции не последовало. Сейчас у администраторов есть возможность устранить проблему малой кровью, так что я решил опубликовать описание очень простой в воспроизведении и крайне запутанной и в диагностике проблемы — проблеме «flow congestion», она же «flow flood attack», она же «странная неведомая фигня, из-за которой всё работает странно». Раньше в комментариях и в рассылках про эту проблему я уже несколько раз писал, но у меня ни разу не хватало пороху полностью описать проблему на русском языке так, чтобы суть проблемы была понятна обычному айтишнику. Исправляюсь.

Следующая строчка hping3 -i u10 virtual.machine.i.p нарушает работоспособность хоста виртуализации, где запущена виртуальная машина. И не только хоста виртуализации — любую систему, работающую на Open vSwitch версий меньше 1.11. Я делаю особый упор на версиях 1.4.3 и 1.9, потому что они являются LTS-версиями и используются чаще всего.

Более суровая версия того же вызова, на этот раз с нарушением правил пользования сетью: hping3 --flood --rand-source virtual.machine.i.p. Соотношение исходящего трафика (~10-60Мбит/с) и (потенциальной) пропускной способности интерфейса жертвы (2x10G, соотношение по доступной полосе атакующий/атакуемый порядка 1:300-1:1000) позволяет говорить именно про уязвимость, а не про традиционную DoS атаку флудом, забивающем каналы аплинков до нерабочего состояния.

Симптомы со стороны хоста виртуализации: неожиданные задержки при открытии соединений, рост потребления CPU процессом ovs-vswitchd до 100%, потеря пакетов для новых или малоактивных сессий. Если используется OVS 1.4, то процесс ovs-vswitchd не только съедает свои 100% CPU, но и начинает подъедать память и делает это со скоростью до 20 мегабайт в минуту, пока к нему не приходит добрый дедушка OOM и не проводит воспитательную беседу.

Сегодня я хочу рассказать про то, как мы сделали так, чтобы в Яндекс.Почте не нужно было включать отображение картинок в каждом письме, как это приходится делать много где, и вообще — как мы обеспечиваем защиту при показе текста письма. Что не такое очевидное дело, как может показаться.

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



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

Примерно неделю назад Vasyutka опубликовал пост про распознавание номеров и обещал, что мы выложим софт, который можно будет опробовать. Мы немножко схитрили, не рассказав все подробнее. Ну, а то бы никакой интриги не было! Ядро алгоритма распознавания мы сделали с полгода назад, но тот проект, для которого оно было сделано, не двинулся. Он остановился где-то на альфа-версии. Подумав, и посовещавшись с заказчиком, мы решили, что это нехорошо, когда такой алгоритм пылится на полке и не приносит пользу обществу. С другой стороны выкладывать все исходники распознающей части не хотелось. Тогда и родилась идея, о которой пойдёт речь в этой статье.

Решили мы, собственно, сделать открытый сервер, который бы распознавал номера, приходящие http-запросами. Так как вся идея некоммерческая, то сервер, конечно, слабенький, но на то, чтобы народ игрался, надеюсь, его хватит.
А вот тут крутой поворот сюжета. Пост этот не про протокол обращения к серверу. Об этом будет следующий пост. Этот пост о программе, которую мы начали делать как пример работы с сервером, но которая вылилась в интересную на наш взгляд концепцию. В статье будет рассказано про Android-приложение, которым можно сфотографировать номер автомобиля… И обругать владельца бранным словом! Ну, или посмотреть статистику того, сколько раз сего автомобилиста обругали.
Те, кому невтерпёж, смогут расковырять работу с сервером из исходников в конце статьи. Остальных подержим пару дней в напряжении, а потом выложим законченный мануал.

Когда объявляется крупный онлайн тендер, иногда случается так, что одна заявка приходит довольно быстро, а затем площадка с тендером ложится под крепкой DDoS атакой. Атака странным образом заканчивается в момент окончания тендера. Поскольку одна заявка поступила, именно она и выигрывает. С такой проблемой (как и с обычными DDoS атаками от недоброжелателей и шантажистов) сталкиваются многие наши корпоративные клиенты.

Теперь мы обеспечиваем защиту как сервис. Делается это на двух уровнях: установкой железа Radware DefensePro у клиента и при необходимости переключением трафика на наш центр очистки.



Максимальная мощность атаки — 80 Гб/с (на уровень приложений, более мощные тоже фильтруются, но уже без гарантий по отсутствию потерь легитимного трафика), планируем по мере необходимости расширять до 160. Время от начала до отражения атаки на стороне клиента — 18 секунд максимум, на стороне центра очистки данных — до 40 секунд с учётом времени переключения трафика. При переключении потерь трафика не происходит.

Поскольку системник в себе несет всего 256 Гб под систему и софт, бОльшую часть рабочих файлов, библиотеки, архивы и т.п. храню на нЕком файл-сервере под управлением XP который по гигабитному Ethernet подключен к рабочему компу. СтоИт сей девайс в подвале, шумом не напрягает ))) А так-же по Wi-Fi расшарены папки с музыкой и кино с этой файло-свалки для нубуков, планшетов, смартфонов.

Задался вопросом как все эти сетевые диски автоматом монтировать в МАК-ОСь? Начитался интернетов и написал скриптик, оформив его в стандартную программу и заснув ее в автозагрузку.



Итак, что в нем используется:
Поскольку комп грузится на столько быстро, что DHCP роутера не успевает присвоить IP-адрес МАКу выдавая ошибку, что команде не удалось подключить внешний диск. Посему пришлось поставить десяти-секундную задержку перед выполнением команд монтирования сетевых дисков:

set pause to (10)
delay pause

Следующим этапом создаем тома в МАКе и монтируем сетвые диски.
Уточнение: МАК и файл-сервер висят в рабочей группе WORKGROUP, а сервер имеет сетевое имя serverX32 (хотя можно использовать и IP-адрес сервера):

do shell script ("mkdir /Volumes/My_DOCs") <!--  создание директории сетевого диска My_DOCs в МАКе -->
do shell script ("mount -t smbfs //login:password@serverx32/My_DOCs /Volumes/My_DOCs") <!-- Подключение по SMB-протоколу Виндового диска с именем My_DOCs с логином и паролем, для доступа на чтение/запись, если заход на данный диск происходит без логина/пароля диск имеет статус только чтение (для смартфонов и планшетов). -->
do shell script ("mkdir /Volumes/Video") <!-- создание директории второго сетевого диска в МАКе -->
do shell script ("mount -t smbfs //login:password@serverx32/Video /Volumes/Video")
и т.д. сколько нужно подключить дисков…

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
• >>>PIM Dense Mode
• >>>Pim Sparse Mode
• >>>SPT Switchover — переключение RPT-SPT
• >>>DR, Assert, Forwarder
• >>>Автоматический выбор RP
• >>>SSM
• >>>BIDIR PIM
• Мультикаст на канальном уровне
• >>>IGMP-Snooping
• >>>MVR

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

19 мая 2014 года состоится полный переход сети Jabber на полное шифрование. Шифроваться будет как соединение от клиента к серверу (C2S), так и между серверами (S2S). Об этом договорились представители крупнейших джаббер-серверов и участники XSF – XMPP Standards Foundation. Теперь использование Jabber будет на 99% безопасным для конечного пользователя

Понимая современные проблемы безопасности и приватности, сеть Jabber переключается на полностью защищённый режим работы. Договорённость зафиксирована в Манифесте о безопасности XMPP-протокола, расположенном на Github:
«Мир меняется, интернет меняется. И с каждым месяцем, годом люди все больше и больше задумываются о приватности информации, передаваемой ими в сеть. Никто не хочет, чтобы его переписка с другом\любимым\коллегой\работодателем была прочтена кем-либо другим.
Протокол XMPP поддерживает шифрование by design, как на уровне большинства клиентов так и на уровне практически всех реализаций сервера, но далеко не все пользователи осведомлены об этом, и далеко не все администраторы корректно сконфигурировали программное обеспечение сервера. Данный манифест фактически призван формально укрепить шифрование в сети XMPP, объединив операторов серверов, которые хотят обеспечить приватность и безопасность для своих пользователей. Так же он подразумевает информирование пользователей о шифровании данных, о настройке их программного обеспечения».

	Сеть Jabber – это множество серверов в интернете, работающих по протоколу XMPP и поддерживающих межсерверное общение между собой. Любой пользователь одного сервера может написать пользователю на любом сервере.
	Протокол XMPP – открытый свободный протокол для передачи данных (сообщения, звук, видео и прочие), который может использоваться как в публичной сети (Jabber), так и в локальной сети (интранет, локальные чаты предприятий, провайдеров и т.д), а также в проприетарных сервисах (WhatsApp, Facebook, Одноклассники)

В субботу, 22 марта 2014 — пройдёт третий тестовый день. На один день многие сервера перейдут на полное шифрование, а связь с серверами, которые не поддерживают шифрование, будет отключена. В частности, будет потеряна связь с Gmail, который не поддерживает межсерверное шифрование. Это предпоследний шанс проверить готовность джаббер-серверов (перед окончательным переходом будет ещё один), а в русскоговорящей среде об этом никто и в ус не дует.
Сколько таких серверов? Как подготовиться к переходу на полное шифрование юзеру, а как — админу? Мне нужно многое вам рассказать. Под катом ответы на эти вопросы и следствия.

Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).

Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.

Оригинал

Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.

IBM Redbook «Introduction to SAN and System Networking»

Начало

По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.

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


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

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

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

Сервера, размещенные в сети администрируемой мной AS, часто подвергаются различным DDOS атакам. Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом. С каждым месяцем количество, сложность и мощность атак возрастает. Атаки в 300-400Мб/с выросли до 70-80Гб/с. В этой ситуации не все атаки могут быть отражены тюнингом серверов, а крупные атаки могут помешать работе и всей площадки в целом. Бороться с такими атаками необходимо силами всей команды хостинга. Сетевые администраторы также должны иметь средства борьбы с такими атаками на сетевом уровне. О таких средствах и пойдет речь под катом.

Здравствуйте, уважаемые читатели!

Картинка, кратко и аллегорично передающая смысл описанного в посте скрипта:


У меня есть несколько сайтов, на которых в какой-то момент начал появляться вредоносный код, выглядящий как отдельные php-файлы либо дополнительные строки с длинными eval() в существующих файлах.

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

Тогда я задумался, как бы мне так оперативно узнавать, куда в очередной раз будет внедрен код, чтобы можно было его тут же прибить?

В первом своем посте на данном ресурсе хотел бы описать простейший пример создания информера, с помощью колоссально удобной утилиты Automator, идущей в комплекте с Mac Os X.

Буквально на днях, при радикальном снижении уличной температуры в Москве у меня внезапно появилась задача: визуально отслеживать температуру в серверном помещении (а точнее в стойке), с определенным интервалом, т.к. кондиционер, обслуживающий помещение, отказался работать при T < -15 ºC.

Citrix Xen Server при том что основан на дистрибутиве Linux в процессе установки не позволяет управлять размерами разделов и конфигурацией жестких дисков под устанавливаемую систему. По умолчанию при установке он спрашивает только диск на который требуется установка с автоматической разметкой дискового пространства под свои нужды. В процессе установки на выбранном диске создается 3 primary раздела. Два по 4Гб и один на все оставшееся место. (Кстати, может кто подскажет, для чего нужен второй раздел на 4Гб? Предполагаю, что на случай обновлений, восстановлений системы там лежит копия первого раздела с установленной системой, но точной информации не нашел.)

Столкнувшись с необходимостью поднять Xen Server на трех дисках задумался об обеспечении хоть какой то сохранности данных. Итак схема итогового массива примет следующий вид:

Далее как это реализуется.

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

1. Схема

Имеем:

• Frontend — NGINX проксирующий сервер для принятия и распределения нагрузки (IP — 1.2.3.4 — внешний, IP — 192.168.5.10 — внутренний DMZ) по хорошему он тоже должен стоять за firewall-ом, но тут схема для простоты понимания.
• Два сервера с поднятыми ownCloud
• cloud-1 IP — 192.168.1.11
• cloud-2 IP — 192.168.1.12
• Хранилище файлов NFS-storage IP — 192.168.1.20 для размещения данных пользователей с доступом по NFS.

Автоматический подсчет ссылок (Automatic Reference Counting, ARC) для языка Objective-C был представлен компанией Apple еще в 2011 году для iOS 4.0 и выше, Mac OS X 10.6 и выше, с использованием xCode 4.2 и выше. И, хотя всё больше библиотек, фреймворков и проектов сегодня используют ARC, до сих пор среди программистов встречается либо неприятие этой технологии, либо eё неполное понимание. Опытные программисты, привыкшие к retain/release, иногда считают, что они лучше и эффективней справяться с подсчетом ссылок, чем это за них сделает компилятор, а новички, начищающие сразу использовать ARC, полагают, что им не надо вообще думать об управлении памятью, и всё сделается магическим образом само.

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

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