​​Подписывание SMB-пакетов в Samba

В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.

SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.

Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.

В Linux также не трудно настроить подписывание пакетов, для этого в секции [global] файла smb.conf потребуется указать две опции.

Для сервера это server signing, которая может принимать следующие значения:

▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено

По умолчанию применяется значение disabled.

Для клиента используется опция client signing с доступными значениями:

▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено

Значение по умолчанию: auto.

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

[global]
 server signing = auto

Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.

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

​​Подборка актуальных материалов по Samba

▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu

▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning

▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux

▫️ Включаем отображение Samba-сервера в сетевом окружении Windows

▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu

▫️ Монтирование файловых систем при помощи systemd

В очередной рассылке Let’s Encrypt уведомила о грядущем прекращении рассылки с напоминанием об окончании срока действия сертификата:

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

В этом же письме они рекомендовали к использованию сторонний сервис для мониторинга сертификатов: https://redsift.com/pulse-platform/certificates-lite

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

Но есть ложка дегтя – на территории РФ сервис недоступен, через туннель все работает, проблем с добавлением доменов в зоне RU нет, равно как и получение уведомлений на отечественные почтовые службы.

Кому лень регистрироваться – можно войти через Google или Microsoft.

По мотивам реальных событий.

▫️ Вася решил мониторить температуру произвольных устройств.

▫️ Вася решил использовать для этого sensors

▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:

UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.

❓Что не так сделал Вася?

​​В чем был не прав Вася?

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

▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.

▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.

▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.

▫️ Затем это все передается команде awk, где и происходит основная магия.

🔹 -F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.

🔹 {avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.

🔹 END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.

👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.

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

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

Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:

nvme-pci-0100
Adapter: PCI adapter
Composite:    +37.9°C  (low  =  -0.1°C, high = +114.8°C)
                       (crit = +119.8°C)

Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:

sensors | grep nvme-pci-0100 -A 2

Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:

sensors | grep nvme-pci-0100 -A 2 | tail -n 1

И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:

sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'

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

Уже видели новость? Слёрм запускает серию вебинаров с экспертами из бигтеха про вакансии в DevOps.

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

🔴 Что реально важно конкретным лидам, когда они набирают команду?
🔴 Готовы ли компании снизить требования к позиции, чтобы ускорить поиск?
🔴 Если бы каждый пункт в вакансии стоил +20к к офферу, какие бы остались?

📆 Первая встреча: 13 февраля в 19:00

Ведущий: Вячеслав Федосеев, TeamLead DevOps в «‎Честном знаке», автор канала «‎DevOps Bootcamp с Федосеевым»
Приглашённый гость: Владимир Федорков, основатель fournines.ru

Далее встречи — два раза в неделю по понедельникам и средам. В феврале ждем в гости эйчаров и лидов из VK Cloud, Kaspersky, Инфосистемы Джет.

Расписание, подробности и ссылки на встречи — в боте 📌

#реклама
О рекламодателе
erid: 2W5zFHUFkK2

Вроде это знают все, как оказалось - не все.

Linux - начинающим. Потоки, перенаправление потоков, конвейер

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

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

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

https://interface31.ru/tech_it/2021/10/linux---nachinayushhim-chast-7-potoki-perenapravlenie-potokov-konveyer.html

​​Чтоб ты жил в эпоху перемен

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

Изменения – это не хорошо и не плохо, это неотъемлемая часть нашей жизни и профессиональной деятельности, но плохо, когда изменений слишком много и все они происходят примерно в одно и тоже время.

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

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

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

Обновить существующее ПО/оборудование

Добавить новое ПО/оборудование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В комментариях к статье читатели посоветовали еще один конфигуратор для PostgreSQL.

Но это не просто конфигуратор. А разработка отечественных ребят и заточенный именно под 1С (выбираем Нагрузка базы данных - ERP1C).

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

https://tantorlabs.ru/pgconfigurator

Сегодня у нас в Белгороде случилась страшная трагедия. BMW X7 в самом центре Белгорода протаранил карету Скорой помощи. Две девушки фельдшера погибли на месте, водитель крайне тяжелый в реанимации.

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

​​Неочевидное - невероятное

Работая с определенным оборудованием накапливается опыт и определённые практики. Некоторые действуют на подсознательном уровне.

Так в Mikrotik если мы что-то изменили - оно становится синим. Но не всегда и не везде.

Откроем брандмауэр и создадим там правило пустышку, ну, скажем, такое.

0 chain=forward action=accept log=no log-prefix=""

Теперь откроем его в Winboх и полазим на закладке Extra, ничего не трогаем, просто смотрим. Как видим ничего не посинело, спокойно уходим и жмем OK.

Но не тут-то было, вывод правил в терминал покажет нам:

0 chain=forward action=accept psd=21,3s,3,1 limit=1,5:packet dst-limit=1,5,dst-address/1m40s time=0s-1d,sun,mon,tue,wed,thu,fri,sat log=no
log-prefix="

Внезапно!

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

Во всем виноват IPsec, однозначно!

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

Чтобы потом не было подобных вопросов. Хотя это как раз классика: я поднял IPsec и где мои маршруты? Равно как и почему у меня из-за NAT работает ровно один клиент.

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

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

​​Про IPsec для самых маленьких

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

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

При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.

Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.

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

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

Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.

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

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

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

Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.

Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.

GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.

Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.

А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.

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

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