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



Насколько безопасна ваша сеть? Используете ли вы файрвол для защиты вашей сетевой инфраструктуры?

Ранее я писал об управляемых облачных файрволах и получил предложение написать о бесплатных файрволах или файрволах с открытым исходным кодом.

Вот, пожалуйста!

Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

Полагаем, что следующая остановка на этом пути — книга о Prometheus, поэтому сегодня предлагаем вашему вниманию перевод небольшой статьи Бьёрна Венцеля о тесном взаимодействии Prometheus и Kubernetes. Не забудьте пожалуйста поучаствовать в опросе.

— Последний вопрос нашей повестки. – зашуршала бумажками Светлана Владимировна. – Оценка удовлетворенности персонала. Татьяна, вам слово.

— Добрый день, коллеги. – поднялась со стула молодая, симпатичная девушка, новый HR-директор. – Как вы знаете, мы провели оценку удовлетворенности персонала, и результаты, к сожалению, неутешительные.

Татьяна выдержала театральную паузу, оглядывая всех присутствующих менеджеров – и топ, и не топ.

— Удовлетворенность стала ниже, по сравнению с прошлым годом. – видя, что реакции нет, сконфуженно продолжила Татьяна. – С этим нужно что-то делать. Я подготовила несколько предложений. Светлана Владимировна, можно озвучить?

— Начинается… — раздался тихий шепот с дальнего конца стола.

— Что, простите? – подняла бровь директор. – Я что, с разнорабочими разговариваю? Или с руководителями, которые радеют за благо предприятия? Марина, это вы сейчас сказали?

— Нет, не я. – возмутилась Марина, директор по качеству. – Вон, умник наш. Господин ИТ-директор. Сергей, отвлекись от телефона, что ты там все время делаешь?

Linux in RAM: debirf way

Do you want to have absolute disk speed nowadays, don’t you? Let's revise how it could be done with versioning and automation in 2018.

От модератора: нам в Песочницу пришла статья на английском языке. Мы её прочитали и и в качестве пятничного эксперимента решили опубликовать. Не судите строго, всем peace and happy Friday! Let's come together! Короче, фром зе боттом оф ауа хартс.

Каждый раз, когда появляется статья про какой-нибудь новый мессенджер, большинство пользователей Хабра в комментариях интересуются — централизованный или децентрализованный IM?

Если нет — то тогда — «все, ребята, расходимся».

Многие в качестве примера также упоминают децентрализованность Skype, подразумевая то, каким он был до 2011 года.

Давайте тогда в качестве подводки и вступления к основной идее статьи рассмотрим, каким был Skype в его золотые годы, до покупки Microsoft.

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

9 лет назад мы начали развивать облачное направление. Потом выделились в такой автономный чукотский округ, что-то вроде компании в компании.

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

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

Эта история началась 1 октября 2012 года, когда мне позвонил институтский товарищ Игорь и попросил помочь с горящим проектом. Они пытались сделать терминал сбора данных для технологического применения в РЖД. Такая штука для обходчиков путей и вагонов, чтобы они могли фиксировать все неполадки онлайн.

Так сложилось, что мне пришлось почти весь прошедший год провести на даче. Вроде бы почти в черте города, но все-таки коммуникаций кроме электричества никаких. Ни газа, ни воды, ни, что самое главное, Интернета! Но если газ можно купить в баллонах, воду провести от скважины/колодца, то как быть с интернетом? Постоянно на мобильном трафике не посидишь, тем более если работаешь на фрилансе, да и фильмы по вечерам охота в хорошем качестве посмотреть? В сентябре прошлого года я принялся искать решение.

Мы долго думали, чем интересным можно поделиться с коллегами в День системного администратора. Решили сделать подборку любимой музыки сисадминов Selectel — в нашей компании работают 44 специалиста этой замечательной профессии. Пока собирали статистику, послушали кучу хорошей музыки и выяснили про самих себя много интересного. Поэтому кроме десятки лучших композиций для работы от сисадминов Selectel расскажем самые любопытные музыкальные факты о нас в честь профессионального праздника.

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

Представили? Получилось? Вы успешно прошли тест на самое богатое воображение!

На самом деле, конечно же, всё не так. Чаще всего руководству не до наших ИТ-шных штучек. Поэтому приходится убеждать. Но как?

Статьи цикла:

1. Обзор материалов и литературы по NAS. По предложениям пользователей ссылки на материалы будут сведены в отдельную статью.
2. Выбор железа. Описан один из вариантов выбора железа и дан краткий обзор рынка домашних и офисных NAS систем.
3. Установка ОС, на которой будет строиться NAS. В отдельной статье описано дополнение, позволяющее отказаться ото всех файловых систем, кроме ZFS.
4. Проектирование поддерживающей инфраструктуры, которая будет лежать в основе всех сервисов NAS.
5. Реализация поддерживающей инфраструктуры.
6. Механизм аварийной удалённой разблокировки. Требуется для того, чтобы разблокировать систему, не имея к ней физического доступа.
7. Повышение защищённости NAS. Исправление ошибок, допущенных в предыдущих статьях и описание Hardening процесса.
8. Система контроля версий на базе Git. Установка Gitlab в контейнере.
9. Система резервного копирования. От регламента до установки ПО, где в качестве примера используется UrBackup.
10. Персональное облако. Обеспечивает хранение персональных файлов пользователя, обмен файлами между пользователями, а также интеграцию различных сервисов между собой.
11. Сквозная аутентификация контейнеров.
12. Управление файлами.
13. Библиотека.
14. Мультимедийная система 1: музыка.
15. Мультимедийная система 2: медиа сервер.
16. Фронтенд. Интерфейс, позволяющий быстро обращаться к сервисам.
17. Заметки про управление контейнерами.

Такие офисы обычно ужасны, но есть варианты

Об авторе: Джейсон Фрайд — основатель и исполнительный директор Basecamp



На прошлой неделе DHH [создатель Ruby on Rails, основатель и технический директор Basecamp — прим. пер.] разнёс в пух и прах открытые офисы. Он прав. Но погодите, ведь мы сами работаем в офисе такого типа. И мы проделали достойную работу, чтобы улучшить ситуацию. Может, есть смысл поделиться опытом.

Уточнение от переводчика: пост, перевод которого вы видите перед собой, был написан 23 февраля 2017 года, по мотивам исходного поста Moby/Docker в продакшене. История провала, перевод которого (за авторством olegchir) здесь, на Хабре, вызвал живые обсуждения. Просьба читать, делая поправку на дату написания — оригинальный текст написан почти год назад!

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

Предыдущая статья Moby/Docker в продакшене. История провала оказалась хитом. Сегодня, после долгих обсуждений, сотен отзывов, тысяч комментариев, встреч с различными людьми, с крупными игроками, ещё большего количества экспериментов и большего числа сбоев, пришло время опубликовать обновления картины.

Мы рассмотрим уроки, извлеченные из всех последних общений и статей, но, для начала — уточнение, напоминание и немного контекста.

Отказ от ответственности: предполагаемая аудитория

Большое количество комментарием показло, что мир делится на людей всего 10 типов:

1) Любители

Обычно поддерживают тестовые или хобби-проекты, где нет реальных пользоваталей. Могут полагать, что использование бета-версии Ubuntu — нормально, и называют все “стабильное” устаревшим.

Нельзя его винить: на его-то машине код работает.

Обновление: у этой статьи появилось продолжение, переведённое @achekalin. В каком порядке читать — на ваше усмотрение: в этой статье можно получить удовольствие от обширной попоболи автора, а в продолжении — от сделанных им выводов.

Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, Gryphon88 задал резонный вопрос: как отличить cutting-edge и хайп? Нижеследующая статья наполнена сочной незамутненной истерикой, которую так приятно читать с утра, попивая чашечку кофе. Минус в том, что она написана в ноябре 2016, но нетленка не стареет. Если после прочтения захочется добавки, есть комментарии на Hacker News. А у тебя, юзернейм, такой же ад? Пиши в комментариях. Итак, начнем.

В первый раз я встретился с Докером в начале 2015. Мы экспериментировали с ним, чтобы понять, для чего бы его можно употребить. В то время нельзя было запустить контейнер в фоне, не было команд чтобы посмотреть что запущено, зайти под дебагом или SSH внутрь контейнера. Эксперимент оказался быстрым, Докер был признан бесполезным и более похожим на альфу или прототип, чем на релиз.

Промотаем нашу историю до 2016. Новая работа, новая компания, и хайп вокруг докера поднялся безумный. Разработчики уже выкатили докер в продакшен, так что сбежать с него не удастся. Хорошая новость в том, что команда run наконец-то заработала, мы можем запускать и останавливать контейнеры. Оно шевелится!

У нас 12 докеризованных приложений, бегающих на проде прямо в момент написания этой заметки, размазанные на 31 хост на AWS (по одному приложению на хост, дальше объясню — почему).

Эта заметка рассказывает, как мы путешествовали вместе с Докером — путешествие полное опасностей и неожиданных поворотов.

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

Как всегда без имен и названий, и так как я дополнительно связан подписью о неразглашении, еще и с немного видоизменённой историей (и опуская некоторые подробности, на публикацию которых я не получил разрешения).
Ниже следует реальная история проникновения на компьютер сотрудника… ну скажем некоторого частного банка. События, о которых повествует ваш покорный слуга, происходили в некоторой европейской стране не так что бы давно, еще до DSGVO (GDPR, RGPD) но в процессе становления оного, в преддверии так сказать.

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

Опустим слова, которые пришлось выслушать от краснеющих на глазах IT-безопасников, но общий лирический посыл таков — я бросаюсь голословными обвинениями, а у них — всё на замке, а ключ у CSO в кармане под сердцем.

Попытки объяснить, что система безопасности выстроенная вокруг firewall+proxy+webwasher like content-filter & antivirus, без какой-либо худо-бедно настроенной гибридной IDS (HIDS+APIDS), хонепотов и т.д. и т.п., во первых по определению не является безопасной, во вторых я же как бы показал уже несколько мест, где оно как минимум не комильфо. Попытки вернуться к конструктивному диалогу (собственно обратно к разбору) разбивались о трехэтажную стену обиды, выстроенную всем отделом.

Свернув совещание и отпустив сотрудников, CSO вкупе с двумя важными начальниками попытался всё-таки честно выяснить у меня где собака порылась и понять как дальше жить как собственно и что конкретно, по моему скромному мнению, нужно делать.

Kubernetes aka k8s — это система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнерными приложениями. В этой статье я расскажу как настроить кластер Kubernetes и развернуть на нем кластер Elasticsearch в AWS. Эти настройки также работают на GCE и Azure.

Предисловие

На моем сервере крутится 2 отдельных домена. До истории с блокировками Роскомнадзора мы собирали трафик около 2000 посещений в сутки, а почтовый сервер отправлял в сутки около 200 писем на все популярные почтовые сервисы, в т.ч. Гугл и Яндекс. Все было здорово. Но как говорится в известном ролике: «Все было так хорошо, пока не пришел Навальный Роскомнадзор!

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

MX сервер google выбрасывает мою почту с примерно следующим сообщением: „Твое сообщение похоже на нежелательное, давай до свидания...“

Привет! Все мы знаем и любим такие продукты для vulnerability assessment процессов как Nessus, Qualys, Max Patrol и всякие прочие OpenVAS. Одной из основных задач, которые они решают, является обеспечение контроля версионных уязвимостей.

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

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

Что развернуто в большинстве продуктовых систем? Конечно же мониторинг. И довольно часто это Zabbix. Так давайте к нему и прикрутимся!