Всем привет! Данное руководство поможет вам установить централизованное логирование событий на основе Graylog версии 4.2.1 (на момент написания статьи). Использовать мы будем операционную систему AlmaLinux 8.5 (альтернатива CentOS 8 от Red Hat). В процессе установки Graylog, мы рассмотрим первоначальную настройку сервера, настройку правил файрвола, а также использование NGINX в качестве обратного прокси серверу Graylog’а.

Вводные данные:

1. Свежеустановленный сервер на базе AlmaLinux release 8.5 (Arctic Sphynx);

2. 8 CPUs, 15 GB RAM и раздел подкачки размером 4 GB;

3. Graylog будет доступен по адресу https://logs.example.com

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

Напишем небольшой скрипт для этого:

В этой статье мы рассмотрим, как настроить реестр образов GitLab Container Registry, находящийся за обратным прокси сервером NGINX. Предполагается, что у вас уже установлен GitLab с помощью пакета Omnibus. Согласно документации, Container Registry можно настроить на том же домене, на котором работает сам GitLab, но в случае работы GitLab за прокси сервером, необходимо завести отдельный домен для реестра образов, чтобы избежать конфликта доменных имен при настройке виртуальных хостов в GitLab Nginx.

Реестр образов будет доступен по адресу: registry.example.com. Добавляем А запись для домена реестра в DNS. Приводим конфиг виртуального хоста на сервере обратного прокси к следующему виду:

Хочу поделиться информацией по поднятию прозрачного HTTP и HTTPS прокси сервера Squid с фильтрацией сайтов и без подмены сертификатов на FreeBSD 13.0 RELEASE. На Хабре уже есть похожая статья по настройке прозрачного прокси сервера Squid с фильтрацией ресурсов и без подмены сертификатов на Linux. Решил актуализировать информацию на свежо установленной ОС FreeBSD 13.0 и поделиться с вами.

При использовании действий «peek-and-splice», сквид выдергивает имя ресурса с помощью SNI и клиент дальше работает с ресурсом. Т.е. не происходит подмена сертификата. Этот режим подходит для нашего прозрачного прокси.

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

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

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

Контейнеризация — эффективный способ виртуализации на уровне ядра ОС. В системах контейнеризации гипервизора нет, но есть Container Engine, который создаёт контейнеры и управляет ими. В качестве движка контейнеризации мы будем использовать Podman.

Почему не Docker?

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

Большинство традиционных сетей контейнеров обрабатываются мостами bridge, преобразованием сетевых адресов (NAT) или путем привязки к сети хоста. Если вы хотите, чтобы ваши контейнеры выглядели как физические хосты в вашей сети и каждый с уникальным MAC-адресом, то самый простой способ — это использовать плагины macvlan и dhcp, которые поставляются с пакетом containernetworking-plugins.

В данном туториале мы рассмотрим, как быстро развернуть LEMP-стэк на виртуальный сервер VPS, используя технологию контейнеризации на базе Docker для сайта под управлением CMS DataLife Engine (DLE).

Kinsing — вредоносное ПО на основе Golang, работает как агент. Основная цель данной малвари это добыча криптовалюты на взломанном сервере. Оно распространяется путем использования уязвимости в ошибке конфигурации сервисов, которые доступны извне.

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

Как определить, что ваш сервер используется для майнинга малварью Kinsing?

Определите процессы, которые используют ресурсы процессора с помощью диспечера задач top или htop. В результате вы увидете, например, такие процессы: kdevtmpfsi, kinsing или dbused, которые максимально используют все ресурсы процессора.

Убить процессы отправкой сигнала KILL вы не сможете, так как со временем они запустятся снова.

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