Каких только top-ов в Linux нет. Встречайте ещё один, про который большинство скорее всего не слышали - dnstop. Живёт в базовых репах:

# apt install dnstop

Пригодится в основном на локальном dns сервере, но не обязательно только там. С помощью dnstop можно в режиме реального времени смотреть статистику dns запросов, как приходящих на сервер, так и исходящих от него самого.

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

# dnstop eth0

Если хотите сразу исключить локальные запросы сервера, то исключите его IP адрес с помощью ключа -i:

# dnstop eth0 -i 10.20.1.2

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

◽ s - таблица source address, экран по умолчанию после запуска
◽ d - таблица destination address
◽ t - статистика по типам запросов
◽ r - таблица кодов ответов
◽ @ - таблица source + адреса доменов 2-го уровня в запросе

Это не все горячие клавиши. Я перечислил только те, что показались полезными. Остальные возможности можно посмотреть в man.

По своей сути dnstop похож на tcpdump, потому что использует библиотеку libpcap, только она анализирует исключительно dns запросы. Результат работы можно сохранить в pcap файл с помощью ключа savefile.

#dns #perfomance

Есть тут настоящие девопсы? У вас так же в среднем проходит рабочий день? В целом, распорядок неплохой.

Музыкальная комната немного удивила. Впервые услышал, что такие есть в офисах. Немного поискал информации в интернете. Оказывается, такие комнаты много где есть - Яндекс, VK, Ростелеком и т.д.

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

p.s. видео отсюда

#devops

Я делал уже много заметок на тему systemd, где эта изначально система инициализации и управления службами стала заменять старые компоненты системы Linux. Повествование не будет полным без рассказа о монтировании файловых систем с помощью systemd. Сейчас этот механизм встречается повсеместно, особенно у облачных провайдеров, так что знать о нём необходимо.

Давно уже рассказывал, как попал в неприятную ситуацию с облачной виртуалкой, где нужно было заменить диск. Я не учёл момент, что провайдер напрямую управляет монтированием внутри пользовательских виртуалок через systemd, из-за чего я чуть не потерял все данные.

Монтирование файловых систем с помощью systemd обладает явными преимуществами перед привычным fstab:

1️⃣ Есть возможность автомонтирования при обращении и отключения устройства по заданным параметрам.
2️⃣ Можно автоматически создавать директории для точек монтирования. За их наличием не обязательно следить.
3️⃣ Можно настроить таймаут подключения устройства. Если оно не доступно, это не заблокирует загрузку системы, как это бывает с fstab.
4️⃣ Можно настраивать зависимость монтирования от других служб. Актуально для монтирования после подключения по VPN, либо запуска какого-то специального софта для работы с диском.

Самый простой пример монтирования локального диска в /mnt/backup со стандартными настройками. Создаём юнит в /etc/systemd/system с именем mnt-backup.mount:

[Unit]
Description=Disk for backups
[Mount]
What=/dev/disk/by-uuid/f774fad3-2ba0-47d1-a20b-0b1c2ae1b7d6
Where=/mnt/backup
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target

На диске должен быть создан раздел с файловой системой ext4. Если раздела нет, то создайте с помощью cfdisk. Если нет файловой системы, то создайте:

# mkfs -t ext4 /dev/sdb1

Uuid диска смотрим с помощью blkid:

# blkid
/dev/sdb1: UUID="f774fad3-2ba0-47d1-a20b-0b1c2ae1b7d6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a6242d02-8cff-fd44-99ce-a37c654c446c"

Перечитываем содержание юнитов и монтируем файловую систему:

# systemctl daemon-reload
# systemctl start mnt-backup.mount

Если всё в порядке, можно добавить в автозагрузку:

# systemctl enable mnt-backup.mount

Теперь покажу пример юнита автомонтирования на примере диска NFS, который доступен только после подключения по openvpn с помощью локального клиента. Он будет автоматически подключаться при обращении к точке монтирования и отключаться в случае отсутствия активности в течении 60 секунд. У него должно быть расширение .automount. Для этого мы должны создать обычный юнит mnt-backup.mount, но не включать его автозагрузку, и к нему добавить mnt-backup.automount.

mnt-backup.mount:

[Unit]
Description=NFS share
[Mount]
What=srv.example.com:/backup/nfs_share
Where=/mnt/backup
Type=nfs4
Options=rw
TimeoutSec=15

mnt-backup.automount:

[Unit]
Description=NFS share
Requires=network-online.target
BindsTo=openvpn@client.service 
After=openvpn@client.service
[Automount]
Where=/mnt/backup
TimeoutIdleSec=60
[Install]
WantedBy=graphical.target

Добавляем автомонтирование в автозагрузку:

# systemctl daemon-reload
# systemctl enable --now mnt-backup.automount

Теперь при старте системы ничего монтироваться не будет. При обращении к точке монтирования /mnt/backup будет предпринята попытка примонтировать сетевой диск при условии запущенной службы openvpn@client.service. Если служба будет отключена, диск принудительно будет отмонтирован, так как .automount жёстко привязан не только к запуску службы, но и к её работе.

Документация по mount и automount:
- systemd.mount — Mount unit configuration
- systemd.automount — Automount unit configuration

📌 Полезные ссылки по теме systemd:

◽️Systemd timers как замена Cron
◽️Journald как замена Syslog
◽️Systemd-journal-remote - централизованное хранение логов
◽️Systemd-journal-gatewayd - просмотр логов через браузер
◽️Hostnamectl для просмотра информации о системе
◽️Systemd-resolved - кэширующий DNS сервер

#systemd

​​Я писал ранее несколько заметок на тему того, что веду свои дела в сервисе todoist.com. Последняя была на тему того, что в этом сервисе появились календари, хоть и не в таком виде, как мне хотелось бы. Это в очередной раз побудило меня поискать что-то другое. В итоге я нашёл, попробовал и перенёс все свои дела в другой сервис.

Речь далее пойдёт про Singularity. Это российский онлайн сервис и одноимённая программа для компьютера и смартфона. Последние две недели я вёл свои дела и календари параллельно в ней. В итоге принял решение полностью перейти на этот сервис. Причины, побудившие меня это сделать, следующие:

1️⃣ Полностью российское решение. Никаких заморочек с оплатой. Цена очень низкая (167 р. в месяц при оплате за год).
2️⃣ Отдельное приложение под десктопную ОС (есть под все системы). Оно хоть и является обёрткой под веб версию и внешне от неё не отличается, тем не менее сделано всё равно удобнее, чем работа через браузер. Можно открыть две копии приложения одновременно, разместить на одном экране и тягать задачи, к примеру, из списка на календарь.
3️⃣ Понравилось мобильное приложение. Оно адаптировано под смартфоны, выглядит не уменьшенной копией веб версии. Постоянно им пользуюсь.
4️⃣ Есть интеграция с telegram, когда ты кидаешь текст боту, а он создаёт в общем списке задачу. С компьютера уже дооформляешь её и ставишь в нужный проект с датами.
5️⃣ Есть календарь со всеми критичными для меня возможностями.
6️⃣ Есть возможность подключать календари в режиме просмотра от сервиса Яндекс. У меня там семейные, совместные с супругой, так что мне удобно видеть их у себя.

По совокупности возможностей Singularity заменил мне связку todoist.com + planyway.com. В итоге вместо двух иностранных сервисов с риском потерять к ним доступ, получил один российский с локальной копией всех данных у меня на компе. Можно запустить приложение без интернета и спокойно в нём поработать. Planyway иногда ложился и я терял доступ к своим календарям. Было очень неудобно, хоть и некритично. Теперь у меня копия всех нужных данных есть локально и доступна без интернета: задачи, календари в Singularity, заметки в Joplin. Подумываю, как организовать Singularity так, чтобы и заметки в ней хранить. Пока пристреливаюсь.

Подобные сервисы плюс-минус одинаковые по возможностям. Выбор зависит от каких-то личных предпочтений и особенностей использования. Я много всего пробовал. Возможно из-за привычки внешний вид todoist мне всегда нравится больше, чем какой-либо другой. Singularity не стала исключением. Внешний вид нравится меньше, хотя в целом нет отторжения. Но буду привыкать теперь. Выбор сделан. Использую, кстати, светлую тему, а не умолчательную тёмную.

Ниже на картинке общий календарь по всем проектам. У задач есть теги, отображение можно сегментировать по ним. То есть не всё в одной куче. Для меня это важно.

#заметки

Расскажу своими словами о такой характеристики сетевого пакета как TTL (Time to live). Думаю, многие если что-то и знают или слышали об этом, то не вдавались в подробности, так как базово системному администратору не так часто приходится подробно разбираться с временем жизни пакета.

Вообще, я впервые познакомился с этим термином, когда купил свой первый модем Yota и захотел не просто пользоваться интернетом на одном устройстве, но и раздать его другим. В то время у Yota был безлимит только для конкретного устройства, в который воткнут модем или сим карта. А одним из способов определить, что интернет раздаётся, был анализ его TTL. Но не только. Из забавного расскажу, что также был контроль ресурсов, к которым обращается пользователь. Я тогда ещё иногда админил Freebsd, а на ноуте была тестовая виртуалка с ней. Как только я пытался обновить список портов (это аналог обновления репозитория в Linux), мне провайдер отключал интернет за нарушение условий использования. Видимо какой-то местный админ, настраивавший ограничения, решил, что пользователь Yota с usb модемом не может обновлять пакеты для Freebsd. Обходил это VPN соединением. Сразу весь траф в него заворачивал, чтобы не палить.

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

Как это работает на практике, наглядно можно показать на примере ограничений Yota того периода. У разных устройств и систем по умолчанию устанавливается разное TTL. Для Linux, Android обычно это 64, для Windows 128. Если вы используете интернет напрямую на смартфоне, то TTL выходящего из вашего устройства пакета будет 64. Если же вы раздаёте интернет другому смартфону, то на вашем устройстве TTL будет 64, на втором устройстве, которому раздали интернет, будет 63. И провайдер на своём оборудовании увидит TTL 63, а не 64. Это позволяет ему определить раздачу. Способ простой, но эффективный для большей части абонентов.

Изменить TTL довольно просто, если у вас есть навыки и инструменты системы. Можно поменять настройки по умолчанию TTL на системе, раздающей интернет. Просто увеличить значение на 1. Пример для Linux:

# sysctl -w net.ipv4.ip_default_ttl=65

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

# iptables -t mangle -A POSTROUTING -j TTL --ttl-set 65

Для android устройств (рутованных) и многих usb модемов (перепрошитых) выпускали патчи, где как раз с помощью параметра системы или iptables решали этот вопрос. Под Windows он решался таким же способом, только другими инструментами.

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

#network

​​Пару лет назад я писал про удобную программу для контроля за сетевой активностью приложений в системе - Portmaster (поддерживает Windows и Linux ). Хочу ещё раз привлечь к ней внимание, особенно для тех, кто про неё не знает. Программа активно развивается и обрастает дополнительными возможностями. Чего-то более функционального и удобного и при этом бесплатного я не знаю.

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

Вся основная информация по программе есть в первой заметке. Кратко поясню, что это Firewall, который перехватывает все сетевые пакеты. Но при этом умеет ими управлять не только на уровне IP адресов и портов, но и доменов, приложений, системных служб. Последнее особенно удобно. С помощью Portmaster можно взять под контроль сетевую активность Windows. Посмотреть, куда и какие службы ходят. Выборочно их ограничить или полностью всё заблокировать.

У Portmaster удобное и наглядное управление. Он автоматически находит все установленные приложения и службы. Выводит статистику в различных разрезах и группировках. Есть обзорный Dashbord по всей сетевой активности системы.

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

В настоящее время Portmaster может выступать также в роли блокировщика рекламы на уровне списков сайтов и dns запросов. Всё это настраивается более гибко, чем в популярных блокировщиках.

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

⇨ Сайт / Исходники / Видеообзор

#security

​​❓Как бы вы решили следующую задачу.

Как проверить, есть ли обращение клиента на порт TCP 22 сервера с определённого IP адреса и порта?

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

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

Если же речь идёт о любом другом соединении, то если оно активно, посмотреть его можно с помощью netstat или более современного ss:

# netstat -ntu
# ss -ntu

Нужный адрес и порт можно грепнуть:

# netstat -ntu | grep ':22'

Менее очевидный вариант с помощью lsof:

# lsof -ni TCP:22

Если же речь вести про прошлые, а не активные соединения, то первое, что мне приходит на ум из подручных системных средств - логирование с помощью firewall. В iptables я это делаю примерно так:

# iptables -N ssh_in
# iptables -A INPUT -j ssh_in
# iptables -A ssh_in -j LOG --log-level info --log-prefix "--IN--SSH--"
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Сделал отдельную цепочку для логирования и отправил туда запись всех пакетов с портом назначения 22. Логи будут по умолчанию собираться в системном логе syslog. При желании можно в отдельный файл вынести через правило в rsyslog. Отдельную цепочку для каждой службы я обычно не делаю. Вместо этого создаю три цепочки - input, output, forward, куда добавляю правила для тех адресов и портов, которые я хочу логировать.

Это всё, что мне пришло в голову по данному вопросу. Если знаете ещё какие-то способы, то напишите. Будет интересно посмотреть.

Пока заканчивал материал, вспомнил про ещё один:

# cat /proc/net/nf_conntrack | grep 'dport=22'

В принципе, это тот же самый ss или netstat. Они скорее всего отсюда и берут информацию.

#network #terminal

​​Расскажу вам про одну систему, которая привлекла моё внимание. Сначала думал, что это какая-то малорабочая поделка, но когда навёл справки понял, что нет. Видел отзывы людей, которые её использовали месяцами. Речь пойдёт об Qubes OS.

Идея там очень похожа на то, что я описывал ранее в рассказе про Distrobox. Только тут вместо контейнеров полноценные виртуальные машины на базе гипервизора XEN. То есть вся система - это набор самостоятельных виртуальных машин, разделённых по некоторым логическим признакам или приложениям. Например, отдельная VM для работы, для развлечений, для приватной информации и т.д. Можно настроить работу какого-то приложения в отдельной виртуальной машине.

Система построена на базе Fedora. В качестве основной хостовой системы может быть выбрана Fedora либо Debian. Все виртуальные машины интегрированы в единый интерфейс основной системы. Разработчики постарались всё это организовать так, чтобы было похоже на единую систему на базе Linux.

Для того, чтобы всё нормально работало, железо должно поддерживать технологию IOMMU (Intel VT-d или AMD IOMMU). Она нужна для корректной работы изолированных сетей и проброса PCI устройств в виртуалки. Я попробовал развернуть Qubes OS во вложенной виртуализации в Proxmox. Систему поставил, но сеть между VM не заработала как раз из-за отсутствия IOMMU. Так что для нормальной работы системы её надо ставить на соответствующее железо. Оценить удобства работы такой необычной схемы не получилось.

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

Если кто-то уже пользовался этой системой, поделитесь впечатлениями. Концепция, как я уже сказал, выглядит заманчивой. Загрузил шаблон нужной системы и развернул любой софт на его основе. И всё это добавил в единое рабочее пространство. Удобно же. Чем-то похоже на Windows и WSL, только более масштабно. Qubes OS, кстати, Windows тоже поддерживает.

⇨ Сайт / Свежий обзор

#разное

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

Задач вести какую-то статистику с помощью iptables у меня обычно нет, так что логирую я чаще всего заблокированные соединения. И то только на момент отладки, потому что часто это большой объём информации.

Вот пример простейшего набора правил для веб сервера, где запрещено всё, что не разрешено явно (22,80,443 порты). Показываю для понимания принципа.

# default rules
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# allow established
iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# allow ping
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# allow server connections
iptables -A OUTPUT -o ens3 -j ACCEPT

# allow ssh, www
iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT

# logging
iptables -N block_in
iptables -N block_out
iptables -N block_fw
iptables -A INPUT -j block_in
iptables -A OUTPUT -j block_out
iptables -A FORWARD -j block_fw
iptables -A block_in -j LOG --log-level info --log-prefix "-IN-BLOCK-"
iptables -A block_in -j DROP
iptables -A block_out -j LOG --log-level info --log-prefix "-OUT-BLOCK-"
iptables -A block_out -j DROP
iptables -A block_fw -j LOG --log-level info --log-prefix "-FW-BLOCK-"
iptables -A block_fw -j DROP

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

📌 Полезные материалы по теме:

▪ Графическое отображение правил iptables
▪ Защита от брута и скана портов
▪ Отладка работы с помощью iptables-tracer
▪ Бан всех, кто стучит в закрытый порт
▪ Блокировка стран по IP

#iptables

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

Очень нужен совет. Имеется два выделенных сервера, арендованных в Selectel. Сервера с приватной сетью. На серверах планируется поставить RDP сервер на Windows и сервер под базу данных. Сервера должны уметь общаться между собой. Плюс еще нужен безопасный доступ к RDP серверу. Как лучше на ваш взгляд все это организовать? Поставить на оба сервер Proxmox и на него виртуалки? Возможно ли при таком раскладе чтобы виртуалки с разных хостов Proxmox видели друг друга? Как обезопасить доступ RDP? Поднимать какой-то шлюз или как? Или вообще без Proxmox обойтись?

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

2️⃣ На машине с терминальным сервером сделал бы отдельную виртуалку под шлюз. Все остальные виртуальные машины ходили бы в интернет через неё. В эту виртуалку прокинул бы сетевой интерфейс с внешним IP. Сами гипервизоры настроил бы только в приватной сети, чтобы они ходили в интернет тоже только через этот шлюз. Обязательно настроить автоматический запуск этой виртуальной машины.

3️⃣ На шлюзе настроил бы firewall и управлял доступом к виртуалкам и их доступом в интернет через него. На него же поставил бы Nginx для проксирования запросов к внутренним веб ресурсам.

4️⃣ Доступ к терминальному серверу реализовал бы либо с помощью Openvpn, если нужен прямой доступ через терминальный клиент, либо с помощью Guacamole, если будет достаточен такой режим работы на сервере через браузер. Настраивал бы это на шлюзе. Можно сразу и то, и другое.

5️⃣ В отдельной виртуальной машине поднял бы Zabbix для мониторинга всего этого хозяйства и какую-то систему для сбора логов (ELK или Loki). И добавил бы внешний мониторинг, типа uptimerobot или uptime-kuma.

6️⃣ Если есть возможность по месту на дисках, на одном из серверов организовал бы вируталку под локальные бэкапы как самих виртуальных машин, так и сырых данных. С этой виртуалки забирал бы данные куда-то во вне. Если есть возможность поднять Proxmox Backup Server, поднял бы его для внешнего бэкапа виртуалок целиком.
 
Итого, получается следующая минимальная конфигурация по виртуалкам:

▪ СУБД
▪ Терминальник
▪ Шлюз
▪ Мониторинг и логи
▪ Бэкап.

Раскидываются между серверами в зависимости от ресурсов и нагрузки. Скорее всего СУБД и Мониторинг с логами это один сервер, Терминальник, Шлюз и Бэкап это второй сервер. При желании можно раздробить всё это на большее количество виртуальных машин. Мониторинг, Guacamole, Логи разнести по разным машинам. Это будет удобнее и безопаснее, но больше расходов по ресурсам и поддержке.

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

#виртуализация #совет

​​Тема с Portmaster получила очень живой отклик в виде сохранений заметки. Решил её немного развить и предложить альтернативу этому хоть и удобному, но очень объёмному и тяжёлому приложению. Тяжёл прежде всего интерфейс на Electron, само ядро там на Go. В противовес можно поставить simplewall. Это обёртка над Windows Filtering Platform (WFP) весом буквально в мегабайт. В репозитории все скрины на русском языке, так что автор, судя по всему, русскоязычный.

Компания Microsoft действует очень разумно и логично в своей массовой системе Windows. Закрывает наиболее актуальные потребности людей, замыкая их в своей экосистеме. Отрезает всех остальных от бигдаты пользователей. Её встроенных средств безопасности и защиты достаточно среднестатистическому пользователю. Нет необходимости ставить сторонние антивирусы или прочие приложения.

WFP - это набор системных служб для фильтрации трафика, охватывающий все основные сетевые уровни, от транспортного (TCP/UDP) до канального (Ethernet). Simplewall взаимодействует с WFP через встроенный API. То есть это не обёртка над Windows Firewall, как может показаться вначале.

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

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

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

#windows #security #network

▶️ Нескончаемая тема приколов на тему разработчиков и тестировщиков. Ютуб подкинул в рекомендации. Вообще, неплохо эти рекомендации работают. Я постоянно что-то оттуда смотрю и периодически сохраняю, чтобы вам показать. Некоторое вижу там впервые. То есть не видел в других каналах с приколами, как, к примеру, представленное видео.

Кто не видел, рекомендую ещё вот это посмотреть по схожей теме: https://t.me/srv_admin/1189

#юмор

​​🎓 За всё время ведения канала не было ни одной рекомендации по хорошему обучающему материалу по Ansible. Хотел сам что-то пройти, чтобы освежить знания, и не нашёл ничего у себя на канале.

Если у кого-то есть рекомендации на хорошие бесплатные курсы по этой теме, то поделитесь информацией. Вот то, что нашёл я.

▪ Ansible На Русском Языке от небезызвестного Дениса Астахова, автора канала ADV-IT. Зная другие материалы этого автора, предполагаю, что это качественный материал.

▪ ИТМО: Инфраструктура как код - свежий курс от известного сообщества DeusOps. У них свой канал в ютубе, телеграме, там же есть чат. Я сам не слежу за этим сообществом, но временами видел материалы оттуда, как и пересылку своих постов отсюда в их чат.

▪ Ansible для начинающих + практический опыт - бесплатный курс на Stepik, плюс от этой же компании небольшой плейлист на ютубе.

▪ Небольшой курс из двух уроков от автора канала Unix way. Я уже не раз упоминал его на канале. Уровень материала у него хороший. Да и отзывы к урокам говорят о том, что уроки сделаны качественно.

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

#обучение #ansible

​​Смотрите, какой прикол. Не знал, что такое в принципе возможно. В голом терминале можно ходить по современным сайтам, даже с подключением по SSH. Причём они выглядят так, что сразу и не поймёшь, что смотришь в терминале. Только картинки выдают, да и то не сразу.

# docker run --rm -ti fathyb/carbonyl https://google.com

Carbonyl собран на базе Chromium. Он даже видео c ютуба проигрывает. Правда, если подключился к голому серверу по SSH, то звука, очевидно, не будет.

Не знаю, кому и зачем приходит в голову подобное разрабатывать и поддерживать. У кого-то есть идеи, зачем это может пригодиться?

⇨ Исходники

#разное

​​Для тех, кто сам настраивает и обслуживает почтовые сервера, хочу предложить удобный инструмент для диагностики - Swaks (Swiss Army Knife for SMTP). В нём нет чего-то особенного, что вы не смогли бы выполнить с помощью прямых запросов через telnet. Но со swaks удобнее, быстрее и проще, и при этом вы видите полный лог общения с почтовым сервером, как если бы вы с ним общались по telnet.

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

# apt install swaks

Можете сразу же проверить свой сервер на возможность отправки сообщений без аутентификации:

# swaks --to user@example.com --server mail.example.net

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

# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth PLAIN --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru

С помощью похожего запроса можно удобно проверить поддерживаемые методы аутентификации. Например, CRAM-MD5:

# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth CRAM-MD5 --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru

=== Trying mail.zeroxzed.ru:25...
=== Connected to mail.zeroxzed.ru.
<- 220 mail.zeroxzed.ru ESMTP
 -> EHLO debian11.homelab.local
<- 250-mail.zeroxzed.ru
<- 250-8BITMIME
<- 250-SIZE 31457280
<- 250-AUTH PLAIN LOGIN
<- 250-STARTTLS
<- 250 PIPELINING
*** Auth not attempted, requested type not available
 -> QUIT
<- 221 Goodbye

Сервер ответил, что подобный механизм аутентификации не поддерживает.

Если не хочется каждый раз указывать данные аутентификации, их можно добавить в файл .netrc. Это тот же файл, что поддерживает и curl. Формат его такой:

machine mail.server.ru login root@server.ru password password123

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

В качестве тела письма можно использовать текстовый файл. Это удобно, если нужно проверить работу антивируса или антиспама. К примеру, берём файл EICAR-Test-File, на который все антивирусы дают реакцию, как на вирус, и отправляем его содержимое письмом:

# wget http://eicar.eu/eicar.com.txt
# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth PLAIN --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru --attach - --suppress-data <eicar.com.txt

Gmail не принял письмо: "552 5.7.0 This message was blocked because its content presents a potential security issue."

Тело письма можно и сразу в консоли передать через ключ --body 'foo', тему через --header 'Subject: foo'. Можно и случайные заголовки добавлять примерно так: --header-X-Test "test email".

В общем, инструмент простой, универсальный, интуитивно понятный. Автор поддерживает и регулярно обновляет. Можно использовать и в каких-то велосипедах на bash. Swaks умеет работать через различные прокси, использовать tls сертификаты с выбором шифров и некоторых настроек.

⇨ Исходники

#mailserver

У меня давняя привычка — прятать все непубличные службы за firewall. Это касается и веб интерфейса Proxmox. Если сервер настраиваю сам, то всегда на самом хосте настраиваю iptables. Мало того, что так проще всего ограничить доступ к гипервизору, так он еще и шлюзом может выступить для виртуальных машин, так как всё управление NAT тоже через правила iptables.

Если сервер настраивал не я, и тем более если к серверу нет доступа напрямую в консоль, настраивать firewall я уже не буду. Все эти вещи всегда делаю после установки системы и перед переносом рабочей нагрузки. Если по какой-то причине доступ к веб интерфейсу Proxmox не ограничили, сделать это можно отдельно для службы pveproxy, которая отвечает за веб интерфейс. Это безопасно и всегда можно исправить ошибки, если что-то пошло не так.

У службы pveproxy есть файл конфигурации /etc/default/pveproxy, в который можно добавить правила с ограничением доступа. По умолчанию файла нет, его нужно создать. Выглядит это примерно так:

ALLOW_FROM="10.0.0.1-10.0.0.5,192.168.0.0/22"
DENY_FROM="all"
POLICY="allow"

После этого службу надо перезапустить:

# systemctl restart pveproxy.service

Если где-то ошиблись, можно зайти по SSH и внести изменения. Подключение по SSH намного безопаснее открытого веб интерфейса, так что за SSH можно сильно не переживать. А вот веб интерфейс мне всегда стрёмно оставлять в открытом доступе.

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

LISTEN_IP="192.0.2.1"

Также там можно переназначить дефолтные tls сертификаты. Это удобно, если вы используете свои. Все эти возможности описаны в документации.

#proxmox

​​Iptables по прежнему остаётся наиболее распространённым файрволом на Linux. Несмотря на то, что nftables уже давно анонсированы и по умолчанию установлены во многих дистрибутивах, тот же Docker по прежнему по умолчанию использует iptables.

Я в своё время уже разбирал работу nftables, делал для себя типовой набор правил. Могу сказать, что nftables реально удобнее, функциональнее iptables. Набор правил там нагляднее и читабельнее. Так что если будет нужно, я спокойно на него перейду. Пока так и не вижу смысла, так как конкретно я не решаю ни одну из своих задач быстрее и удобнее в nftables по сравнению с iptables. То есть мне в целом всё равно, поэтому использую то, что привычнее и более распространено.

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

Пакеты проходят по списку правил по порядку, сверху вниз. Если пакет соответствует какому-то правилу, то он прекращает движение по цепочке. Из этого следует важный вывод — первыми в цепочке должны быть правила, которые охватывают максимальный объем трафика, чтобы он дальше не обрабатывался устройством. Примером такого правила является разрешение пакетов уже установленных (established) или связанных (related) соединений, которые ранее были разрешены каким-то правилом. Повторно проверять по всем правилам их не имеет смысла. То же самое относится к проблемным пакетам (например, invalid), которые нам не нужны и мы можем их сразу отбросить.

Правила читаются по порядку в каждой отдельной цепочке: Input, Forward, Output. Если вы в списке своих правил как-то их перемешаете, то это не повлияет на порядок их обработки. Каждое правило попадёт в ту цепочку, к которой оно относится и будет выполняться в соответствии со списком правил в этой цепочке.

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

1️⃣ Разрешающие правила, охватывающие максимальный объём трафика.
2️⃣ Остальные разрешающие правила.
3️⃣ Правило, запрещающее весь трафик данной цепочки.

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

Вот пример минимального набора правил для шлюза на базе Linux и iptables. Он подойдёт как для обычного офиса, так и для шлюза виртуальных машин гипервизора. Его же можно использовать прямо на гипервизоре Proxmox, если он сам выступает шлюзом для виртуальных машин.
⇨ https://pastebin.com/0sw4Cr5w

#iptables

​​Несколько полезных команд для консоли клиента mysql из практики, которыми пользуюсь сам.

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

SELECT table_schema "DB Name", ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) "Size in MB" FROM information_schema.tables GROUP BY table_schema ORDER BY `Size in MB` DESC;

📌 Посмотреть размер конкретной базы данных:

SELECT table_schema `Database`, round(Sum(data_length + index_length) / 1024 / 1024, 1) `Size in MB` FROM information_schema.TABLES WHERE table_schema = "имя базы";

📌 Посмотреть размер самых больших таблиц в базе данных:

SELECT table_name `Table`, round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB` FROM information_schema.TABLES WHERE table_schema = "имя базы" ORDER BY `Size in MB` DESC LIMIT 10;

📌 Удалить все таблицы в базе данных, не удаляя саму базу. То есть полная очистка базы без удаления:

SELECT CONCAT ('DROP TABLE ',GROUP_CONCAT(TABLE_NAME),';') INTO @qery FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = "имя базы"; PREPARE drop_tables FROM @qery; EXECUTE drop_tables;

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

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

#mysql

​​Мы все привыкли к тому, что интерфейс MC — это синий цвет двух панелей. Я когда-то давно узнал, что у популярного файлового менеджера можно выбрать другую цветовую тему оформления. Немного поигрался и забросил это дело. Но с тех времён у меня до сих пор осталась одна виртуальная машина с тёмной темой MC. Решил рассказать об этом. Наверняка многие не знают, что у Midnight Commander есть разные темы оформления.

В составе пакета MC есть большой набор различных тем. Живут они в /usr/share/mc/skins. Чтобы быстро посмотреть, как выглядит файловый менеджер с любой из тем, достаточно указать нужную тему отдельным ключом:

# mc -S darkfar

Если тема понравилась, то можно установить её по умолчанию. Для этого нужно выключить MC, открыть файл конфигурации ~/.config/mc/ini редактором, отличным от mcedit и изменить параметр с
skin=default
на
skin=darkfar

Теперь MC будет запускаться с выбранной темой. Если выбираете тему с 256 цветами, то убедитесь, что ваш терминал поддерживает 256 цветов. Настроить это можно в .bashrc или .bash_profile, добавив туда:

export TERM=xterm-256color

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

Сам я обычно оставляю тему по умолчанию. Но после того, как написал эту заметку, решил поменять у себя в WSL тему на xoria256.

❗️Ну и раз уж речь зашла о MC, добавлю информацию о настройке, которую я делаю всегда по умолчанию сразу после установки этого пакета на сервере:

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

Я копирую правила подсветки синтаксиса для файлов .sh на все неопознанные форматы файлов. Сюда будут относиться в основном лог файлы и файлы конфигураций без расширений. Чаще всего для них как раз актуален стандартный синтаксис скриптов sh.

Большие лог файлы иногда начинают подтормаживать при открытии с подсветкой. Тогда она быстро отключается комбинацией клавиш Ctrl + S.

#linux #mc

​​Если вам по какой-то причине не нравится современное именование сетевых интерфейсов в Linux вида ens18, enp0s18 и т.д. то вы можете довольно просто вернуться к привычным названиям eth0, eth1 и т.д. Только сразу предупрежу, что не стоит это делать на уже работающем сервере. Если уж вам так хочется переименовать сетевые интерфейсы, то делайте это сразу после установки системы.

Итак, если вам хочется вернуть старое именование интерфейсов, то в файле конфигурации grub /etc/default/grub добавьте в параметр GRUB_CMDLINE_LINUX дополнительные значения net.ifnames и biosdevname:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

У вас уже могут быть указаны какие-то другие значения. Новые добавьте через пробел. Изначально их вообще может не быть, а параметр указан вот так:

GRUB_CMDLINE_LINUX=""

Или могут быть какие-то другие значения:

GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"

После этого нужно обновить загрузчик. В зависимости от дистрибутива, это может выглядеть по-разному. В deb дистрибутивах то выглядит так:

# dpkg-reconfigure grub-pc

В rpm уже точно не помню, специально не проверял, но вроде бы раньше это выглядело так:

# grub2-mkconfig -o /boot/grub2/grub.cfg

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

После этого нужно везде в сетевых настройках изменить имена интерфейсов со старых на новые. Для Debian достаточно отредактировать /etc/network/interfaces. Не забудьте про firewall, если у вас правила привязаны к именам интерфейсов.

Теперь можно перезагружать сервер. Загрузится он со старыми названиями сетевых интерфейсов.

Попутно задам вопрос, на который у меня нет ответа. Я не понимаю, почему в некоторых виртуалках по умолчанию используется старое именование сетевых интерфейсов, а в некоторых новое. Причём, это не зависит от версии ОС. У меня прямо сейчас есть две одинаковые Debian 11, где на одной eth0, а на другой ens18. Первая на HyperV, вторая на Proxmox. Подозреваю, что это зависит от типа эмулируемой сетевухи и драйвера, который используется в системе.

#linux #network