​​Бесплатный антивирус для сайтов - https://virusdie.com. Сразу говорю, что это не реклама, а мой опыт использования. Приходится делать такие пометки, так как регулярно вижу комментарии о том, что я что-то рекламирую. Абсолютно вся оплаченная реклама на канале помечается соответствующим тэгом. Если его нет, значит это моя личная инициатива написать о том или ином продукте.

Сервис virusdie.com позволяет бесплатно раз в месяц проверять на наличие вирусов один сайт. Для этого надо зарегистрироваться и подтвердить своё владение сайтом. Делается это с помощью загрузки проверочного файла в корень сайта, который по сути является вебшелл. Имейте это ввиду. Сканирование сайта происходит не снаружи, а внутри, через этот php файл. После проверки вы получите отчёт на почту. У компании одно время был блог на хабре.

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

Был еще бесплатный aibolit от той же компании Revisium. Его постигла та же участь. Компания Revisium вошла в группу CloudLinux. Антивирус revisium получил название ImunifyAV. Продукты Revisium стали частью системы комплексной безопасности серверов Imunify360, AI-Bolit в Imunify360 стал Malware Scanner. Бесплатной версии больше нет. Компания CloudLinux, как я понял, ориентирована на англоязычный рынок. Простых способов оплатить российскому юрлицу я не нашел, как и просто телефона тех. поддержки на русском языке.

Есть еще Manul от Яндекса, но не развивается уже давно. Да и на старте был не очень.

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

#website #антивирус #security

​​В последнее время системы статистики посещаемости сайтов, такие как Яндекс.Мертика и Google Analytics превратились в настоящих монстров. Они собирают тонны информации о посетителях, грузя свои скрипты им в сеансы. Я бы очень хотел от них избавиться, но не могу себе этого позволить по двум причинам:

1. У меня почти весь трафик поисковой.
2. У меня крутится реклама от этих компаний.

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

Это легкий (написан на GO), бесплатный счётчик для сайта или веб приложения.

https://github.com/ihucos/counter.dev
https://counter.dev/

Демка - https://counter.dev/dashboard.html?demo=1 Проект работает как сервис. То есть вы ставите их код и вся статистика хранится на серверах проекта. В репозитории отмечено, что при желании, можно поднять сервер у себя, но готовой инструкции о том, как это сделать, я не увидел.

#website

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

Для тех, кому описанная выше проблема не критична, существуют другие более простые и быстрые решения по сбору статистики. Ранее я уже рассказывал про одно из таких решений - counter.dev. Сейчас добавлю только одно - разработчик этой системы сбора статистики живёт в Киеве. Последние коммиты можете сами посмотреть. Я познакомился с похожим аналогом, который мне понравился больше - umami.is.

Это тоже Open Source система. Umami понравилась за очень простой, лаконичный и быстрый веб интерфейс. Написана на Node.js, использует базу MySQL или Postgresql для хранения статистики. Код скрипта сбора данных всего 2KB. Статистику можно сделать публичной при желании. Есть встроенное API, что удобно, если есть желание забирать метрики в мониторинг.

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

Сайт - https://umami.is/
Исходники - https://github.com/mikecao/umami
Демо - https://app.umami.is/share/8rmHaheU/umami.is

#website

​​Ранее рассматривал локальную систему сбора статистики о посетителях сайта umami.is, которую условно можно назвать аналогом Яндекс.Метрики и Google.Analytics. Это неплохой продукт с хорошими отзывами. Собирает статистику с помощью небольшого js скрипта.

Есть похожий бесплатный аналог GoatCounter, который тоже можно развернуть у себя и собирать статистику крохотным js скриптом. Но у этого счётчика есть одна замечательная возможность - он умеет строить статистику на базе логов веб сервера в режиме онлайн. У него для этого есть импортёр, который постоянно запущен и следит за зименениями лога:
# goatcounter import -follow -format=combined \
-exclude=static -site='https://MYCODE.goatcounter.com' \
 /var/log/nginx/access_log

Я знаю, что анализаторов веб логов существует великое множество. Сам то я анализировал логи Apache на Freebsd еще лет 15 назад с помощью Webalizer и AWStats. Эти продукты и сейчас могут нормально работать, потому что формат логов не изменился. В данном случае GoatCounter представляет и ту, и другую возможность. Хочешь скриптом собирай, хочешь из логов инфу бери. Потом можно сравнить результат.

GoatCounter написан на Go, не имеет внешних зависимостей. Достаточно запустить бинарник в режиме сервера. Хранить данные может в SQLite или PostgreSQL.

Сайт - https://www.goatcounter.com
Исходники - https://github.com/arp242/goatcounter

#website

​​Те, кто активно используют Zabbix, в частности его Web проверки, знают, как неудобно они устроены. Разработчики давно обещают переработать этот функционал, но пока не случилось. По мне основное неудобство - нельзя выбрать, с какого хоста будет выполняться проверка. Они все идут с сервера мониторинга.

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

https://github.com/mohitrajvardhan17/Zabbix-Web_monitoring

Я проверил работу этого шаблона на Zabbix Server 6.0. Работает нормально, но проблемы возникли на самом хосте с Zabbix Agent. Скрипт проверок WebMonitoring.py писался под Python2, на Python3 не заработал. Мне не захотелось разбираться в скрипте, поэтому я запустил всё на 2-й версии.

Для работы скрипта нужно установить через pip модули: requests, pyOpenSSL. И сделать одно важное изменение. Так как Python2 больше не поддерживается, при запуске скрипта через него выезжает Warning, который нарушает работу правила обнаружения в шаблоне. Так что в файле userparameter_web.conf нужно вызов python заменить на python2 -W ignore.

Проверить работу скрипта можно так:
# python2 -W ignore /etc/zabbix/WebMonitoring.py \
--metric=discovery --url=https://yandex.ru
{"data":[{"{#URL}":"https://yandex.ru", "{#HEADER}":"None", "{#TIMEOUT}":"30"}]}
Вывод соответствует формату автообнаружения Zabbix Server.

Теперь можно идти на сервер, импортировать шаблон. В нём ровно одно правило автообнаружения с семью прототипами данных. Триггеров нет, их надо делать отдельно. Одно правило обнаружения - один сайт. Для добавления второго сайта надо скопировать правило и изменить в нём url сайта.

Шаблон поддерживает установку параметра timeout (по дефолту 30 секунд) и передачу заголовков. А так же отдельно можно указать проверяемую строку, по наличию которой будет оцениваться корректность содержания страницы.

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

#zabbix #website

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

Задача. Есть типовой веб проект, который разработчики запустили в докере: фронт, бэк и база данных (postgresql). Нужно:
- настроить бэкап данных в виде файлов и базы данных
- настроить мониторинг сервера, сайта, домена, tls сертификата, бэкапов
- оповещения с мониторинга отправлять в telegram

Заказано:
- VPS 1 CPU, 1 Гб RAM, 20 Гб Disk для сервера Zabbix.
- Файловое хранилище с доступом по ssh, rsync для бэкапов.

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

Файловое хранилище с доступом по SSH и CRON. Настроил скрипт, который ходит на веб сервер и сам с помощью RSYNC забирает оттуда все необходимые данные - сырые файлы сайта, БД и дамп БД. Все изменения файлов между синхронизациями сохраняются. Всегда имеется свежая полная копия файлов и изменения после каждой синхронизации.

Мониторинг. Тут всё более ли менее стандартно. Настраивается Zabbix Server, на веб сервер ставится агент. Настраиваются типовые проверки по стандартному шаблону Linux Server. Отдельно настраивается мониторинг делегирования домена, tls сертификата. На канале было много заметок по этому поводу.

Далее мониторинг web сайта тоже делается встроенными проверками. Отслеживается его доступность, время отклика, коды ответа, содержимое ключевых страниц. Если отклик растёт выше обычного, предупреждаем.

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

Оповещения в telegram настроены дефолтным способом через встроенный webhook в Zabbix Server. На всякий случай добавил ещё и по email их.

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

Следующим этапом нужно купить ещё одну VPS, заскриптовать восстановление из бэкапа и сделать мониторинг восстановленного сайта. Нужно понимать, что всё восстановилось и сайт реально работает.

Если кому-то интересно, сколько подобная настройка стоит, то лично я беру за первый этап 10 т.р., если всё стандартно, как описано тут. За второй этап столько же, если там нет каких-то особых проблем. На каждый этап уходит примерно день, если делать всё аккуратно, проверять, записывать.

#website #monitoring #backup

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

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

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

Потом заглянул в конфиги Mariadb и сначала не понял, а где вообще основная конфигурация. Всё пересмотрел и тут до меня дошло. Я забыл подтюнить СУБД под ресурсы сервера. В итоге MariaDB работала с дефолтными настройками. Если не ошибаюсь, там innodb_buffer_pool_size установлен в 128M. Это очень сильно влияет на производительность.

Скачал mysqltuner и выставил основные параметры в соответствии с объёмом оперативной памяти сервера. Этого оказалось достаточно, чтобы нормализовалась работа. Я этот тюнер использую как калькулятор. С его помощью удобно подобрать параметры innodb_buffer_pool_size и все сопутствующие настройки, а также буферы. И чтобы всё это не потребляло ресурсов больше, чем есть оперативной памяти под нужды СУБД. Если ошибиться, то можно словить OOM Killer, который будет прибивать базу данных.

Полезные ссылки по теме:
- Сравнение mysql vs mariadb
- На что обращать внимание при настройке Mysql
- Производительности Mysql сервера на файловой системе zfs
- индексы в Mysql
- Размещение субд в контейнерах

#mysql #website

​​Рассказываю про полезный бот в Telegram, который уже довольно давно использую сам для дублирования мониторинга сайтов. Основной мониторинг у меня всегда сделан на Zabbix. Но помимо него есть несколько бесплатных для подстраховки и дополнительной информации. Один из них - @SiteKnockerBot.

Не помню, откуда узнал про него. Может кто-то посоветовал. Бот выполняет простые проверки к заданному урлу сайта. Может не только доступность смотреть, но и анализировать содержимое, проверяя наличие заданной строки. Через бота можно посмотреть статистику, результат последних проверок, время отклика сайта. Судя по логам веб сервера, проверки делает с сервера в Германии.

Второй бесплатный сервис, который использую - freshping.io. Я писал о нём отдельно. С тех пор постоянно пользуюсь. Удобно сделан.

Основной мониторинг, как я уже сказал, настраиваю с помощью Zabbix. У меня есть подробная статья на эту тему, которая полностью актуальна - Мониторинг web сайта в Zabbix. Мониторинг сайтов давно обещают переработать, но изменений пока не видно. Сделано не очень удобно, но приходится мириться, так как стараюсь держать весь мониторинг в одном месте.

#мониторинг #website

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

В статье автор предлагает использовать фреймворк Selenium для создания скриншота сайта. Для его использования он написал небольшой скрипт на Python и опубликовал его в виде картинки 🤦

Дальше он предлагает добавить этот скрипт в Zabbix и использовать в каких-то действиях. Например, в триггере для мониторинга сайта. Если получаем ошибку мониторинга, то делаем автоматом скриншот. Скрипту url сайта передаём через макрос триггера {TRIGGER.URL}, так что не забудьте этот url указать в триггере.

Идея мне понравилась, только не захотелось возиться с Selenium. Я его вообще никогда не использовал. А ещё и скрипт набирать бы пришлось с картинки. В комментариях один человек посоветовал использовать утилиту cutycapt. И тут началось...

У меня тестовый Zabbix Server работает на базе Oracle Linux 8. Cutycapt старая утилита и для 8-й версии её вообще нет. Попытался собрать из исходников, не получилось, так как для сборки надо qt4, а он давно снят с поддержки и в репах его нет. Есть только qt5, но под ним не собирается. Долго я мучался со сборкой и установкой пакетов. Потом плюнул и просто установил пакет от 7-й версии, который взял в epel7. И на удивление, всё получилось. В зависимостях там qt5, которые подтянулись из epel8.

Также понадобился пакет Xvfb для запуска Cutycapt на сервере без графического окружения. В итоге скриншот сайта делается вот так:
# xvfb-run CutyCapt --url=https://serveradmin.ru --out=serveradmin.png

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

Помимо привязки к триггеру, можно сделать ручной запуск скрипта через веб интерфейс. А скриншот добавить на дашборд в виджет. Я так понял, что подобный виджет появился в версии 6.2, так как в 6.0 у себя не нашёл его.

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

#zabbix #website

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

Is-website-vulnerable - npm пакет, который для проверки использует публичную базу уязвимостей https://security.snyk.io. Проверка сайта выполняется автоматически и легко встраивается в ваш CI/CD или мониторинг. Можно как напрямую поставить в виртуалку, так и запускать в Docker. Первое будет удобнее для мониторинга, второе для CI/CD.

Ставим на виртуалку:
# apt install nodejs npm chromium
Запускаем тест:
# npx is-website-vulnerable https://google.com/

Exit Code покажет результат:
0 - уязвимостей нет
1 - проверка не завершена из-за ошибки
2 - найдена уязвимость

Запускаем проверку через Docker:
# docker run --rm lirantal/is-website-vulnerable:latest https://www.google.com
Контейнер запустится, выполнит проверку и сам удалиться.

При желании, можно добавить ключик --json для вывода результата в этом формате. В репозитории есть пример, как автоматизировать проверку с помощью GitHub Action. Особой сложности с интеграцией в другие CI системы возникнуть не должно.

Исходники - https://github.com/lirantal/is-website-vulnerable

#security #devops #website