Расскажу старую историю про взлом Микротика, который я лично наблюдал. Публиковал её давно, когда на канале было в разы меньше читателей, так что большинство из тех, кто читает канал сейчас, её не видели. А история показательная и поучительная.
Ко мне обратился знакомый с просьбой помочь разгрести последствия взлома локальной сети. Я у него администрировал сервера в ЦОД, а к локалке не имел никакого отношения. Расскажу кратко то, что узнал сам.
На входе стоит Mikrotik, в который воткнут usb модем провайдера сотовой сети. Интернет заходит через него. На Микротике был обнаружен VPN канал злоумышленника. С его помощью он закрепился в локальной сети и изучал ее.
Проблемы заметили со стороны ip телефонии. Позвонил провайдер и предупредил, что звонки заблокированы, так как израсходован дневной лимит. Это позволило сразу обнаружить взлом, который был осуществлен в выходной день. При этом было настроено ограничение по IP на подключения к облачной АТС. Считается, что это самая надежная защита, так как физически невозможно осуществить звонок извне, даже если утекают учётные данные пиров. По факту это не спасло, так как через VPN канал это ограничение обошли. Повезло, что был дневной лимит.
Дальше были обнаружены попытки аутентификации на других устройствах в сети. На вид ничего особо не пострадало, так как в локалке ничего кроме компьютеров, оргтехники и VOIP телефонов не было. Все сервера располагались в другом месте и судя по всему не были обнаружены, а пользовательские компьютеры все были выключены. Поэтому и не получилось их найти.
Это все подробности, что стали известны мне. Как произошел взлом Микротика, точно не известно. Его сразу же перенастроили и закрыли все доступы извне. Там либо пароль был простой, либо обновлений не стояло. Думаю, сломали стандартно, через уязвимость и доступ через Winbox. Он был доступен. А там время от времени всплывают уязвимости. Может и сейчас есть, но мы их пока не знаем.
Отсюда можно сделать несколько закономерных выводов:
1️⃣ Доступ к пограничным роутерам запрещать максимально сильно. Лучше снаружи вообще всё закрыть. Если всё же нужно оставить доступ, то настройте хотя бы Port knocking или доступ по спискам IP. Касательно Микротик, надо дополнительно отключить все способы удалённого подключения, которые вы не используете (FTP, SSH и т.д.).
2️⃣ Сервера изолировать от всего остального. Я не всегда следую этому правилу 😔.
3️⃣ На выходные компьютеры в офисе выключать.
4️⃣ Использовать дневной лимит на звонки через VOIP телефонию, если оператор поддерживает. Меня, кстати, не раз выручала эта история. Были инциденты. Вроде даже писал об этом. Надо будет поискать эти старые публикации и повторить. Уже и сам подзабыл подробности.
5️⃣ Всегда и везде своевременно ставить обновления.
Так то много всего надо делать для обеспечения безопасности, но это прям самая база, которая закрывает большинство проблем.
#mikrotik
Ко мне обратился знакомый с просьбой помочь разгрести последствия взлома локальной сети. Я у него администрировал сервера в ЦОД, а к локалке не имел никакого отношения. Расскажу кратко то, что узнал сам.
На входе стоит Mikrotik, в который воткнут usb модем провайдера сотовой сети. Интернет заходит через него. На Микротике был обнаружен VPN канал злоумышленника. С его помощью он закрепился в локальной сети и изучал ее.
Проблемы заметили со стороны ip телефонии. Позвонил провайдер и предупредил, что звонки заблокированы, так как израсходован дневной лимит. Это позволило сразу обнаружить взлом, который был осуществлен в выходной день. При этом было настроено ограничение по IP на подключения к облачной АТС. Считается, что это самая надежная защита, так как физически невозможно осуществить звонок извне, даже если утекают учётные данные пиров. По факту это не спасло, так как через VPN канал это ограничение обошли. Повезло, что был дневной лимит.
Дальше были обнаружены попытки аутентификации на других устройствах в сети. На вид ничего особо не пострадало, так как в локалке ничего кроме компьютеров, оргтехники и VOIP телефонов не было. Все сервера располагались в другом месте и судя по всему не были обнаружены, а пользовательские компьютеры все были выключены. Поэтому и не получилось их найти.
Это все подробности, что стали известны мне. Как произошел взлом Микротика, точно не известно. Его сразу же перенастроили и закрыли все доступы извне. Там либо пароль был простой, либо обновлений не стояло. Думаю, сломали стандартно, через уязвимость и доступ через Winbox. Он был доступен. А там время от времени всплывают уязвимости. Может и сейчас есть, но мы их пока не знаем.
Отсюда можно сделать несколько закономерных выводов:
Так то много всего надо делать для обеспечения безопасности, но это прям самая база, которая закрывает большинство проблем.
#mikrotik
Please open Telegram to view this post
VIEW IN TELEGRAM
🔍 Хотите освоить регулярные выражения для системного администрирования? Погрузитесь в мир grep, sed и awk!
📅 На вебинаре вы узнаете, как читать, писать и применять регулярные выражения для реальных задач в Linux. Изучите различия между основными типами регулярных выражений (Basic, Extended, PCRE) и научитесь использовать их в системных утилитах.
✨ В результате вебинара вы поймёте, как составлять шаблоны для поиска, фильтрации и парсинга логов, а также как отлаживать и тестировать регулярные выражения на практике. Получите практические советы и рабочие шаблоны для повседневной работы.
Все участники вебинара получат скидку на курс "Administrator Linux. Professional".
👉 Для участия зарегистрируйтесь https://clck.ru/3LVkpY
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
📅 На вебинаре вы узнаете, как читать, писать и применять регулярные выражения для реальных задач в Linux. Изучите различия между основными типами регулярных выражений (Basic, Extended, PCRE) и научитесь использовать их в системных утилитах.
✨ В результате вебинара вы поймёте, как составлять шаблоны для поиска, фильтрации и парсинга логов, а также как отлаживать и тестировать регулярные выражения на практике. Получите практические советы и рабочие шаблоны для повседневной работы.
Все участники вебинара получат скидку на курс "Administrator Linux. Professional".
👉 Для участия зарегистрируйтесь https://clck.ru/3LVkpY
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
⇨ Мониторинг и Логи ПРОДАКШЕН уровня — Grafana + Loki + Prometheus + Promtail
Подробное видео про настройку указанного стека от Python разработчика. Качественное видео. Даётся база, так что если вы всё это настраивать уже умеете, вряд ли узнаете что-то новое. Отдельно отмечу, что автор показывает пример простого приложения и интеграцию его логов и метрик в указанный стек.
⇨ Moodle - an incredibly powerful online training platform
Обзор open source платформы, на базе которой можно организовать обучающие онлайн курсы. Видео обзорное, будет полезно только тем, кто подбирает себе подобный инструмент. Продукт вполне стабилен и функционален.
🔥CURSOR AI - Установка, Настройка и Использование для DEVOPS
Руководство от Астахова Дениса, автора канала ADV-IT. У него почти всегда интересные видео, если они не про AWS. Всегда с удовольствием смотрю, даже если он там кулеры от своего ноута чистит. Тут он показал пример работы в редакторе с участием AI.
⇨ Установка и настройка Proxmox в 2025 году от А до Я (установка и подготовка к работе с нуля)
Простое обзорное видео. Интересно будет только тем, кто Proxmox либо вообще не ставил, либо новичок в нём и хочет что-то узнать о практике настройки других специалистов.
⇨ ОСОБЕННОСТИ УСТАНОВКИ ПРОГРАММ В СБОРКЕ САМОХОСТИНГ. 3/3 Ролик в серии PVE Samohosting Edition
Автор устанавливает различный софт на Proxmox, который считает для себя полезным. Я последнее время проматываю его ролики, потому что они очень длинные и конкретно для меня не очень актуальные. Я в основном всё, что он рассказывает, и так знаю. Но тем не менее, видео качественные, с хорошим монтажом и содержанием. Рекомендую, если вам интересна тема домашнего сервера, Proxmox и различного прикладного софта на нём для личных и семейных нужд.
⇨ DNS Failover designs for Home Lab: Pi-Hole, Unbound, Windows Server, Nebula Sync and more!
Хорошее обзорное видео про DNS Failover с примерами реализации.
⇨ Протокол TCP | Компьютерные сети 2025 - 28
Очередной обновлённый урок бесплатного курса по сетям от Созыкина Андрея.
⇨ I Rebuilt My Home Server — Quieter, Faster, and Ready for 2025
Интересное видео про сборку домашнего сервера. Хорошая картинка, монтаж и в целом интересно посмотреть на домашнюю лабораторию этого блогера.
⇨ What hardware runs in my HomeLab in 2025?
Интересный обзор домашней лабы блогера Christian Lempa. Его лабу я ещё не видел и здесь не публиковал. У него там акцент не на железо и картинки серверной, а на схемы сети и описание. Интересно посмотреть. Сама серверная выглядит более-менее приземлённо, а не как у некоторых, шик и блеск.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Мониторинг и Логи ПРОДАКШЕН уровня — Grafana + Loki + Prometheus + Promtail
Поднимаем всю инфраструктуру для мониторинга и логирования — в одном видео!
Развернуть выделенный сервер с сетевыми дисками: https://slc.tl/hhkr1
Получи PDF схему из видео и репозиторий с кодом — напиши слово GRAFANA в боте: https://t.me/ArtemShumeikoBot…
Развернуть выделенный сервер с сетевыми дисками: https://slc.tl/hhkr1
Получи PDF схему из видео и репозиторий с кодом — напиши слово GRAFANA в боте: https://t.me/ArtemShumeikoBot…
Посмотрел небольшой ролик про удобное рабочее место человека с сидячей работой, который захотел обсудить, прокомментировать и дополнить своим опытом. Думаю, это будет полезно с учётом того, что у меня большой личный опыт по этой части.
Тех, кто не читал мои прошлые публикации на тему сидячей работы и болей в спине, отправляю в прошлые заметки по тэгу #спина. Повторяться не хочу. Отмечу только, что у меня большой стаж хронических болей в мышцах, которые привели к осложнениям в виде миофиброза, протрузий и грыж. Сейчас живу относительно нормально, ничего особо не болит, научился делать простую профилактику, которая мне помогает.
▶️ Рабочее место программиста БЕЗ БОЛЕЙ В СПИНЕ // Девайсы для здоровья и продуктивности работы из дома
Пройдусь по пунктам из видео и прокомментирую их.
1️⃣ Рабочий стол со сменой положения сидя и стоя. Я за таким работал несколько лет. В целом, мне нравилось. Важно понимать одну простую вещь и дальше вы уже сами сможете выработать правильные привычки и приобрести подходящие предметы. К болям в спине, шее и других отделах чаще всего приводит перегрузка мышц. Причём она может быть как от казалось бы небольшой, но постоянной статической нагрузки (сидение в неестественной позе), так и разовой динамической (поднял что-то очень тяжёлое). Поэтому от болей в спине страдают одинаково как физически развитые и сильные люди, так и задохлики, которые тяжести вообще не поднимают.
Стол со сменой положений позволяет разгружать одни мышцы и нагружать другие и так несколько раз в течении дня. Практически одинаково вредно как целый день сидеть, так и целый день стоять в одной позе, поэтому такой стол не панацея. Можно и сидя постоянно менять положение, разминаться, и в целом всё будет нормально.
Автор отмечает этот момент и дополняет стоячий режим работы специальной подставкой под ноги, которая заставляет постоянно немного двигаться и не застаиваться. Совет разумный, который практически наверняка вам поможет и уменьшит проблемы со спиной если вы просто купите такой стол и будете менять положения.
2️⃣ Фитбол или различные стулья без спинок, чтобы держать спину ровно. Лично я эту рекомендацию не разделяю и вообще удивился, когда увидел фитбол у автора. Ранее он справедливо заметил, что к проблемам спины приводит постоянная перегрузка мышц. Но фитбол как раз и вызывает постоянную перегрузку, так как нужно без дополнительной поддержки держать спину. Мой опыт показывает, что это провальная тактика. Когда я пытался следовать рекомендации держать спину ровно, чтобы мышцы не расслаблялись и работали, неизменно получал боли в спине. Сидеть весь день с напряжённой спиной вредно. Побалансировать 15-20 минут на фитболе возможно и будет полезно, но долго сидеть на нём не рекомендую. Надо подбирать удобное кресло с поддержкой поясницы и головы, в котором ты сидишь максимально расслабленно. Посидел, поработал и пошёл размялся.
3️⃣ Источник света сбоку от рабочего места со сменой яркости в зависимости от деятельности. Я привык работать с верхним светом от люстр и светильников. Дополнительно рабочее место не подсвечиваю.
4️⃣ Автоматический корректор осанки. Небольшая электронная приблуда, которая запоминает заданное положение тела и сигнализирует, когда оно меняется. Не уверен, что это имеет смысл. Обычно человек стремится оказаться в расслабленной позе, чтобы не напрягать мышцы. Другое дело, что часто эта поза оказывается нефизиологичной, расслабляет одни мышцы (например, спину), но перегружает другие (шею), что приводит к проблемам. Лучше подобрать кресло или положение стоя где ты и расслаблен, и находишься в удобной позе.
5️⃣ Смартфон вне зоны внимания, уведомления отключены. Тоже так делаю.
6️⃣ Наушники с шумоподавлением. Постоянно использую уже много лет, рекомендую.
7️⃣ Техника Pomodoro с интервальной работой циклами по 25 минут и отдыхом. Я не пробовал так работать, не знаю, насколько удобно и эффективно.
Надеюсь, вам будет полезна эта информация. В целом в видео всё поделу рассказано. Мне понравилось.
#спина
Тех, кто не читал мои прошлые публикации на тему сидячей работы и болей в спине, отправляю в прошлые заметки по тэгу #спина. Повторяться не хочу. Отмечу только, что у меня большой стаж хронических болей в мышцах, которые привели к осложнениям в виде миофиброза, протрузий и грыж. Сейчас живу относительно нормально, ничего особо не болит, научился делать простую профилактику, которая мне помогает.
Пройдусь по пунктам из видео и прокомментирую их.
Стол со сменой положений позволяет разгружать одни мышцы и нагружать другие и так несколько раз в течении дня. Практически одинаково вредно как целый день сидеть, так и целый день стоять в одной позе, поэтому такой стол не панацея. Можно и сидя постоянно менять положение, разминаться, и в целом всё будет нормально.
Автор отмечает этот момент и дополняет стоячий режим работы специальной подставкой под ноги, которая заставляет постоянно немного двигаться и не застаиваться. Совет разумный, который практически наверняка вам поможет и уменьшит проблемы со спиной если вы просто купите такой стол и будете менять положения.
Надеюсь, вам будет полезна эта информация. В целом в видео всё поделу рассказано. Мне понравилось.
#спина
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Рабочее место программиста БЕЗ БОЛЕЙ В СПИНЕ // Девайсы для здоровья и продуктивности работы из дома
Миша делится девайсами, которые помогли ему избавиться от болей в спине и повысить концентрацию внимания во время работы за компьютером.
✈️ 🇺🇸 РЕЛОКЕЙТ в США со мной — http://ocitizens.com/ (uDevs Inc.)
⏱ ТАЙМИНГ:
0:00 - Почему этот выпуск необычный
1:07…
✈️ 🇺🇸 РЕЛОКЕЙТ в США со мной — http://ocitizens.com/ (uDevs Inc.)
⏱ ТАЙМИНГ:
0:00 - Почему этот выпуск необычный
1:07…
23 апреля встречаемся на ну ооочень техническом митапе «Метрокластер на отечественном»
Что в программе?
▪️Разбор архитектуры и нюансов технологии метрокластера, особенностей проектирования и реализации
▪️Live-demo работы решения на отечественном оборудовании и ПО
Вы увидите, как ведет себя прикладное ПО при выходе из строя отдельных компонентов кластера и продуктивной площадки целиком.
В составе стенда два набора оборудования:
▪️СХД Аэродиск
▪️Сервер виртуализации Aquarius под управлением zVirt
▪️Коммутатор Qtech
и один набор ПО:
▪️СУБД Postgres Pro под синтетической нагрузкой
▪️Платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных
Между двумя площадками эмулируется расстояние 60 км. Отслеживать состояние комплекса будет система мониторинга «Пульт».
🗓 Когда?
23 апреля, 16:00
✅ Регистрация
Что в программе?
▪️Разбор архитектуры и нюансов технологии метрокластера, особенностей проектирования и реализации
▪️Live-demo работы решения на отечественном оборудовании и ПО
Вы увидите, как ведет себя прикладное ПО при выходе из строя отдельных компонентов кластера и продуктивной площадки целиком.
В составе стенда два набора оборудования:
▪️СХД Аэродиск
▪️Сервер виртуализации Aquarius под управлением zVirt
▪️Коммутатор Qtech
и один набор ПО:
▪️СУБД Postgres Pro под синтетической нагрузкой
▪️Платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных
Между двумя площадками эмулируется расстояние 60 км. Отслеживать состояние комплекса будет система мониторинга «Пульт».
🗓 Когда?
23 апреля, 16:00
✅ Регистрация
В пятницу рассказал про реальный случай взлома Микротика. Имеет смысл дополнить ту заметку информацией о том, как защитить свой роутер от подобных историй. Я не буду составлять полную подборку настроек, так как их любой ИИ сейчас бесплатно составит за 5 секунд. Расскажу, что лично я обычно делаю. Не всегда и не везде весь предложенный список, а в каких-то вариациях.
1️⃣ System ⇨ Users, отключаю или удаляю админа, добавляю нового пользователя с полными правами.
2️⃣ IP ⇨ Services, отключаю всё, кроме ssh и winbox. Ограничение доступа через параметр Aviable From в этом разделе не настраиваю. Предпочитаю все настройки по ограничению доступа делать в Firewall.
3️⃣ System ⇨ Logging, настраиваю отправку логов куда-то вовне, если инфраструктура предполагает такой сервис. Обычно это Syslog или ELK.
4️⃣ IP ⇨ Firewall, тут зависит от функциональности роутера, но что касается доступа извне, то закрываю либо статическим списком IP адресов, либо настраиваю Port knocking. Даже если настроен VPN, всегда страхую доступ извне каким-то ещё входом, не только по VPN.
5️⃣ Настраиваю мониторинг стандартным шаблоном Zabbix. Но сразу скажу, что не очень его люблю. Не потому, что он сделан плохо, а просто там много информации и триггеров, которые мне не нужны. Потом много спама прилетает, приходится править или отключать какие-то триггеры.
6️⃣ Знаю, что некоторые ещё отключают прямой доступ по MAC адресу в Tools ⇨ MAC Server ⇨ MAC WinBox Server, но я обычно оставляю.
В целом по безопасности у меня всё. Если есть чем ещё дополнить из вашей практики, поделитесь информацией.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mikrotik
1️⃣ System ⇨ Users, отключаю или удаляю админа, добавляю нового пользователя с полными правами.
2️⃣ IP ⇨ Services, отключаю всё, кроме ssh и winbox. Ограничение доступа через параметр Aviable From в этом разделе не настраиваю. Предпочитаю все настройки по ограничению доступа делать в Firewall.
3️⃣ System ⇨ Logging, настраиваю отправку логов куда-то вовне, если инфраструктура предполагает такой сервис. Обычно это Syslog или ELK.
4️⃣ IP ⇨ Firewall, тут зависит от функциональности роутера, но что касается доступа извне, то закрываю либо статическим списком IP адресов, либо настраиваю Port knocking. Даже если настроен VPN, всегда страхую доступ извне каким-то ещё входом, не только по VPN.
5️⃣ Настраиваю мониторинг стандартным шаблоном Zabbix. Но сразу скажу, что не очень его люблю. Не потому, что он сделан плохо, а просто там много информации и триггеров, которые мне не нужны. Потом много спама прилетает, приходится править или отключать какие-то триггеры.
6️⃣ Знаю, что некоторые ещё отключают прямой доступ по MAC адресу в Tools ⇨ MAC Server ⇨ MAC WinBox Server, но я обычно оставляю.
В целом по безопасности у меня всё. Если есть чем ещё дополнить из вашей практики, поделитесь информацией.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mikrotik
Telegram
ServerAdmin.ru
Расскажу старую историю про взлом Микротика, который я лично наблюдал. Публиковал её давно, когда на канале было в разы меньше читателей, так что большинство из тех, кто читает канал сейчас, её не видели. А история показательная и поучительная.
Ко мне обратился…
Ко мне обратился…
Достаем листочки, сейчас будет контрольная!
Задача: подобрать подходящий сервер для компании. И на этот раз без “долго и мучительно”. А просто и с комфортом благодаря нашей шпаргалке. Собрали важные рекомендации в одном доке — забирайте!
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJDJ6wA
@itelon_servers
Задача: подобрать подходящий сервер для компании. И на этот раз без “долго и мучительно”. А просто и с комфортом благодаря нашей шпаргалке. Собрали важные рекомендации в одном доке — забирайте!
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJDJ6wA
@itelon_servers
Как вы относитесь к работе с ночными дежурствами? Я – крайне отрицательно. Причём речь идёт не о постоянном дежурстве, когда ты сидишь в свои заранее оговорённые рабочие часы, а о ситуациях, когда ты уже отработал своё время, но тебе могут позвонить во внерабочее в случае аварии и попросить что-то сделать.
У меня был опыт работы пару лет на таких условиях. Мне могли позвонить в выходной или поздно вечером. Делали это не часто, может раз в месяц-два, но меня всё равно напрягало то, что могут позвонить в любой момент, даже при условии, что у меня не было обязанности любой ценой начинать решать проблемы. Но даже простой звонок с вопросом или просьбой сделать что-то несрочное мог испортить выходной день, так как из головы уже не выходил этот разговор и над тобой висела незаконченная задача.
А после пары ночных аварий, когда пришлось практически до утра разбираться с проблемой, окончательно решил, что на таких условиях больше работать не хочу и не буду. Ушёл оттуда и больше никогда не работал с теми системами и задачами, которые требуют участия в нерабочее время и не могут подождать.
Смотрел разные видео одного блогера (Антон Павленко) по поводу работы. Он рассказывал, что тоже работал с ночными дежурствами по похожей схеме и подорвал здоровье. И теперь при поиске работы отсутствие ночных дежурств – одно из основных требований. Я полностью поддерживаю такой подход.
Лет до 30 ещё можно не замечать вреда от подобных вещей, но чем старше становишься, тем яснее понимаешь, что твоё здоровье важнее работы и зарплаты. И кроме тебя никто о нём не позаботится, иначе потом отдашь денег больше, чем заработал. Лучше проиграть в деньгах, но жить в спокойном графике без лишних стрессов и ночных побудок. Если бизнес и его сервисы не терпят простоя, пусть организовывают дежурные смены с постоянным графиком или закрывают эти вопросы через найм людей в разных часовых поясах.
Но по факту практически всегда находятся люди, готовые работать за доплату (а некоторые и без неё) с дежурствами помимо основного графика, пока у них так же не начнутся проблемы со здоровьем. Берегите себя, своё здоровье и не соглашайтесь работать на таких условиях. Здоровье практически всегда обходится дороже заработанных денег за его счёт.
#мысли #совет
У меня был опыт работы пару лет на таких условиях. Мне могли позвонить в выходной или поздно вечером. Делали это не часто, может раз в месяц-два, но меня всё равно напрягало то, что могут позвонить в любой момент, даже при условии, что у меня не было обязанности любой ценой начинать решать проблемы. Но даже простой звонок с вопросом или просьбой сделать что-то несрочное мог испортить выходной день, так как из головы уже не выходил этот разговор и над тобой висела незаконченная задача.
А после пары ночных аварий, когда пришлось практически до утра разбираться с проблемой, окончательно решил, что на таких условиях больше работать не хочу и не буду. Ушёл оттуда и больше никогда не работал с теми системами и задачами, которые требуют участия в нерабочее время и не могут подождать.
Смотрел разные видео одного блогера (Антон Павленко) по поводу работы. Он рассказывал, что тоже работал с ночными дежурствами по похожей схеме и подорвал здоровье. И теперь при поиске работы отсутствие ночных дежурств – одно из основных требований. Я полностью поддерживаю такой подход.
Лет до 30 ещё можно не замечать вреда от подобных вещей, но чем старше становишься, тем яснее понимаешь, что твоё здоровье важнее работы и зарплаты. И кроме тебя никто о нём не позаботится, иначе потом отдашь денег больше, чем заработал. Лучше проиграть в деньгах, но жить в спокойном графике без лишних стрессов и ночных побудок. Если бизнес и его сервисы не терпят простоя, пусть организовывают дежурные смены с постоянным графиком или закрывают эти вопросы через найм людей в разных часовых поясах.
Но по факту практически всегда находятся люди, готовые работать за доплату (а некоторые и без неё) с дежурствами помимо основного графика, пока у них так же не начнутся проблемы со здоровьем. Берегите себя, своё здоровье и не соглашайтесь работать на таких условиях. Здоровье практически всегда обходится дороже заработанных денег за его счёт.
#мысли #совет
Пару лет назад у VictoriaMetrics вышел продукт, который является частью именного стека, – VictoriaLogs. Руки не доходили раньше на него посмотреть и вот дошли. Сразу скажу, что всё очень понравилось за простоту, функциональность и удобство. Покажу сразу с примерами.
Отдельно перечислю особенности VictoriaLogs:
▪️По своей сути это одиночный бинарник, который можно сконфигурировать ключами запуска, не нужен даже конфигурационный файл.
▪️В бинарнике есть всё, что надо для сбора и просмотра логов: веб интерфейс, метрики для мониторинга за системой, все типы приёмников логов.
▪️Для бэкапа достаточно скопировать директорию с данными, например, с помощью rsync. То есть вообще никаких проблем и заморочек с бэкапом.
▪️Есть плагин для datasource в Grafana, чтобы делать оттуда запросы к логам, а также готовый дашборд для визуализации метрик хранилища.
▪️Простая, короткая документация, где есть всё необходимое для запуска и настройки.
Покажу примеры сбора логов в VictoriaLogs от Journald, Syslog и Vector. Для этого подготовил небольшой
Запускаем проект, переходим на порт 9428, чтобы убедиться в том, что всё запустилось. По умолчанию открывается страница с некоторыми ссылками на Web UI, Метрики и ключи запуска.
Отправим в VictoriaLogs логи от systemd от любого сервера, локального или внешнего. Для этого понадобится служба systemd-journal-remote. Ставим её:
Редактируем конфиг
URL, соответственно, измените, если у вас сбор логов не с локального сервера, а удалённого. Запускаем службу и проверяем, что она успешно начала отправку логов:
Идём в веб интерфейс VictoriaLogs - http://212.193.59.87:9428/select/vmui и смотрим там логи.
Переходим к Syslog. Я уже добавил параметр
Если у вас этот порт уже занят syslog сервером, то измените порт для VictoriaLogs. В общем-то настраивать больше ничего не надо. Теперь в любом софте, который умеет отправлять данные в формате syslog, укажите в качестве сервера IP вашего VictoriaLogs. Например, в том же Микротике: System ⇨ Logging ⇨ Actions ⇨ Add Type Remote.
Для сбора логов от всех популярных агентов, типа Filebeat, Fluentd, Vector и т.д. тоже ничего специально настраивать не надо. Делаете всё точно так же, как для отправки логов в Elasticsearch, только в качестве endpoint указываете URL от вашего сервера VictoriaLogs. Вот пример для Vector:
Решение очень понравилось своей простотой, универсальностью и скоростью настройки. Буквально за час со всем разобрался и настроил. Никаких затруднений. Отдельно нужно решать вопрос доступа к приёмнику логов и веб интерфейсу. С уровня приложения никаких решений нет. Нужно либо firewall, либо proxy использовать.
Отдельно отмечу, что те же логи syslog и journald сразу парсятся по основным полям, типа hostname, time, cmdline и т.д. Ничего для этого настраивать не надо. Сразу в веб интерфейсе можно поиск и группировку по ним делать. Получается очень функциональное решение по простоте и скорости настройки на уровне обычного syslog сервера, но с гораздо большими возможностями.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #devops
Отдельно перечислю особенности VictoriaLogs:
▪️По своей сути это одиночный бинарник, который можно сконфигурировать ключами запуска, не нужен даже конфигурационный файл.
▪️В бинарнике есть всё, что надо для сбора и просмотра логов: веб интерфейс, метрики для мониторинга за системой, все типы приёмников логов.
▪️Для бэкапа достаточно скопировать директорию с данными, например, с помощью rsync. То есть вообще никаких проблем и заморочек с бэкапом.
▪️Есть плагин для datasource в Grafana, чтобы делать оттуда запросы к логам, а также готовый дашборд для визуализации метрик хранилища.
▪️Простая, короткая документация, где есть всё необходимое для запуска и настройки.
Покажу примеры сбора логов в VictoriaLogs от Journald, Syslog и Vector. Для этого подготовил небольшой
docker-compose.yml с некоторыми параметрами:services:
victoria-logs:
image: victoriametrics/victoria-logs:latest
volumes:
- ./victoria-logs-data:/victoria-logs-data
command:
- --storageDataPath=/victoria-logs-data
- --retentionPeriod=90d
- --syslog.listenAddr.tcp=:514
ports:
- 9428:9428
- 514:514
restart: always
Запускаем проект, переходим на порт 9428, чтобы убедиться в том, что всё запустилось. По умолчанию открывается страница с некоторыми ссылками на Web UI, Метрики и ключи запуска.
Отправим в VictoriaLogs логи от systemd от любого сервера, локального или внешнего. Для этого понадобится служба systemd-journal-remote. Ставим её:
# apt install systemd-journal-remoteРедактируем конфиг
/etc/systemd/journal-upload.conf, добавляя один параметр:[Upload]URL=http://localhost:9428/insert/journaldURL, соответственно, измените, если у вас сбор логов не с локального сервера, а удалённого. Запускаем службу и проверяем, что она успешно начала отправку логов:
# systemctl start systemd-journal-upload# systemctl status systemd-journal-uploadИдём в веб интерфейс VictoriaLogs - http://212.193.59.87:9428/select/vmui и смотрим там логи.
Переходим к Syslog. Я уже добавил параметр
syslog.listenAddr.tcp=:514. Убедитесь, что указанный порт прослушивается:# ss -tulnp | grep 514Если у вас этот порт уже занят syslog сервером, то измените порт для VictoriaLogs. В общем-то настраивать больше ничего не надо. Теперь в любом софте, который умеет отправлять данные в формате syslog, укажите в качестве сервера IP вашего VictoriaLogs. Например, в том же Микротике: System ⇨ Logging ⇨ Actions ⇨ Add Type Remote.
Для сбора логов от всех популярных агентов, типа Filebeat, Fluentd, Vector и т.д. тоже ничего специально настраивать не надо. Делаете всё точно так же, как для отправки логов в Elasticsearch, только в качестве endpoint указываете URL от вашего сервера VictoriaLogs. Вот пример для Vector:
sinks:
vlogs:
inputs:
- nginx_access_logs
type: elasticsearch
endpoints:
- http://212.193.59.87:9428/insert/elasticsearch/
api_version: v8
compression: gzip
Решение очень понравилось своей простотой, универсальностью и скоростью настройки. Буквально за час со всем разобрался и настроил. Никаких затруднений. Отдельно нужно решать вопрос доступа к приёмнику логов и веб интерфейсу. С уровня приложения никаких решений нет. Нужно либо firewall, либо proxy использовать.
Отдельно отмечу, что те же логи syslog и journald сразу парсятся по основным полям, типа hostname, time, cmdline и т.д. Ничего для этого настраивать не надо. Сразу в веб интерфейсе можно поиск и группировку по ним делать. Получается очень функциональное решение по простоте и скорости настройки на уровне обычного syslog сервера, но с гораздо большими возможностями.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #devops
Открытый практикум Linux by Rebrain: Установка Linux на свой домашний сервер
После регистрации мы отправим вам подарок! Вы сможете найти его в ответном письме.
👉 Регистрация
Время проведения:
30 апреля (среда), 20:00 по МСК
Программа практикума:
▪️Формулируем задачу
▫️Планируем способ аллокации дискового пространства
▪️А если на загрузочном диске будет только загрузчик?
Кто ведёт?
Андрей Буранов — специалист по UNIX-системам в компании VK, входит в топ 3 лучших преподавателей образовательных порталов. 10+ лет опыта работы с ОС Linux и 8+ лет опыта преподавания.
Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь!
Реклама. ООО "РЕБРЕИН", ИНН: 7727409582, erid: 2W5zFGRpmjN
После регистрации мы отправим вам подарок! Вы сможете найти его в ответном письме.
👉 Регистрация
Время проведения:
30 апреля (среда), 20:00 по МСК
Программа практикума:
▪️Формулируем задачу
▫️Планируем способ аллокации дискового пространства
▪️А если на загрузочном диске будет только загрузчик?
Кто ведёт?
Андрей Буранов — специалист по UNIX-системам в компании VK, входит в топ 3 лучших преподавателей образовательных порталов. 10+ лет опыта работы с ОС Linux и 8+ лет опыта преподавания.
Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь!
Реклама. ООО "РЕБРЕИН", ИНН: 7727409582, erid: 2W5zFGRpmjN
Я очень много лет использовал в Linux утилиту screen для того, чтобы в случае обрыва связи при подключении по SSH не завершалось выполнение запущенных интерактивных операций. Особенно это касается обновлений системы через apt или dnf. Типичная проблема, не считая банального обрыва связи, - подключился по VPN к серверу, запустил обновление, обновился софт для VPN, тебя отключило, обновление завершилось на середине процесса. Это может привести к проблемам (система не загрузилась из-за прерванного обновления).
В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.
В tmux такой проблемы нет. Всё работает ожидаемо, можно разворачивать, сворачивать MC, содержимое терминала не очищается. В итоге у меня на половине серверов по старинке screen стоит, на другой - tmux. Я никакими дополнительными возможностями tmux и screen не пользуюсь, мне главное при обрыве соединения вернуться в свою сессию. В screen привык к горячим клавишам и ключам и переучиваться на tmux не хотелось, так как нет большого смысла.
Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.
Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.
Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.
Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?
#linux #terminal
В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.
В tmux такой проблемы нет. Всё работает ожидаемо, можно разворачивать, сворачивать MC, содержимое терминала не очищается. В итоге у меня на половине серверов по старинке screen стоит, на другой - tmux. Я никакими дополнительными возможностями tmux и screen не пользуюсь, мне главное при обрыве соединения вернуться в свою сессию. В screen привык к горячим клавишам и ключам и переучиваться на tmux не хотелось, так как нет большого смысла.
Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.
Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.
Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.
Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?
#linux #terminal
На днях случился необычный для меня инцидент. Расскажу, как его преодолел. Сразу скажу, что это будет не инструкция, как надо делать, а то, как поступил я в конкретной ситуации. У меня есть в управлении одиночный сервер, где одна из виртуальных машин выполняет роль Nginx Proxy для других сервисов. Кто-то эту прокси решил ддоснуть. Немного растерялся от ситуации, так как сталкиваешься с ней нечасто и выверенного алгоритма действий нет.
Я не знаю, кем и для чего это делалось. Виртуалка проксировала доступ на неприметный публичный сайт, который давно не обновлялся и работал для галочки. Также проксировались соединения на мониторинг, 1С и некоторые другие внутренние сервисы для доступа к ним извне. На виртуалке внутри не было никакой защиты от ddos, внешняя, соответственно, тоже подключена не была. В этом не было необходимости. Ничего критичного там не стояло.
От мониторинга прилетел алерт на недоступность некоторых ресурсов, и на высокий LA виртуалки. По SSH хоть и небыстро, но подключился к ней. Заодно сразу зашёл на гипервизор. Он нормально переваривал нагрузку. Увидел, что на виртуалке CPU на четырёх ядрах в потолке. И все ядра нагрузил Nginx. Голым Nginx нагрузить практически пустыми соединениями на 100% 4 CPU не так просто. Я думал, что сейчас провайдер просто отрубит сервак и на этом всё закончится. Но нет, он переваривал, так что я стал разбираться на сервере локально.
Глянул лог Nginx и увидел массовые обращения на один конкретный URL публичного сайта с разных IP адресов. Вообще не понял, причём тут этот URL и почему в него долбят. Первое, что сделал, вообще отключил этот сайт. Nginx стал отдавать 502 ошибку, но серверу это слабо помогло.
Потом добавил параметр
в nginx.conf и
в настройки виртуального хоста. Хотел собирать айпишники тех, кто открывает более 50 соединений к сайту, чтобы потом их банить. Но там особо не собиралось, плюс лог ошибок рос с огромной скоростью, трудно было из него что-то выбирать. Виртуалка и так сильно тормозила. IP постоянно менялись, одновременных запросов, которые бы ловились Nginx, не было.
Решил мимо Nginx напрямую с iptables работать. У меня есть в закладках команда, которая сортирует и считает соединения с каждого IP адреса:
Тут уже было хорошо видно адреса, которые открыли много соединений. Немного изменил скрипт, чтобы выводить чистые списки IP адресов, открывших более 50-ти соединений и сохранять их в файл:
Дальше создал список ipset для использования списка IP адресов в правилах iptables. Напрямую большие списки в iptables направлять не надо, он их может не переварить.
Закинул туда список пойманных ранее IP адресов:
И сделал правило в iptables для блокировки из этого списка:
Блокировка заработала, счётчики правила пошли вверх, но помогло это слабо. Адреса постоянно менялись. Собрал всё это в скрипт и запускал по крону раз в минуту, тоже не помогло.
Решил забанить всех, кто обращается к урлу, который ддосят. Забирал IP ардеса, чтобы сильно не грузить сервак, так:
Собрал их в ipset, добавил правило блокировки:
Продолжение в следующей заметке 👇👇👇👇
#ddos #nginx #iptables
Я не знаю, кем и для чего это делалось. Виртуалка проксировала доступ на неприметный публичный сайт, который давно не обновлялся и работал для галочки. Также проксировались соединения на мониторинг, 1С и некоторые другие внутренние сервисы для доступа к ним извне. На виртуалке внутри не было никакой защиты от ddos, внешняя, соответственно, тоже подключена не была. В этом не было необходимости. Ничего критичного там не стояло.
От мониторинга прилетел алерт на недоступность некоторых ресурсов, и на высокий LA виртуалки. По SSH хоть и небыстро, но подключился к ней. Заодно сразу зашёл на гипервизор. Он нормально переваривал нагрузку. Увидел, что на виртуалке CPU на четырёх ядрах в потолке. И все ядра нагрузил Nginx. Голым Nginx нагрузить практически пустыми соединениями на 100% 4 CPU не так просто. Я думал, что сейчас провайдер просто отрубит сервак и на этом всё закончится. Но нет, он переваривал, так что я стал разбираться на сервере локально.
Глянул лог Nginx и увидел массовые обращения на один конкретный URL публичного сайта с разных IP адресов. Вообще не понял, причём тут этот URL и почему в него долбят. Первое, что сделал, вообще отключил этот сайт. Nginx стал отдавать 502 ошибку, но серверу это слабо помогло.
Потом добавил параметр
limit_conn_zone $binary_remote_addr zone=perip:10m;в nginx.conf и
limit_conn perip 50;в настройки виртуального хоста. Хотел собирать айпишники тех, кто открывает более 50 соединений к сайту, чтобы потом их банить. Но там особо не собиралось, плюс лог ошибок рос с огромной скоростью, трудно было из него что-то выбирать. Виртуалка и так сильно тормозила. IP постоянно менялись, одновременных запросов, которые бы ловились Nginx, не было.
Решил мимо Nginx напрямую с iptables работать. У меня есть в закладках команда, которая сортирует и считает соединения с каждого IP адреса:
# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//'Тут уже было хорошо видно адреса, которые открыли много соединений. Немного изменил скрипт, чтобы выводить чистые списки IP адресов, открывших более 50-ти соединений и сохранять их в файл:
# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//' | awk '{if ($1 > 50 ) print$2}' > ~/top_connect.txtДальше создал список ipset для использования списка IP адресов в правилах iptables. Напрямую большие списки в iptables направлять не надо, он их может не переварить.
# ipset -N top_connect nethashЗакинул туда список пойманных ранее IP адресов:
# cat ~/top_connect.txt | xargs -n1 ipset -A top_connectИ сделал правило в iptables для блокировки из этого списка:
# iptables -I INPUT 1 -m set --match-set top_connect src -j DROPБлокировка заработала, счётчики правила пошли вверх, но помогло это слабо. Адреса постоянно менялись. Собрал всё это в скрипт и запускал по крону раз в минуту, тоже не помогло.
Решил забанить всех, кто обращается к урлу, который ддосят. Забирал IP ардеса, чтобы сильно не грузить сервак, так:
# tail -1000 /var/log/nginx/access.log | egrep "GET /url-for-ddos/" | awk '{print $1}' | sort -n | uniq -c | sort -n | tail -n100 | awk '{if ($1 > 2 ) print $2}' > ~/top_get.txtСобрал их в ipset, добавил правило блокировки:
# ipset -N top_get nethash
# iptables -I INPUT 1 -m set --match-set top_get src -j DROPПродолжение в следующей заметке 👇👇👇👇
#ddos #nginx #iptables
Продолжение, начало 👆👆👆
И тоже добавил в cron на выполнение раз в минуту. Опять не помогло. Список растёт, банов много, но у CPU всё равно загрузка на 100%. Nginx переваривает всё новые и новые соединения с разных IP.
Решил закрыться списками стран. Разрешить только РФ и некоторые соседние. Списки IP для автоматизации всегда брал здесь:
⇨ https://www.ipdeny.com/ipblocks/
Примерно так это выглядит:
Скачал список адресов, закинул его в ipset, разрешил соединения из этого списка, остальных заблокировал. Тут важен порядок правил. Пишу уже по памяти, может где ошибся, не проверяю команды. Но смысл ясен.
После того, как применил всё, понимаю, что я сам не могу подключиться. Проверяю свой IP и вижу, что его тупо нет в скачанном списке. Становится ясно, что этот список неактуальный и пользоваться им не нужно. Частично, кстати, он помог, но всё равно было много запросов и из РФ. Виртуалку не разгрузил.
Дальше начал выборочно смотреть IP адреса и банить отдельные страны таким же способом через iptables + ipset. Понемногу это помогало, но мне в итоге надоело. Решил просто проверить и поставить на указанный URL код ответа 404. После того, как это сделал, ддос прекратился в течении минуты. Почему-то 502 код ответа не помог, а на 404 ддос сразу закончился.
Я не знаю, что это было. Наверное со временем я бы перебанил кучу IP адресов и стало бы полегче, но перспективы самостоятельной борьбы против сильно распределённого ддоса сомнительные. У тебя тупо нет инструментов. IP адресов много, закрыться наверняка не получается. Нужен мощный устойчивый промежуточный узел для фильтрации. Я, когда оставил только РФ, видел, что массовые запросы идут в том числе с московских IP адресов.
Вывод можно сделать такой. Если вам нужна реальная защита от ддос, то подключайте внешний сервис. Сами вы ничего особо не сделаете. У меня явно была какая-то случайная история. Может по ошибке кто-то долбил в сервер, может просто тренировался. Я не знаю. Если бы хотели, сервер бы уронили. Надо было ещё немного добавить трафика и меня бы банально хостер отключил. Ну а так вышло, как вышло.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
И тоже добавил в cron на выполнение раз в минуту. Опять не помогло. Список растёт, банов много, но у CPU всё равно загрузка на 100%. Nginx переваривает всё новые и новые соединения с разных IP.
Решил закрыться списками стран. Разрешить только РФ и некоторые соседние. Списки IP для автоматизации всегда брал здесь:
⇨ https://www.ipdeny.com/ipblocks/
Примерно так это выглядит:
# wget -O ru_ip http://www.ipdeny.com/ipblocks/data/countries/ru.zone# ipset -N ru_ip nethash# cat ~/ru_ip | xargs -n1 ipset -A ru_ip# iptables -I INPUT 3 -m set --match-set ru_ip src -p tcp --dport 80 -j ACCEPT# iptables -I INPUT 4 -m set --match-set ru_ip src -p tcp --dport 443 -j ACCEPT# iptables -I INPUT 5 -p tcp --dport 80 -j REJECT# iptables -I INPUT 6 -p tcp --dport 443 -j REJECTСкачал список адресов, закинул его в ipset, разрешил соединения из этого списка, остальных заблокировал. Тут важен порядок правил. Пишу уже по памяти, может где ошибся, не проверяю команды. Но смысл ясен.
После того, как применил всё, понимаю, что я сам не могу подключиться. Проверяю свой IP и вижу, что его тупо нет в скачанном списке. Становится ясно, что этот список неактуальный и пользоваться им не нужно. Частично, кстати, он помог, но всё равно было много запросов и из РФ. Виртуалку не разгрузил.
Дальше начал выборочно смотреть IP адреса и банить отдельные страны таким же способом через iptables + ipset. Понемногу это помогало, но мне в итоге надоело. Решил просто проверить и поставить на указанный URL код ответа 404. После того, как это сделал, ддос прекратился в течении минуты. Почему-то 502 код ответа не помог, а на 404 ддос сразу закончился.
Я не знаю, что это было. Наверное со временем я бы перебанил кучу IP адресов и стало бы полегче, но перспективы самостоятельной борьбы против сильно распределённого ддоса сомнительные. У тебя тупо нет инструментов. IP адресов много, закрыться наверняка не получается. Нужен мощный устойчивый промежуточный узел для фильтрации. Я, когда оставил только РФ, видел, что массовые запросы идут в том числе с московских IP адресов.
Вывод можно сделать такой. Если вам нужна реальная защита от ддос, то подключайте внешний сервис. Сами вы ничего особо не сделаете. У меня явно была какая-то случайная история. Может по ошибке кто-то долбил в сервер, может просто тренировался. Я не знаю. Если бы хотели, сервер бы уронили. Надо было ещё немного добавить трафика и меня бы банально хостер отключил. Ну а так вышло, как вышло.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
Треть россиян считают до 40% встреч бессмысленными
Делюсь результатами исследования Контур.Толка. Аналитики выяснили, что усталость от созвонов — реальная проблема, о которой предпочитают молчать сотрудники.
Лишь четверть опрошенных решаются прямо сказать организатору, что не будут участвовать в бесполезной встрече. Большинство же формально присутствуют на созвоне — выключают камеру и параллельно занимаются другой работой.
Чтобы помочь сделать созвоны эффективнее, команда Контур.Толка представила автоматические резюме встреч. Работает это так: после встречи ИИ обрабатывает запись, создает расшифровку и анализирует содержание беседы. Затем создается краткий пересказ разговора.
Саммари особенно пригодится, когда встреча заканчивается коллективным «ну вроде договорились», а через два дня никто не помнит, о чем. Теперь не нужно искать контекст по чатам — Толк сделает это за вас.
Инструмент уже доступен. Регистрируйтесь в Толке и тестируйте обновление — это бесплатно.
Делюсь результатами исследования Контур.Толка. Аналитики выяснили, что усталость от созвонов — реальная проблема, о которой предпочитают молчать сотрудники.
Лишь четверть опрошенных решаются прямо сказать организатору, что не будут участвовать в бесполезной встрече. Большинство же формально присутствуют на созвоне — выключают камеру и параллельно занимаются другой работой.
Чтобы помочь сделать созвоны эффективнее, команда Контур.Толка представила автоматические резюме встреч. Работает это так: после встречи ИИ обрабатывает запись, создает расшифровку и анализирует содержание беседы. Затем создается краткий пересказ разговора.
Саммари особенно пригодится, когда встреча заканчивается коллективным «ну вроде договорились», а через два дня никто не помнит, о чем. Теперь не нужно искать контекст по чатам — Толк сделает это за вас.
Инструмент уже доступен. Регистрируйтесь в Толке и тестируйте обновление — это бесплатно.
У меня уже были заметки про фишки LVM, сегодня расскажу про ещё одну, которая может пригодиться. С помощью LVM и снепшотов можно делать консистентные бэкапы баз данных Mysql на уровне файлов, а не дампов, практически без простоя. Для таких задач в СУБД Percona есть инструмент под названием XtraBackup, а вот если у вас обычная бесплатная MySQL или MariaDB, то с бэкапами на уровне файлов там не так всё просто, особенно если вы уже не можете делать дампы из-за их больших размеров.
Идея там вот в чём. Мы закрываем все открытые таблицы, сбрасываем кэш, блокируем изменение данных, после этого делаем снепшот раздела с базами данных и сразу отключаем блокировки. Это занимает буквально пару секунд, на которые блокируются все базы, а потом спокойно копируем файлы сервера, примонтировав снепшот.
Это всё хорошо работало до появления движка InnoDB. У него есть нюансы, когда блокировки не предотвращают изменение данных в таблицах. Нужно дополнительно сбрасывать на диск так называемые dirty_pages. Покажу всё это на практике. Способ немного костыльный и вряд ли подойдёт для прода, так как есть много нюансов. Но в каких-то ситуациях может помочь быстро снять консистентную копию без остановки сервера.
Для того, чтобы всё получилось, раздел, где хранятся данные MySQL сервера, должен располагаться на LVM, а в Volume Group должно быть свободное место для снепшотов. Проверяем так:
Если места нет, надо добавить. Не буду на этом останавливаться, рассказывал ранее. Первым делом заходим в консоль mysql, сбрасываем кэш и включаем блокировки:
Если база не сильно большая и нагруженная, кэш быстро сбросится. Наблюдать можно так:
Следим за значением
После этого возвращаем обратно настройку с dirty_pages в исходное значение (по умолчанию 90) и снимаем блокировки:
Когда это делается автоматически скриптом, всё это происходит быстро. Но есть нюансы. Команда блокировки дожидается завершения всех запросов. Если у вас там есть какие-то очень длинные запросы, то вся база будет заблокирована, пока они не завершатся. Так что имейте это ввиду.
Монтируем снепшот и копируем данные:
После копирования снепшот надо обязательно удалить.
Получили консистентный бэкап всех баз данных практически без остановки сервера, но с кратковременной блокировкой изменений.
Я собрал всё это в скрипт и протестировал на сервере с MariaDB и Zabbix Server. Сохранил бэкап локально, потом остановил MariaDB, полностью удалил директорию
Скрипт особо не отлаживал, так что аккуратнее с ним. Просто убедился, что работает. Сначала немного накосячил, так как после включения блокировки закрывал сессию, делал снепшот и подключался снова. Так нельзя, потому что команда
Такой вот небольшой трюк в копилку LVM, который можно применять не только к СУБД, но и другим данным.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm #mysql #backup
Идея там вот в чём. Мы закрываем все открытые таблицы, сбрасываем кэш, блокируем изменение данных, после этого делаем снепшот раздела с базами данных и сразу отключаем блокировки. Это занимает буквально пару секунд, на которые блокируются все базы, а потом спокойно копируем файлы сервера, примонтировав снепшот.
Это всё хорошо работало до появления движка InnoDB. У него есть нюансы, когда блокировки не предотвращают изменение данных в таблицах. Нужно дополнительно сбрасывать на диск так называемые dirty_pages. Покажу всё это на практике. Способ немного костыльный и вряд ли подойдёт для прода, так как есть много нюансов. Но в каких-то ситуациях может помочь быстро снять консистентную копию без остановки сервера.
Для того, чтобы всё получилось, раздел, где хранятся данные MySQL сервера, должен располагаться на LVM, а в Volume Group должно быть свободное место для снепшотов. Проверяем так:
# pvsЕсли места нет, надо добавить. Не буду на этом останавливаться, рассказывал ранее. Первым делом заходим в консоль mysql, сбрасываем кэш и включаем блокировки:
> SET GLOBAL innodb_max_dirty_pages_pct = 0;> FLUSH TABLES WITH READ LOCK;Если база не сильно большая и нагруженная, кэш быстро сбросится. Наблюдать можно так:
> SHOW ENGINE INNODB STATUS\G;Следим за значением
Modified db pages. Оно должно стать 0. После этого можно делать снэпшот:# lvcreate --size 5G --snapshot --name mysql_snapshot /dev/vgroup/rootПосле этого возвращаем обратно настройку с dirty_pages в исходное значение (по умолчанию 90) и снимаем блокировки:
> SET GLOBAL innodb_max_dirty_pages_pct = 90;> UNLOCK TABLES;Когда это делается автоматически скриптом, всё это происходит быстро. Но есть нюансы. Команда блокировки дожидается завершения всех запросов. Если у вас там есть какие-то очень длинные запросы, то вся база будет заблокирована, пока они не завершатся. Так что имейте это ввиду.
Монтируем снепшот и копируем данные:
# mkdir /mnt/mysql_backup# mount /dev/vgroup/mysql_snapshot /mnt/mysql_backup# rsync -avz --delete /mnt/mysql_backup/var/lib/mysql/ user@10.20.1.5:/mnt/backup/mysql/После копирования снепшот надо обязательно удалить.
# umount /mnt/mysql_backup# lvremove -f /dev/vgroup/mysql_snapshotПолучили консистентный бэкап всех баз данных практически без остановки сервера, но с кратковременной блокировкой изменений.
Я собрал всё это в скрипт и протестировал на сервере с MariaDB и Zabbix Server. Сохранил бэкап локально, потом остановил MariaDB, полностью удалил директорию
/var/lib/mysql и восстановил из бэкапа. Потом запустил СУБД. Запустилось без проблем, никаких ошибок. Бэкап получается консистентный.Скрипт особо не отлаживал, так что аккуратнее с ним. Просто убедился, что работает. Сначала немного накосячил, так как после включения блокировки закрывал сессию, делал снепшот и подключался снова. Так нельзя, потому что команда
FLUSH TABLES WITH READ LOCK живёт, пока открыто соединение. Надо в рамках него делать всё необходимое. Запустил lvcreate через SYSTEM. Такой вот небольшой трюк в копилку LVM, который можно применять не только к СУБД, но и другим данным.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm #mysql #backup
Решал на днях простую задачку. Нужно было сделать так, чтобы разработчики могли сами включать на сайте режим обслуживания, чтобы весь трафик пользователей шёл на страницу заглушку, а они могли с сайтом работать, как обычно. Такой режим есть в движке Битрикс. Довольно удобно, разработчики пользуются.
Хотелось сделать примерно то же самое на базе Nginx/Angie, но с помощью файла-флага, который можно положить в корень сайта и это будет включать режим обслуживания. Если файл есть – весь трафик пользователей идёт на заглушку, а IP адреса разработчиков или какие-то подсети видят сайт как обычно и работают с ним.
Задача в целом популярная, в сети легко находятся готовые примеры. Но там везде используется
Создаём файл
Указывать можно как одиночные IP адреса, так и подсети. Вынес эти настройки в отдельный файл для удобства. Добавляем в настройки виртуального хоста, для которого настраиваем режим обслуживания:
Теперь если в корне сайта создать файл
Это максимально простой и быстрый вариант. Но столкнулся с небольшим нюансом. Когда обслуживание закончено, желательно пользователей, кто остался на странице maintenance.html обратно вернуть на главную, когда они в очередной раз обновят страницу. Добавляем проверку в
Получилось относительно простое и эффективное решение. Не надо менять конфигурацию и дёргать веб сервер. Достаточно любым способом положить или переименовать заготовку для файла maintenance.flag, а потом обратно переименовать, когда работы закончены.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #angie
Хотелось сделать примерно то же самое на базе Nginx/Angie, но с помощью файла-флага, который можно положить в корень сайта и это будет включать режим обслуживания. Если файл есть – весь трафик пользователей идёт на заглушку, а IP адреса разработчиков или какие-то подсети видят сайт как обычно и работают с ним.
Задача в целом популярная, в сети легко находятся готовые примеры. Но там везде используется
if. Хотелось сделать без него, но у меня не получилось. Долго мучал chatgpt. Он бодро предлагал неработающие решения, потом так же бодро сообщал, что действительно тут ошибка и так не работает. Надо делать вот так и тогда получится. В итоге простого красивого и удобного решения именно с файлом-флагом, без правки конфигурации и reload веб сервера сделать не получилось. Реализовал наиболее простой вариант с помощью пары if. Создаём файл
/etc/angie/allowed_ips.conf следующего содержания:map $remote_addr $bypass_maintenance {
default 0;
187.192.238.175 1;
192.168.0.0/24 1;
}Указывать можно как одиночные IP адреса, так и подсети. Вынес эти настройки в отдельный файл для удобства. Добавляем в настройки виртуального хоста, для которого настраиваем режим обслуживания:
location = /maintenance.html {
try_files $uri =503;
}
location / {
set $in_maintenance 0;
if (-f $document_root/maintenance.flag) {
set $in_maintenance 1;
}
set $maintenance_check "${in_maintenance}_${bypass_maintenance}";
if ($maintenance_check = "1_0") {
return 302 /maintenance.html;
}
try_files $uri $uri/ /index.php?$args;
}Теперь если в корне сайта создать файл
maintenance.flag, то всем пользователям, кого нет в списке allowed_ips.conf будет отображаться содержимое файла maintenance.html, который надо добавить.Это максимально простой и быстрый вариант. Но столкнулся с небольшим нюансом. Когда обслуживание закончено, желательно пользователей, кто остался на странице maintenance.html обратно вернуть на главную, когда они в очередной раз обновят страницу. Добавляем проверку в
location /maintenance.html location = /maintenance.html {
if (!-f $document_root/maintenance.flag) {
return 302 /;
}
try_files $uri =503;
}Получилось относительно простое и эффективное решение. Не надо менять конфигурацию и дёргать веб сервер. Достаточно любым способом положить или переименовать заготовку для файла maintenance.flag, а потом обратно переименовать, когда работы закончены.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #angie
😱 Хотите научиться настраивать кластер Elasticsearch с нуля? Задача кажется сложной?
⏰ На вебинаре 29 апреля в 20:00 мск мы разберём архитектуру Elasticsearch: шарды, реплики и их роль в распределении данных. Узнайте, как правильно настраивать конфигурацию кластера для устойчивой работы и добавлять новые ноды без простоев.
⭐️ Спикер Андрей Буранов — системный администратор в VK, входит в топ-3 лучших преподавателей образовательных порталов.
Мы покажем, как обеспечить отказоустойчивость и надежность хранения данных, а также как масштабировать кластер, добавляя новые ноды.
Участники вебинара получат скидку на курс «Инфраструктура высоконагруженных систем».
👉 Для участия зарегистрируйтесь: https://clck.ru/3LdzGy
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
⏰ На вебинаре 29 апреля в 20:00 мск мы разберём архитектуру Elasticsearch: шарды, реплики и их роль в распределении данных. Узнайте, как правильно настраивать конфигурацию кластера для устойчивой работы и добавлять новые ноды без простоев.
⭐️ Спикер Андрей Буранов — системный администратор в VK, входит в топ-3 лучших преподавателей образовательных порталов.
Мы покажем, как обеспечить отказоустойчивость и надежность хранения данных, а также как масштабировать кластер, добавляя новые ноды.
Участники вебинара получат скидку на курс «Инфраструктура высоконагруженных систем».
👉 Для участия зарегистрируйтесь: https://clck.ru/3LdzGy
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
This media is not supported in your browser
VIEW IN TELEGRAM
Вспомнился старенький ролик. У меня дома почти все вентиляторы стали сильно шуметь. И на NAS, и на обычном компе, и на моём тестовом, и на ноуте сына. Не так, как на ролике, где они трещат, а просто крутиться с шумом. Если новые были почти бесшумные, а на NAS (HP Microserver) и системнике (специально собирал на шумопоглощающем корпусе и тихих вентиляторах) вообще бесшумные, их не слышно было, я не выключал вообще, то сейчас все они стали как-то неприятно шуметь. Включаешь и слышен этот звук. Хотел написать гул, но это не гул, а именно шум, с шуршанием.
Понимаю, что просто пришло время и надо заменить, но всё как-то руки не доходят. Надо всё разбирать, смотреть размеры, заказывать новое, опять всё собирать. Раньше любил этим заниматься, но сейчас особо нет времени для таких дел. Давно уже выпал из этой темы. Да и с маленькими детьми в доме это не такая уж простая задача. Дома я всегда под пристальным вниманием, дети скучают и липнут на мне.
Кто-то может посоветовать бренд вентиляторов, чтобы можно было купить и быть уверенным, что они нормально прослужат и не зашумят через пару лет. На Озон зашёл, там сотни вариантов, не знаешь, на чём остановиться. Хорошо бы, чтобы они без лгбт подсветки были, но особо не надеюсь на это.
#железо
Понимаю, что просто пришло время и надо заменить, но всё как-то руки не доходят. Надо всё разбирать, смотреть размеры, заказывать новое, опять всё собирать. Раньше любил этим заниматься, но сейчас особо нет времени для таких дел. Давно уже выпал из этой темы. Да и с маленькими детьми в доме это не такая уж простая задача. Дома я всегда под пристальным вниманием, дети скучают и липнут на мне.
Кто-то может посоветовать бренд вентиляторов, чтобы можно было купить и быть уверенным, что они нормально прослужат и не зашумят через пару лет. На Озон зашёл, там сотни вариантов, не знаешь, на чём остановиться. Хорошо бы, чтобы они без лгбт подсветки были, но особо не надеюсь на это.
#железо