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

Далее мы рассмотрим несколько подходов к интеграции, и начнем с простейшего случая, когда между системами нет интеграции.

То есть, представим ситуацию, когда в компании используются несколько независимых информационных систем: складская, бухгалтерская, CRM и финансовая. Между этими системами нет информационного обмена.

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

В результате у нас образуется некоторый «Paper Net», то есть бумажный обмен данными между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской).

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

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

На тему автоматизации тестирования написано множество статей, посвященных различным инструментам QA в рамках процессов DevOps. В этой статье мы тоже будем говорить об автоматизации тестирования, но уже в контексте процессов DevSecOps.

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

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

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

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

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

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

Итак, SIEM (Security information and event management) — это система управления событиями безопасности. Технология SIEM обеспечивает анализ в реальном времени событий безопасности, исходящих от сетевых устройств и приложений, и позволяет реагировать на них до наступления существенного ущерба. Основными задачами систем данного класса являются сбор, обработка и анализ событий безопасности, поступающих в систему из множества источников, также обнаружение в режиме реального времени атак и нарушений критериев и политик безопасности. На основе получаемых событий ИБ осуществляется оперативная оценка защищенности информационных, телекоммуникационных и других критически важных ресурсов, анализ и управление рисками безопасности. Во многие современные SIEM системы встроены механизмы принятия решений и инструменты расследования инцидентов. Также неотъемлемой частью SIEM является наличие средств для формирования отчетных документов. Но, давайте для начала посмотрим, для чего вообще нужны SIEM системы.

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

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

Можно конечно, поднять виртуалку/контейнер с Windows/Linux и в нем с помощью специальных инструментов анализировать работу данного файла. Естественно, использовать свою рабочую машину для анализа вредоносов идея, мягко говоря, не очень хорошая. Рано или поздно (скорее рано) вы не уследите при анализе в отладчике, и вредонос выполнится полностью и захватит контроль над машиной. 

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

В сегодняшней статье я предлагаю обратить внимание на такой важный аспект информационной безопасности как физическая безопасность. Традиционно, практически все рекомендации по обеспечению защиты ЦОД, контролируемой зоны, виртуализации, контейнеризации и много другого начинают с необходимости ограничения физического доступа к компонентам инфраструктуры: серверам, сетевому оборудованию, различным компонентам управления и т.д. Будет не очень хорошо, если злоумышленник получив физический доступ к оборудованию сможет выключить кабель питания, а еще веселее будет, если он сможет поменять местами патчкорды, подключенные к портам коммутатора. Такие простейшие DoS атаки может организовать любой, при этом обладать какими либо техническими знаниями совершенно не нужно, достаточно просто получить физический доступ к оборудованию.

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

Сегодня мы поговорим о СУБД Redis, рассмотрим процесс установки и настройки. В отличие от реляционных систем управления базами данных, Redis является СУБД класса NoSQL с открытым исходным кодом, работающей  со структурами данных типа «ключ — значение».

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

Но, вернемся к СУБД Redis. Redis - это хранилище значений ключей в памяти, известное своей гибкостью, производительностью и широкой языковой поддержкой. Данная система ориентирована на достижение максимальной производительности на атомарных операциях (заявляется о приблизительно 100 тыс. SET- и GET-запросов в секунду на Linux-сервере начального уровня). Написана на Си, интерфейсы доступа созданы для большинства основных языков программирования. Далее мы поговорим о том, как установить и безопасно настроить Redis на сервере Ubuntu 22.04.

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

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

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

Программный код, будучи по факту виртуальной сущностью не может иметь запах в прямом смысле этого слова. Однако, термин “запах кода” (code smell) некоторое время назад был введен Кентом Беком и популяризирован книгой Мартина Фаулера о рефакторинге (Refactoring: Improving the Design of Existing Code).

В русскоязычном переводе можно встретить “код с душком”. Такой перевод явно говорит о том, что речь идет о чем-то не слишком хорошем и для того, чтобы понять, что же такое code smell, рассмотрим несколько примеров.

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

NodeMCU — это платформа на основе модуля ESP8266. Отличием этой платы от других Arduino подобных решений является наличие встроенного модуля WiFi. С помощью этого модуля мы можем управлять различными схемами на расстоянии посредством передачи сигнала  через Wi-Fi. Для NodeMCU написано множество различных библиотек и помимо прочего на ней можно реализовать точку доступа. Да, для создания полноценной точки доступа к плате необходимо подключать Ethernet модуль, но как вы увидите далее, для тех задач, которые мы будем реализовывать, нам отправлять трафик дальше совсем не обязательно.

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

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

В сегодняшней статье мы поговорим об использовании Python для проверки API веб приложений. Но сначала давайте рассмотрим, что представляет из себя тестирование API.

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

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

В этой статье речь пойдет об использовании отражающих dll инъекций (reflective dll injection), которые позволяют в определенной степени спрятаться от средств защиты на этапе закрепления на машине жертвы.

В этой статье мы продолжим тему инъекций кода и поговорим о том, как можно осуществлять инъекции кода с помощью DLL. Общая идеология будет та же, что и в предыдущей статье – с помощью инъекции запустить реверсивный шелл на машине жертвы, и получить доступ на нее. Но для начала давайте поговорим о том, что такое DLL и как с ними работать.

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

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

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

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

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