ServerAdmin.ru. Страница 11

Чем заменить зарубежное ПО класса UTM и NGFW? 🛡 Вебинар для тех, кого интересует российский софт для импортозамещения. 🔝 В программе: ◽на что стоит обращать внимание при миграции с зарубежных решений ◽этапы перехода и их продолжительность ◽как сберечь бюджет предприятия на покупке дополнительного ПО ◽функциональные возможности ИКС ◽преимущества российской разработки ◽льготные условия перехода с программ-аналогов на ИКС ◽ответы на ваши вопросы Присоединяйтесь 🗓 17 мая в 11.00, и вы узнаете, как легко и эффективно мигрировать на надежное российское решение, сэкономив бюджет.  👉 Регистрация Предлагаем протестировать полнофункциональную версию ИКС (35 дней бесплатно), действует приоритетная техподдержка. 💎 ИКС — продукт класса NGFW, с большим количеством функций и веб интерфейсом: интернет-шлюз, DHCP, VPN, DNS прокси сервер, NAT, системы обнаружения и предотвращения вторжений IPS/IDS, контроль приложении, WAF, антивирус, файловый и VOIP сервер, контент-фильтр. ✅ Телеграм ИКС #реклама

Ещё один пример защиты веб сервера с помощью fail2ban. На этот раз пример будет более универсальный, который защитит не только от брута, но и от любых множественных подключений к серверу. Для этого нам понадобятся модули nginx limit_req и limit_conn. С их помощью можно ограничить скорость обработки запросов с одного IP адреса. Для этого в основной конфигурации nginx, в разделе http, нужно добавить одну или несколько зон с максимальной скоростью обработки запросов или количеством числа соединений с одного IP. Я обычно использую несколько зон, чаще всего четыре. Одна для общего ограничения соединений, вторая для статики, третья для легких динамических запросов (обычные php страницы), четвёртая для тяжёлых динамических запросов (аутентификация, поиск, формирование большого каталога и т.д.). Выглядят настройки примерно так: limit_conn_zone $binary_remote_addr zone=perip:10m; limit_req_zone $binary_remote_addr zone=lim_50r:10m rate=50r/s; limit_req_zone $binary_remote_addr zone=lim_10r:10m rate=10r/s; limit_req_zone $binary_remote_addr zone=lim_3r:10m rate=3r/s; Зону лучше называть по разрешённому лимиту, чтобы проще было использовать в настройках. Далее идём в конфиг виртуального хоста и там расставляем зоны в общей настройке server и разных locations. Примерно так: server { ... limit_conn perip 100; ... # поиск location /?s= { limit_req zone=lim_3r burst=5 nodelay; ... } # динамика location ~ \.php$ { limit_req zone=lim_10r burst=15 nodelay; ... } # всё остальное location / { limit_req zone=lim_50r burst=65 nodelay; ... } } Здесь главное без фанатизма использовать лимиты, особенно на общие страницы и статику, чтобы не блокировать поисковые системы или какие-то другие полезные боты. После настройки некоторое время понаблюдайте за ограничениями. Сработанные ограничения будут отображаться в error.log nginx. Его мы и будем проверять с помощью fail2ban. Для этого добавляем в директорию /etc/fail2ban/filter.d два конфига. nginx-limit-conn.conf: [Definition] failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting connections by zone.*client: <HOST> ignoreregex = nginx-limit-req.conf: [Definition] ngx_limit_req_zones = [^"]+ failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>, ignoreregex =  datepattern = {^LN-BEG} И в /etc/fail2ban/jail.d два файла конфигурации: nginx-limit-conn.conf [nginx-limit-conn] enabled = true filter = nginx-limit-conn port = http action = iptables-multiport[name=ConnLimit, port="http,https", protocol=tcp] logpath = /web/sites/*/logs/error.log bantime = 3600 maxretry = 20 nginx-limit-req.conf [nginx-limit-req] enabled = true filter = nginx-limit-req action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp] logpath = /web/sites/*/logs/error.log bantime = 3600 maxretry = 10 Теперь нарушители лимитов будут отправляться в бан. При этом не так критично разрастание логов, так как error лог редко растёт быстро, даже если вас ддосят. Но всё равно не нужно забывать про его ротацию. Все лимиты и реакции настраивайте в зависимости от вашей ситуации. Не надо брать мои значения из примера. Они сильно зависят от типа сайта и производительности сервера. Главное, как я уже сказал, без фанатизма. Лимиты должны быть комфортными для легитимных пользователей и систем. Есть более простой в плане нагрузки способ блокировать тех, кто открывает слишком много соединений. Использовать системную информацию о подключениях, например, с помощью netstat и если превышен лимит, отправлять IP в бан. Я не очень люблю этот способ и редко использую, так как нет гибкой настройки по сайтам, урлам и т.д. Его стоит использовать, если вас ддосят и вам надо максимально быстро и дёшево по ресурсам блокировать атакующих. Иногда это помогает, если ддос не очень сильный и провайдер вас не отключает. Если интересно посмотреть эту реализацию, то напишите в комментах, я расскажу с примером. #security #fail2ban #webserver #nginx

🔥 Пройдите тест по DevSecOps, ответьте на 25 вопросов и проверьте, насколько вы готовы к обучению на курсе — «Внедрение и работа в DevSecOps» в OTUS. Курс можно приобрести в рассрочку! ❗️На курсе вы научитесь интегрировать в CI/CD, использовать инструменты ИБ и обеспечивать безопасность в непрерывном процессе разработки и продакшена. Именно эти навыки дают мощное конкурентное преимущество IT-специалистам и повышают вашу привлекательность у крупных работодателей. 👉🏻 Пройти тест — https://otus.pw/bhRh/ 🎁 Сможете пройти успешно тест - получите доступ к 2 открытым урокам курса уже сейчас! #Реклама. Информация о рекламодателе на сайте www.otus.ru

Покажу на простом и наглядном примере методику защиты от типичных брутфорс атак (перебор учётных записей). Для этого возьму всем привычный инструмент 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

🔝Как обычно, традиционный топ постов за прошедший месяц. Надеюсь, вам хорошо отдыхается в эти праздники. Я наконец-то уехал на дачу до 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) #топ

​​Распространённая ситуация (картинка внизу 👇), когда люди не понимают работу айтишников или не могут правильно её оценить. Из-за этого некоторые специалисты сознательно делают что-то плохо, растягивают дела, создают видимость работы. Они это объясняют тем, что иначе трудно убедить заказчика или работодателя платить определённую сумму. Он заплатит только за фактическое время, а потом скажет, что я сижу без дела и платить мне не обязательно. На практике так реально бывает. Кого-то даже увольняют, считая, что и так всё хорошо работает. Перебьёмся фрилансером, приезжающим по заявкам. Иногда перебиваются, иногда нет. Я всегда решал подобные разногласия по-другому. Если я видел, что с руководителем могут возникать подобные разговоры, то просто скрупулёзно вёл список дел. И если меня кто-то спросит, чем я занимался в течении дня или на прошлой неделе, я спокойно покажу список дел. Если были какие-то аварии или настройка новых сервисов, то прямо об этом напишу. Тут все просто и понятно. Если не было чего-то особенного, а обычная рутина по обслуживанию, то оберну это примерно в такие формулировки: ◽Плановая проверка бэкапов, как по их наличию, так и возможности восстановления сохранённой информации ◽Анализ возможных уязвимостей используемого в инфраструктуре ПО, установка критических обновлений с предварительной проверкой их на тестовом стенде ◽Аудит потребления ресурсов сервером 1С. Присутствовали всплески потребления CPU, которые приводили к кратковременным задержкам в работе баз. Анализ вероятных причин и вариантов решения проблемы Формулировки обтекаемые и человеку, который погружён в тему (шарит), понятно, что ему немного ездят по ушам. Но такие люди обычно и не спрашивают, чем занимается айтишник, итак понимают. А вот если человек не понимает его работу, то для него это сойдёт. К тому же, этот список не виртуальный, а реальный. Вы сможете его развернуть с подробностями, если у вас попросят. Вы же реально настроили бэкапы и проверяете их наличие и качество, просто автоматически. Но на создание этой системы ушло время, к тому же всё равно нужен контроль. То же самое с обновлениями. Так или иначе вы всё равно их регулярно ставите и если попросят подробности, то можно рассказать, что конкретно и зачем было обновлено. То же самое с сервером 1С. Подобная задача возникла, потому что от сервера 1С реально прилетали оповещения с мониторинга и приходилось как-то реагировать на них, тратить время. Достаточно просто в конце дня подумать, чем ты занимался и оформить это в краткий список дел (3-5). Со временем это входит в привычку и занимает очень мало времени. Да и проверять эти списки чаще всего никто не будет, потому что на это надо время. У вас их проверят один-два раза, а потом либо вообще просить не будут, либо не будут проверять. Подробный список задач поможет убедить нанять помощника, если у вас действительно не хватает времени на все свои задачи. Также на основе своих задач вы сможете объяснить, почему новая задача откладывается на какой-то срок, так как сейчас вы занимаетесь другой. Со списком задач вы можете более предметно обсуждать повышение зарплаты. ❗️Таким образом, записанный реальный список задач — это ваш надежный помощник, а не просто какая-то формальность, которая отнимает время. Причём не обязательно искать какой-то софт для них. Я в обычном текстовом формате их вёл и отправлял в основном по почте. #мем

👾 Этичный Хакер — канал, где вас научат хакингу с нуля. ➖ТОП-10 опасных вирусов ➖Как сделать личный VPN и Proxy-сервер ➖Узнаём IP-адрес человека через Telegram ➖Wireshark — учимся сканировать сеть ➖Взлом хэшей паролей с помощью Hashcat Освой информационную безопасность в 2023 бесплатно — https://t.me/hack_less #реклама

Один подписчик вчера рассказал мне поучительную историю практически из первых уст от непосредственного участника. Была приложена вся первичка в виде технических подробностей и скринов, но я не буду на этом акцентировать ваше внимание, так как это второстепенная информация. У человека был гипервизор 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

Когда увлечён своей деятельностью, она тебя не отпускает даже во сне. В этом месяце приснились пару снов по рабочей тематике, которые не забылись, а очень хорошо закрепились в памяти. Решил с вами поделиться содержимым. ⏰ Первый сон был на тему шифровальщиков. Я писал недавно про них заметку, но не помню, то ли после сна о них вспомнил, то ли наоборот — сон был после заметки. Снится мне, как на мой рабочий ноутбук попадает шифровальщик. Я заметил неладное, когда увидел, что все системные иконки на рабочем столе превратились в ярлыки, нажатие на которые ни к чему не приводит. Пытаюсь открыть Этот компьютер (уже давно не Мой), но проводник не запускается. Горячими клавишами запускаю диспетчер задач и вижу, что какой-то процесс занимает 100% CPU. Почему-то во сне уверенность, что это шифровальщик. Паники нет, потому что знаю, что есть бэкап всей системы с данными. Завершаю работу, но вместо реального завершения работы понимаю, что запускается какая-то заставка, которая имитирует завершение работы, но на самом деле продолжается шифрование. Выключаю ноут зажатием кнопки включения. После этого просыпаюсь и радуюсь, что не надо ничего восстанавливать из бэкапа, так как это был сон. Кстати, такое поведение вируса никогда не видел. Мозг придумал всё это сам или с чьей-то помощью во сне. ⏰ Второй сон совсем недавно приснился. У меня в квартире почему-то постоянно работают мои сервера. Организована мини серверная. Одно время у меня так и было, я хостил сайты дома на самосборном сервере. Но быстро понял, что это так себе идея и больше к домашнему серверу не возвращался. У меня его и нет, кроме небольшого семейного NAS и пары тестовых гипервизоров (HyperV и Proxmox), которые включаются по необходимости, не часто. Возвращаюсь ко сну. Мне поступает предложение от знакомого — разместить чужой сервер у меня дома. Причём платят прилично, даже больше чем на colocation в ЦОД. Я сначала обрадовался и принял предложение. Мне заплатили и привезли сервер. Потом я во сне начинаю соображать. А зачем они привезли свой сервер ко мне на квартиру, если дешевле разместить его в нормальном ЦОД, где намного стабильнее и интернет, и электроснабжение? Немного покумекав, я догадываюсь, что это может быть выгодно только тем, кто хочет заниматься какой-то противозаконной деятельностью, а виноват в итоге окажусь я, так как тут никакого договора и оплата налом. А в ЦОД надо на юр. лицо договор оформлять. В итоге отказываюсь от предложения и возвращаю уже переданную мне сумму за размещение. Просыпаюсь с мыслью, какой же я все-таки умный. Даже во сне я осторожен и меня так просто не провести 😁 А вам снятся сны на профессиональную тему? Мне регулярно, но чаще всего их помнишь в тот же день утром, и уже к вечеру или на следующий день забываешь, если сразу не запишешь или не зафиксируешь в памяти. #мысли

➕ Открытые практикумы DevOps, Linux, Networks и Golang by Rebrain: расписание на май 2023 Мы проводим бесплатные практикумы на всевозможные IT темы. Основное — Kubernetes, Docker, Ansible, Gitlab CI, Linux, Kafka, MySQL, Golang и др. Работаем в консоли, разбираем реальные кейсы на практике. Анонсы публикуем на нашем канале в Telegram ↘️Подключайтесь 🟢2 мая DevOps: Использование регулярных выражений на примере анализа логов (Виктор Щупоченко - DevOps-engineer) 🟢3 мая Linux: Виртуальные интерфейсы и канальный уровень в Linux (Даниил Батурин - VyOS) 🟢4 мая Networks: Traffic Engineering (TE) (Дмитрий Радчук - Team Lead Вконтакте) 🟢10 мая Linux: ФСТЭК для Linux. Часть 2 (Андрей Буранов - Специалист по UNIX-системам VK) 🟢16 мая DevOps: Введение в Docker (Николай Лавинский - Тех. директор в ООО “Метод Лаб”) 🟢17 мая Linux: ФСТЭК для Linux. Часть 3 (Андрей Буранов - Специалист по UNIX-системам VK) 🟢18 мая Networks: Segment Routing (SR) (Дмитрий Радчук - Team Lead Вконтакте) 🟢23 мая DevOps by Rebrain (Александр Крылов - Lead DevOps В ПАО СК Росгосстрах) 🟢24 мая Linux: Сертификат WEB-сервера (Андрей Буранов - Специалист по UNIX-системам VK) 🟢25 мая Golang by Rebrain (Павел Грязнов - Go Senior Developer) 🟢30 мая DevOps: Шифрование секретов в GitOps (Василий Озеров - Co-Founder REBRAIN/Fevlake) 🟢31 мая Linux: Реализации протоколов маршрутизации для Linux (Даниил Батурин - VyOS) Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь! #реклама

​​Для просмотра истории консольных команд в 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

​​Одной из наиболее известных, если не самой известной, бесплатной платформой с открытым исходным кодом для организации онлайн конференций является BigBlueButton. Условно её можно назвать бесплатной заменой Zoom, которую можно поднять на своих серверах. 📌 Базовый функционал BigBlueButton: ◽ видео и аудио конференции в режиме реального времени ◽ проведение публичных презентаций ◽ чаты и опросы, сопровождающие конференции ◽ возможность показа рабочего стола выступающим ◽ запись конференций для последующего доступа к просмотру В общем случае BigBlueButton ориентируется на сферу обучения. То есть это в первую очередь инструмент учебных заведений для проведения онлайн лекций. В этой роли лично я и видел отзывы о продукте, в том числе от знакомых, которые работают в учебных заведениях. Продукт не сказать, что простой для установки и освоения. Очень много нюансов в плане потребления ресурсов, полосы пропускания, качества картинки, производительности и т.д. И дело тут не только в самой программе, сколько в тематике онлайн конференций. Это в целом технологичная и непростая отрасль. С установкой и запуском базовой конфигурации особых проблем не будет. Продукт известный, в сети много руководств. Есть готовый bash скрипт для Ubuntu, который надо запустить, передав ему некоторые базовые параметры в виде домена и почтового ящика для учётной записи Let's Encrypt. Процесс подробно описан в документации. Установка будет выполнена с помощью deb пакетов из подключенного репозитория и кое-что будет запущено в Docker (greenlight — веб панель для управления). Альтернативным вариантом установки может стать Ansible, с использованием которого написаны различные варианты разворачивания полной инфраструктуры. Например, вариант HA кластера, с PeerTube для стриминга, ELK для логов, Prometheus + Grafana для мониторинга — Ansible roles deploying BigBlueButton. ⇨ Сайт / Исходники / Документация / Demo #видеоконференции

💪 Пройди тест по MS SQL и проверь свои знания. Ответишь — пройдешь на углубленный курс "MS SQL Server разработчик" от OTUS по специальной цене + получишь запись мастер-класса от преподавателя курса🎁 . 📌 ПРОЙТИ ТЕСТ:   https://otus.pw/vH8u/ #Реклама. Информация о продукте www.otus.ru

​​Напоминаю про очень функциональное и удобное решение для бэкапов — 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

​​▶️ Информация для тех, кто учится или уже использует Ansible, но возможно не так, как следует: ⇨ Ansible плох? Нет, просто готовьте его правильно! Интересное выступление от специалиста в своей области знаний. Я после доклада захотел купить у него курс, но, как оказалось, как такового курса нет, а когда-то проводилось групповое обучение. В выступлении разобраны популярные по мнению автора ошибки при использовании Ansible. Основные: ◽использование шаблонизации yaml, как текстов, а не как структурированных данных ◽использование группы хостов all, а потом методом исключения добавляются условия ◽использование модулей python с зависимостями, которые непонятно что вам принесут в систему ◽использование Ansible для управления учётками и доступами на машинах ◽хранение инвентаря в формате ini ◽подмена тэгов условиями и т.д. Я лично собрал почти все ошибки, что были перечислены автором. Но тут мне не обидно, не питаю иллюзий. Мне в работе ансибл почти не нужен. Я по нему учился, немного писал плейбуки, пока не понял, что в моём формате работы на это уходит слишком много времени и это не окупается. У меня нет часто повторяющихся задач, либо большой однотипной инфраструктуры. Достаточно того, что я умею с ansible работать, могу читать чужие плейбуки, править их под свои нужды, дебажить и в целом пользоваться инструментом. Ещё полезные материалы по Ansible от этого автора: ▪ Ansible это вам не bash (текст, видео) ▪ Блеск и нищета Ansible ▪ Ansible-vault decrypt: обходимся без Ansible ▪ Ускоряем Ansible Единственное, что не понравилось — автор несколько раз акцентированно сослался на то, что в русскоязычном ютубе не стоит смотреть обучающие видео по ansible, так как там полно ошибок. Но при этом его же выступления я посмотрел в русскоязычном ютубе. При чём тут русский язык и ютуб, я не понял. Надо смотреть, у кого ты учишься и понимать, какого уровня информацию ты можешь получить. Например, у меня учиться не надо, я не учитель и не акцентируюсь на правильных решениях или точности формулировок. Просто пишу свои заметки. Их достаточно принимать к сведению. #видео #ansible

Внедряем, сопровождаем и обучаем 🔎ElasticSearch 🔎OpenSearch Подписывайтесь на наш канал @elasticstack_ru Разбираемся в кейсах безопасности, логирования, поиска и APM-мониторинга. На базе одной из этих бесплатных систем создадим для вас систему управления событиями информационной безопасности. Вы всегда будете знать: ⚡️ кто и когда создал удалил новую учетную запись или группу в AD или Linux ⚡️ кто открывал, создавал или удалял файлы на файловом хранилище ⚡️ кто и когда подключался к 1С, веб-ресурсам компании, рабочим станциям, серверам или по VPN ⚡️ какие веб-ресурсы посещали пользователи (например, по данным прокси Касперского) ⚡️ когда происходит подбор пароля ⚡️ и о многих других событиях. Все собранные данные мы аккуратно визуализируем в Kibana/OpenSearch Dashboards, чтобы вы могли видеть полную картину происходящего. По каждому событию настроим уведомления в почту или телеграм. Также мы проконсультируем по эффективному использованию этих систем в качестве SIEM-системы. Если у вас уже есть в эксплуатации ElasticSearch/OpenSearch, мы займёмся его развитием и сопровождением или проведем для вас обучение на специализированных курсах по ElasticSearch и OpenSearch. Запрос можно оставить через форму обратной связи на нашем сайте, отправить в адрес [email protected] либо написать в телеграм @galssoftware. #реклама

​​Необходимо внедрить в небольшой компании примерно на 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

Хочу порассуждать с вами на тему, которая интересна лично мне. И по которой у меня нет однозначного мнения, что лучше делать вот так, а не иначе. Речь пойдёт про интеграцию аутентификации с единым LDAP каталогом. Удобно, когда для аутентификации используется единый каталог. Когда все сервисы в закрытом периметре, никаких проблем не вижу. А если речь идёт, например, о почте, или о VPN подключениях? Эти сервисы люди используют, получая к ним доступ через интернет. Я много раз сталкивался, что учётные данные от почты утекают куда-то на сторону и через сервер начинают рассылать спам. Когда это отдельная учётная запись только от почты, никаких проблем нет. Сменил её и всё, кроме спама никаких последствий. А если это учётная запись от всех сервисов пользователя, то последствия могут быть серьёзнее, в зависимости от организации инфраструктуры. То же самое и для VPN. Нужно обязательно добавлять второй фактор. Но тогда и упрощения никакого нет, как и удобства для пользователя. Удобнее становится запароленный сертификат отдать, от которого пароль вручную вводить надо. Я лично всегда для почты и VPN делал отдельные учётные записи, не интегрируя их в общий каталог. Да, это неудобно, но для малого и среднего бизнеса, где и пользователей не много, и текучка не такая большая, считаю это оправданным. Отнимает не так много времени в месяц пару-тройку учёток сделать или заблокировать. Зато так спокойнее. ❓А вы что думаете на этот счёт? Как обычно настраиваете? В первую очередь почта и VPN интересуют. #разное