ServerAdmin.ru

2023-05-04 09:11:10 ​​В systemd есть удобный механизм автозапуска сервиса в случае его завершения работы по той или иной причине. Какой-то стандартный софт имеет эту настройку в том или ином виде по умолчанию, например, Mariadb в Debian, какой-то нет, и это нужно сделать вручную.

Автозапуском сервиса управляет параметр Restart в разделе [Service]. Он может принимать следующие значения:
always — перезапускать всегда, когда сервис был остановлен корректно (exit code 0), с кодом ошибки или завис по таймауту
on-success — перезапускать, только если служба завершилась без ошибок (exit code 0)
on-failure — перезапускать, только если код завершения был не нулевым, был прибит одним из сигналов принудительного завершения работы (например SIGKILL), завис по таймауту
on-abnormal — перезапускать только если сервис был прибит одним из сигналов принудительного завершения работы или завис по таймауту
on-abort — перезапускать только если сервис был прибит одним из сигналов принудительного завершения работы
on-watchdog — перезапускать только если наступил настроенный для сервиса watchdog timeout
no — автоматического перезапуска нет

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

Для того, чтобы настроить автоматический запуск сервиса, не надо редактировать его основной unit файл. Сделайте отдельный файл изменений override.conf и положите его в директорию сервиса со специальным именем. Для nginx оно будет такое: /etc/systemd/system/nginx.service.d/override.conf.

Добавьте туда:
[Service]
Restart=always
RestartSec=5s

После изменений надо перечитать настройки служб:
# systemctl daemon-reload

Теперь можно прибить Nginx и убедиться, что через 5 секунд он поднимется снова:
# systemctl status nginx ; смотрим pid корневого процесса (Main PID)
# kill -9 1910155
# systemctl status nginx

К автозапуску процессов надо подходить с умом. Не стоит для всех подряд его настраивать. Особенное внимание надо уделить службам СУБД. После аварийного завершения работы может запускаться очень ресурсоёмкая процедура восстановления данных, которая в нагруженном сервере может быть прибита oom killer и так по кругу. Это может привести к более серьезным последствиям или потере данных.

То же самое касается каких-то кластерных служб. Они могут падать и подниматься в цикле и приводить к рассинхронизации или каким-то ещё проблемам. Например, elasticsearch может подниматься очень долго на слабом железе. Иногда приходится стандартные таймауты systemd увеличивать, чтобы он удачно стартовал. Если настроить автозапуск, он может в цикле прибивать службу по таймауту.

А тот же самый Nginx, Postfix, Dovecot, Apache, Zabbix Agent можно спокойно ставить в автозапуск в случае падений. Проблем быть не должно.

У автозапуска есть более тонкие настройки и зависимости. Я описал только основной функционал, который нужен чаще всего. Более подробно всё описано в документации. Там настраиваются таймауты, различные статусы завершения работы, которые стоит считать успешными, количество попыток перезапуска, прежде чем они прекратятся и т.д. Можно слать оповещения на почту в случае падения и перезапуска службы. Это делается через параметр OnFailure.

Табличку себе сохраните на память для настройки. Без неё неочевидно, какой параметр лучше использовать. Например, Mariadb по умолчанию имеет настройку on-abort.

#systemd #linux Открыть/Комментировать

2023-05-03 18:30:29 ​​Рассказываю про практически бесполезную, но интересную программу на go, которая позволяет создавать в консоли дашборды с виджетами из разных сервисов. Речь пойдёт про wtfutil. Программа состоит из одного бинарника и конфигурационного файла в формате yaml.

Можете сразу посмотреть картинку к посту, чтобы понять, о чём пойдёт речь. Я собрал себе вот такой дашборд из модулей, которые не требуют внешних интеграций через API сервисов и токены. Там только локальные виджеты:
RSS ридер со статьями с моего сайта
Информация о моём внешнем IP
Погода в Москве
Цифровые часы
Аптайм ноутбука (попробовал виджет с любой консольной командой)
Обзор локальных репозиториев GIT

Некоторые виджеты, например с GIT или RSS, имеют отдельное управление. На них можно переключаться через tab, открывать ссылки или листать разные репозитории. Я добавил пару локальных для теста.

Wtfutil имеет довольно много модулей для интеграции с внешними сервисами. Например, может из google analytics показывать статистику по какому-то сайту, из todoist выводить список дел, из gitlab информацию о своих проектах, из UptimeRobot информацию о проверках, из google календаря информацию о событиях и т.д. Полный список можно посмотреть в документации. Для всех модулей есть примеры. Настраивается всё интуитивно и легко. Вот здесь подробно описаны некоторые модули сразу с картинками.

Я просто скачал бинарник и запустил wtfutil на ноуте в WSL2. Без проблем заработало. Шутка интересная, но не знаю, насколько может быть полезной. Мне по приколу было собрать этот дашборд. Думаю для тех, у кого Linux основная система это может оказаться полезным. Судя по тому, что программа живёт в Homebrew, написана она была скорее всего для маководов.

#linux #terminal Открыть/Комментировать

2023-05-03 12:30:29 Чем заменить зарубежное ПО класса UTM и NGFW?

Вебинар для тех, кого интересует российский софт для импортозамещения.

В программе:
на что стоит обращать внимание при миграции с зарубежных решений
этапы перехода и их продолжительность
как сберечь бюджет предприятия на покупке дополнительного ПО
функциональные возможности ИКС
преимущества российской разработки
льготные условия перехода с программ-аналогов на ИКС
ответы на ваши вопросы

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

Регистрация

Предлагаем протестировать полнофункциональную версию ИКС (35 дней бесплатно), действует приоритетная техподдержка.

ИКС — продукт класса NGFW, с большим количеством функций и веб интерфейсом: интернет-шлюз, DHCP, VPN, DNS прокси сервер, NAT, системы обнаружения и предотвращения вторжений IPS/IDS, контроль приложении, WAF, антивирус, файловый и VOIP сервер, контент-фильтр.

Телеграм ИКС

#реклама Открыть/Комментировать

2023-05-03 09:11:37 Ещё один пример защиты веб сервера с помощью 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:
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: ,
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

4.0K views06:11

Открыть/Комментировать

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

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

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

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

#webserver Открыть/Комментировать

2023-05-02 12:31:06 Пройдите тест по DevSecOps, ответьте на 25 вопросов и проверьте, насколько вы готовы к обучению на курсе — «Внедрение и работа в DevSecOps» в OTUS. Курс можно приобрести в рассрочку!

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

Именно эти навыки дают мощное конкурентное преимущество IT-специалистам и повышают вашу привлекательность у крупных работодателей.

Пройти тест — https://otus.pw/bhRh/

Сможете пройти успешно тест - получите доступ к 2 открытым урокам курса уже сейчас!

#Реклама. Информация о рекламодателе на сайте www.otus.ru Открыть/Комментировать

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

5.3K views06:11

Открыть/Комментировать

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

#топ Открыть/Комментировать

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

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

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

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

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

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

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

#мем Открыть/Комментировать

2023-04-28 12:30:09 Этичный Хакер — канал, где вас научат хакингу с нуля.

ТОП-10 опасных вирусов
Как сделать личный VPN и Proxy-сервер
Узнаём IP-адрес человека через Telegram
Wireshark — учимся сканировать сеть
Взлом хэшей паролей с помощью Hashcat

Освой информационную безопасность в 2023 бесплатно — https://t.me/hack_less

#реклама Открыть/Комментировать