@zloytapochek

Создание systemd сервиса

2026-02-28T14:56:29.749Z

TL;DR
Создание "сервисного" пользователя
Создание systemd-сервиса

Создание пользователя

Создание пользователя обычно чем-то подкрепляется. В моем случае нужно было создать "сервисного" юзера. У которого не будет домашней директории и через него нельзя будет залогиниться. А нужен он будет для запуска веб-сервера
Поэтому входные данные такие:

Имя группы
Имя пользователя
Путь до исполняемого файла
Путь до директорий, к которым нужен будет доступ

Создаем группу

sudo groupadd <имя_группы>

Создаем самого пользователя

sudo useradd -r -s /usr/sbin/nologin -g <имя_группы> <имя_пользователя>

-r - создает системного пользователя без домашней директории
-s /usr/sbin/nologin - запрещает авторизацию пользователя через терминал
-g <имя_группы> - добавляет пользователя в определенную группу

Полный список флагов здесь.

Назначаем права доступа

sudo chown -R <пользователь>:<группа> <путь_до_исполняемого_файла>

sudo chown -R <пользователь>:<группа> <дополнительные_директории>
...

Управление systemd-сервисом

Чтобы создать сервис, нужно описать его в конфигурационном файле. Располагаться он должен в /etc/systemd/system/<имя_сервиса>.service

Ниже приведен пример шаблона с пояснениями. Данный шаблон был использован для настройки Copyparty

Шаблон:

[Unit]
Description=CopyParty File Server # Описание
After=network.target # запуск после успешного поднятия сети

[Service]
Type=simple

User=copyparty # Пользователь, которого создали ранее
Group=copyparty # Группа, которую создали ранее

WorkingDirectory=/opt/copyparty # Директория, где лежит исполняемый файл

ExecStart=/usr/bin/python3 /opt/copyparty/copyparty-sfx.py -c /opt/copyparty/copyparty.conf # Команда запуска. На всякий случай пишем пути полностью

# Настройки перезапуска при сбоях
Restart=on-failure
RestartSec=5

# Базовые настройки безопасности
NoNewPrivileges=yes # Запрет процессу и его дочерним повышать привелегии
ProtectSystem=full # Делает системноважные папки неприкосаемыми

Environment="HOME=/opt/copyparty" # Т.к. пользователь copyparty был создан без домашней директории, то укажем ее вручную

AmbientCapabilities=CAP_NET_BIND_SERVICE # Дает разрешение на откртые системных портов(0-1023)
[Install]
WantedBy=multi-user.target # Устанавливает условие для запуска: система должна полностью загрузиться и быть готовой к работе

Изначально шабон не завелся из-за двух ошибок:

srv.bind((ip, port)) -> [Errno 13] Permission denied
Unable to store config in ~/.config

Чтобы их исправить были добавлены строчки:

Environment="HOME=/opt/copyparty" # Т.к. пользователь copyparty был создан без домашней директории, то укажем ее вручную

AmbientCapabilities=CAP_NET_BIND_SERVICE # Дает разрешение на откртые системных портов(0-1023)

Кстати список всех Capabilities лежит здесь.

🔥Hint

Если заполняли файл на winodws, то на всякий случай наш его преобразовать с dos на unix командой dos2unix /etc/systemd/system/copyparty.service

Теперь запустим наш сервис:

Перезагружаем конфиг systemd

sudo systemctl daemon-reload

Включаем наш сервис, тем самым добавляем его в автозагрузку

sudo systemctl enable copyparty

Запускаем наш сервис

sudo systemctl start copyparty

Проверяем статус сервиса

sudo systemctl status copyparty

Просмотр логов сервиса

sudo journalctl -u copyparty.service

На этом создание нашего сервиса завершено :)

Всем добра!

"Домашний" Compute Cloud | Или как создавать машинки в Hyper-V без ошибок и с Cloud-Init

2025-11-03T21:27:50.509Z

Мотивация сделать это

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

Почему Ansible?
Изначально я думал написать связку Ansible и Terraform, а запускать их через Powershell скрипт, но из-за проблем провайдера Terraform я не смог этого сделать. И как мне кажется, так даже лучше, ибо Ansible можно запустить на любой системе, в отличие от того же Powershell.

А как же Proxmox и другие средства виртуализации + Terraform?
Для этого нужны дополнительные ресурсы. А мое решение подходит для тех, у кого есть ПК + ноутбук, или 2 ПК, или 2 ноутбука.

Как это сделать

Итак, вот мой репозиторий: https://github.com/ZloyTapochek/HyperV-VMs-Ansible-Role

Вам нужно его склонировать и перейти в директорию

git clone https://github.com/ZloyTapochek/HyperV-VMs-Ansible-Role.git
cd HyperV-VMs-Ansible-Role

Самое главное, с чем я боролся 2 дня - выполнение конвертации диска .img в .vhdx в WSL. Сейчас это звучит непонятно, но поймете, когда перейдете в репозиторий и прочитаете Readme.

Далее следуйте инструкции в Readme, заполняйте переменки. Я в свободное время буду дополнять ее и совершенствовать.

После всем подготовительных действий, запускайте эту команду и отдыхайте, пока программа все сделает за Вас.

ansible-playbook ./playbook.yml -i ./hosts.ini

Всем добра!

Поговорим про Templates для Ansible Roles

2025-06-05T13:52:36.955Z

Сейчас пришлось окунуться в изучение Roles для Ansible. Поэтому пока знания свежие спешу поделиться ими и легко объяснить то, с чем у меня возникли трудности.

Ликбез

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

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

ansible localhost -m ansible.builtin.apt -a "name=apache2 state=present" -b -K

Данная команда запускает ansible localhost- на вашей локальной системе. — name=apache2 state=present — устанавливает пакет apache2 на систему на базе Debian. -b — использует become для выполнения с повышенными привилегиями. -m — указывает имя модуля. -K — запрашивает пароль для повышения привилегий.

Либо же можно использовать Playbook (далее просто «Плейбук"/"Плейбуки»).

Ansible Playbooks — основная конфигурация, которой будет следовать Ansible при настройке удаленных хостов. Плейбуки хороши своей легкостью, повторяемостью и изменяемостью.
Ansible Roles — вот переведенное определение из документации: «Роли позволяют автоматически загружать связанные с ними vars, файлы, задачи, обработчики и другие артефакты Ansible на основе известной структуры файлов. Сгруппировав содержимое по ролям, вы сможете легко использовать их повторно и делиться ими с другими пользователями.»
Если говорить проще, то Roles (в дальнейшем просто «Роли») помогают разделять задачи на контексты.
Также я упоминал «…указывает имя модуля…».
Ansible Module (далее просто «Модуль») — основной параметр, с помощью которого Ansible будет знать, что делать в конкретной задаче. Для примера:

ansible.builtin.copy — может копировать файлы
community.docker.docker_compose — работает с файлами докера, тем самым может запускать контейнеры, проверять запущены ли они уже и многое другое.

На этом ликбез окончен и мы переходим к нашему сегодняшнему гостю — ролям для Ansible.

Роли

Вообще сами по себе роли не сложны. По сути, если мы используем роли, то наш каталог, где находится плейбук, дополняется директорией roles:

roles/
└── role_name/  
    ├── defaults/       # Переменные по умолчанию (низкий приоритет)  
    ├── vars/           # Переменные роли (высокий приоритет)  
    ├── tasks/          # Основные задачи  
    ├── handlers/       # Обработчики  
    ├── templates/      # Jinja2-шаблоны  
    ├── files/          # Статические файлы  
    ├── meta/           # Информация о роли (зависимости и т. д.)  
    └── tests/          # Тесты

Роль может иметь любое название, чтобы запустить роль в главном .yml файле плейбука нужно указать:

--- 
- hosts: all  
  roles:    
    - <имя_вашей_роли>

Потом в директории tasks создаете файл, например main.yml, в котором пишете:

--- 
- name: Creates docker directory
  become: true  ansible.builtin.file:
    path: /home/ubuntu/docker
    state: directory

Это пример задачи, которая создаст директорию docker.

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

---
- name: Copying backup_db
  become: true
  ansible.builtin.copy:
    dest: /home/ubuntu/docker/scripts/
    src: files/backup.sh

Данная задача копирует файл на удаленный хост.

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

Роли с чувствительной информацией: как прятать пароли с помощью templates

Для нашего случая возьмем простейший docker compose файл:

version: '3.8'

services:
  postgres:
    image: postgres:latest
    environment:
      POSTGRES_PASSWORD: "mysecretpassword"  # Пароль для PostgreSQL
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

А теперь легенда:
Мы разработчики, которые разворачивают контейнер с базой данных PostgreSQL у себя на удаленном хосте. Весь свой код мы храним в каком-нибудь хранилище кода, например GitLab. Также у нас настроен CI, который сам будет выполнять плейбуки для Ansible.
Получается такой алгоритм:

Написали код.
Запушили в хранилище.
CI начинает выполняться.
Наша БД готова.

Но все не так просто. Для CI нужны переменные паролей, а в открытом виде их держать нельзя. Вот тут и выходят на сцену Templates. И вот их я постараюсь объяснить максимально легко.

Итак, Template — это файл с расширением .j2, ссылаясь на который Ansible будет генерировать другой файл. Звучит сложно, понимаю, поэтому вот пример:

Наш docker compose файл называется docker-compose.yml. Его template будет называться docker-compose.yml.j2. Выглядеть template будет так:

version: '3.8'

services:
  postgres:
    image: postgres:latest
    environment:
      POSTGRES_PASSWORD: {{ postgres_password }}  # Пароль для PostgreSQL
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Мне кажется, что теперь все должно проясниться. Наш CI будет иметь переменную, которую передаст Ansible. Ansible возьмет template и сгенерирует на его основе исходный файл, заменяя переменные в {{ … }} переменными, которые получили из CI.

А теперь как это все провернуть.

Во первых, создайте переменные в своем хранилище кода. Например в GitLab это делается так:

Settings → CI/CD → Variables → Add Variable

Отталкиваясь от нашего примера в переменной мы укажем следующее:

KEY: POSTGRES_PASSWORD
VALUE: mysecretpassword

Во вторых, нам нужно изменить (не скопировать, не добавить, а именно изменить) файл, где находится чувствительная информация, а затем переместить его по пути /roles/<имя_вашей_роли>/templates. Изменяем мы его следующим образом:

Чувствительная информация заменяется на {{ <имя_переменной> }}. Тут смотрите внимательно: имя переменной, которая НЕ В ХРАНИЛИЩЕ. Это важно.
К имени файла добавляется .j2

В третьих, нужно создать задачу, которая сгенерирует нам исходный файл.

- name: Rendering docker-compose file
  become: true
  ansible.builtin.template:    
    src: templates/docker-compose.yml.j2    
    dest: /home/ubuntu/docker/docker-compose.yml    
    owner: ubuntu    
    group: ubuntu  
    mode: '0644'

И наконец построим «мост», по которому наши переменные будут передаваться от хранилища кода и сопоставляться с переменными Ansible. Для этого создаем директорию, которая находится на одном уровне с roles/. Называем ее group_vars, внутри добавляем файл, например all.yml с содержимым:

<имя_вашей_переменной_которую_вы_указали_в_файле_.j2>: "{{ lookup('ansible.builtin.env', '<имя_вашей_переменной_в_хранилище_кода>' }}"

И на этом все. Ansible будет работать. И для полноты картины покажу полный пример с нашим Docker Compose.

Пример

Исходный docker-compose.yml:

version: '3.8'

services:
  postgres:
    image: postgres:latest
    environment:
      POSTGRES_PASSWORD: "mysecretpassword"  # Пароль для PostgreSQL
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Измененный ./roles/postgre_install/templates/docker-compose.yml.j2:

version: '3.8'

services:
  postgres:
    image: postgres:latest
    environment:
      POSTGRES_PASSWORD: {{ postgres_password }}  # Пароль для PostgreSQL
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Переменная внутри хранилища кода:

KEY: POSTGRES_PASSWORD
VALUE: mysecretpassword

Файл с переменными ./group_vars/all.yml:

postgres_password: "{{ lookup('ansible.builtin.env', 'POSTGRES_PASSWORD' }}"

Основной файл ./roles/postgre_install/tasks/main.yml:

---
- name: Rendering docker-compose file  
  become: true   
    ansible.builtin.template:    
    src: templates/docker-compose.yml.j2    
    dest: /home/ubuntu/docker/docker-compose.yml    
    owner: ubuntu    
    group: ubuntu
    mode: '0644'
- name: starting docker-compose  
  become: true  
  community.docker.docker_compose:    
    project_src: "/home/ubuntu/docker"    
    state: present

Самый главный файл ./playbook.yml:

---
- hosts: all  
  roles:    
    - postgre_instal

После этого ваша роль заработает на нужных хостах.

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

Всем добра!

Поговорим про DevSecOps. Jenkins with Bandit

2025-02-04T18:57:06.973Z

В прошлой статье мы разобрали инструмент Bandit. Если вкратце, этот инструмент сканирует исходный код. Мы применили его на практике, но в нестандартной для DevSecOps форме, запустив его в обычной ОС. Но на практике подобные инструменты встраиваются в CI/CD пайплайн.

CI/CD пайплайн — набор практик и методов, которые позволяют автоматизировать процесс разработки. То бишь, мы просто вносим изменения в код, а этот код автоматически собирается, тестируется, встает на облачные сервера ну и т. д.

В этой статье мы интегрируем запуск Bandit для нашего кода на GitHub в Jenkins.

Jenkins — инструмент для автоматизации процесса разработки, который поддерживает практики CI/CD

Устанавливаем Jenkins

Итак, все это безобразие будет сделано с помощью Docker.

Docker — инструмент для контейнеризации приложений.

Процесс установки Docker я оставлю за кадром, но приложу ссылку на иструкцию.

Итак, сначала напишем Dockerfile.

Dockerfile — это текстовый файл, содержащий набор инструкций, которые Docker использует для автоматической сборки образа контейнера.

FROM jenkins/jenkins:lts
# Устанавливаем необходимые пакеты и Bandit
USER root
RUN apt-get update 
RUN apt-get upgrade -y 
RUN apt-get install virtualenv  -y
RUN virtualenv bandit-env 
RUN . bandit-env/bin/activate 
RUN apt-get install python3 -y
RUN apt-get install python3-pip -y
RUN apt install python3-bandit -y
RUN apt-get install ssh -y

USER jenkins

Сначала запустим Bandit в том же контейнере, что и Jenkins. А потом сделаем все по уму и добавим агента Jenkins, который сделает все в отдельном контейнере.

Итак, сформировали Dockerfile. Теперь сформируем Docker-compose.yml

Docker-compose.yml — файл конфигурации для многоконтейнерных приложений

version: '3.8'

services:  
  jenkins:    
    build: .    
    ports:      
      - "8080:8080"      
      - "50000:50000"    
    volumes:      
      - jenkins_home:/var/jenkins_home    
    networks:      
      - jenkins

volumes:  
  jenkins_home:  

networks:  
  jenkins:

Быстро разберем данный файл:

version — версия файла Docker-compose
services — контейнеры нашего приложения
build — пусть к Dockerfile данного сервиса
volumes — томы. Иными словами: постоянная память для контейнеров, которая не будет стираться после каждого перезапуска
networks — сети для контейнеров, которые позволяют изолировать трафик между контейнерами

Запустим наше приложение командой Docker-compose up -d. Флаг -d означает работу в фоновом режиме. Таким образом мы не будем видеть логи контейнера в терминале.

Наша рабочая директория должна выглядеть так:

|-workspace
 |--docker-compose.yml
 |--Dockerfile

Когда пропишем команду, наш терминал будет выглядеть следующим образом (Название может отличаться):

Результат успешного запуска нашего приложения

Надписи CACHED означают, что изображение, по которому строится контейнер уже имеется в памяти ПК, поэтому и время построение очень маленькое. У Вас может быть больше.

Итак, что мы видим в приложении Docker Desktop:

Как выглядит Docker Desktop

Workspace — многоконтейнерное приложение. Имя этого приложения подтягивается от нашей рабочей директории.
Jenkins-1 — наш контейнер.

Перейдем по двум портам, которые у нас открыты. Порт 5000 нас пока что не интересует, поэтому перейдем по 8080.

Нам нужно ввести пароль, который лежит внутри контейнера.

Кликнув по имени контейнера мы можем посмотреть его логи:

c7e456fbad25460190ff7d2ec416734d — наш пароль. Введем его.

Теперь нас спрашивают, какие плагины мы хотим установить. Устанавливаем те, которые сообщество Jenkins использует больше всего.

Процесс установки плагинов

После установки нас просят создать Админа

Потом предлагают поменять ссылку, по которой доступен Jenkins. Мы же не будем ничего менять

Наш Jenkins готов к использованию!

Начало работы с Jenkins

Главная страница Jenkins выглядит так:

Jenkins dashboard

Давайте создадим item (job).

Job (Джоба) — в контексте DevOps — единица работы

Мы выберем свободную конфигурацию и имя BanditWithJenkins.

Настройка нашей джобы выглядет так:

Для нашей статьи хватит флажка GitHub project.

Теперь вставим ссылку на репозиторий GitHub из прошлой статьи:

Теперь внизу страницы добавим шаг сборки, а именно выполнение команды Shell. Для проверки работоспособности введем обычный Hello, world! И сохраним изменения.

Теперь попробуем собрать наш проект

Во вкладке Build у нас появилась сборка и она успешна

Заглянем внутрь данной сборки:

Здесь мы видим краткую информацию, такую как: время выполнения, создателя и т. д.

Но нас интересует вывод консоли

Результат нас устраивает. Теперь перейдем к Bandit.

Настройка Bandit

Нам нужно добавить новые команды в наш проект:

После запуска Jenkins проведет сканирование нашего кода, создаст уникальный текстовый файл и выведет его содержимое в консоль.

Текущий вывод выглядит так:

Bandit запустился, но ничего не просканировал. Потому что мы забыли добавить управление исходным кодом. Исправим это в настройках проекта. Репозиторий открытый, так что данные (Credentials) для доступа к нему можно не настраивать.

А вот это уже интересно:

Ошибка сборки, давайте посмотрим, что случилось.

Первое выделение говорит нам о том, что мы правильно поменяли настройки и теперь наш проект клонирует репозиторий GitHub. А вот второе выделение по началу непонятно, но сейчас все объясню.
Когда Bandit находит угрозу, он возвращает false. Jenkins воспринимает false как ошибку, поэтому, делаем следующее:
Меняем команду, чтобы текущий шаг всегда возвращал true.

Сохранив изменения и запустив сборку видим следующее (#5 потому что 4-ую из-за человеческого фактора пришлось удалить, не обращайте внимания):

Вывод следующий:

Прекрасно! Все работает.

Все наши файлы доступны внутри контейнера по пути var/jenkins_home/workspace/BanditWithJenkins. (Метка Volume подтверждает, что все мы настроили правильно и при перезапуске контейнера эти файлы не пропадут)

Настройка агента Jenkins

Теперь настало время сделать все по уму. Небезопасно выполнять тесты на машине, где установлен Jenkins. Поэтому создадим Jenkins agent.

Итак, изменим наш Docker-compose файл:

version: '3.8'

services:
  jenkins:
    build: .
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
    networks:
      - jenkins

  agent:
    build: /for_ubuntu
    ports:
      - "2673:2673"
    volumes:
      - agent_home:/var/agent_home
    networks:
      - jenkins

volumes:
  jenkins_home:
  agent_home:

networks:
  jenkins:

В папке for_ubuntu создадим еще один Dockerfile:

FROM ubuntu:latest

# Устанавливаем необходимые пакеты и Bandit
RUN apt-get update 
RUN apt-get upgrade -y 
RUN apt-get install virtualenv -y 
RUN virtualenv bandit-env 
RUN . bandit-env/bin/activate 
RUN apt-get install python3 -y 
RUN apt-get install python3-pip -y 
RUN apt install python3-bandit -y 
RUN apt-get install ssh -y 
RUN apt-get install curl -y
RUN apt-get install -y openjdk-17-jdk

CMD ["sleep", "infinity"]

Теперь наша рабочая директория должна выглядеть так:

|-workspace
 |--for_ubuntu
  |--Dockerfile
 |--docker-compose.yml
 |--Dockerfile

Команда Docker-compose up -d запустит наше приложение. В этот раз никаких команд не было кэшировано, отсюда и долгий запуск (703 секунды).

Пример успешного запуска приложения

Итак, зайдя на http://localhost:8080 нас встречает окно логина в Jenkins. Что подтверждает правильность наших настроек, ведь если бы у Jenkins были удаленны все данные, то регистрация началась бы заново.

Приступим к созданию агента.

Jenkins Agent — компонент системы Jenkins на другой машине. Он будет выполнять команды, которые дал ему наш основной сервис.

Кстати, даже сам Jenkins говорит нам настроить агента:

Мы пойдем по длинному пути через кнопку «Настроить Jenkins».

Настройки Jenkins

Ноды или Узлы Jenkins и их настройки

Создание новой Ноды или Узла

Итак, остановимся подробнее на этом скриншоте:

Нас просят указать удаленные корневую директорию. Мы укажем наш Volume, который прописывали в Docker-compose «/var/agent_home»

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

Нас перенаправит на страницу настройки нод\узлов. Нажимаем на наш недавно созданный агент.

И нам сразу же дают команды, которые мы должны выполнить внутри Docker контейнера:

Важное уточнение:
Нам нужен IP сервера. И именно на этот IP мы меняем localhost в командах, которые нам дали.

Пример:
Была команда curl -sO http://localhost:8080/jnlpJars/agent.jar
Стала curl -sO http://172.18.0.3:8080/jnlpJars/agent.jar

IP контейнера можно посмотреть через команду docker container inspect <container_name_or_id>

Заходим в Docker и выполняем эти команды.

Если не менять localhost, ответ следующий:

Отрицательный ответ

Если поменяем:

Положительный ответ

Также пропал крестик на иконке нашего агента

Собираем проект через агента

Все что осталось, так это перейти в настройки нашей джобы, поставить вот такой флажок:

А в его поле выбрать нашего агента:

Все, сохраняем и запускаем.

Сборка успешна:

Вывод такой же:

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

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

Критику, желательно конструктивную, жду в комментариях.

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

Всем добра!

Поговорим про DevSecOps. Bandit

2025-01-01T10:37:40.483Z

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

Т.к. эта статья первая, было бы неправильно не рассказать о главной теме наших разговоров. Что такое DevSecOps? При запросе в поисковиках вы получите скучный, но верный ответ «DevSecOps — методология безопасной разработки». Предлагаю перевести это в более читабельный вид. Для этого немного истории. Раньше разработка приложений шла примерно так:

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

Та самая шутка про дыру в безопасности

DevSecOps старается внедрить отдел безопасности как можно раньше в процесс разработки.

Есть несколько типов инструментов DevSecOps:

SAST (Static Application Security Testing): такие как SonarQube, Checkmarx и Fortify, анализируют исходный код на наличие уязвимостей до его выполнения.
DAST (DynamicApplicationSecurityTesting): OWASP ZAP, Burp Suite и подобные инструменты тестируют приложение в работающем состоянии, выявляя уязвимости.
Сканеры уязвимостей: например, Nessus, Qualys и OpenVAS, которые помогают находить уязвимости в инфраструктуре и приложениях.

Наш сегодняшний гость — Bandit. Не в прямом смысле этого слова конечно же. Bandit относится к первой группе инструментов. Давайте поближе его рассмотрим.

Этот инструмент специализируется на Python, что весьма актуально. Вот краткое описание из официальной документации:

Bandit — это инструмент, предназначенный для поиска распространенных проблем безопасности в коде Python. Для этого Bandit обрабатывает каждый файл, строит из него AST и запускает соответствующие плагины к узлам AST. Как только Bandit завершит сканирование всех файлов, он создаст отчет.

Что же, давайте посмотрим на него в деле.

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

Итак, начнем. Предварительно я установил Bandit, прописав следующую команду:

pip install bandit

Теперь, распаковав скачанный репозиторий начнем сканирование. Для этого стоит перейти в нужный нам каталок, у меня это «F:\Education\Examples\app-master» и ввести команду

bandit -r .

bandit — наименование нашего инструмента
-r — флаг, обозначающий сканирование директории
. — путь к директории. В данном случае к той, в которой находимся

Первый вывод после запуска

Запустив программу нам выведет информацию о текущей конфигурации, но это не совсем то, что мы ищем.

Подождав, мы видим следующее:

Итоговый отчет

Bandit выдал нам отчет, давайте разберем его.

Мы видим три основных раздела:

Code scanned
Run metrics
Files skipped

В первом разделе нам сообщается об общем количестве сканированных строчек кода.
Во втором разделе мы видим самое главное — общее количество уязвимостей, разделенных на угрозы по уровню серьезности (severity) и по уровню доверия (confidence). Помимо этого все угрозы подразделяются по уровням риска: неопределенный (Undifined), низкий (Low), средний (Medium), высокий (High).

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

Вывод конкретной уязвимости

Но есть одна проблема. У нас уязвимостей около 2х тысяч. и на каждую приходится около 10 строк в командной строке. И она просто будет удалять историю. Предлагаю вывести все отчеты в один отдельный файл. Сделаем это командой

bandit -r . -o result.json

Где флаг -o означает путь к файлу, в который будет выведен отчет.

И нам выведет ошибку. Bandit’у нужно сказать, чтобы он переформатировал выходные данные в txt. Финальная команда выглядит так:

bandit -r . -o result.json -f txt

Ну или

bandit -r . -o result.txt -f txt

Давайте посмотрим что получилось.

Отчет в формате текстового файла, открытый в Notepad++

И все работает! У нас есть отчет на 21507 строк. Передаем его программистам и пусть трудятся😁

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

Всем добра!

Поговорим про терминал

2024-12-30T15:10:06.023Z

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

Терминал операционной системы

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

Скриншот QTerminal для Linux

Вот о функционале подобных терминалов мы и поговорим.

Интересный факт

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

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

В своей жизни, когда мне нужно посчитать что-то сложное, я захожу в Windows Terminal и выполняю команду «python». И уже в нем высчитываю то, что мне нужно. А знали ли вы, что можно Bash может считать выражения тоже? Для этого нужно выполнить команду expr.

$ expr 123 + 945 * 2 + 45
2058

Да и вообще на оболочках можно писать программы. Они имеют свой синтаксис для объявления переменных:

$ first="Hello"
$ second="World!"
$ mid=","
$ echo $first$mid $second
Hello, World!

Для создания циклов:

$ for i in {1..10}; do   echo $i; done
1
2
3
4
5
6
7
8
9
10

И т. д.
В этих примерах используется команда «echo», надеюсь, что все с ней знакомы.

Только не пишите полноценные программы на оболочках. Они для этого не оптимизированы👀

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

$ history

Впору упомянуть, что переменные оболочка тоже хранит. И чтобы удалить переменную нужно ввести:

$ unset имя_файла

Что там по работе с файлами?

Команда cat поможет прочитать содержимое файл, это мы знаем. А если нам нужно вывести только первые или последние n строк?

В первом случае нам поможет следующая команда:

$ head -n 10 имя_файла

Во втором случае:

$ tail -n 10 имя_файла

Ах да, чтобы прочитать файл, сначала нужно его создать. Что же, команда touch спешит на помощь

$ touch имя_файла

В качестве аналога ctrl+f используется команда grep

$ grep "то что нужно найти" имя_файла

Если нужно найти файл по имени, то пишем следующее

$ find имя_директории -name имя_файла

В предыдущей команде поддерживается знак «*», который означает что угодно, являясь неким регулярным выражением

find имя_директории -name "*.txt"
# Найдет все файлы с расширением .txt

Сейчас очень важно знать основы работы с терминалом. Конечно, во многие приложения всё больше и больше добавляют собственный GUI(Graphical User Interface). Но у него есть недостатки:

GUI медленные
GUI подстраивается под каждого пользователя
То бишь, если у одного сотрудника монитор 1920×1080, а у другого меньше или больше, то на каждом из рабочих мест GUI будет смотреться по-разному
GUI нельзя автоматизировать
И т. д.

Если испытываете сложность с работой в терминале, то вот здесь можете пройти бесплатный курс и стать мастером своего дела.

Всем добра!

Поговорим про IPsec

2024-12-22T14:42:10.601Z

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

Итак, IPsec — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP (Internet Protocol).

Защита наших данных может быть реализована на разных протоколах. IPsec же реализован на сетевом уровне (network layer).

Ядро нашего сегодняшнего гостя состоит из трех протоколов:

Authentication Header (АН) — гарантирует, что данные не были изменены во время передачи, проверяет, откуда пришла информация, и защищает от повторной отправки одних и тех же данных.
Encapsulating Security Payload (ESP) — обеспечивает конфиденциальность передаваемой информации с помощью шифрования и контролирует поток конфиденциальных данных. Кроме того, он может выполнять функции AH. При использовании ESP обязательно указывать, какие именно функции безопасности будут применяться, так как их можно включать по желанию.
Internet Security Association and Key Management Protocol (ISAKMP) — протокол, который используется для первоначальной настройки соединения, взаимной проверки подлинности между конечными устройствами и обмена секретными ключами.

Теперь, когда мы знаем о «внутрянке» IPsec, давайте рассмотрим режимы его работы. Их, к слову, два: транспортный и туннельный.

Транспортный, как правило, используется для установления соединения между хостами. В этом режиме шифруются или подписываются только данные IP-пакета. Другими словами, шифруется только полезная нагрузка, а заголовок остается неизменным

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

Далее мы рассмотрим режим работы IPsec, но перед этим нужно знать, что такое IKE.

IKE (Internet Key Exchange) — протокол, связывающий все компоненты IPsec в работающее целое. В частности, IKE обеспечивает первоначальную аутентификацию сторон, а также их обмен общими секретными ключами. Он работает через порт 500 UDP и имеет две фазы.

Первая фаза:

Создание безопасного канала (IKE SA) и согласование сессионного ключа с использованием алгоритма Диффи-Хеллмана. В это фазе есть два режима:

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

Вторая фаза:

Выполняется только в одном быстром режиме после создания безопасного канала. Он согласует политику IPsec, устанавливает IPsec SA и обновляет секретные ключи, используя алгоритм Диффи-Хеллмана.

Наконец, как работает IPsec:

На первом этапе создаются политики безопасности на каждом узле, поддерживающем стандарт IPsec.
Второй этап, по сути, является первой фазой IKE. Здесь организовывается безопасный канал между сторонами.
Третий этап является второй фазой IKE. Его задачей является создание IPsec-туннеля.
Четвертый этап — рабочий этап. Все настроено, начинается процесс передачи данных.
На пятом этапе IPsec SA прекращают действовать. Их либо удаляют, либо истекает время жизни. При надобности продолжить передачу данных запускается вторая фаза IKE (если требуется, то и первая)

Внимательный читатель заметил, что мы не говорили об IPsec SA… Исправим это!

IPsec SA — это база IPsec. Без SA не существовало бы и IPsec.

SA (Security Association) — симплексный набор правил по отношению к трафику: что шифровать и как шифровать.

Теперь самый главный вопрос «Для чего и где это используется?», ответ на который нетривиальный.

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

А под конец вопрос.

Сколько раз в статье было использовано «IPsec»?
Всем добра!