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

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

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

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

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 # Устанавливает условие для запуска: система должна полностью загрузиться и быть готовой к работе

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

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

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

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

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

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

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

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

sudo systemctl daemon-reload

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

sudo systemctl enable copyparty

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

sudo systemctl start copyparty

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

sudo systemctl status copyparty

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

sudo journalctl -u copyparty.service

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

Всем добра!

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

Всем добра!

Ликбез

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

ansible localhost -m ansible.builtin.apt -a "name=apache2 state=present" -b -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.
Получается такой алгоритм:

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

Но все не так просто. Для 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:

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

Во первых, создайте переменные в своем хранилище кода. Например в 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

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

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

Всем добра!

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

Содержание:

• Устанавливаем Jenkins
• Начало работы с Jenkins
• Настройка Bandit
• Настройка агента Jenkins
• Собираем проект через агента

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

Мы выберем свободную конфигурацию и имя 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 говорит нам настроить агента:

Мы пойдем по длинному пути через кнопку «Настроить 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? При запросе в поисковиках вы получите скучный, но верный ответ «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

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

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

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

Всем добра!

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

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

Итак, в качестве примера мы возьмем оболочку 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 же реализован на сетевом уровне (network layer).

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

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

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

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

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

Первая фаза:

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

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

Вторая фаза:

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

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

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

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

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

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

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