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

Как бизнесу и ИТ правильно интегрировать безопасность в процесс разработки, какие инструменты для этого лучше использовать, как это все ложится на реальную практику внедрения. Делимся подходами Ростелеком, М.Видео-Эльдорадо, DD Planet, AGIMA.

Ярослав Александров, руководитель отдела разработки Solar appScreener в Ростелеком, — о том, как встроить SAST в разработку

С ростом компании и увеличением числа разработчиков проверять продукт на уязвимости «вручную» становится все сложнее. Приходится использовать SAST — средства статического тестирования защищенности приложений (Static Application Security Testing). В Solar appScreener информационная безопасность строится на базе внутреннего продукта. Продукт анализирует исходные коды. На сегодня поддерживается 26 языков программирования, исходники которых могут быть проанализированы уязвимость, и поддерживает все популярные форматы и системы управления проектами.

Как выбрать SAST?

Даже простую уязвимость невозможно отыскать при помощи примитивных алгоритмов. Сегодня на рынке представлена масса SAST-решений, как платных, так и бесплатных. Самые популярные из них — AppScan от IBM Security, Synopsys, Veracode, Application Inspector, Micro Focus, Appercut, Checkmarks.

От выбора инструмента зависит эффективность процесса разработки. Главные преимущества платных решений:

Ник Йи торгует секретами.

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

И он продаёт эти знания разработчикам. Некоторые из них изменяют свои игры на основании этих знаний, чтобы вы покупали их, играли в них, и рассказывали о них другим.

Йи основал в 2015 году компанию Quantic Foundry, занимающуюся продажей его данных в такие игровые компании, как Tencent (владелица League of Legends), PopCap (студия, разработавшая Plants vs Zombies) и Wizards of the Coast (издатель Magic: The Gathering).

«В прошлом отрасль разработки игр не могла узнать истинных данных», — рассказывает Йи. «Когда люди играли на консолях без Интернета, разработчики не получали обратной связи. Они не могли составить чёткой картины того, как пользователи играют в их игры».

Теперь, по словам разработчиков, у них есть большие объёмы данных, как от телеметрии продуктов (внутриигрового поведения игроков), так и из внешних источников (например из опросов Йи). И некоторые люди начинают опасаться, что у них может быть слишком много информации.

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

В одном из предыдущих постов про DevOps мы обещали рассказать про технологическую составляющую нашего CI/CD-конвейера.

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

Раз уж на Хабре были опубликованы отчеты об экскурсиях в Самарский ЦОД Мегафона, позвольте поделиться и мне сегодняшней (вчерашней, от 31 мая) экскурсией в ЦОД Мегафона в Подмосковье в городе Дмитров.



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

У нас в компании для организации и управления доступами для Linux-серверов
используется такой сервис как FreeIPA. FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL. В новой версии появились уровни доменов и был переработан процесс настройки репликации. Так как инструкций вменяемого вида в рунете найти не удалось, я решил написать собственную.

 

Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В репозитории приложения? В системе деплоя (Jenkins, Teamcity, etc)? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов?
Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры.
Начнём исследование вопроса с определения требований к хранению секретов.

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

Сергей Носков (Albibek) — руководитель группы информационной безопасности платформы из Авито, знает ответ на эти вопросы и поделится с нами. В Авито два года активно используют HashiCorp Vault, за это время набили шишки, и прокачали опыт до уровня «Мастер».

В статье всесторонне поговорим про Vault: что это такое, где и как используется в компании, как в Авито управляют секретами с помощью HashiCorp Vault, как используют Puppet и Kubernetes, варианты использования с Puppet и другими SCM, какие возникают проблемы, что болит у безопасников и разработчиков, и, конечно, поделимся идеями, как все исправить.

Внезапно, без предварительного анонса, на 8.8.8.8 заработал DNS over TLS. Ранее Google анонсировал только поддержку DNS over HTTPS.

Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.

Зачем это нужно

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

C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.

А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.

Как это работает

На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.

К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.

Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).

Настройка на macOS

Разберем настройку DNS over TLS на последней версии macOS, на примере резолвера knot

Здравствуйте! Я почти 10 лет работаю в сфере ИТ и ИБ, всегда интересовался практической безопасностью, в настоящее время работаю пентестером. За все время работы я постоянно сталкивался с типовыми ошибками в настройках и дизайне инфраструктуры. Ошибки эти чаще всего досадные, легко устранимые, однако быстро превращают сеть в полигон для взлома. Порой кажется, что где-то специально учат так настраивать, насколько часто они встречались. Это и побудило меня написать данную статью, собрав все самое основное, что может улучшить защищенность.

В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.

Инструкций-рецептов намеренно не прикладываю, так как многое ищется очень легко по ключевым словам.

Совсем недавно я уже писал про доработку домофона протоколом MQTT.

В комментариях Владимир instalator написал:

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

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

Привет, Хабр! Меня зовут Сергей Прутских, я руковожу направлением мониторинга компании «Сбербанк-Технологии». Основная задача нашей организации — разработка и тестирование программных продуктов для Сбербанка. Для этого в компании сосредоточена крупная ИТ-инфраструктура — 15 тысяч серверов разделены примерно на 1500 тестовых сред, которые относятся к более чем 500 автоматизированным системам. Всего с ними работает около 10 тысяч специалистов.

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

Картинка: источник

Привет, Хабр! Меня зовут Илья Аблеев, я работаю в отделе мониторинга Badoo.

Можно долго холиварить на тему того, какая система мониторинга круче. Основным инструментом для реакции на проблемы в Badoo является Zabbix, и мы неоднократно делились опытом его кастомизации.

«Из коробки» узнавать о новых проблемах можно либо через веб-интерфейс, либо по почте/SMS. Это хорошо работает и до определённого момента нас устраивали эти способы.

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

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

Кому подойдёт данное решение:

• дежурным администраторам, которые не только круглосуточно смотрят в монитор, но и занимаются решением других задач;
• всем остальным администраторам, которым не нравится просматривать простыню PROBLEM и OK`ов в почте или SMS, но которые хотят своевременно узнавать о критичных проблемах.

Придётся потратить время на установку, но, думаю, если вы используете Zabbix и уже использовали кастомные скрипты, для вас это не составит труда.

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

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

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

Сегодня мы с вами цинично поговорим о старой-доброй задаче – защите сотрудников и их рабочих станций при доступе к Интернет-ресурсам. В статье мы рассмотрим распространённые мифы, современные угрозы и типовые требования организаций по защите веб-трафика.

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

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

Для сервера, на котором будет установлена связка Puppet + Foreman, будет использоваться виртуальная машина (1 CPU, 2 Gb RAM, 20Gb HDD), в качестве клиентов будут физические ПК на которых установлена Ubuntu. Конфигурация моего виртуального сервера с указанными выше характеристиками позволяет без проблем обслуживать 500 клиентов (можно и больше).

Установка Puppet довольно простая (все последующие команды выполняются от root):


Этими командами мы скачиваем deb пакет с сайта разработчиков puppet и устанавливаем его. Данный пакет puppetlabs-release-trusty.deb при установке создает файл /etc/apt/sources.list.d/puppetlabs.list в котором прописаны репозитории puppet, а также импортируется gpg ключ которым подписан репозиторий puppet. Сам puppetmaster мы не устанавливаем, он будет установлен автоматически при установке Foreman.

На этом установка Puppet закончена, приступим к установке веб-интерфейса Foreman:

Модели машинного обучения нужно уметь не только разрабатывать, но и «продавать» заказчику. Если у него не будет понимания, почему предлагается именно такое решение, то всё закончится статьёй в журнале и выступлением на конференции. Директор компании Loginom Алексей Арустамов обращает внимание на ключевые моменты, которые важно отразить в описании модели. Это выступление прошло пару недель назад на конференции Яндекса из серии «Data & Science».

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

В этом году компанию Positive Technologies назвали «визионером» в рейтинге Gartner Magic Quadrant for Web Application Firewalls. Это вызвало ряд вопросов о том, за какие достижения мы туда попали и что такое WAF вообще. Вопросы вполне правомерные, ведь Gartner выпускает своё исследование WAF лишь с прошлого года (для примера: «квадранты» по SIEM стали выходить на пять лет раньше, в 2009 году). Кроме того, некоторые до сих пор путаются с терминологией, не отличая «экран для защиты веб-приложений» (WAF) от обычного «межсетевого экрана» (network firewall) или «системы предотвращения вторжений» (IPS).

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

1. Основные сведения

В данной инструкции описывается процесс интеграции LinOTP и FreeRadius на машинах под управлением CentOS а также настройка аутентификации пользователей SSH по ОТР, сгенерированному с помощью программного обеспечения Google Authenticator (или любого, использующий аналогичный алгоритм).

В век облачных технологий, когда у каждого пользователя есть собственное облако для хранения фотографий, а компании арендуют сервера для облачных вычислений, встает вопрос о конфиденциальности хранимой информации. И если пользователи для защиты хранимых данных могут обойтись доверием к облаку или использованием крипто контейнеров, то у компаний дела обстоят хуже. Так как в облака переносится не только хранилище данных, но и сами вычисления.
Особенно страдает защита виртуальных машин, так как в случае компрометации хоста, не составит труда получить доступ к ВМ. До недавнего времени ни один из гипервизоров будь то VMware, Xen, Hyper-V не предоставляли каких-либо значимых технологий по защите ВМ.