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

Основная идея проекта — формализация взаимодействия между внутренней ИБ и внешними исследователями, давая четкое указание как и куда направлять информацию об уязвимостях или проблемах безопасности. Формализация взаимодействия — серьезная проблема, не все сайты имеют программы bug bounty, или даже просто указывают контакты специалистов по безопасности. А попытки достучаться через службу поддержки и твиттер зачастую заканчиваются уверениями что «Все так и должно быть», и последующим игнорированием.

Конечно, это будет работать только если компания, размещающая информацию в security.txt, готова проверять и своевременно реагировать на информацию, полученную через этот канал.

Сканеры веб-приложений — довольно популярная сегодня категория софта. Есть платные сканеры, есть бесплатные. У каждого из них свой набор параметров и уязвимостей, возможных для обнаружения. Некоторые ограничиваются только теми, что публикуются в OWASP Top Ten (Open Web Application Security Project), некоторые идут в своем black-box тестировании гораздо дальше.



В этом посте мы собрали восемь популярных сканеров, рассмотрели их подробнее и попробовали в деле. В качестве тренировочных мишеней выбрали независимые точки на двух платформах (.NET и php): premium.pgabank.com и php.testsparker.com.

В ходе прочтения этой статьи и комментариев к ней, у меня сформировалось стойкое ощущение, что большинство пользователей, использующих другие дистрибутивы, имеют не совсем верное представление о gentoo-like системах. Скорее всего виновато в этом само словосочетание «source-based».

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

Поиск по Хабру не нашел подробных статей по системе Alfresco. В данной статье попробую убить сразу двух зайцев: рассказать что представляет из себя система Alfresco и как мы используем ее в нашей работе.

Как хранятся документы в небольшой организации? Самое простое — на локальном диске. А если необходима совместная работа — пересылаются по почте, либо, самый популярный вариант, на сетевом диске. Еще прекрасный вариант — Google Docs, но не уверен что он широко используется в Российской практике.

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

При мысли о системе электронного документооборота первыми на ум приходят дорогие решения от известных вендоров, таких как Microsoft, EMC, 1С и т.д. Но есть и альтернатива закрытым решениям — система управления документами с открытым исходным кодом Alfresco. Или, если по-английски, то Open Source Enterprise Content Management System (ECM, CMS).

Конкуренты Alfresco — это закрытое ПО, такое как EMC Documentum, Open Text, Sharepoint. Сами разработчики Alfresco пишут о своих конкурентах, как о наследии 90-х годов, которое:

• слишком дорого стоит
• слишком сложно использовать, разворачивать, масштабировать
• слишком сложно модифицировать под свои нужды
• слишком “проприетарно”

Попробую рассказать о системе, а вы уже решайте правы ли были разработчики.

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

В этом посте я хотел бы поделиться своим опытом использования системы управления конфигурациями SaltStack, и, в частности, её применением в Masterless режиме при помощи salt-ssh компонента.

По сути, salt-ssh является аналогом системы Ansible.

salt-ssh '*-ec2.mydomain.com' test.ping

Будут затронуты следующие темы:

• Почему SaltStack, ключевые особенности
• Базовые понятия SaltStack
• Salt-ssh установка и использование

Неделю назад разработчики Rancher представили предварительный релиз своей будущей крупной версии — 2.0, — попутно объявив о переходе на Kubernetes в качестве единой основы для оркестровки контейнеров. Что побудило разработчиков пойти таким путём?

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

Нас часто спрашивают, какие книги стоит почитать тем, кто делает первые шаги в сфере информационной безопасности? Наша команда экспертов по тестированию на проникновение составила подборку книг, которые помогут освоить практические вопросы ИБ.

Scapy — инструмент создания и работы с сетевыми пакетами. Программа написана на языке python, автор Philippe Biondi. Познакомиться с основным функционалам можно здесь. Scapy — универсальный, поистине мощный инструмент для работы с сетью и проведения исследований в области информационной безопасности. В статье я попытаюсь заинтересовать Вас использовать scapy в своей работе/проектах. Думаю, что лучше всего этого можно добиться, показав на примерах основные преимущества scapy.
В качестве примеров я возьму простые и наглядные задачи, которые можно решить средствами scapy. Основным направлением будет формирование пакетов для реализации того или иного вида атак.

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

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

В статье я поделюсь своим опытом автоматизации всего процесса разработки приложения Symfony с нуля от настройки инфраструктуры до деплоя в production. От development- и до production-окружения для запуска приложения будет использоваться docker-compose, а все процедуры непрерывной интеграции/внедрения будут запускаться через GitLab CI/CD Pipelines в docker-контейнерах.

Подразумевается, что вы знакомы с docker и docker-compose. Если нет или вы не знаете как его установить, я подготовил инструкцию по подготовке локального окружения разработчика. Фактически, для работы над приложением потребуется только Docker, VirtualBox и, опционально, Yarn.

Кто, если не ты? Когда, если не сейчас?



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

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

Только автоматизация. Только PowerShell.

Предисловие

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

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

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

Внимание: PowerShell вызывает привыкание.

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

Основная идея непрерывной поставки в том, чтобы построить конвейер (Deployment Pipeline), позволяющий каждому изменению в системе контроля версий попасть в боевое окружение стандартным и полностью автоматизированным способом.

Пример построения Deployment Pipeline на Jenkins для первой части:

1. Создание pipeline проекта
1.1. “Создать item” — ввести название и выбрать конфигурацию pipeline
1.2. В поле “GitHub project” ввести адрес до репозитория
1.3. Выбрать чекбокс “Опрашивать SCM об изменениях” и настроить расписание на проверку репозитория каждую минуту “* * * * *”
1.4. В поле “Pipeline script” ввести шаги проекта

node{
    stage 'Deploy'
       build 'Deploy_CHECK'
    stage 'Sonar_analysis'
       build job: 'Sonar_analysis', parameters: [string(name: 'STAND', value: 'CHECK')]
    stage 'Unit tests'
        build job: 'Unit_tests', parameters: [string(name: 'STAND', value: 'CHECK')]
    stage 'Deploy DEV'
        build 'Deploy_DEV'
    stage 'Unit tests'
        build job: 'Unit_tests', parameters: [string(name: 'STAND', value: 'DEV')]
    stage 'Acceptance_test'
        build 'Acceptance_test'
    stage 'Smoke_tests'
        build job: 'Smoke_tests', parameters: [string(name: '', value: 'DEV')]
}

2. Внести изменение в репозиторий
3. В течение минуты pipeline увидит новое изменение в репозитории и запустит проверку

Книга «Безопасность в PHP» (часть 1)

В списке десяти наиболее распространённых видов атак по версии OWASP первые два места занимают атаки с внедрением кода и XSS (межсайтовый скриптинг). Они идут рука об руку, потому что XSS, как и ряд других видов нападений, зависит от успешности атак с внедрением. Под этим названием скрывается целый класс атак, в ходе которых в веб-приложение внедряются данные, чтобы заставить его выполнить или интерпретировать вредоносный код так, как это нужно злоумышленнику. К таким атакам относятся, например, XSS, внедрение SQL, внедрение заголовка, внедрение кода и полное раскрытие путей (Full Path Disclosure). И это лишь малая часть.

Пользуясь случаем, хотелось бы лишний раз напомнить о существовании сертификации PHP инженеров. На дворе уже 2018й и мир увидела PHP 7.2, сертификация постоянно обновляется. Текущая версия: ZCPE-2017. Получить сертификат сейчас, или все же дождаться выхода обновленной версии — решать вам.

Говорят, в 70-х годах Геннадий Зайцев, первый президент легендарного Ленинградского рок-клуба, так сформулировал принцип отбора музыкантов: «Беглость пальцев — дело наживное. Был бы человек хороший».

Возможно, если бы мы с Геннадием Борисовичем решили за рюмкой чего-нибудь горячительного пожаловаться друг другу на сложности в подборе кадров, то обнаружили бы много общих моментов. Когда мы собирали первую команду Solar JSOC, рынка сервисов мониторинга и противодействия кибератакам фактически еще не существовало, следовательно, не было ни готовых специалистов под эти задачи, ни даже четких критериев поиска. Нам предстояло собрать команду уникумов, но до этого — много раз пробовать новое, ошибаться и снова пробовать. Именно про команду сегодня и поговорим: как это было в самом начале и к чему мы пришли в результате.

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

Качество картинки на YouTube варьируется от 144p (144 строчки в прогрессивной развёртке) до 8K 4320p. Последнее видео в четыре раза крупнее 4К 2160p, в шестнадцать — 1080p, в тридцать шесть — 720p, который также называют HD.


Мало какой компьютер может проиграть это видео в его полном разрешении, а доступных по цене 8K-мониторов в мире просто нет.

Технология MPEG-DASH разбивает контент на куски, а браузер запрашивает эти сегменты автоматически. Логично хранить и отдавать отдельно видео и звук. У DASH есть жирный плюс: адаптивность воспроизведения.

Несколько лет назад пользователи YouTube заметили введение DASH по тому, что буферизация видео больше не шла до конца ролика, а ограничивалась примерно минутой. Около того же времени другая проблема возникла у скачивающих видео с YouTube. Внезапно обнаружилось, что ролики с качеством 1080p доступны в виде файлов без звука. Сайты-сервисы, которые раньше выдавали ссылки на скачивание видео, отдавали лишь 720p, не выше. Около 1080p стояло «без звука» или «только видео».