Создать зеркало обновлений для Eset Nod32?

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

Если подробнее — то она не подходила для версий антивируса старше четвертой. Как оказалось — нод не умеет самостоятельно определять под-директорию из которой ему следует обновиться, и как следствие все пытались обновиться из корня — и как следствие обновлялась только «четверка». Далее — старая версия не умела обновлять компоненты антивируса. Далее — в итоговое зеркало не попадали все необходимые «модули». Ещё — был чертовски кривой веб-интерфейс.

Так же просмотрел значительное количество решений других разработчиков. Забавно то, что 90% из них написаны на php, и состоят из одного файла с лютым хардкодом всего что можно, и чего нельзя. Да и не поддерживаются совсем.

А что же теперь? А теперь мне удалось избавиться и от этих проблем, и попутно (с момента публикации этого поста уже произошли какие-то изменения, однозначно) повысить стабильность. Не получилось пока реализовать авто-обновление, но я над этим думаю. Традиционно скрипт умеет сам искать ключи.

Подробнее под катом

LEMP + CentOS = ❤

Данный пост скорее заметка для самого себя, дабы не забыть чего при новой итерации. Нового в ней ничего нет, ставим пакеты да настраиваем. У нас имеется новый и девственно чистый сервер под управлением CentOS 7.2 (minimal). Задача — поставить на него nginx + php + php-fpm + mysql и чтоб всё это шустро работало, да обновлялось самостоятельно из репозиториев (при возможности). Так же необходим тот же phpMyAdmin и настроенная отправка почты с сервера. В общем — минимальный web-stack, на котором хоть разработкой занимайся, хоть что-то вордпресо-подобное разворачивай. Сервер, к слову, располагается на hetzner.de.
Подробнее под катом

Собираем и настраиваем msmtp

msmtp — это простой консольный клиент для отправки сообщений электронной почты по протоколу SMTP.

Можно, конечно, пойти сложным путем и поставить полноценный почтовый сервер, но зачем? Нам ведь требуется просто позволить скриптам и демонам отправлять почту, а заморачиваться с DKIM, SPF, заголовками и прочим — крайне лень. Поэтому мы будем отправлять почту с помощью почтового ящика на yandex.ru, и поможет нам в этом приложение под названием msmtp.

Важное замечание — в моем случае домен уже делегирован на яндекс, в DNS имеются все необходимые записи, почтовый ящик создан на странице pdd.yandex.ru, к нему прописаны алиасы вида no-reply, noreply, donotreply, do-not-reply для того, что бы была возможность иметь почтовый ящик с именем [email protected], но успешно отправлять письма от имени, например, [email protected].

Единственное но — в репозиториях находится старая и бажная версия. Самый критичный для нас баг — это неизменяемое поле Sender, т.е. мы не можем указать имя (или адрес? не помню) отправителя. Смотрим что есть в репозиториях:

$ yum info msmtp
# ...
Name        : msmtp
Version     : 1.4.32
Release     : 1.el7
Size        : 120 k
# ...

Смотрим информацию о релизах на официальном сайте — на момент написания этих строк это версия 1.6.5 (уже без описанного выше бага).

Все манипуляции производились на «чистой» системе CentOS 7.2.

Скачаем исходники и соберем приложение ручками.
Подробнее под катом

Настройка хостинга на RU-Center (nic.ru)

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

Итак, отбросим причины в сторону. Первым делом — что нам понадобится для того чтоб всё сделать «под ключ», т.е. владельцем домена/хостинга был заказчик (как физ.лицо), а ты был лишь лицом, которое выполняет работу? От заказчика тебе потребуется:

  • Фотографии/сканы разворота паспорта и страницы с пропиской;
  • Логин/пароль от почтового ящика, который будет фигурировать при регистрации;
  • Необходимая сумма денег для оплаты требуемых услуг.

Вопрос: При регистрации домена может сразу встать вопрос — делегировать домен на руцентр или, например, сразу же на DNS-хостинге от Яндекса?

Ответ: На руцентр. Так как для делегирования на Яндекс потребуется подтвердить права на владение доменом. И проще всего это сделать с помощью проверки наличия определенного файла с кодом в корне сайта. Поэтому — смело всё делай по дефолту, потом переделегируем, если потребность такая возникнет.

Сразу скажу — если «с сайта» будут отправляться письма и при этом хостить DNS у Яндекса — возникнут проблемы с отправкой писем. DKIM настроить на Яндекс будет невозможно, а у руцентра он принципиально не настраиваемый. Поэтому считай это тонкостью использования руцентра в целом.

Итак, считаем что аккаунт у нас заведен, домен — зарегистрирован, хостинг — заказан. Не забудь а «Личных данных» приложить сканы/фотографии паспорта клиента для верификации личности, так правильнее будет.

Подробнее под катом

Тотальная защита WordPress

В прошлом посте мы рассматривали методы повышения безопасности WordPress с помощью nginx. В данной же записи мы рассмотрим дополнительные меры противодействия сбору информации о работающей CMS (и плагинах), версии WP и некоторым типам атак на сайт.

Помогать нам будет уже не только nginx — но и fail2ban вкупе с некоторыми дополнениями и настройками самого WP.

Обозначим проблемы безопасности, которые «по умолчанию» имеют место быть:

  1. WordPress вставляет данные о своей версии в различные места генерируемого контента;
  2. Стандартные настройки его имеют довольно много потенциально слабых мест;
  3. Стандартные настройки доступа к сайту позволяют без особых трудностей собрать потенциальному взломщику довольно много информации;
  4. «Из коробки» отсутствуют какие-либо средства против перебора директорий и паролей.

Ниже мы примем требуемые меры к их решению. Данная запись будет со временем обновляться и дополняться.

Подробнее под катом

Повышение безопасности WordPress с помощью nginx

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

Проанализировав логи одного блога на WordPress заметил, что присутствует довольно большое количество запросов к страницам, которых не существует. Посмотрев внимательнее стало очевидно, что имеет место как сбор данных как об используемой CMS, так и попытки эксплуатировать различные уязвимости плагинов, тем и самого WP.

Запрошенные страницы имели примерно следующий вид:

/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php
/wp-admin/admin-ajax.php?action=revolution-slider_show_image&img=../wp-config.php
/wp-content/themes/infocus/lib/scripts/dl-skin.php
/wp-admin/admin-ajax.php?action=showbiz_show_image&img=../wp-config.php
/wp-content/plugins/google-mp3-audio-player/direct_download.php?file=../../../wp-config.php
/wp-admin/admin-ajax.php?action=kbslider_show_image&img=../wp-config.php
/wp-content/themes/parallelus-mingle/framework/utilities/download/getfile.php?file=../../../../../../wp-config.php
/wp-content/plugins/db-backup/download.php?file=../../../wp-config.php
/wp-admin/admin-ajax.php?action=revslider_ajax_action&img=../wp-config.php
/wp-content/plugins/wp-filemanager/incl/libfile.php?path=../../&filename=wp-config.php&action=download
/wp-content/themes/churchope/lib/downloadlink.php?file=../../../../wp-config.php
/magmi/web/plugin_upload.php

Для повышения безопасности мы будем использовать nginx, путем добавления описанных ниже правил в секцию server {...} нашего блога

Подробнее под катом

Включаем поддержку HTTPS на сайте

Крайнее время, в связи с различными факторами — всё чаще встает вопрос безопасности передачи данных между клиентом и сервером. Разные жулики и спец. службы перехватывают трафик, вытаскивают из него различные данные (включая пароли), некоторые провайдеры публичные точки доступа в сеть даже встраивают в него рекламные баннеры. Для решения этой задачи уже имеются необходимые механизмы под именем SSL, с которыми мы сейчас довольно плотно и поработаем. Данная технология позволяет дать почти 100% гарантии, что трафик не будет прослушан и видоизменен. Подробнее об этом есть смысл спросить у Вики.

Подробнее под катом