⚡️ На днях ко мне обратился знакомый с просьбой помочь разгрести последствия взлома локалки. Я у него админю сервера в ЦОД, а к локальной сети не имею никакого отношения. Расскажу кратко то, что узнал сам. Ситуация типовая и показательная.

На входе стоит Mikrotik, в который воткнут usb модем провайдера сотовой сети. Интернет заходит через него. На микротике был обнаружен vpn канал злоумышленника. С его помощью он закрепился в локальной сети и изучал ее.

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

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

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

Отсюда можно сделать несколько закономерных выводов:

1. Доступ к пограничным роутерам запрещать максимально сильно. Лучше снаружи вообще всё закрыть. Если все же нужно оставить доступ, то настройте хотя бы Port knocking.
2. Сервера изолировать от всего остального.
3. На выходные компьютеры в офисе выключать.
4. Дневной лимит на звонки через ip телефонию, если оператор поддерживает, использовать.
5. Всегда и везде своевременно ставить обновления.

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

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

А оправдано его использование может быть в следующих ситуациях:
1️⃣ К серверу подключаются разные администраторы. Нужно логировать их действия и разграничивать права доступа.
2️⃣ Linux ваша рабочая системы, с помощью sudo вы запускаете редкие команды с полными правами.
3️⃣ Sudo используется в скриптах для ограничения доступа. Абсолютно оправданное использование, сам так поступаю.

А что вы думаете по поводу sudo? Используете или нет и в каких случаях?

https://serveradmin.ru/sudo-ne-nuzhen-pri-rabote-v-konsoli-servera-tak-li-eto/

Ко мне на обзор попал очень интересный сервис для дистанционного управления компьютерами - Getscreen.me. И хотя сервисов для удаленного подключения к компьютерам очень много, уверен, этот вас заинтересует. Основные моменты, за которые лично мне он сразу понравился - работа через браузер, интеграция с telegram (есть крутые фишки) и удобный личный кабинет, через который все управляется.

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

https://serveradmin.ru/otzyv-na-getscreen-me/

​​📆 Завтра пройдет вебинар Zabbix - Как правильно обнаруживать проблемы: используем все возможности триггеров. Я уже смотрел его и в целом могу порекомендовать. Там дается обзор основного функционала триггеров с примерами.

Может быть полезно не только новичкам, но и тем, кто давно использует Zabbix. Так как функционал у него обширен, какие-то вещи не попадают в поле зрения. Вебинар как раз поможет расширить кругозор.

https://us02web.zoom.us/webinar/register/WN_XB2165P8Rz6CJsFMGlqohQ

#zabbix #вебинар

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

Команда Инфратех сделала этот труд за вас. 👌🏼

Представляем книгу «Всё о FortiGate от А до Я» — полное руководство по одному из лучших NGFW по Гартнеру, тестам NSS Labs и ФСТЭК.

На 75 страницах вы:

💠 узнаете фишки FortiGate которых нет у других вендоров
💠 в одном месте просмотрите все линейки моделей от десктоп-исполнения до модульных FortiGate на 8 слотов в серверном шкафу
💠 на примере рассчитаете вместе с автором стоимость устройства и лицензий
💠 получите схемы создания отказоустойчивых кластеров на VDOMs и нескольких устройствах

Книга бесплатная, придет на почту в течении 15 минут после регистрации по ссылке 👉🏻 https://clck.ru/SEMfy

#реклама

Недавно обновил свою очень старую статью (писал 5 лет назад) про бэкап сайтов на Яндекс.Диск. Тогда он еще нормально работал по webdav. Я сам уже не пользуюсь этим диском для бэкапов с линукс серверов, но одно время использовал очень активно.

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

Работало все это на таких объемах не очень стабильно, клиент периодически вис. Но при наличии мониторинга бэкапов это было терпимо. В какой-то момент просто перестали влезать в технологическое окно и бэкапы не успевали синхронизироваться. После этого пришлось перейти на другие инструменты (арендовали сервер с большими дисками).

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

https://serveradmin.ru/bekap-sayta-wordpress-na-yandeks-disk/

​​Регулярно вижу в некоторых вакансиях требование быть на связи 24/7. На вид обычная вакансия, все как у всех, но маленькая такая приписочка в конце. Вроде и ничего особенного, но по факту вас хотят разбудить ночью в 3 часа и вынудить что-то сделать.

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

Не делайте так и даже не позволяйте работодателям думать, что работая по стандартному графику 8/5 вы готовы будете еще и ночью что-то чинить. Если сервис не терпит простоя, то должны выделяться деньги на дежурную смену, которая будет способна решать проблемы.

Я даже не представляю, на каких условиях можно соглашаться с таким дополнением. Наверное, только если зарплата будет x2. Несмотря на то, что у меня свободный график, я всегда и всем, когда договариваюсь о сотрудничестве, говорю, что мой рабочий день в интервале с 9 до 19 и в выходные я не работаю. Ночью на звонки не отвечаю. Я всегда выключаю звук на смартфоне после 20:30, готовлю детей ко сну. А когда ложусь спать, оставляю аппарат на кухне.

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

Несколько дней назад у меня была публикация по быстрой подготовке конфига postgresql с помощью готового web сервиса. В комментариях были вопросы про то же самое, только для mysql.

Лично я основные параметры конфигурации mysql сервера выставляю на глазок сам, так как чаще с ним работаю и уже привык. А потом в процессе эксплуатации использую вот этот скрипт - https://github.com/major/MySQLTuner-perl

В первую очередь он полезен в определении максимального потребления оперативной памяти сервером mysql. Если он будет пытаться занять больше памяти, чем есть на сервере, его будет грохать OOM Killer.

Более подробно вопрос тюнинга mysql с помощью этого скрипта я рассматривал в разделе статьи - https://serveradmin.ru/bitrixenv-optimizacziya-nastroek-servera-pod-sajt-na-bitrix/#_Mysql

#mysql

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

В статье даны не только рекомендации по использованию танка в нагрузочных тестированиях, но и даны советы, как от него защищаться. По сути он представляет из себя отличный инструмент для dos атак. Неподготовленные веб сервера и сайты он кладет на раз. Так что будьте внимательны с ним и не шалите ☝️

https://serveradmin.ru/primer-nagruzochnogo-testirovaniya-sajta-s-yandex-tank/

#нагрузочное_тестирование

​​А вы знали, как работает проверка интернета в Windows? Я думаю, всем знакома надпись рядом с сетевым соединением: "Подключение к интернету отсутствует" или "No Internet" в английской версии. Называется эта штука - Индикатор состояния подключения к сети или Network Connectivity Status Indicator (NCSI).

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

1️⃣ Выполняется DNS lookup адреса www.msftconnecttest.com и отправляется HTTP GET запрос по адресу https://www.msftncsi.com/ncsi.txt. Скачивается текстовый файл. Его можно и вручную проверить, если интересно посмотреть, что там. Если оба действия выполнены корректно, значит все ОК, интернет работает.

2️⃣ Выполняется DNS lookup адреса dns.msftncsi.com и проверяется ответ. Он должен быть 131.107.255.255.

Подозреваю, что dns имена и возвращаемые ip адреса могут меняться. Но принцип, судя по всему, особо не меняется. Я немного погуглил тему и убедился, что вроде бы все так и есть.

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

Компания Mikrotik регулярно проводит мероприятия под названием MUM (MikroTik User Meeting). Из названия понятно, что это встречи пользователей микротиков. Подобные мероприятия проводятся по всему миру, в том числе и в России.

Предыдущая встреча в Москве была в сентябре 2019 года. Доклады и записи выступлений можно посмотреть по ссылке - https://mum.mikrotik.com/2019/RUM/agenda/ru. Информация там обычно очень интересная и актуальная. Можете оценить даже по заголовкам выступлений.

Я иногда просматриваю презентации всех выступлений. Они на английском языке в основном, поэтому все понятно. К примеру, информацию по NCSI из предыдущей заметки я случайно узнал из одной презентации, продемонстрированной в последнем MUM в Индонезии. Там, кстати, приведен интересный пример проверки интернета на микротиках с помощью скрипта, который реализует схожую логику с NCSI.

В комментариях к одной из заметок со мной поделились ссылкой на подборку с инструментами по нагрузочному тестированию по HTTP - https://github.com/denji/awesome-http-benchmark. Мне показался полезным список, поэтому делюсь с вами. К каждому инструменту есть ссылка на описание.

Из предложенного списка лично мне знакомы 2 инструмента - всем известный ab и siege. Последний я даже использовал когда-то давно для написания статьи со сравнением производительности php 5.4, 5.6 и 7.0. Статья уже давно не актуальна, но может кому-то будет интересно почитать, как я это делал - https://serveradmin.ru/ustanovka-i-obnovlenie-php-7-na-centos-7/ В сравнении в итоге победил с огромным отрывом статичный кэш :)

📆 Завтра, 10-го декабря в 10:00 будет очередной вебинар Zabbix, тема которого меня заинтересовала - Работа с Zabbix посредством API: ваша первая интеграция.

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

Регистрация - https://us02web.zoom.us/webinar/register/WN_q8o6xYFrSqKjWRiGbyCMSg

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

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

Ошибка при отправке была следующая:

550 5.7.0 Sender or From header address rejected: not owned by authorized user

При этом отправитель точно соответствовал пользователю, под которым авторизовывались. Написали запрос в тех. поддержку Яндекса. Ответ несколько удивил:

Сервера Яндекс.Почты не предназначены для отправки автоматических уведомлений и любых рассылок. К подобным сообщениям применяются ограничения.

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

Я так сходу и не придумаю бесплатных альтернатив для таких случаев. Можно пробовать почту для домена от mail ru, но как-то не нравится она мне. А настраивать свой сервер только для отправки почты с сайта не всегда целесообразно, особенно если проект очень маленький и объем отправлений не большой.

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

А как вы решаете подобные задачи с почтой? Что используете, помимо своего почтового сервера?

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

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

Скажу честно, в работе его не пробовал, так как просто нет времени. Загружен текущими делами и заботами. Плюс, недавно активно Trello изучал и перенес туда часть своих задач. Понравился календарь с бесплатным расширением функционала Planyway. Я там план публикаций в каналы веду.

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

​​Вы хорошо понимаете значение метрики в Linux под названием Load Average? Традиционно считается, что она показывает загрузку системы. Кто-то думает, что это загрузка процессора. На самом деле ни то, и ни другое. Вообще, это такая таинственная метрика, что иногда мне кажется, я сам толком не понимаю, что она значит и как считается.

Например, можно зайти на сервер, увидеть LA под 100 и при этом заметить, что процессор не нагружен вообще. Более того, вообще не понятно, кто или что нагружает систему. А это у вас просто дисковая подсистема не справляется с нагрузкой.

Или еще пример. У вас на сервере LA в районе 20. Кажется, что много и надо разбираться, в чем дело. Но есть еще один факт - на сервере 36 ядер. И вроде как все в порядке, рабочая нагрузка, хоть и выше средней.

То есть метрика неоднозначная, которая сама по себе не дает понять, с чем конкретно проблема. Ко всему прочему, она еще и изменяется не линейно, а экспоненциально. То есть не верно считать, что load average за минуту включает активность только за последнюю минуту, но в основном, конечно, её.

Для однопроцессорной системы понять логику измерения load average можно с помощью картинки во вложении. Для простоты восприятия la сравнивают с транспортным потоком. Значение более 1.00 означает наличие очереди на въезде на магистраль. Размер этой очереди будет равен превышению единицы. Например, значение 1.70 показывает, что в очереди стоит 70% от числа машин, находящихся на магистрали.

В ядре linux процессы, выполняющиеся в данный момент, это машины на магистрали, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на магистраль. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).

А теперь добавьте сюда многоядерность, многопроцессорность, HyperThreading и попробуйте интерпретировать значения load average. Это нетривиальная задача. Так что надо аккуратно относиться к этой метрике.

Чтобы получше разобраться, как все это работает и что считает, рекомендую статью - https://habr.com/ru/post/260335/ Автор залез в исходники ядра, чтобы точно понять, что конкретно показывает load average.

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

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

# wget -q -O install-snoopy.sh https://github.com/a2o/snoopy/raw/install/install/install-snoopy.sh
# chmod 755 install-snoopy.sh
# ./install-snoopy.sh stable

По умолчанию, он логирует кучу всевозможных команд от системных процессов. Если вам все это не нужно, то можете оставить во такой конфиг /etc/snoopy.ini

[snoopy]
filter_chain = "only_tty"
output = file:/var/log/snoopy.log

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

Остается только активировать snoopy и перезагрузить сервер.

# snoopy-enable
# reboot

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

#ssh

Я тут прикольный канал нашел с айтишным юмором. Он местами специфичен и не очень смешной, но в целом все равно забавно. Вот этот ролик про удаленную работу дома зашел, рекомендую :)

https://www.youtube.com/watch?v=_F-_2s6SJPU

Там еще про devops неплохие ролики.

​​Тут на дня прилег хостер TimeWeb на несколько часов. Причем так крупно прилег. Не работал ни телефон, ни NS сервера, ни сам сайт хостера. Вообще все отрубило. Он потом написал пояснения, что лег корневой маршрутизатор, а когда включили запасной, оказалось, что с ним ничего не работает 🤷🏻‍♂️

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

Пошел на hh и посмотрел вакансии Timeweb. Из технических вакансий там было только две - программист python и специалист технической поддержки Linux. Я не поленился, зашел в описание вакансии и посмотрел требования. Он должен знать linux, писать скрипты, работать в консоли, разбираться в ошибках и т.д. То есть нормальный такой линукс админ средней руки.

Как думаете, какая для него объявлена зарплата? 80-100 т.р.? Увы, нет - от 35 000 до 50 000 руб. Я, конечно, понимаю, что это не те люди, которые проектируют и поддерживают инфраструктуру. Но тем не менее. Это же очень мало. За эти деньги даже нормального эникея на винду найти затруднительно.

Зато в других вакансиях на зп не экономят:
▪ Product Manager от 180 000 руб.
▪ Product Marketing Manager до 250 000 руб.
▪ Продуктовый маркетолог от 130 000 руб.
▪ IT Sales manager/менеджер по продажам до 200 000 руб.

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

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

​​Думаю, все уже в курсе про изменения, которые ожидают в скором времени CentOS. Для меня это оказалось ударом ниже пояса. И дело не в том, что я не вижу других подходящих дистрибутивов Linux. Я все свои процессы уже перестроил на Centos 8. Обновил инструкции, кое-где сделал миграцию. Еще больше миграций запланировал на эти новогодние праздники. Все новые установки последние пол года делал на Centos 8.

И теперь без всяких предупреждений срок поддержки Centos 8 сокращают до конца 2021 года. При этом, для Centos 7 поддержка сохраняется до 24-го. Какая-то изощренная подлость. Объявили бы об этом заранее, во время релиза Centos 8 и никаких проблем бы не было ни у кого. Все бы успели подстроиться и спланировать свои миграции. А сейчас как гром среди ясного неба.

Я сейчас завис в состоянии неопределенности, на что переходить и какая судьба ожидает CentOS. Для тех, кто до конца не понял, какие изменения произошли, поясню. Раньше разработка RHEL двигалась в таком направлении: Fedora (альфа) -> Centos Stream (бета) -> RHEL (релиз) -> Centos. По факту Centos была максимально стабильной системой. Теперь ее просто убирают и оставляют только Centos Stream в качестве бета системы для RHEL.

Пока трудно судить о стабильности Centos Stream. Может так оказаться, что она окажется вполне нормальной системой для сервисов общего назначения (почта, web сервер и т.д.) Кто-то даже сейчас умудряется использовать Fedora Server и называть его вполне стабильным. К тому же у Centos Stream не будет номерных релизов, она будет обновляться непрерывно. В каких-то случаях это может быть удобным. Но все, опять же, зависит от стабильности такого похода в данном конкретном случае.

Всегда есть запасной вариант в виде старого и надежного дистрибутива Debian. Лично я смотрю пока на него. Ну и подождать надо, что выйдет из проекта Rocky Linux. На дистрибутив от Oracle лично я переходить не хочу. Думаю, что рано или поздно они тоже какую-нибудь подлянку сделают.

Лично у меня сейчас проблема одна - какую систему ставить на новых проектах. Понятно, что не Centos 8. Выбираю из Centos 7 и Debian 10. А вы что сейчас ставить будете? Надо до нового года определяться.

​​Отличный сервис по проверке работы почтового сервера - mail-tester.com. Постоянно им пользуюсь. Достаточно просто отправить письмо со своего сервера на специально сформированный ящик и дальше смотреть отчет.

Сервис проверяет следующие параметры:
◽ Настройку DKIM, SPF, DMARC
◽ Все необходимые DNS записи, в том числе PTR
◽ Наличие вашего сервера в черных списках
◽ Контекстные факторы (форматирование, картинки, наличие List-Unsubscribe и т.д.)
◽ Анализ вашего письма с помощью SpamAssasin

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

Сервис хорошо подходит для того, чтобы продемонстрировать заказчику, что вы все сделали корректно и сервер готов к работе. Бесплатное использование допускает не более 3 проверок в сутки для одного домена, так что не спамьте запросами. Используйте только для итоговой проверки.