Если ваша IT инфраструктура растёт слишком быстро, вы рано или поздно столкнётесь с выбором – линейно увеличивать людские ресурсы на её поддержку или начинать автоматизацию. До какого-то момента мы жили в первой парадигме, а потом начался долгий путь к Infrastructure-as-Code.

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

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


Осторожно, под катом 99 иллюстраций и схем и все важные.

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

К примеру, по итогам пентеста в одной компании мы пришли к выводу, что все доступные машины в домене были не ниже Windows10/Windows Server2016, и на них стояли все самые свежие патчи. Сеть регулярно сканировалась, машины хардились. Все пользователи сидели через токены и не знали свои «20-символьные пароли». Вроде все хорошо, но протокол IPv6 не был отключен. Схема захвата домена выглядела так:

mitm6 -> ntlmrelay -> атака через делегирование -> получен хеш пароля локального администратора -> получен хеш пароля администратора домена.

К сожалению, такие популярные сертификации, как OSCP, GPEN или CEH, не учат проведению тестирования на проникновение Active Directory.

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

Итак, для демонстрации используем ноутбук на Kali Linux 2019 и поднятые на нем виртуальные хосты на VMware. Представим, что главная цель пентеста — получить права администратора домена, а в качестве вводных данных у нас есть доступ в корпоративную сеть компании по ethernet. Чтобы начать тестировать домен, нам понадобится учетная запись.

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

Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.

Добрый день, %username%. Меня зовут Антон Резников, я работаю над проектом Облако Mail.Ru Сегодня я хочу рассказать о технологиях балансировки трафика, проиллюстрировав историей о развитии социальной сети. Все персонажи выдуманы, а совпадения почти случайны. Статья обзорная, составлена по следам доклада на Highload Junior 2017. Некоторые вещи могут показаться элементарными, но опыт проведения собеседований показывает, что это не совсем так. Кое-что будет спорным, не без этого.

Если интересно, добро пожаловать под кат.

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

Добро пожаловать под кат, если вам это интересно.

В конце прошлого месяца состоялся официальный релиз Google Ассистента на русском языке, так что самое время разобраться, как делать свои приложения (экшены) для Ассистента на стандартном технологическом стеке Google. В этой статье мы рассмотрим создание экшена в Actions on Google, разберём процесс извлечения сущностей и интентов из фраз в Dialogflow, узнаем, как писать обработчики извлеченной информации и работать с сетью в Cloud Functions for Firebase.


Рис. 1. Архитектура приложения для Ассистента.

Админ — это тот человек, без которого ничего в ИТ-компании не заработает. А со счастливым и продуктивным админом, дело будет двигаться лучше и быстрее, поэтому комфортная рабочая атмосфера — забота компании. О том, с помощью каких инструментов сделать команду продуктивной, был доклад Антона Турецкого (banuchka) на Highload++ 2017.

Антон любит инфраструктурные задачи и автоматизацию всего, что можно автоматизировать, поэтому его рассказ основан на примере настройки инфраструктуры в дата-центре и сопутствующих технологиях (Docker, Consul, Puppet...). Но аспекты, мешающие качественной работе и способы их решения максимально универсальны и подходят практически для любой исполнительной команды. Так что милости просим под кат за расшифровкой этого доклада.



Badoo с каждым годом растет, вот несколько чисел, которые это отражают: 350 млн сообщений в сутки, 364 млн зарегистрированных пользователей по всему миру, 300 тысяч новых пользователей в день. Но это далеко не самое главное, для человека, который в Badoo работает, главное — это в первую очередь образ мышления и команда. Badoo — это семья, это про людей и это круто!

Хочу начать с провокации, которую, возможно, кто-то не поддержит:

Админ — это главный человек в компании!

Думаю, вы со мной согласитесь: админ — это тот человек, без которого ничего в компании не заработает: оборудование приезжает к нему, систему ставит он, выделяет новое оборудование опять же он. Поэтому я и считаю, что он — главный.

Детектив в 1 части.
Эта история произошла в октябре.

Есть Ceph версии 0.94 (Hammer). 6 стораджей, 8 мониторов, по 6-8 osd на каждом сторадже, SSD диски объемом от 1 ТБ до 4 ТБ. Реплика — 2, минимум 1.

Как-то раз случилось такое: вечером прошел некий шторм по всему кластеру и самопроизвольно перезапустилось множество osd. В логах osd были видны стандартные для ceph ошибки вида no reply from osd.X. Немного slow requests и самопроизвольные рестарты, что для ceph не критическое событие и довольно частое. В общем, такое бывает. Но, к сожалению, не все перезапустившиеся osd смогли подняться. А именно пала героем osd.45 на storage6.

Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».

Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.

После того, как в комментариях к одной из статей на Хабре я сказал, что готов помочь пострадавшим с настройкой схемы обхода, ко мне обратились несколько человек с просьбой о такой помощи. Когда у них всё заработало, один из них порекомендовал описать методику в статье. Поразмыслив, решил нарушить свое молчание на сайте и попробовать в кои-то веки написать что-то промежуточное между проектом и постом в Facebook, т.е. хабрапост. Результат — перед вами.

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

Плюс в питоне есть немало регулярных плюшек. Например, re.split может добавлять тот кусок текста, по которому был разрез, в список частей. А в re.sub можно вместо шаблона для замены передать функцию. Это — реальные вещи, которые прямо очень нужны, но никто про это не пишет.
Так и родился этот достаточно многобуквенный материал с подробностями, тонкостями, картинками и задачами.

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

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

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

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

С версии 0.8.46 в nginx появились опции, позволяющие легко и просто настроить прозрачное кэширование для анонимных пользователей.

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

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

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

Очень часто администраторы выполняют настройку системы просто настройкой базовых вещей — ip,dns,hostname, поставить софт, а все остальное уже настройки приложений. В большинстве случаев так оно и есть, поскольку в linux’е очень разумные умолчания и, в большинстве случаев, этих умолчаний хватает и все живут счастливо. Среди совсем начинающих ходят легенды о неких sysctl’ях, а те, кто поопытнее видели и даже чего-то правили.

Но приходит момент, когда админ в своих походах по системе встречает этого зверя — sysctl. Вероятнее всего он встречает кого-то из семейства net.ipv4 или vm, даже вероятнее всего net.ipv4.ip_forward, если поход за роутером или vm.swappinness, если он обеспокоен подросшим swap’ом своего пингвина. Первый зверь разрешает пингвину принимать пакеты одним крылом и отдавать другим (разрешает маршрутизацию), а второй помогает справиться с использованием swap’а в спокойной системе и регулировать его использование — в нагруженной.

Елена Соловьева, менеджер проектов в компании Лаборатория Касперского, специально для блога Нетологии поделилась советами о том, как вести деловую переписку с иностранными коллегами и партнерами на английском языке. Статья участвует в конкурсе.

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

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