Кибербезопасность на Python: от нуля до junior-скриптера за 4–6 месяцев

Введение в кибербезопасность, роли, законность и рабочая среда

Зачем кибербезопасность и где тут Python

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

Python в этом курсе нужен не для «написать вирус», а для того, чтобы:

автоматизировать повторяющиеся задачи

быстро разбирать данные (логи, JSON, CSV, текст)

интегрироваться с API (SIEM, EDR, облака, сканеры)

писать небольшие утилиты для диагностики, проверки и расследований

К концу курса целевая роль — junior-скриптер в безопасности: человек, который понимает базовые принципы, умеет работать в терминале и писать простые, надёжные скрипты под реальные задачи.

Базовая модель: что мы защищаем

Три свойства информации

В безопасности часто опираются на триаду CIA:

Confidentiality (конфиденциальность) — доступ к данным только у тех, кому можно

Integrity (целостность) — данные не изменены незаметно и не повреждены

Availability (доступность) — сервисы и данные доступны, когда нужны

Пример на пальцах:

утечка паролей — проблема конфиденциальности

подмена реквизитов в платёжке — проблема целостности

DDoS, из-за которого сайт «лежит» — проблема доступности

Активы, угрозы, уязвимости и риск

Чтобы говорить на одном языке, введём простые термины:

Актив — то, что имеет ценность (данные клиентов, сервер, домен, репозиторий)

Угроза — что может пойти не так (фишинг, вирус, инсайдер, ошибка администратора)

Уязвимость — слабое место (старый софт, слабый пароль, открытый порт, неверные права)

Риск — вероятность проблемы и её ущерб

Смысл работы в безопасности — снижать риск: закрывать уязвимости, уменьшать последствия, быстрее обнаруживать инциденты.

> “You can’t protect what you don’t know you have.” (Нельзя защитить то, о существовании чего вы не знаете.) — принцип инвентаризации активов, часто цитируется в контексте управления активами; как ориентир можно использовать рамку NIST CSF, где инвентаризация относится к функции Identify. NIST Cybersecurity Framework

Чем занимается специалист по безопасности

Основные направления

Профессии в кибербезопасности разнообразны, но их удобно группировать:

Защита (Blue Team): мониторинг, настройка защиты, реагирование

Атака/оценка (Red Team): проверка реальной стойкости и поиск слабых мест

Инженерия безопасности (AppSec/DevSecOps): встроить безопасность в разработку и инфраструктуру

Расследования (DFIR): форензика и реагирование на инциденты

Управление (GRC): политики, соответствие требованиям, риски

!Карта ролей и их взаимодействий

Роли, с которых часто стартуют

Ниже — роли, которые ближе всего к “junior-скриптеру” и куда реально целиться через 4–6 месяцев при дисциплине.

| Роль | Что делает | Где пригодится Python | |---|---|---| | SOC analyst (Junior) | смотрит алерты, триаж, первичная проверка | парсинг логов, обогащение IOC, отчёты | | Security analyst (Junior) | базовые проверки, контроль настроек, помощь команде | скрипты аудита, API-интеграции | | Junior AppSec | находит типовые уязвимости в веб-приложениях | автоматизация проверок, обработка результатов сканеров | | Junior DFIR assistant | помогает собирать артефакты и строить таймлайны | разбор артефактов, нормализация данных | | Junior Pentest assistant | выполняет типовые задачи по методологии и чек-листам | подготовка словарей, обработка вывода утилит |

Чтобы понимать, как думает атакующий и как строится защита, полезны общие базы знаний:

OWASP Top 10 — самые распространённые проблемы веб-безопасности

MITRE ATT&CK — техники злоумышленников и язык описания атак

CVE — публичные идентификаторы уязвимостей

Законность: что можно делать, а что нельзя

Главный принцип

В кибербезопасности законность определяется не “интересом” и не “пользой”, а разрешением.

Без явного разрешения нельзя:

сканировать чужие системы на уязвимости

подбирать пароли, эксплуатировать баги, перехватывать трафик

пытаться получить доступ к данным или аккаунтам

Даже “аккуратное сканирование портов” может считаться несанкционированным воздействием или подготовкой атаки — в зависимости от юрисдикции, обстоятельств и ущерба.

Как выглядит легальная работа

Легальная проверка (пентест/аудит) обычно имеет:

письменное разрешение владельца системы

scope (границы): какие IP/домены/приложения можно трогать

методы: что разрешено (например, без DoS, без социальной инженерии)

время проведения и контакт для экстренной остановки

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

На практике это часто оформляется как договор/заказ-наряд и Rules of Engagement.

Безопасная учебная политика в этом курсе

В рамках курса действуют правила:

тренируемся только на своих машинах, в лаборатории и на учебных стендах

не трогаем чужие сети, чужие сайты и чужие аккаунты

любые примеры атак рассматриваются как модели угроз и способы защиты

Если захочется практики на легальных площадках, можно использовать тренировочные платформы и CTF, где явно разрешено атаковать в пределах правил:

Hack The Box

TryHackMe

Рабочая среда: как мы будем учиться и работать

Почему важна лаборатория

Безопасность изучают через практику, но практика должна быть контролируемой. Лаборатория нужна, чтобы:

не сломать основную систему

не «вылететь» из-за эксперимента с зависимостями

делать снимки (snapshots) и быстро откатываться

!Минимальная схема домашней киберлаборатории

Рекомендуемый набор инструментов

Минимальный стек, который подходит новичку и востребован в вакансиях:

ОС для работы: Linux (Ubuntu) или Windows + WSL2

Виртуализация: VirtualBox

Язык: Python 3

Редактор: VS Code

Контроль версий: Git

Терминал: bash/zsh (в Linux/WSL)

Официальные источники:

Python

Документация Python

Visual Studio Code

Git

VirtualBox

Ubuntu

Kali Linux

WSL

Базовые правила гигиены рабочей среды

С самого начала привыкаем к практикам, которые ценятся на работе:

отделяйте учебную среду от личной: отдельная VM или WSL-дистрибутив

обновляйте систему и инструменты, но делайте снимок VM перед крупными изменениями

храните учебные скрипты в Git-репозиториях

не запускайте непонятные скрипты “с интернета” в основной системе

не используйте реальные пароли в учебных конфигурациях

Как будет устроена практика в курсе

Чтобы через 4–6 месяцев вы выглядели как junior-специалист, обучение будет идти по циклу:

изучаем концепт простыми словами

повторяем руками в терминале

автоматизируем то же самое небольшим Python-скриптом

оформляем результат как мини-инструмент: ввод, вывод, ошибки, логирование, README

В следующих материалах мы начнём с самого нуля: установка среды, терминал, основы Python, файлы и сети — и постепенно перейдём к типовым задачам безопасности.

Что важно запомнить после этой статьи

кибербезопасность — это снижение риска для активов, а не “взлом ради интереса”

роли разные, но почти везде ценится умение автоматизировать и работать с данными

законность определяется разрешением и границами работ, а не намерениями

безопасная лаборатория и дисциплина в инструментах — фундамент для быстрого прогресса

Python с нуля: синтаксис, типы данных, функции, файлы и ошибки

Как это связано с кибербезопасностью

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

читают логи и находят события по правилам

обрабатывают списки IP/доменов/хэшей

разбирают JSON/CSV, которые отдают системы мониторинга и API

формируют отчёты и результаты проверок

Python подходит, потому что он читаемый, быстро пишется и имеет мощную стандартную библиотеку.

Справочник по основам (официально): Учебник Python.

Базовый синтаксис: как “читать” Python-код

Отступы и блоки кода

Python использует отступы вместо фигурных скобок.

Правила, которые спасают новичков:

используйте 4 пробела на уровень отступа

не смешивайте табы и пробелы

после if, for, while, def, try ставится двоеточие :

Комментарии

Переменные и присваивание

Переменная появляется в момент присваивания.

В Python тип хранится у значения, а не “жёстко” у переменной.

Типы данных, которые вы будете использовать каждый день

Официальная справка: Встроенные типы данных.

Числа: int и float

Строки: str

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

Полезные операции:

конкатенация: "a" + "b"

проверка подстроки: "Failed" in message

приведение к нижнему регистру: message.lower()

разбиение: line.split()

удаление пробелов/переноса: line.strip()

Булевы значения: bool

В условиях Python считает “ложными” значения:

False

None

0, 0.0

пустые "", [], {}, set()

None

None означает “значения нет”. Часто встречается, когда функция ничего не нашла.

Коллекции

#### Список: list

Упорядоченная коллекция, можно менять.

#### Кортеж: tuple

Упорядоченная коллекция, обычно не меняют. Удобно хранить “пару/набор полей”.

#### Множество: set

Неупорядоченная коллекция уникальных значений. Хорошо для дедупликации.

#### Словарь: dict

Ключ → значение. В безопасности это основной формат для структурирования данных.

Преобразование типов

Часто нужно приводить строки к числам и обратно.

Если строка не является числом, int() вызовет ошибку. В конце статьи мы разберём, как это обрабатывать.

Управление логикой: условия и циклы

Условия: if / elif / else

Операторы сравнения:

== равно, != не равно

<, <=, >, >=

in принадлежность (например, подстрока в строке)

Цикл for

Чаще всего перебирают строки файла, список IOC, результаты API.

Цикл while

Нужен реже. Полезен, когда повторяем действие до условия (например, пока пользователь не введёт “quit”).

break и continue

break завершает цикл

continue пропускает текущую итерацию

Функции: делаем код повторяемым и удобным

Функции позволяют превращать “кусок логики” в инструмент, который можно переиспользовать.

Что важно:

def имя(): объявляет функцию

return возвращает значение

если return нет, функция возвращает None

Аргументы и значения по умолчанию

f"..." — f-строки для удобного форматирования.

Разделяем скрипт и библиотеку: if __name__ == "__main__"

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

Файлы: читаем логи и пишем результаты

В безопасности вы почти всегда работаете с файлами: логи, выгрузки, отчёты.

Официально:

Функция open

Модуль pathlib

Чтение текстового файла построчно

Самый безопасный и удобный способ — через контекстный менеджер with: файл закроется автоматически.

Пояснения:

encoding="utf-8" помогает корректно читать текст

errors="replace" не падает на “битых” символах, а заменяет их

strip() убирает пробелы и перенос строки

Запись в файл

Режимы:

"r" чтение

"w" перезапись

"a" дозапись

Мини-инструмент: посчитать “failed password” в логе

Ниже пример, который очень близок к реальным задачам junior-аналитика: быстро посчитать типовые события.

!Как устроен простой скрипт: входной лог → обработка → результат

JSON и CSV: самые частые форматы в автоматизации

Официально:

Модуль json

Модуль csv

#### Прочитать JSON

Обычно JSON превращается в комбинацию dict, list, str, int.

#### Записать CSV-отчёт

newline="" — стандартная рекомендация для корректной записи CSV на разных ОС.

Ошибки и исключения: как сделать скрипт надёжным

В реальной работе входные данные “грязные”: файла нет, формат сломан, строка неожиданная. Хороший junior-скриптер умеет:

понимать сообщения об ошибках

обрабатывать ожидаемые ошибки

не скрывать проблемы “молчанием”

Официально: Встроенные исключения.

Что такое исключение

Исключение — это сигнал, что выполнение не может продолжаться в текущем виде. Например:

FileNotFoundError — файла нет

PermissionError — нет прав

ValueError — не получилось преобразование (например, int("abc"))

KeyError — в словаре нет ключа

try / except: ловим ожидаемые ошибки

Важное правило: ловите конкретные исключения. Не делайте “поймать всё” без причины.

else и finally

else выполняется, если ошибки не было

finally выполняется всегда (удобно для “обязательно завершить действие”)

Когда стоит использовать raise

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

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

Практические привычки, которые полезны в безопасности

пишите маленькие функции, которые делают одну вещь

работайте со строками аккуратно: приводите к lower(), используйте strip()

не доверяйте входу: проверяйте формат и обрабатывайте ошибки

читайте файлы построчно для больших логов

храните результаты в понятных форматах: JSON или CSV

Что должно получаться после этой статьи

читать и писать простой Python-код с условиями, циклами и функциями

уверенно использовать базовые типы: str, int, bool, list, dict, set

читать логи из файла и формировать результат

понимать типовые ошибки и писать обработку исключений

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

Автоматизация в Linux: CLI, Bash-основы, процессы, права и сети

Зачем это junior-скриптеру по безопасности

В прошлых материалах вы:

разобрались, что кибербезопасность — это про снижение рисков и законность действий

начали писать простые Python-скрипты, которые читают файлы, обрабатывают строки и выдают результат

Теперь добавляем второй обязательный инструмент junior-специалиста: Linux и командную строку. В реальной работе вы часто:

подключаетесь к серверам по SSH и быстро проверяете состояние системы

фильтруете логи через пайплайны команд

запускаете утилиты, собираете их вывод в файл и затем анализируете Python-скриптом

проверяете сетевые соединения и слушающие порты

Важная идея курса: CLI и Bash помогают быстро «собрать данные», Python помогает «нормализовать и автоматизировать».

Что такое CLI, shell и почему именно Bash

CLI (command-line interface) — работа через команды в терминале.

Shell — программа, которая читает ваши команды и запускает другие программы.

Bash — один из самых распространённых shell на Linux.

Официальный справочник: Bash Reference Manual.

Навигация и базовые команды, которые нужны каждый день

Где я нахожусь и что вокруг

pwd показывает текущую директорию

ls -la показывает файлы и права (подробнее ниже)

cd меняет директорию

Чтение файлов и логов

less — лучший выбор для больших файлов: поиск /строка, выход q

tail -f — «подписка» на конец файла (полезно при расследованиях)

Поиск по содержимому: grep

-i игнорирует регистр

-n показывает номер строки

Справочник: grep(1) — Linux manual page.

Поиск файлов: find

Здесь появляется важная тема потоков вывода (разберём ниже): 2>/dev/null прячет ошибки доступа.

Справочник: find(1) — Linux manual page.

Пайплайны и перенаправления: фундамент автоматизации

Три потока: stdin, stdout, stderr

У большинства программ есть стандартные потоки:

stdin — откуда программа читает вход

stdout — куда пишет обычный вывод

stderr — куда пишет сообщения об ошибках

В Bash это выражается номерами:

0 — stdin

1 — stdout

2 — stderr

Пайплайн |

Пайплайн соединяет вывод одной команды со входом другой.

Чаще пишут короче (без cat):

Но пайплайны очень нужны, когда команд несколько:

!Как работает пайплайн и потоки ввода/вывода

Перенаправления > >> и отдельно для ошибок 2>

Записать вывод в файл (перезапись):

Дописать в файл:

Перенаправить ошибки:

Спрятать ошибки:

Код возврата (exit status) и логика && ||

Почти каждая команда возвращает код:

0 — успех

не 0 — ошибка/неуспех

Проверить код последней команды:

bash chmod +x count_failed.sh ./count_failed.sh /var/log/auth.log bash ps aux | head bash top bash kill <PID> bash kill -9 <PID> bash ls -l bash -rw-r----- 1 root adm 12345 Jan 1 12:00 auth.log bash ip a ip route bash ping -c 4 8.8.8.8 bash ss -tulpen bash getent hosts example.com bash sudo tcpdump -n -i any -c 20 bash ss -tulpen > sockets.txt ``

Дальше Python-скрипт может:

вытащить порт, протокол, процесс

оставить только подозрительные (например, неожиданные сервисы)

сформировать отчёт CSV

Это ровно тот уровень задач, который часто дают junior-скриптеру.

Что важно запомнить после этой статьи

CLI и пайплайны — быстрый способ собрать и отфильтровать данные

stdout и stderr нужно разделять, чтобы автоматизация была надёжной

exit status и связки &&/|| позволяют строить предсказуемые сценарии

права доступа и принцип минимальных привилегий важнее привычки «запускать всё через sudo»

базовые сетевые команды (ip, ss, getent`) — ежедневный минимум для диагностики

В следующих шагах курса вы начнёте совмещать: терминал для сбора артефактов и Python для анализа и отчётности, приближая ваши навыки к требованиям вакансий junior-уровня.

Сети для ИБ: TCP/IP, DNS, HTTP, сокеты и анализ трафика

Зачем это junior-скриптеру по безопасности

В прошлых статьях вы настроили рабочую среду, выучили базовый Python и освоили Linux-CLI. Следующий обязательный шаг для задач ИБ и автоматизации — понимание сети.

Практически любая работа в SOC, AppSec, DFIR или инфраструктурной безопасности упирается в вопросы:

куда и почему ходит процесс по сети

что означает “подключение установлено”, “соединение сброшено”, “таймаут”

какой DNS-ответ получила система и почему один и тот же домен резолвится по-разному

что именно отправлено по HTTP и какие заголовки важны

как корректно собрать трафик (PCAP) и извлечь из него факты для отчёта

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

Модель TCP/IP простыми словами

Сеть удобнее понимать слоями: каждый слой решает свою задачу и «опирается» на нижний.

!Упрощённая карта слоёв TCP/IP и примеры протоколов

Что где находится

Канальный уровень: доставляет данные внутри одной сети (например, Ethernet/Wi‑Fi).

Сетевой уровень: отвечает за маршрутизацию между сетями (протокол IP).

Транспортный уровень: доставка между процессами через порты (TCP/UDP).

Прикладной уровень: протоколы «для приложений» (DNS, HTTP, SSH и т.д.).

Официальный справочник по базовой архитектуре Интернета: RFC 1122.

IP-адреса и порты: “куда” и “в какой процесс”

IP-адрес

IP-адрес — это адрес узла в сети. На практике вы будете постоянно видеть:

IPv4: например, 192.168.1.10

IPv6: например, 2001:db8::1

Быстрые проверки в Linux:

Порт

Порт — это номер, который помогает доставить трафик в конкретный процесс на хосте (например, веб-сервер на 443).

Важные факты:

диапазон портов: 1..65535

TCP и UDP имеют отдельные пространства портов (TCP 53 и UDP 53 — это разные “сервисы” на уровне ОС)

многие протоколы имеют “типовые” порты (HTTP 80, HTTPS 443, DNS 53), но в реальности сервис может работать на любом

Смотреть слушающие порты и процессы (из предыдущей статьи):

TCP и UDP: что вы увидите в логах и трафике

TCP

TCP — протокол с установлением соединения и контролем доставки. Типичные свойства:

есть понятие соединения

есть подтверждения доставки и порядок

часто проще для приложений, но дороже по накладным расходам

С точки зрения ИБ это важно, потому что в расследовании вы часто видите события “подключился/отключился”, “RST”, “таймаут”, “повторная передача”.

Если хочется первоисточник по TCP: RFC 9293.

UDP

UDP — протокол без установления соединения. Типичные свойства:

нет гарантии доставки и порядка

меньше накладных расходов

широко используется для DNS, VoIP, телеметрии, некоторых VPN

Первое, что должен помнить junior:

“UDP-таймаут” или “UDP недоступен” часто выглядит как тишина (нет ответа), а не как явная ошибка

многие системы мониторинга и правила корреляции опираются на частоту и направление UDP-пакетов

DNS: как имя превращается в IP

DNS — это система, которая сопоставляет доменные имена с данными (чаще всего с IP).

Официальная основа DNS: RFC 1034 и RFC 1035.

Базовые термины

Резолвер — компонент на вашей машине, который делает запросы (обычно через настройки ОС).

Рекурсивный DNS-сервер — сервер провайдера/организации, который “ходит по миру” и возвращает итоговый ответ.

Авторитетный DNS-сервер — сервер, который “знает правду” про конкретную зону (например, example.com).

Типовые записи (records)

| Тип | Что означает | Пример | |---|---|---| | A | IPv4-адрес | example.com -> 93.184.216.34 | | AAAA | IPv6-адрес | example.com -> 2606:... | | CNAME | псевдоним на другое имя | www -> example.com | | MX | почтовые серверы домена | mx1.example.com | | TXT | текстовые данные (SPF, проверки) | v=spf1 ... |

Кэширование и TTL

DNS активно кэшируется. У ответа есть TTL (time to live) — сколько секунд его можно хранить в кэше.

Для ИБ это означает:

вы можете видеть разные IP для одного домена в разные моменты времени

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

при инциденте “вредоносный домен” нужно сохранить как минимум домен, тип записи, ответ и время

Как проверить резолвинг «как у системы»

Команда из предыдущего урока, полезная именно в расследованиях:

Она учитывает настройки системы, включая /etc/hosts и NSS.

HTTP: что происходит между клиентом и веб-приложением

HTTP — прикладной протокол “запрос-ответ”. Он лежит поверх TCP (обычно 80/443; для 443 — внутри TLS).

Спецификация HTTP/1.1: RFC 9110.

Структура запроса

Запрос состоит из:

метода (например, GET, POST)

пути (например, /login)

заголовков (например, Host, User-Agent, Authorization)

иногда тела (body), чаще в POST/PUT/PATCH

Пример “сырого” запроса (упрощённо):

Структура ответа

Ответ содержит:

статус-код (например, 200, 301, 401, 404, 500)

заголовки (например, Content-Type, Set-Cookie)

тело (HTML/JSON/файл)

Полезные статусы для ИБ и диагностики:

| Код | Смысл | Частый контекст | |---|---|---| | 200 | OK | запрос успешен | | 301/302 | Redirect | редиректы, иногда фишинг/перенаправления | | 401 | Unauthorized | нет/неверная аутентификация | | 403 | Forbidden | доступ запрещён (есть аутентификация, но нет прав) | | 404 | Not Found | ресурс не найден (иногда маскировка) | | 429 | Too Many Requests | сработал лимит (rate limit) | | 500 | Server Error | ошибки приложения |

HTTPS и TLS: что важно знать на базовом уровне

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

содержимое HTTP в TLS не видно в простом сниффере без ключей/прокси

метаданные всё равно видны: IP, порт, время, объём, иногда SNI

Официальное описание TLS 1.3: RFC 8446.

Сокеты: как приложения “разговаривают” через сеть

Сокет — это интерфейс операционной системы для сетевого обмена. Приложение обычно делает так:

сервер: bind (привязаться к адресу/порту) → listen (слушать) → accept (принять соединение)

клиент: connect (подключиться) → send/recv (обмен данными)

В Python это реализовано модулем socket: Документация socket.

Почему сокеты важны в ИБ

многие агенты/боты/утилиты общаются напрямую через сокеты

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

вы начнёте лучше понимать, что именно показывают ss, tcpdump, логи прокси и фаервола

Практика в лаборатории: TCP-клиент и сервер на localhost

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

TCP echo-сервер (принимает строку и возвращает назад)

Запуск:

Проверка, что порт слушается:

TCP клиент с таймаутом и обработкой ошибок

Связь с предыдущими уроками:

таймауты и ошибки здесь — это те же исключения, которые вы уже умеете обрабатывать в Python

вы можете логировать результат в файл и дальше разбирать его (например, CSV/JSON)

Что такое “баннер” и почему он полезен

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

Но важно помнить:

баннер может быть поддельным

отсутствие баннера ничего не доказывает

чтение баннера без разрешения на чужих системах — плохая практика

Анализ трафика: что можно увидеть и чем это собирать

PCAP и зачем он нужен

PCAP — файл захвата пакетов. Его ценность в том, что он сохраняет “сырой факт” сетевого обмена, который можно:

перепроверить

показать коллегам

приложить к отчёту

проанализировать позже другими инструментами

tcpdump: базовый сбор трафика в Linux

Официальная документация: tcpdump manual.

Минимальный безопасный старт в лаборатории:

Полезные флаги:

-n не резолвить имена (быстрее и меньше «шума»)

-i any слушать все интерфейсы (удобно в VM/WSL)

-c ограничить количество пакетов

Запись в PCAP:

Фильтры (BPF-фильтры) для начинающих:

только DNS: udp port 53

только HTTP: tcp port 80

только конкретный хост: host 127.0.0.1

только конкретный порт: tcp port 9000

Пример для echo-сервера из этого урока:

Wireshark: “микроскоп” для PCAP

Wireshark удобен для визуального анализа PCAP и декодирования протоколов.

Официальный сайт: Wireshark.

Что реально нужно junior на старте:

уметь открыть PCAP и найти нужный поток

применять простые фильтры отображения (по IP, порту, протоколу)

извлекать из трафика факты: кто с кем общался, когда, по какому протоколу

Что именно фиксировать при сетевом инциденте

Чтобы ваш сбор данных был полезен для команды, фиксируйте минимум:

время (с таймзоной)

источник и назначение: IP:порт → IP:порт

протокол (TCP/UDP) и приложение (DNS/HTTP/SSH — если известно)

артефакт (PCAP или лог) и как он был получен

Это напрямую перекликается с моделью “активы/угрозы/риск” из первой статьи: вы сохраняете проверяемые факты, чтобы снизить риск неверных выводов.

Типовой рабочий пайплайн: собрать в CLI → разобрать в Python

Ниже схема “как делают на работе” на уровне junior.

собрать данные командой и сохранить в файл

разобрать файл Python-скриптом и сделать отчёт

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

Что важно запомнить после этой статьи

TCP/IP удобно понимать слоями: приложение (DNS/HTTP) поверх транспорта (TCP/UDP) поверх IP

IP отвечает за “куда”, порт отвечает за “в какой процесс”

DNS часто даёт ключ к расследованию: домен → ответы → время → TTL/кэш

HTTP — это методы, заголовки и статусы; HTTPS шифрует содержимое, но не скрывает всё

сокеты в Python — ваш базовый инструмент для сетевой диагностики и небольших утилит

tcpdump и PCAP — способ сохранить проверяемые факты, а Python поможет их агрегировать и оформлять

Парсинг и анализ данных: логи, regex, JSON/CSV, основы SIEM-подхода

Зачем junior-скриптеру уметь парсить данные

В прошлых статьях вы освоили базовый Python, научились работать в Linux-терминале и разобрались с сетями. Теперь логичный шаг к «рабочим» задачам: научиться превращать сырые логи и выгрузки в структурированные события, которые можно агрегировать, коррелировать и превращать в отчёты.

Практически в любой роли (SOC, DFIR, инфраструктурная безопасность, AppSec) вы регулярно делаете одно и то же:

берёте данные из логов или API

выделяете из них поля (IP, пользователь, действие, статус)

приводите их к единому виду

считаете метрики, находите аномалии, готовите отчёт

Это и есть основа «SIEM-подхода» на уровне junior: сбор → разбор → нормализация → обогащение → правила/корреляции → результат.

!Общая схема SIEM-подхода: как сырые данные превращаются в алерты и отчёты

Что такое лог, запись, событие и почему важна структура

Лог и запись

Лог — это файл (или поток), куда система/приложение пишет сообщения о происходящем.

Запись лога — обычно одна строка (но иногда событие занимает несколько строк, например stack trace в приложениях).

Событие

Событие в нашем смысле — это запись, превращённая в структуру (обычно dict в Python), где данные разложены по полям.

Пример:

сырая строка: Failed password for invalid user admin from 203.0.113.10 port 51822 ssh2

событие: { "action": "login_failed", "user": "admin", "src_ip": "203.0.113.10", "src_port": 51822, "app": "ssh" }

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

Неструктурированные: обычный текст, где поля нужно «выковыривать» (типично для многих системных логов).

Полуструктурированные: текст, но с понятным форматом (например, key=value).

Структурированные: JSON/CSV, где поля уже выделены.

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

Какой формат логов встречается чаще всего

Syslog как типовой «стиль» системных логов

Во многих Linux-системах события пишутся в стиле syslog: там обычно есть время, хост, имя процесса и текст.

Спецификация syslog-протокола: RFC 5424.

Важно понимать практическую вещь: даже если транспорт syslog стандартный, формат сообщения часто “как получится”. Поэтому парсинг почти всегда начинается с поиска регулярным выражением.

Типовые источники для junior-задач

auth.log / secure: входы, ошибки аутентификации, sudo, sshd

web access logs (Nginx/Apache): HTTP методы, пути, статусы, User-Agent

DNS логи: домен, тип записи, ответ

выгрузки из систем в JSON/CSV

Принципы хорошего парсинга для безопасности

Чтобы скрипт был полезен на работе, придерживайтесь принципов:

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

Нормализуйте поля: один смысл — одно имя поля (например, везде src_ip, а не то ip, то remote_addr).

Делайте время явным: по возможности приводите к ISO-формату и фиксируйте таймзону.

Старайтесь не падать на “грязных” данных: лучше пропустить строку и записать причину.

Минимум секретов: не логируйте пароли, токены, cookie.

Регулярные выражения: ваш главный инструмент для логов

Модуль Python: re — Regular expression operations.

Что такое regex простыми словами

Регулярное выражение — это шаблон, который описывает, как найти нужные куски текста.

Частые элементы:

. любой символ

\d цифра

\s пробельный символ

+ один или больше

* ноль или больше

? ноль или один

(...) группа

(?P<name>...) именованная группа (очень удобно для парсинга в dict)

В Python почти всегда стоит использовать сырой литерал строки r"...", чтобы не путаться с экранированием \.

search, match и finditer

re.match() ищет совпадение только в начале строки.

re.search() ищет где угодно в строке.

re.finditer() находит все совпадения и отдаёт их итератором.

Для логов чаще всего подходит search() или заранее “якорённый” паттерн с ^ в начале.

Компиляция паттерна

Если вы обрабатываете тысячи строк, лучше один раз скомпилировать regex:

Это делает код быстрее и аккуратнее (паттерн видно сразу, его проще поддерживать).

Практика: парсим строки из auth.log в события

Ниже пример, максимально приближенный к задачам junior SOC: вытащить из sshd события неуспешного входа и собрать статистику по IP.

Пример типовой строки

В auth.log можно встретить (варианты зависят от системы):

Задача: выделить время, пользователя, IP, порт.

Regex с именованными группами

Что здесь важно для практики:

raw помогает отлаживать парсер и доказывать, что именно было в исходных данных.

Поля названы в стиле “похожем на SIEM”: source.ip, user.name, event.action.

datetime.strptime() используется, чтобы превратить строку времени в объект времени и дальше получить ISO-формат.

Документация по времени: datetime — Basic date and time types.

Почему “похожий на SIEM” нейминг полезен

На практике данные часто надо склеивать из разных источников. Если в одном месте у вас ip, в другом src, в третьем remote_addr, то корреляция усложняется.

В индустрии часто используют готовые схемы нормализации. Один из примеров: Elastic Common Schema.

Вам не нужно учить ECS целиком, но полезно привыкнуть к идее:

есть общий словарь полей

новые источники приводятся к этому словарю

правила и отчёты становятся переиспользуемыми

!Зачем нормализация: разные источники приводим к одному набору полей

Агрегация: считаем “топ IP” и делаем отчёт

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

Пример: подсчёт неуспешных логинов по IP

Здесь вы применяете то, что уже проходили:

итерация по файлу

словари и списки

надёжная обработка данных

JSON на практике: обычный JSON и JSON Lines

Документация: json — JSON encoder and decoder.

Обычный JSON

Обычный JSON — это один документ целиком (часто список объектов).

JSON Lines (JSONL)

В логах и потоках часто используют формат JSON Lines, где каждая строка — отдельный JSON-объект. Это удобно, потому что файл можно читать построчно, как обычный лог.

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

CSV: быстрые отчёты для людей и тикетов

Документация: csv — CSV File Reading and Writing.

CSV часто нужен, потому что:

его легко открыть в Excel/Google Sheets

его любят менеджеры и аудиторы

его удобно прикладывать к тикету

Запись CSV-отчёта

Практическая привычка: фиксируйте поле с временем, если отчёт про события. Если вы считаете агрегаты, добавляйте from/to (интервал), чтобы отчёт был воспроизводим.

Основы SIEM-подхода без привязки к конкретному продукту

SIEM (Security Information and Event Management) в продуктовой форме обычно умеет:

собирать события

парсить/нормализовать

хранить и искать

строить правила корреляции

выдавать алерты и отчёты

В рамках обучения нам важна логика (что делает SIEM), а не конкретный UI.

Минимальная модель события для корреляции

Чтобы по событиям можно было делать правила, обычно нужны:

@timestamp: когда произошло

event.action: что случилось (например, login_failed)

host.name или observer.name: где произошло

source.ip и иногда destination.ip: кто с кем

user.name: если есть пользователь

event.outcome: успех/неуспех (если применимо)

Если этих полей нет, правила становятся “хрупкими”: много ложных срабатываний или пропуски.

Обогащение

Обогащение — это добавление контекста к событию. Примеры:

IP → страна/ASN

домен → результаты DNS

хэш → данные из threat intel

На junior-уровне важно понимать идею: сырые факты + контекст = более точные выводы. Реализовывать полноценный threat intel мы будем позже, когда освоим API.

Корреляция на уровне здравого смысла

Корреляция — это когда вы связываете несколько событий, чтобы получить более сильный сигнал.

Примеры простых правил (без “магии”):

много login_failed с одного source.ip за короткое время

один user.name ошибается на многих хостах

после серии неуспехов появился login_success с того же IP

На данном этапе курса достаточно научиться делать основу: качественный парсинг + нормализация + агрегация.

Типовые ошибки при парсинге (и как их избегать)

Regex “съедает” лишнее: используйте границы \b, якоря ^/$, проверяйте на нескольких примерах.

Разные варианты строки: у одного события могут быть разные формулировки. Делайте несколько паттернов или допускайте опциональные части ( ... )?.

Непредсказуемое время: фиксируйте год/таймзону; сохраняйте исходный timestamp строкой, если не уверены.

Падение на одной строке: оборачивайте парсинг в try/except, но не “глотайте” ошибку молча — пишите причину в отдельный файл.

Слишком большой файл: обрабатывайте построчно и не держите всё в памяти, если это не нужно.

Что должно получаться после этой статьи

объяснить разницу между лог-строкой и событием

написать regex с именованными группами и превратить строку в dict

обработать файл построчно и собрать агрегаты (например, топ IP)

читать JSON и JSONL, писать CSV-отчёты

понимать базовую SIEM-логику: парсинг, нормализация, обогащение, корреляция

Скрипты для ИБ: сканеры, OSINT, проверки, уведомления и отчёты

Зачем нужны «скрипты для ИБ» и как это связано с предыдущими темами

Вы уже умеете:

писать базовые Python-скрипты (типы данных, функции, файлы, ошибки)

работать в Linux CLI и собирать данные командами

понимать основы сети (TCP/UDP, DNS, HTTP, сокеты)

парсить логи и превращать строки в события, делать отчёты CSV/JSON

Теперь мы соединяем всё это в типовые рабочие мини-инструменты, которые часто поручают junior-уровню:

сканеры и проверки доступности (для своей инфраструктуры и только в разрешённом периметре)

OSINT-обогащение (добавить к IP/домену открытые данные из публичных источников)

проверки (простые контроли: «что слушает порты», «какие права у файлов», «что изменилось»)

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

отчёты (CSV/JSONL для тикетов и команды)

Ключевая идея: вы строите небольшой конвейер сбор → нормализация → обогащение → вывод (отчёт/уведомление).

!Концептуальная карта, как собрать данные, привести к событиям, обогатить, проверить и выпустить результат.

Законность и безопасные границы

Сканирование и проверки легко переходят грань «диагностика» → «несанкционированное воздействие». В рамках курса правило простое:

работаем только в своей лаборатории, на своих VM, или в инфраструктуре, где у вас есть явное разрешение

заранее фиксируем scope (что именно можно проверять): IP/домены, порты, время, методы

не делаем DoS-нагрузку, не подбираем пароли, не эксплуатируем уязвимости

Если сомневаетесь, можно ли проверять цель, ответ по умолчанию: нельзя.

Что такое сканер в контексте junior-скриптера

Под «сканером» на junior-уровне мы будем понимать не «поиск уязвимостей», а безопасные вещи:

проверка доступности TCP-порта (TCP connect check)

инвентаризация: какие сервисы «отвечают» на каких портах внутри разрешённой сети

измерение времени ответа и фиксация ошибок (timeout, refused)

сбор результатов в машиночитаемом виде (JSONL/CSV)

Почему это важно:

вы быстро подтверждаете факты для команды (например, «порт 443 на хосте X недоступен из подсети Y»)

вы автоматизируете регулярные проверки (например, nightly check стендов)

вы учитесь писать сетевой код с таймаутами и обработкой ошибок

Мини-инструмент: TCP-проверка портов с таймаутом и отчётом

Ниже скрипт, который:

принимает --host и список портов --ports

делает безопасную попытку TCP-подключения

сохраняет результаты в JSON Lines (по одной записи на строку)

JSONL удобен тем, что его можно писать и читать построчно, как лог.

Запуск в лаборатории:

Что здесь «по-рабочему» важно:

есть таймаут, иначе скрипт может «висеть»

ошибки нормализованы в короткие значения (timeout, connection_refused)

результат структурирован как события (поля похожи на SIEM-стиль)

Ускорение и аккуратность: параллельные проверки и лимиты

Если целей/портов много, последовательная проверка будет медленной. На junior-уровне часто применяют concurrent.futures.

Документация: Модуль concurrent.futures.

Ниже фрагмент, как распараллелить без агрессивного шума:

ограничить число потоков

не ставить нулевые таймауты

не делать бесконечные ретраи

Практическое правило: чем менее вы уверены в разрешении и устойчивости цели, тем меньше должны быть workers и тем строже должен быть scope.

OSINT на практике: что это и как использовать безопасно

OSINT (Open-source intelligence) — это получение информации из открытых источников. В ИБ OSINT часто используют для обогащения индикаторов (например, IP или домена) контекстом.

Справка: Open-source intelligence.

Важно:

OSINT не означает «истина»; это подсказки и контекст

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

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

RDAP как безопасный OSINT-источник для IP

RDAP (Registration Data Access Protocol) позволяет получать регистрационные данные (похоже на WHOIS, но в современном виде) по IP и доменам.

Спецификация: RFC 7483.

Для обучения удобно использовать публичный агрегатор rdap.org, который отдаёт JSON по HTTPS.

Ниже функция, которая:

делает запрос по IP

возвращает минимум полей

не падает, если сервис недоступен

Это можно применять как обогащение к вашим событиям tcp_check: если порт «открыт» и IP внешний, добавить сведения о владельце диапазона.

Проверки на хосте: связка Linux CLI → Python → отчёт

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

Пример задачи: собрать слушающие порты на локальной машине (в лаборатории) и сохранить структурированно.

Сбор командой ss

Нормализация в Python через subprocess

Документация: Модуль subprocess.

Почему мы пока сохраняем строку в raw, а не делаем идеальный парсер:

формат ss может отличаться по ОС и версии

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

Уведомления: как «донести результат» до команды

В реальной работе ценность не в том, что вы собрали данные, а в том, что вы:

выделили главное

оформили в удобный формат

доставили адресату

Типовые каналы уведомлений:

email

мессенджеры (webhook)

тикет-системы (через API)

На junior-уровне достаточно уметь делать хотя бы один канал. Ниже пример email через стандартную библиотеку.

Документация: Модуль smtplib.

Важно для безопасности:

не храните пароли/токены прямо в коде

используйте переменные окружения или отдельный конфиг-файл с ограниченными правами

логируйте факт отправки, но не логируйте секреты

Отчёты: что обычно ждут от junior

Отчёт — это не «много текста», а воспроизводимый результат, который можно открыть и проверить. На практике чаще всего просят:

CSV с агрегатами (топ IP, количество ошибок, список хостов)

JSONL с событиями (для дальнейшей загрузки или повторного анализа)

Вы уже умеете CSV/JSON из предыдущих тем. Здесь важно закрепить привычку:

добавляйте интервал или время сборки (когда получили данные)

сохраняйте raw, если парсинг не идеален

нормализуйте имена ключей, чтобы разные источники склеивались проще

Практический шаблон «junior-утилиты»

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

argparse для параметров и --help

таймауты для сети

обработка ожидаемых ошибок (файл не найден, таймаут, отказ)

вывод в JSONL или CSV

аккуратные поля события: @timestamp, event.action, event.outcome, source./destination.

соблюдение законности: не запускать вне разрешённого scope

Документация: Модуль argparse.

Что должно получаться после этой статьи

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

писать безопасные сетевые проверки на сокетах с таймаутами и нормализованными ошибками

делать простое OSINT-обогащение IP через RDAP и фиксировать источник данных

собирать данные CLI-командами и превращать их в JSONL-события

понимать, как оформить результат в отчёт и как отправить уведомление

Портфолио и трудоустройство: проекты, Git, резюме, собеседования, задачи

Зачем портфолио junior-скриптеру по ИБ

К этому моменту курса вы уже умеете:

писать Python-скрипты с обработкой ошибок, файлами, JSON/CSV

работать в Linux CLI, собирать артефакты и запускать утилиты

понимать основы сети (TCP/UDP, DNS, HTTP) и делать сетевые проверки через сокеты

парсить логи через regex, нормализовать события и делать отчёты

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

Рынок часто нанимает не за «знания в голове», а за комбинацию:

понятные артефакты в Git

адекватная инженерная дисциплина (ввод, вывод, ошибки, логирование, документация)

уважение к законности и границам проверки

!Схема, как навыки курса превращаются в портфолио и шаги найма

Каким должно быть портфолио для цели «junior-скриптер»

Портфолио junior-уровня не обязано быть большим. Оно обязано быть:

рабочим: запускается по инструкции

понятным: видно, что делает скрипт и зачем

безопасным: нет секретов, нет вредных действий, есть упоминание scope

проверяемым: есть примеры входных данных и примеры выхода

Минимальный стандарт качества репозитория

Лучше иметь 3 сильных репозитория, чем 12 «набросков». Для каждого проекта стремитесь к одному и тому же каркасу.

#### Что должно быть в репозитории

README.md

исходники в папке src/ или в корне

requirements.txt или pyproject.toml (если используете зависимости)

пример входных данных в data/ или генератор тестовых данных

пример выхода в examples/ или прямо в README

.gitignore

лицензия по желанию (часто используют MIT)

Справка по Git: Git Documentation.

#### Что обязательно описать в README

Сделайте README таким, чтобы рекрутер или тимлид мог запустить проект за 3–5 минут.

Что делает инструмент

Для кого и в каком сценарии полезен

Ограничения и законность: что можно и что нельзя проверять

Установка:

Документация по venv: venv — Creation of virtual environments.

Запуск:

Пример входа и выхода: 5–15 строк примера и 5–15 строк результата

Формат результата: какие поля пишете в JSONL/CSV

Как обрабатываются ошибки: что будет, если файл не найден, таймаут, неверный формат

Git как часть вашей «профпригодности»

На junior-позициях Git почти всегда подразумевается как базовый рабочий навык.

#### Практика коммитов

Хорошие привычки:

коммитить маленькими логическими кусками

писать сообщения так, чтобы было ясно, что изменилось

не смешивать «рефакторинг» и «фичу» в одном коммите

Пример простого стиля сообщений:

Add JSONL writer

Handle FileNotFoundError in parser

Update README with examples

#### Ветки и Pull Request

Даже в одиночных проектах полезно иногда работать через ветку и PR:

вы привыкаете к реальному командному процессу

удобнее показывать изменения

проще оставлять себе заметки в описании PR

Гайд от GitHub: GitHub Docs.

#### Секреты и «гигиена» репозитория

Никогда не коммитьте:

пароли

токены API

приватные ключи

реальные клиентские логи

Если нужно конфигурирование, используйте:

переменные окружения

файл .env (но сам файл добавьте в .gitignore)

config.example.ini или config.example.json с фейковыми значениями

Проекты, которые хорошо продают вас как junior-скриптера

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

Проект: парсер auth.log → события JSONL → отчёт CSV

Что показывает:

файловая обработка больших логов построчно

regex с именованными группами

нормализация полей под SIEM-подход

агрегация через Counter

Минимальный функционал:

вход: путь к auth.log

выход 1: events.jsonl (одно событие на строку)

выход 2: top_ips.csv (топ IP по login_failed)

Полезно добавить:

--year для syslog-строк без года

файл bad_lines.log, куда складываются строки, которые не распарсились, с причиной

Проект: безопасная TCP-проверка портов в разрешённом scope

Что показывает:

работа с сетью через сокеты

таймауты, нормализованные ошибки

параллелизм с ограничением нагрузки

Минимальный функционал:

вход: --host, --ports, --timeout

выход: scan_results.jsonl

поля событий в стиле destination.ip, destination.port, event.outcome, error.type

Важно для README:

явно написать, что это диагностика доступности, а не поиск уязвимостей

указать, что применять только в своей лаборатории или с разрешением

Проект: OSINT-обогащение IP через RDAP

Что показывает:

HTTP-запросы стандартной библиотекой

обработка ошибок сети

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

Минимальный функционал:

вход: список IP (файл или аргумент)

выход: JSONL с rdap.ok, rdap.name, rdap.handle, rdap.source

Спецификация RDAP: RFC 7483.

Проект: снимок слушающих портов ss → JSONL

Что показывает:

связку Linux CLI → Python через subprocess

сохранение артефактов в структурированном виде

привычку сохранять raw для воспроизводимости

Документация по subprocess: subprocess — Subprocess management.

Как оформить код, чтобы он выглядел «по-рабочему»

CLI-интерфейс и --help

Для портфолио крайне желательно, чтобы любой инструмент был CLI-утилитой, а не «скриптом, где нужно править переменные в коде».

Используйте argparse:

--input, --out

--timeout

--format jsonl|csv

--limit для топов

Документация: argparse — Parser for command-line options, arguments and sub-commands.

Логирование вместо хаотичных print

print допустим в учебных примерах, но в портфолио лучше хотя бы в одном проекте показать logging:

уровень INFO для прогресса

уровень WARNING для пропусков строк

уровень ERROR для критических ошибок

Документация: logging — Logging facility for Python.

Стиль кода

Не нужно идеального «enterprise». Нужно базово читабельно:

понятные имена

небольшие функции

аккуратная обработка ошибок

Рекомендации по стилю: PEP 8.

Тестовые данные

Если ваш проект про парсинг логов, приложите в data/ небольшой фрагмент лога с фейковыми IP и пользователями.

Для IP удобно использовать документационные диапазоны:

192.0.2.0/24

198.51.100.0/24

203.0.113.0/24

Источник: RFC 5737.

Резюме под junior-скриптера по ИБ

Резюме должно за 20–40 секунд объяснять:

какая роль вам нужна

что вы умеете делать руками

где это видно в Git

Рекомендуемая структура

заголовок: Junior Security Automation / Junior SOC (Python)

3–5 строк summary: Python, Linux, сети, парсинг логов, отчёты

навыки списком: Python, Linux, Git, regex, JSON/CSV, sockets, subprocess, основы TCP/IP, DNS, HTTP

проекты: 3–5 штук, каждый с ссылкой на репозиторий

опыт (если не ИБ): выделите релевантное, например работа с регламентами, поддержка пользователей, администрирование

Как писать пункты про проекты

Хороший пункт:

начинается с действия

говорит, что именно сделано

говорит, какой результат на выходе

по возможности содержит измеримый масштаб

Пример формулировки:

«Написал парсер auth.log (regex) → события JSONL, построил отчёт CSV топ-10 IP по неуспешным входам; обработка ошибок и сохранение raw-строк для воспроизводимости»

Плохой пункт:

«Изучал Python и кибербезопасность»

Профиль GitHub и публичный образ

Что улучшает впечатление за 5 минут просмотра

закрепите лучшие репозитории в профиле

у каждого репозитория понятное описание и темы

в README есть «как запустить» и пример вывода

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

Что портит впечатление

репозиторий не запускается по инструкции

нет примеров данных, непонятно, как проверить

код сканирует «весь интернет» или выглядит как попытка «взлома»

в истории коммитов попадаются секреты или настоящие логи

Собеседования: что реально спрашивают junior-уровню

На собеседованиях по направлению «скрипты/автоматизация для ИБ» часто проверяют не «хитрые атаки», а базовую инженерную и аналитическую компетенцию.

Python

разница между list, set, dict и когда что использовать

чтение файла построчно и обработка ошибок

простые функции, чистый код, if __name__ == "__main__"

работа с JSON/CSV

Официальная документация: The Python Tutorial.

Linux

пайплайны, grep, перенаправления, коды возврата

права доступа и почему sudo не «решение всех проблем»

диагностика сети через ip, ss, getent

Сети

разница TCP и UDP на уровне поведения

что такое DNS и почему кэш важен

что означает timeout и connection refused

Логи и парсинг

как вы будете извлекать поля из строки

как хранить события (JSONL)

как сделать отчёт для тикета (CSV)

Мышление безопасности

как вы определяете разрешённый scope

как избегаете утечек данных в логах и репозиториях

как формулируете ограничения инструмента

Типовые тестовые и практические задачи

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

Парсинг

дан лог-файл, нужно извлечь IP/время/пользователя, посчитать статистику

требуется поддержка нескольких форматов строк

нужно не падать на «грязных» строках

Сетевые проверки

проверить доступность набора портов

сделать таймауты, ограничить параллелизм

записать результат в JSONL

Автоматизация через CLI

вызвать утилиту (ss, tcpdump, journalctl) и обработать вывод

сделать отчёт и понятное сообщение об ошибке

Мини-расследование

по нескольким артефактам (лог, список IP, дамп вывода команды) собрать краткое резюме: что произошло и почему вы так считаете

Как готовиться к тестовому заданию и как его сдавать

сначала уточните вводные: формат входа, формат выхода, ограничения по времени

зафиксируйте допущения в README.md

сделайте минимально рабочую версию

добавьте обработку ошибок и понятные сообщения

добавьте пример входа и пример выхода

проверьте запуск в чистом окружении через venv

Что обычно оценивают:

корректность

читаемость

надёжность (таймауты, исключения)

форматирование результата

способность объяснить решения

План на последние 3–5 недель курса, чтобы выйти на рынок

выберите 3 проекта из списка выше

выделите по 2–3 сессии на проект: минимальная версия, улучшения, оформление

оформите резюме и профиль GitHub

пройдите 5–10 пробных задач по парсингу и CLI, фиксируя решения в отдельных репозиториях или папках

начните откликаться параллельно: это часть процесса обучения

Финальный чек-лист перед откликами

есть 3 репозитория, которые запускаются по README

в каждом проекте есть пример данных и пример результата

в коде нет секретов и реальных логов

инструменты явно описывают ограничения и scope

резюме содержит ссылки на проекты и отражает навыки курса

вы можете за 2–3 минуты голосом объяснить каждый проект: что делает, какие входы, какие выходы, какие ошибки, какие ограничения