Решил по максимуму наполнить тему почтового сервера. На очереди сбор и обработка логов в ELK, но для этого надо сначала с этим стеком обновить статью.

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

⇨ Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird

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

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

Про плагин к RoundCube у меня уже была ранее заметка, а про Thunderbird даже не упоминал. Настройки простые, если уже есть Nextcloud. Стоит ли его поднимать только для почты - не знаю. По месту надо решать, если в принципе потребность - регулярно обмениваться файлами.

У меня на одном из серверов есть ящики по 100-150 гигабайт. Хлопотно обслуживать такой почтовый архив. Было бы проще, если бы подобная функциональность была внедрена на этапе запуска сервера.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#mailserver #nextcloud

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились.

⇨ Отказоустойчивый кластер Angie c VRRP и KeepaliveD
Пример настройки отказоустойчивости с помощью Keepalived. Типичный и самый популярный подход для кластеризации сервисов на Linux. Подобным образом можно много чего настроить, так что рекомендую посмотреть для общего понимания самого процесса кластеризации.

⇨ How to Build a Home Server in 2026 (without going insane)
Автор выбирает, из чего собирать сервер в 2026 году. Негодует по поводу цен на память и диски. Он, кстати, из Германии. Привёл пример 2х32ГБ за $630. Это информация для тех, кто жалуется, что у нас продавцы цены задрали. К сожалению, это не их рук дело, иначе это было бы просто обойти. Его рекомендация - б.у.шный офисный комп на барахолке 😁

⇨ Proxmox Datacenter Manager — центр управления виртуальной инфраструктурой
Обзор нового продукта Proxmox - единая панель управления всеми гипервизорами, кластерами и серверами бэкапов. Я ещё не пробовал. Интересно было посмотреть. Выглядит удобно. Особенно миграция понравилась. Получается, кластер теперь, если он не HA, уже и не нужен. Миграция и между одиночными хостами работает нормально.

⇨ Как объединить серверы в кластер Proxmox VE | Пошаговая настройка узлов
Если ещё не видел, как собирать кластер из Proxmox VE, можете посмотреть. Сама по себе настройка простая. А вот дальнейшая эксплуатация и сопутствующие вопросы, например, с сетью, миграциями, было бы интересно посмотреть.

⇨ Распаковка и включение ASUS GX10. Компьютер для ИИ от NVIDIA (DGX Spark)
Распаковочка компьютера от Nvidia. Я и не знал, что подобные существуют. Их можно в кластера объединять. В Москве от 312 т.р. за них цены стартуют.

⇨ Установка XPEnology на TerrMaster F4-425 Plus
Если не знаете, что такое XPEnology, можете посмотреть. Тут очень подробно рассказано и показано, как её установить. Это ломаная версия ОС от Synology. Проект известный, у меня 10+ лет уже NAS на XPEnology крутится.

⇨ Manage your network like a PRO // Netbox Tutorial
Хорошее руководство по настройке Netbox - бесплатный и один из самых популярных продуктов для визуализации и документирования информационных систем и сетей. Поддерживает все современные подходы, имеет множество интеграций с другими системами. Это прям топчик среди систем подобного рода.

⇨ Гайд по созданию Telegram бота на Python + деплой
Если интересна эта тема, пробуйте. Не пугайтесь, если вы не программист и не умеете программировать. Я в своё время, когда захотел сделать бота, довольно быстро изучил базу и запустил бота. И это ещё до распространения ИИ. Сейчас ещё проще это сделать. Мне даже кажется, что админам или девопсам проще это сделать, так как они лучше ориентируются в инфраструктуре, которая нужна для работы. Непосредственно написание кода в контексте бота сейчас не самая сложная часть процесса.

⇨ Бекапируем Почту. Архиваторы: Mail-archiver, Open Archiver, Bichon, Piler.
Большой обзор нескольких программ для бэкапа почтовых ящиков. Mail-archiver я недавно обозревал. Нормальное решение. Про другие даже не слышал. Нужно будет пробовать. Тема актуальная. Автору больше всего понравился Open Archiver. Надо будет его попробовать.

⇨ My New Home Assistant Dashboard To Make Plex Kid-Friendly
Любопытный опыт автора по связыванию Home Assistant и Plex для просмотра ребёнком мультиков. Особенно заинтриговало начало, где он настроил запуск мультиков по разным RFID меткам. Для этого даже считыватель приобрёл. Это что-то типа видиков в прошлом получается. Жаль, не показал, как это работает. Он в итоге отказался от карточек.

#видео

В комментариях к заметкам на тему доступа к серверу по SSH регулярно возникают споры о безопасности парольной аутентификации, смены стандартного порта, доступа root, о настройке fail2ban и т.д.

Иногда я специально пишу, что оставляю доступ root по паролю. Просто интересно почитать, что будут писать по этому поводу. Всегда находятся те, кто пишут, что это нубство, небезопасно, так делать нельзя, меня надо уволить и т.д. На что я всегда спрашиваю, а в чём конкретно тут проблема. Ответа не получаю, только общие слова, что так не принято, что пароль можно подобрать и т.д.

В общем случае никаких проблем с безопасностью службы SSH не будет, если вы оставите возможность подключаться root и использовать для этого сложный несловарный пароль. Менять стандартный порт 22 или ставить Fail2Ban тоже не обязательно. Достаточно поменять несколько настроек и про какой-либо перебор паролей можно забыть.

MaxAuthTries 3
MaxSessions 2
MaxStartups 10:30:60

◽️MaxAuthTries - максимальное количество попыток аутентификации для одного соединения.
◽️MaxSessions - ограничение на количество активных сеансов на одно соединение. Можно сделать больше, если в реальности вам это нужно.
◽️MaxStartups - до 10-ти одновременных соединений все принимаются, при количестве соединений от 10 до 60 новые соединения отбрасываются с вероятностью 30%, при 60+ активных соединениях новые не открываются.

При таких настройках массовый перебор паролей становится нереален из-за ограничения в количестве попыток.

Теоретически есть опасность не подключиться к своему серверу, если какой-то злоумышленник вычислит эти параметры и будет постоянно держать 60+ активных соединений. Тогда есть вероятность, что вы тоже не подключитесь. Но шанс очень малый и обычно так никто не делает, потому что зайти владельцу на свой сервер в обход SSH всё равно можно.

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

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

Запускаем одновременно две службы на разных портах. На стандартном 22 для всех и на 22555 для себя с ограничениями по IP. На 22 ставим параметры, как я показал выше. А для 22555 указываем ограничения по своим спискам IP адресов. Показываю, как это примерно выглядит.

# cp /etc/ssh/sshd_config /etc/ssh/sshd_root.conf

# cat sshd_config

Port 22
...
MaxAuthTries 3
MaxSessions 2
MaxStartups 10:30:60
...

Остальные настройки по желанию. Конфигурация приватной службы:

# cat sshd_root.conf

Port 22555
AllowUsers root@192.168.137.0/24 root@1.2.3.4 root@5.6.7.8
...

Создаём для приватной службы юнит systemd:

# cd /etc/systemd/system
# cp sshd.service sshd-root.service

Меняем в конфигурации sshd-root.service один параметр:

ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_root.conf

Запускаем приватную службу:

# systemctl daemon-reload
# systemctl enable --now sshd-root

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

# iptables -A INPUT -p tcp --dport 22555 -s 192.168.137.0/24,1.2.3.4,5.6.7.8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22555 -j DROP

Много написал, что на практике не особо нужно. Я бы всё закрывал через Iptables с любыми настройками. Но даже если SSH открыт для всех, для root и по паролю, то в реальности никаких проблем это не доставит, если всё настроить аккуратно и не сливать пароль. Ключ, как и пароль, тоже может утечь. Это не абсолютная защита и не панацея, в отличии от файрвола, если его случайно не выключат (а так бывает).

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#ssh

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

А я на самом деле сижу на сервере под root и не вижу в этом ничего зазорного. Сервер - не рабочая машина. Я туда не захожу просто так. Обычно я захожу на сервер для выполнения административных действий, для которых требуются права root. Без этих прав мне там и делать особо нечего.

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

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

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

Далее у нас появляются какие-то скрипты или другие инструменты, которые заходят удалённо на наш сервер для выполнения каких-то конкретных действий. Тут опять нужно sudo для того, чтобы их ограничить только теми действиями, которые им разрешены. Сюда же относятся и локальные службы с ограниченными правами, которые через sudo выполняют какие-то конкретно разрешённые действия с повышением прав. Например, это очень актуально для Zabbix Agent, который может что-то автоматически выполнять на сервере.

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

☝️К чему я всё это пишу? Специалист он на то и специалист, что разбирается в теме и в каждом конкретном случае думает, как ему сделать удобнее и безопаснее, а не просто повторяет заученные или случайно увиденные примеры. Подходы к настройке и управлению инфраструктурой на 3 сервера и на 100 будут разные. В одном случае от sudo никакого толка не будет, а в другом без него никуда, хотя и это не точно. По умолчанию никакой безопасности sudo не добавляет. Её и в системе то нет в базовой установке. Надо отдельно устанавливать там, где это действительно нужно.

Например, можно запретить подключение по SSH для root, настроить аутентификацию по ключам, и каждый раз при входе на сервер делать что-то типа sudo su и вводить пароль или перед каждой командой писать sudo. А можно разрешить подключение сразу под root, настроить аутентификацию по ключу и закрыть ключ паролем. Его тоже придётся один раз ввести, но попадаешь на сервер сразу под root. Какая схема безопаснее? А какая удобнее?

Кстати, для тех, кто ещё не знает, напомню, что sudo появилась и в Windows. Я уже пользуюсь, удобно.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#security

Существует простая, эффективная и немного маргинальная технология по ограничению доступа через интернет к своим сервисам - port knocking. Думаю, она многим известна. Я сам не раз про неё делал заметки. Там смысл в том, что нужно послать определённую последовательность сетевых пакетов на файрвол, и он откроется для твоего IP. Пример того, как это настраивается в Mikrotik.

В Linux это можно реализовать специальным софтом knockd или сделать вручную правила для iptables примерно так же, как в Mikrotik. Там под капотом тот же iptables. Настраивается очень просто. Ниже набор правил для открытия доступа на 30 секунд при отправке 1 icmp пакета размером ровно 116 байт. Во всех примерах в интернете в основном не пингуют, а стучат в разные TCP порты. Мне реализация на базе icmp кажется проще и удобнее, главное, чтобы icmp не был заблокирован:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m length --length 144 -m recent --name SSH_KNOCK --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH_KNOCK --rcheck --seconds 30 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Теперь пингуем на винде:
> ping 192.168.137.38 -n 1 -l 116
или в линуксе:
# ping 192.168.137.38 -c 1 -s 116
и нам открывается 22-й порт.

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

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

Но сейчас настали такие времена, когда port knocking имеет смысл настраивать. VPN запросто может не работать. Софт типа Anydesk тоже работает через раз, особенно через мобильную связь. Нет 100% уверенности, что удастся подключиться здесь и сейчас.

Port knocking в этом плане очень прост и надёжен. Открывается конкретно для тебя на короткий срок прямой доступ. При этом установленное соединение уже не ограничено по времени. Пинганул свой внешний файрвол, он открыл для тебя доступ на 1 минуту. Ты подключился и работаешь, пока связь не оборвётся. Потом ещё раз можно пингануть для нового соединения. Этот подход нормально работает для SSH или RDP.

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

▪️Labean
▪️Updater
▪️webhook

Делается обычный вебхук, который создаёт правило в файрволе на основе клиентского IP адреса.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#gateway