Много лет назад (8), когда я активно занимался поддержкой офисов, не раз сталкивался с вирусами-шифровальщиками. Причём с одним из них я столкнулся, когда они прям только начали появляться и были в новинку. Никто толком не понимал, что это такое и как восстанавливать данные.

Как сейчас помню, это был вирус, который ставил расширение .vault на файлы. Он зашифровал компанию, которую я только взял на обслуживание и даже не успел толком дела принять. Проводил инвентаризацию. Бэкапами ещё не занимался. Хорошо хоть права доступа на запись у человека были не ко всем общим файлам, так что пострадал в основном только он, запустивший вирус из почтового вложения и ещё пару человек, которым он его переслал, чтобы они проверили, почему файл не открывается 😁

Самое интересное, что у этих людей были зашифрованные флешки (пин код прям с устройства вводился) с секретной информацией, которая никуда не копировалась и не бэкапилась. Флешки не должны были быть воткнутыми постоянно. Понятное дело, что они были воткнуты постоянно в течении рабочего дня. Все данные там были потеряны. Директор тогда отнёсся философски ко всему этому. Ругаться не стал, сказал, что сами виноваты, пусть выкручиваются, как хотят. В принципе, сами и выкрутились.

Когда я воочию увидел, как легко безвозвратно потерять все данные, стал по-другому относиться к бэкапам. Я сам тогда ещё ни разу не сталкивался с тем, что данные могут быть вот так утеряны безвозвратно и шансов на восстановление нет. Сам за бэкапами всегда следил. Потом и тут всё настроил и забэкапил. Позже они ещё раз словили шифровальщика. Данные им из бэкапа восстановил. Причём всё это было с работающим платным антивирусом Eset. Тогда антивирусы очень слабо реагировали на шифровальщиков.

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

Написать на эту тему решил, чтобы рассказать про сервис https://www.nomoreransom.org/ru/index.html Зашёл его проверить и с удивлением обнаружил, что сайт всё ещё функционирует. Во время разгула шифровальщиков, не все в полной мере шифровали файлы. Были и те, кто косил под популярных шифровальщиков, и те, кто реально ничего не шифровал. Для некоторых случаев антивирусные компании создавали дешифраторы и они реально помогали. Я знал такие случаи.

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

#вирус #сервис

Простой и быстрый способ забэкапить свои репозитории из github или gitlab. Я не стал тут изобретать велосипед, а просто поискал информацию. Нашёл много всяких программ и утилит на различных языках программирования. Всё это отмёл, пока не нашёл простые bash скрипты. Для меня было очевидно, что для решения этой задачи достаточно bash и api указанных сервисов.

В итоге воспользовался вот этим репозиторием:
⇨ https://github.com/alexadam/repo-backup
Очень простое и рабочее решение.

Я всё своё храню в Gitlab. Сходил в настройки, выдал токен с разрешениями на чтение api и репозиториев. И использовал его в скрипте:

#!/bin/sh

dirname=gitlab-backup-$(date "+%Y-%m-%d-%H-%M-%S")
mkdir "$dirname"
cd $dirname

privateToken=YOUR_ACCESS_TOKEN
userName=YOUR_GITLAB_USERNAME

curl --header "Private-Token: $privateToken" \
"https://gitlab.com/api/v4/users/$userName/projects" \
| jq -r '.[] | .id, .name' \
| while IFS= read projectId; read projectName; do
curl --header "Private-Token: $privateToken" \
"https://gitlab.com/api/v4/projects/$projectId/repository/archive.zip" \
--output $projectName.zip
done

echo Done! All files downloaded here: $(pwd)

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

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

#backup #git #devops

​​Мне посоветовали посмотреть на почтовый сервер Axigen Mail Server, про который я вообще ни разу не слышал. С интересом изучил его, но быстро разочаровался. Это коммерческий продукт с очень ограниченной бесплатной версией: 5 доменов, 5 пользователей, 5 групп. С такими ограничениями этот сервер подходит только для личного использования.

Тем не менее, сервер мне понравился. Разворачивается он очень просто и быстро. Для запуска есть всё, что только можно: deb и rpm пакеты, docker образ, образ VM для VMWare и VirtualBox, Helm чарт для k8s, установщик для Windows.

Я выбрал Docker для запуска. В лучших традициях монолита всё, что нужно для работы, упаковано в один образ. Это просто праздник. Вместо дюжины контейнеров тут только один. Запускаем:

# docker run --name=axigen -dt -v ~/axigen_var:/axigen/var \
-p 443:443 -p 9443:9443 \
-p 993:993 -p 995:995 \
-p 25:25 -p 465:465 \
-p 9000:9000 -p 7000:7000 axigen/axigen

Функционал типичный для личного органайзера:
▪ почта
▪ календарь
▪ адресная книга
▪ планировщик дел
▪ заметки

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

Решил сделать заметку про этот почтовый сервер, потому что понравился веб интерфейс. Может кому-то тоже приглянется, и он выберет себе этот инструмент для личного использования в качестве персональной почты и всех остальных сервисов. Удобно, когда всё это интегрировано в единую систему. Из письма сразу же можно сделать заметку или задачу. У меня заметки, календарь, почта, задачи — разные сервисы. И это неудобно. А тут всё в одном месте.

⇨ Сайт / Demo

#mailserver #заметки

​​Вы знаете, как узнать, кто и насколько активно использует swap в Linux? Можно использовать для этого top, там можно вывести отдельную колонку со swap. Для этого запустите top, нажмите f и выберите колонку со swap, которой по умолчанию нет в отображении. Насколько я слышал, это не совсем корректный способ, поэтому, к примеру, в htop эту колонку вообще убрали, чтобы не вводить людей в заблуждение.

Самый надёжный способ узнать, сколько процесс занимает места в swap, проверить /proc/$PID/smaps или /proc/$PID/status. Первая метрика будет самая точная, но там нужно будет вручную вычислить суммарный объём по отдельным кусочкам используемой памяти. Вторая метрика сразу идёт суммой.

В сети много различных скриптов, которые вычисляют суммарный объем памяти в swap для процессов и выводят его в различном виде. Вот наиболее простой и короткий:

#!/bin/bash
SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
if (( $SUM > 0 )); then
echo "PID=$PID swapped $SUM KB ($PROGNAME)"
fi
let OVERALL=$OVERALL+$SUM
SUM=0
done
echo "Overall swap used: $OVERALL KB"

Здесь просто выводятся значения метрики VmSwap из /proc/$PID/status. А тут пример скрипта, где суммируются значения для swap из /proc/$PID/smaps и далее сортируются от самого большого потребителя к наименьшему. Не стал показывать его, потому что он значительно длиннее. Главное, что идею вы поняли. Наколхозить скрипт можно и самому так, как тебе больше нравится.

Можно по-быстрому в консоли посмотреть:
# for file in /proc/*/status ; \
do awk '/VmSwap|Name/{printf $2 " " $3} END { print ""}' \
$file; done | sort -k 2 -n -r | less

#linux #script #perfomance

Немного юмора в пятницу. Диалоги клиентов и заказчиков.

- На каком языке лучше делать сайт интернет-магазина? Ruby, PHP, Python?
- А вы сделайте так, что бы можно было выбрать язык.
===
- Как вы можете рассуждать о невозможности, если даже не пробовали.
===
- Вы профессионал, вот вам деньги, покажите как правильно.
- Вот так правильно.
- Я не согласен.
===
- Вы делаете сайты?
- Да. 
- Сделайте тогда нам сайт с зеркальным фоном, чтобы клиент видел своё отражение.
===
Работаю в сфере дизайна уже 23 года. Мой начальник однажды сказал:
- Смешай два цвета пигмента, чтобы получить жёлтый.*
- Какие два цвета мне использовать?
- Ты эксперт, а не я, вот и думай.
*жёлтый — базовый цвет, как красный и синий, их нельзя получить смешиванием.

Если кто не знает, это комментарии к видео:
⇨ The Expert (Русский дубляж)
Оригинал на английском:
⇨ The Expert (Short Comedy Sketch)
Рекомендую посмотреть, если ещё не видели. Это пародия на современный корпоративный рабочий процесс.

После просмотра роликов, вы поймёте и вот это:

- Что нам мешает скинуть вниз стекло с 10 этажа при этом не разбив его?
- Физика.
- Просто игнорируйте её.

#юмор

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

◽Oh My Git! — одна из самых известных и популярных игр на тему изучения Git. Для этой технологии, на мой взгляд, сделано больше всего игр.

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

◽Elevator Saga — залипательная игра для изучения JavaScript. Нужно программировать эффективную работу лифта по перевозке людей. Играл в неё сам, мне понравилось.

◽Bandit — хакерская тематика со взломом через использование консоли в Linux. Проходится на реальном сервере в интернете, к которому надо подключаться. Советую обратить внимание, игра интересная и сложная.

◽Natas - игра от разработчиков Bandit, но тема другая. Никаких ssh и консоли, только браузер. Нужно проходить уровни, изучая сайт и веб сервер, находя в них уязвимости.

◽while True: learn() - головоломка-симулятор на тему машинного обучения, нейронных сетей, ИИ и BigData. В игре вы выступаете в роли тыжпрограммиста, у которого есть кот, который лучше разбирается в it, чем вы.

◽KodeKloud Engineer - вы регистрируетесь и начинаете путь обычного сисадмина. Вас знакомят с проектом, рассказывают, что там к чему. Для него есть подробная схема, wiki, таблица с ip адресами и доступами. Примерно раз в день вам будут давать какое-то задание по этой инфраструктуре. Всё выполняется в виртуальной консоли в браузере, которая эмулирует консоль Linux. Задания максимально приближены к реальным задачам админа или devops.

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

Если знаете ещё что-то полезное и интересное по данной тематике, поделитесь, пожалуйста, в комментариях.

#игра #обучение #подборка

​​▶️ Понравилось ещё одно выступление с DevOpsConf, которое могу порекомендовать к просмотру:

⇨ DevOps спит, Gitlab CI работает

Выступление будет интересно тем, кто хочет на примерах посмотреть, что такое CI/CD на практике. Не абстрактные интеграции и доставки, а по шагам, что конкретно делаем.

Автор доклада рассказала, как они жили до CI/CD и вручную выполняли все операции по заявкам разработчиков. И как в итоге всё автоматизировали с помощью Gitlab, чтобы вручную не делать ничего. Каждый шаг своего конвейера она описывает. Собственно, об этом весь доклад.

Обратил внимание, что крупная компания использует Rocket.Chat для внутреннего общения. Мне предстоит уже на днях внедрение в небольшую компанию на 50 человек. Расскажу потом, как всё прошло. Самому интересно в работе посмотреть на этот продукт. Дальше тестов никогда дело не заходило. Был опыт внедрения и использования Mattermost и Zulip.

Отдельно хочется отметить, что Виктория начала свой путь с первой линии поддержки в 2018 году. А уже в 2020 стала DevOps инженером. В 2022 выступает на конференции для специалистов. Хорошая мотивирующая история. Дорогу осилит идущий.

#видео #devops #cicd

​​В одном выступлении вскользь увидел упоминание программы Grafana dashboard builder. С её помощью можно автоматически создавать дашборды графаны на основе файлов конфигураций в формате yaml. Идея интересная, поэтому решил посмотреть, как это на практике выглядит.

На то, чтобы установить, запустить и понять, как это работает, ушло довольно много времени. Программа есть в pip, но в Debian 11 просто так не ставится. Не получалось установить все зависимости. В итоге нашёл решение. Нужно было предварительно установить один пакет. В итоге установил вот так:
# apt install python3-pip
# apt install heimdal-dev
# pip3 install grafana-dashboard-builder

Далее склонировал репозиторий, чтобы взять оттуда примеры настроек и проектов:
# git clone https://github.com/jakubplichta/grafana-dashboard-builder
Примеры лежат в директории samples.

Для того, чтобы сгенерировать шаблоны на основе тестового проекта, необходимо в config.yaml указать корректную output_folder. После этого можно запустить генерацию, находять в директории samples:
# grafana-dashboard-builder -p project.yaml \
--exporter file --config config.yaml
В папке Example project будут сгенерированные дашборды в формате json.

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

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

⇨ Исходники

#grafana #devops

Хочу порассуждать с вами на тему, которая интересна лично мне. И по которой у меня нет однозначного мнения, что лучше делать вот так, а не иначе. Речь пойдёт про интеграцию аутентификации с единым LDAP каталогом.

Удобно, когда для аутентификации используется единый каталог. Когда все сервисы в закрытом периметре, никаких проблем не вижу. А если речь идёт, например, о почте, или о VPN подключениях? Эти сервисы люди используют, получая к ним доступ через интернет. Я много раз сталкивался, что учётные данные от почты утекают куда-то на сторону и через сервер начинают рассылать спам.

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

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

❓А вы что думаете на этот счёт? Как обычно настраиваете? В первую очередь почта и VPN интересуют.

#разное

​​Необходимо внедрить в небольшой компании примерно на 50 человек Rocket.Chat. Не хочу долго описывать, почему выбор пал именно на него. Если кратко, то основная причина — большая функциональность платной версии. Менее значимые причины — активная разработка продукта и популярность.

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

Rocket.Chat обновляется часто, поэтому решил запускать в Docker. Инструкция есть, запускается буквально за 5-10 минут. Обязательно в compose измените версию с latest на последний релиз!!! Сразу же настроил обратный прокси на Nginx и работу по HTTPS и доменному имени.

По умолчанию сервер хранит все загруженные файлы в своей базе Mongodb. Это удобно для масштабирования установки на несколько серверов, что мне совершенно не нужно. Так что я сразу немного изменил compose файл, добавил новый volume к контейнеру с rocketchat и настроил хранение файлов в отдельной директории.

Далее сразу же настроил бэкап. В этом деле я люблю подстраховываться, поэтому сразу настроил три типа:
◽Бэкап на уровне виртуальной машины.
◽Воспользовался Docker-volume-backup для бэкапа volumes.
◽Бэкап дампа базы mongodb.

Rocket.Chat всё своё состояние хранит в mongodb. Если вы не переносили хранение файлов в директорию файловой системы, то бэкапа mongodb вам будет достаточно. Я не очень люблю большие дампы баз данных, в том числе поэтому вынес хранение файлов в директорию, которая вместе с дампом базы и бэкапом volume от монги уезжает на бэкап сервер.

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

К сожалению, русский перевод не очень. В целом понятный, но корявенький. Себе сразу поставил английский, иначе настраивать неудобно. Пользователям оставил русский. Посмотрим, как проявит себя этот чат. Я им ещё не пользовался и не внедрял. Только для тестов ставил. Из неприятного заметил, что страница логина не грузится в Яндекс.Бразуре. Во всех других, что я проверял, загружается (Chrome, Edge, Firefox). В первом же бесконечно крутится загрузка стартовой страницы.

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

#chat

​​▶️ Информация для тех, кто учится или уже использует Ansible, но возможно не так, как следует:

⇨ Ansible плох? Нет, просто готовьте его правильно!

Интересное выступление от специалиста в своей области знаний. Я после доклада захотел купить у него курс, но, как оказалось, как такового курса нет, а когда-то проводилось групповое обучение.

В выступлении разобраны популярные по мнению автора ошибки при использовании Ansible. Основные:
◽использование шаблонизации yaml, как текстов, а не как структурированных данных
◽использование группы хостов all, а потом методом исключения добавляются условия
◽использование модулей python с зависимостями, которые непонятно что вам принесут в систему
◽использование Ansible для управления учётками и доступами на машинах
◽хранение инвентаря в формате ini
◽подмена тэгов условиями
и т.д.

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

Ещё полезные материалы по Ansible от этого автора:
▪ Ansible это вам не bash (текст, видео)
▪ Блеск и нищета Ansible
▪ Ansible-vault decrypt: обходимся без Ansible
▪ Ускоряем Ansible

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

#видео #ansible

​​Напоминаю про очень функциональное и удобное решение для бэкапов — Restic. Часто вижу его упоминание в различных выступлениях и интервью. Я уже делал про него заметку, хочу дополнить информацию. Кратко перечислю плюсы ➕ :

🔹простая установка, так как это всего лишь один бинарник, написанный на GO, есть в репозитории Debian
🔹очень хорошая производительность
🔹поддержка дедупликации, снепшотов на уровне данных
🔹разные бэкенды для хранения: локальная директория, sftp, S3, rclone и т.д.
🔹проверка целостности, шифрование

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

Для Prometheus есть готовый экспортёр метрик — restic-exporter. Указываете репозиторий, пароль к нему и получаете на выходе полезные метрики: статус проверок, количество снэпшотов, время последнего бэкапа, кол-во файлов в бэкапе, их размер и т.д. А бонусом идёт дашборд для Grafana.

Zabbix тоже имеет готовый шаблон для мониторинга за бэкапами, сделанными Restic. Его написали не разработчики, так как он в отдельном репозитории community-templates, но, тем не менее, они за ним следят и актуализируют к свежим версиям. Мониторинг работает через прокладку resticprofile, которая формирует конфигурационные файлы для бэкапов и умеет сохранять результаты работы в json файл.

Есть ещё один вариант для Zabbix — шаблон, который анализирует стандартный вывод от команды на бэкап или проверку архива. Для этого вывод нужно сохранять в лог файл, а потом скриптом его анализировать и отправлять результат через zabbix_sender. В указанном репозитории есть все примеры — шаблон и скрипты.

Вообще, решение с Prometheus выглядит более целостным, простым и удобным. Если бы мне сейчас нужно было мониторить бэкапы Restic, я бы взял именно его. А если всё же нужен Zabbix, то распарсил бы промовский экспортер. Там буквально, запускаем контейнер с restic-exporter и смотрим метрики:

# docker run -d \
 --name=restic-exporter \
 -v /mnt/backup:/data
 -e TZ=Europe/Moscow \
 -e RESTIC_REPO_URL=/data \
 -e RESTIC_REPO_PASSWORD=123 \
 -e REFRESH_INTERVAL=60 \
 -p 8001:8001 \
 --restart unless-stopped \
 ngosang/restic-exporter

# curl http://localhost:8001

Очень просто и удобно.

#backup

​​Одной из наиболее известных, если не самой известной, бесплатной платформой с открытым исходным кодом для организации онлайн конференций является BigBlueButton. Условно её можно назвать бесплатной заменой Zoom, которую можно поднять на своих серверах.

📌 Базовый функционал BigBlueButton:

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

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

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

С установкой и запуском базовой конфигурации особых проблем не будет. Продукт известный, в сети много руководств. Есть готовый bash скрипт для Ubuntu, который надо запустить, передав ему некоторые базовые параметры в виде домена и почтового ящика для учётной записи Let's Encrypt. Процесс подробно описан в документации. Установка будет выполнена с помощью deb пакетов из подключенного репозитория и кое-что будет запущено в Docker (greenlight — веб панель для управления).

Альтернативным вариантом установки может стать Ansible, с использованием которого написаны различные варианты разворачивания полной инфраструктуры. Например, вариант HA кластера, с PeerTube для стриминга, ELK для логов, Prometheus + Grafana для мониторинга — Ansible roles deploying BigBlueButton.

⇨ Сайт / Исходники / Документация / Demo

#видеоконференции

​​Для просмотра истории консольных команд в Linux есть соответствующая утилита history. Помимо неё есть ещё одна — fc. Я не знаю, кто и зачем её придумал. Функционал у неё довольно скромный и нет ничего такого, чего бы не умела history. Например, смотрим 5 последних команд:

# fc -l -5
# history 5

На самой fc я не буду подробно останавливаться, так как цель этой заметки не в ней. Я увидел эту команду и думаю, что это вообще такое. Захожу в Debian, пробую:

# man fc
No manual entry for fc

Пусто, нет информации. Ищу бинарник:

# which fc

Опять пусто. Думаю, наверное это алиас в виде обёртки над history.

# alias | grep fc

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

# type fc
fc is a shell builtin

Всё встало на свои места. Утилита fc входит в состав оболочки bash, наряду с pwd, cd, и, кстати, той же history и type. Так что, если хотите быстро понять, с чем имеете дело, используйте утилиту type. Она помогает увидеть, чем является конкретная команда — алиасом, частью оболочки или отдельным бинарником.

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

1️⃣ Сначала проверяются алиасы.
2️⃣ Потом проверяются встроенные в оболочку команды.
3️⃣ И только потом ищутся бинарники, определённые в $PATH, причем не абы как, а по порядку следования этих директорий в переменной слева направо.

Последнее особенно важно, так как иногда не очень понятно, почему при наличии разных версий python или php, по умолчанию выполняется какая-то конкретная версия, хотя ты явно не указывал использовать именно её. Просто она первая попалась в $PATH.

Зная последовательность проверки команд, можно временно сломать какую-то команду. Например, сделать алиас history и назначить ему какое-то другое действие:

# alias history='echo "Здесь истории нет"'
# history
Здесь истории нет

Пока не удалишь созданный алиас, утилита history запускаться не будет, потому что алиас первый в списке на исполнение. А проверить всё это можно с помощью ключа -a:

# type -a history
history is aliased to `echo "Здесь истории нет"'
history is a shell builtin

#bash #terminal

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

⏰ Первый сон был на тему шифровальщиков. Я писал недавно про них заметку, но не помню, то ли после сна о них вспомнил, то ли наоборот — сон был после заметки. Снится мне, как на мой рабочий ноутбук попадает шифровальщик. Я заметил неладное, когда увидел, что все системные иконки на рабочем столе превратились в ярлыки, нажатие на которые ни к чему не приводит. Пытаюсь открыть Этот компьютер (уже давно не Мой), но проводник не запускается.

Горячими клавишами запускаю диспетчер задач и вижу, что какой-то процесс занимает 100% CPU. Почему-то во сне уверенность, что это шифровальщик. Паники нет, потому что знаю, что есть бэкап всей системы с данными. Завершаю работу, но вместо реального завершения работы понимаю, что запускается какая-то заставка, которая имитирует завершение работы, но на самом деле продолжается шифрование. Выключаю ноут зажатием кнопки включения. После этого просыпаюсь и радуюсь, что не надо ничего восстанавливать из бэкапа, так как это был сон.

Кстати, такое поведение вируса никогда не видел. Мозг придумал всё это сам или с чьей-то помощью во сне.

⏰ Второй сон совсем недавно приснился. У меня в квартире почему-то постоянно работают мои сервера. Организована мини серверная. Одно время у меня так и было, я хостил сайты дома на самосборном сервере. Но быстро понял, что это так себе идея и больше к домашнему серверу не возвращался. У меня его и нет, кроме небольшого семейного NAS и пары тестовых гипервизоров (HyperV и Proxmox), которые включаются по необходимости, не часто. Возвращаюсь ко сну.

Мне поступает предложение от знакомого — разместить чужой сервер у меня дома. Причём платят прилично, даже больше чем на colocation в ЦОД. Я сначала обрадовался и принял предложение. Мне заплатили и привезли сервер. Потом я во сне начинаю соображать. А зачем они привезли свой сервер ко мне на квартиру, если дешевле разместить его в нормальном ЦОД, где намного стабильнее и интернет, и электроснабжение? Немного покумекав, я догадываюсь, что это может быть выгодно только тем, кто хочет заниматься какой-то противозаконной деятельностью, а виноват в итоге окажусь я, так как тут никакого договора и оплата налом. А в ЦОД надо на юр. лицо договор оформлять. В итоге отказываюсь от предложения и возвращаю уже переданную мне сумму за размещение. Просыпаюсь с мыслью, какой же я все-таки умный. Даже во сне я осторожен и меня так просто не провести 😁

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

#мысли

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

У человека был гипервизор Hyper-V, смотрящий напрямую в интернет. Встроенный брандмауэр включен, RDP порт открыт только по белым спискам IP. На хосте крутятся виртуалки, в одной из них установлена RouterOS (операционка от Микротик) со своим внешним IP. Все виртуалки в интернет ходят через неё. Соответственно, всё тоже закрыто, проброшены только нужные порты.

В какой-то момент на гипервизор установили Veeam Backup & Replication и не проконтролировали открытые порты. А он открыл для себя TCP 9401 на весь интернет. Через некоторое время через этот порт зашёл шифровальщик, всё зашифровал и оставил информацию, куда обращаться за расшифровкой.

Дальше пострадавшему повезло. Он зашёл в чат, рассказал, что денег нет и платить никто не будет, а сумма для него неподъёмная. И его почему-то пожалели и дали дешифратор. Он успешно всё расшифровал и заодно увидел в системе следы взлома в виде новой учётки с правами администратора. В чате на прощание парню дали подсказку, чтобы он обновил свой Veeam.

Он стал разбираться и нашёл относительно свежую уязвимость, через которую его скорее всего и взломали: CVE-2023-27532. The vulnerable process, Veeam.Backup.Service.exe (TCP 9401 by default), allows an unauthenticated user to request encrypted credentials.

❗️Лишний раз напоминаю, что следите за своими внешними IP адресами. Тут ошибка была в том, что гипервизор сидел на своём отдельном IP адресе напрямую во внешний интернет. Надо было его тоже закрыть Микротиком, раз он есть. Я всегда так делал, если есть отдельная виртуальная машина под шлюз. Пусть она закрывает всю виртуальную инфраструктуру и сам гипервизор. Главное, не забыть настроить её автозапуск, иначе после выключения доступа к гипервизору не будет.

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

⚠ У меня тоже были ситуации, когда гипервизор по ошибке оказывался открыт со стороны интернета. Например, программно погасил интерфейс с внешним интернетом, сетевые настройки не прописывал. А в какой-то момент по неизвестной мне причине, этот интерфейс стал активен, а провайдер выдавал настройки внешнего IP по DHCP. Я очень удивился, когда обнаружил свой гипервизор вместе с RDP доступным из интернета. Просто в порядке профилактики просканировал все внешние IP адреса и заметил это.

Так что, если используете Veeam Backup & Replication, обновляйтесь. И не выставляйте в интернет то, чему там не место. За этим надо регулярно следить, так как от ошибок и случайностей никто не застрахован.

📌 Полезные ссылки по теме:
▪ Esxi: меня взломали! Лечим и понимаем причину
▪ Автоматическая проверка серверов с помощью OpenVAS
▪ Проверка хостов на CVE на открытых портах
▪ Регулярная проверка с помощью Nmap
▪ Сетевой сканер для поиска уязвимостей - Nessus Scanner

Заберите список в закладки. Что-нибудь наверняка пригодится.

#security

​​Распространённая ситуация (картинка внизу 👇), когда люди не понимают работу айтишников или не могут правильно её оценить. Из-за этого некоторые специалисты сознательно делают что-то плохо, растягивают дела, создают видимость работы. Они это объясняют тем, что иначе трудно убедить заказчика или работодателя платить определённую сумму. Он заплатит только за фактическое время, а потом скажет, что я сижу без дела и платить мне не обязательно. На практике так реально бывает. Кого-то даже увольняют, считая, что и так всё хорошо работает. Перебьёмся фрилансером, приезжающим по заявкам. Иногда перебиваются, иногда нет.

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

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

Формулировки обтекаемые и человеку, который погружён в тему (шарит), понятно, что ему немного ездят по ушам. Но такие люди обычно и не спрашивают, чем занимается айтишник, итак понимают. А вот если человек не понимает его работу, то для него это сойдёт. К тому же, этот список не виртуальный, а реальный. Вы сможете его развернуть с подробностями, если у вас попросят. Вы же реально настроили бэкапы и проверяете их наличие и качество, просто автоматически. Но на создание этой системы ушло время, к тому же всё равно нужен контроль. То же самое с обновлениями. Так или иначе вы всё равно их регулярно ставите и если попросят подробности, то можно рассказать, что конкретно и зачем было обновлено. То же самое с сервером 1С. Подобная задача возникла, потому что от сервера 1С реально прилетали оповещения с мониторинга и приходилось как-то реагировать на них, тратить время.

Достаточно просто в конце дня подумать, чем ты занимался и оформить это в краткий список дел (3-5). Со временем это входит в привычку и занимает очень мало времени. Да и проверять эти списки чаще всего никто не будет, потому что на это надо время. У вас их проверят один-два раза, а потом либо вообще просить не будут, либо не будут проверять.

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

❗️Таким образом, записанный реальный список задач — это ваш надежный помощник, а не просто какая-то формальность, которая отнимает время. Причём не обязательно искать какой-то софт для них. Я в обычном текстовом формате их вёл и отправлял в основном по почте.

#мем

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

📌 Больше всего просмотров:
◽️Утилита ioping для анализа дисков (8863)
◽️Бэкап реп из github или gitlab (8038)
◽️Self-hosted система анализа посещений сайта PostHog (7910)

📌 Больше всего комментариев:
◽️Замена бесплатной почты для домена от Яндекс (381)
◽️Бесплатный программный шлюз Sophos Firewall Home Edition (107)
◽️Почтовый сервер Tegu (103)

📌 Больше всего пересылок:
◽️Бэкап и перенос систем с помощью ReaR (457)
◽️Утилита ioping для анализа дисков (366)
◽️Советы по безопасности для Debian от CIS (318)
◽️Подборка обучающих игр (315)

📌 Больше всего реакций:
◽️Описание работы протокола DHCP (196)
◽️Бэкап и перенос систем с помощью ReaR (157)
◽️Баг и отключение Credential Guard в Windows 11 (152)
◽️За что вам, айтишникам, вообще платят? (147)

#топ

Покажу на простом и наглядном примере методику защиты от типичных брутфорс атак (перебор учётных записей). Для этого возьму всем привычный инструмент nmap и популярный движок сайта Wordpress. Все настройки возьму с реально работающего сервера, где блокировка переборов паролей успешно работает.

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

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

В составе nmap есть готовый скрипт для брута админки Wordpress. Достаточно указать адрес сайта, учётную запись, например, admin и список паролей для перебора. Запускаем перебор:

# nmap example.com --script http-wordpress-brute --script-args \
'user=admin, passdb=password.lst, http-wordpress-brute.thread=3, brute.firstonly=true'

В логах веб сервера увидите POST запросы к /wp-login.php от user_agent="Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)". Этот скрипт удобно использовать для тестирования своей защиты.

Теперь расскажу, как работает защита от такого перебора с помощью fail2ban. Устанавливаете его в систему и делаете очень простой фильтр wp-login.conf, положив его в директорию /etc/fail2ban/filter.d:

[Definition]
failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).*

Он ищет все POST запросы к указанным url. Это защита от подборка учёток через wp-login и xmlrpc (последний лучше вообще отключить или закрыть доступ через nginx). Далее создаём настройку jail wp-login.conf и кладём её в директорию /etc/fail2ban/jail.d:

[wp-login]
enabled = true
port = http,https
action = iptables-multiport[name=WP, port="http,https", protocol=tcp]
filter = wp-login
logpath = /var/log/nginx/example.com/access.log
maxretry = 5

Это пример настроек, когда используется iptables. Теперь, как только в логе access.log появится более 5 попыток POST запросов к wp-login.php или xmlrpc.php, IP адрес обратившегося будет забанен. Это удобно проверить с помощью скрипта для nmap.

Подобным образом можно настроить защиту от перебора учётных записей любого сервиса, который записывает информацию об аутентификации в текстовый лог файл. Главное не забыть очень важный момент. Лог файл не должен быть очень большим. Обязательно необходима ротация по размеру файла. Если лог становится очень большим, то fail2ban может сам повесить сервер. Он написан, если не ошибаюсь, на Python и работает не очень быстро. Если вас начинают ддосить и access лог разрастается за минуту до гигабайтов, fail2ban вам сам повесит сервер. Его надо оперативно выключать. В отдельной заметке расскажу, как сделать более универсальную защиту без необходимости парсить access.log.

Более подробно с примерами эта настройка описана у меня на сайте в статье: Защита админки wordpress с помощью fail2ban.

Отдельно отмечу, что для fail2ban есть веб интерфейс — fail2web

#security #webserver #wordpress #fail2ban

Не надо вот так настраивать веб сервера. В тексте ошибки полная информация о системе. Всю техническую информацию о системе, веб сервере и его версии нужно отключать в настройках. Везде есть этот параметр. Например, в nginx это server_tokens off. По умолчанию он в режиме on.

И обязательно удаляйте или заменяйте стандартные заглушки от страниц с ошибками, особенно 404 и 502. Они иногда тоже выдают служебную информацию.

Кстати, если в поисковиках поискать что-то по подобным служебным строкам, то можно найти кучу сайтов с открытыми потрохами. Вот несколько примеров:
- http://www.zoonman.ru/files/
- https://gusto-ufa.ru/test.php
- https://neiroplus.ru/test/ (phpinfo в паблик вывалили)

Нашёл через Яндекс.

#webserver