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

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

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

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

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

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

Автоматический деплой WordPress темы/плагина с Bitbucket

Времена, когда приходилось ручками заливать изменения файлов на prod-сервер — стремительно проходят, и на смену им приходят системы контроля версий и автоматизированный деплой. Ведь это чертовски удобно, когда ты один или с командой можешь работать над проектом, обкатывать изменения на локальном/тестовом сервере, и уже протестированный код отправлять на «боевой» сервер простым коммитом или слиянием. Ничего более не запуская, Карл!
Временами так же приходиться работать над проектами, построенными на (пускай и по дизайну очень убогому) WordPress, у которого очень низкий порог вхождения как у разработчиков, так и у конечных заказчиков (с первого раза правильно прочитал «конечных заказчиков»?).
Почему бы не настроить автоматический деплой кода из приватного репозитория на Bitbucket.org (или GitHub — не принципиально, но на нем нет халявных бесплатных репозиториев) на «боевой» сервер под управлением этой CMS?

Давай сперва определимся с некоторыми моментами:

  • В репозитории будет храниться только тема. Хранить в репозитории код самого WP и плагинов с wordpress.org смысла не имеет, так как авто-обновление (надеюсь, включенное и настроенное по умолчанию) делает это совершенно бессмысленным. Можно аналогичным способом деплоить и кастомные плагины;
  • Конфиги для nginx так же в репозиторий не попадают. Да, можно было бы подключать их директивой include /path/to/theme/config/*nginx*.conf, но это и потенциальная возможность править от имени пользователя php конфиги nginx, и необходимость ему же дать право перезапускать его. Нельзя так делать;
  • Использовать мы будем webhooks, а это ещё тот костыль по большому счету, так как не дает гарантии корректного выполнения кода на prod-сервере по причине отсутствия контроля состояния запроса;
  • Синхронизацию БД придется делать любыми другими средствами, если они необходимы. О миграциях и прочих «вкусных» штучках задумываться есть смысл при разработке именно плагина, и реализовывать их придется самостоятельно;
  • Придется разрешить php выполнять функцию exec().

Но не смотря на озвученные выше очевидные минусы — это в дохрена раз удобнее, чем ничего. Работать будем под CentOS 7.

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

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.

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

Дружим Kali Linux с VMware

Для комфортной работы в Kali linux запущенной в VMware Workstation потребуется выполнить несколько простых манипуляций:

  1. Установка VMware tools:
    # В окне VMware Workstation нажимаем "VM -> Install Vmware Tools"
    $ mkdir ~/vmware && cd ~/vmware
    $ cp /media/cdrom/* ./
    $ apt-get install gcc make linux-headers-$(uname -r)
    $ tar -xvf VMwareTools-*.tar.gz vmware-tools-distrib/
    $ ./vmware-tools-distrib/vmware-install.pl
    # На все запросы нажимаем Enter
    $ service gdm3 restart
    

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

Брутим пароли с Гидрой (hydra)

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

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

И такой инструмент уже имеет место быть. Быстрый, сочный, достойный внимания — THC-Hydra. Версия 7.5 (из репозитория epel) поддерживает подбор по/для: asterisk cisco cisco-enable cvs firebird ftp ftps http[s]-{head|get} http[s]-{get|post}-form http-proxy http-proxy-urlenum icq imap[s] irc ldap2[s] ldap3[-{cram|digest}md5][s] mssql mysql nntp oracle-listener oracle-sid pcanywhere pcnfs pop3[s] postgres rdp rexec rlogin rsh sip smb smtp[s] smtp-enum snmp socks5 ssh sshkey svn teamspeak telnet[s] vmauthd vnc xmpp. Примеры эксплуатации мы рассмотрим чуть ниже, а пока — посмотрим как можно заполучить данный инструмент в свой арсенал.

Под катом описание всех флагов и живые примеры

Samba 4 — доступ к публичным шарам без логина/пароля

Наткнулся на одну интересную особенность Samba 4, связанную с анонимным доступом к публичным шарам. Делается это для того, чтоб пользователи могли спокойно заходить на файл-сервер и не запариваться с вводом, например, пользователя guest и пустого пароля (и в то же время существовали шары, доступ к которым возможен только после ввода пары логин:пароль).

Ранее (до третьей версии включительно) для реализации данной задачи мы пользовались указанием в секции [global] директивы security = share, а в секции самой шары — просто guest ok = yes и всё работало как надо. Теперь же надо делать чуть-чуть иначе, а именно:

Необходимо использовать директивы security = user и map to guest = Bad Password в секции [global], а так-же указывать guest ok = yes в секции шары.

Дело в том, что директивы security = share|server считаются устаревшими, именно поэтому нам и остается пользоваться security = user. Для отделения же пользователя от гостя применяется новая директива map to guest = Bad Password (смысл которой заключается в том, что если пользователь Samba существует в системе и введен неверный пароль, то вход этого пользователя отклоняется, если пользователя не существует, тогда ему присваивается статус гость). Ну а для того чтобы открыть доступ к общему ресурсу для гостей осталась старая добрая директива guest ok = yes которую необходимо указывать непосредственно в секции шары.

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