Все записи автора KulMaks

Уязвимость во всех версиях Joomla, позволяющая выполнить удаленно любой код (CVE-2015-8562)

CMS, Joomla,

Несколько дней назад была обнаружена уязвимость (CVE-2015-8562), которая затрагивает все версии Joomla, начиная с версии 1.5 и позволяет злоумышленнику удаленно выполнить любой код на сервере. Уязвимость возникла из-за недостаточной фильтрации информации о браузере (в частности, юзерагенте) при записи данных сессии в БД. Для актуальных версий Joomla уже доступен апдейт до версии 3.4.6, в котором уязвимость устранена. Если же вы пользуетесь версией 1.5 или 2.5, вам необходимо вручную заменить файл libraries/joomla/session/session.php на исправленный файл, который вы можете скачать отсюда: https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions

Также, можно по логам веб-сервера отследить пытались ли вас взломать. Для взлома, в строку юзер-агента записывается примерно следующее:

}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:60:\x22eval(base64_decode($_POST[111]));JFactory::getConfig();exit;\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}\xF0\x9D\x8C\x86"

Таким образом, примерная строка для поиска в логах будет выглядеть как  __test|O:

Этого вполне достаточно для того, чтобы отсеять все правильные юзер-агенты и запросы от попыток эксплойта.

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

Список медленных запросов MS SQL

Microsoft SQL Server, Windows,

Довольно часто причиной медленной работы SQL-сервера является не слабое железо, а неоптимизированные запросы. Если бы речь шла про MySQL, все было бы просто — достаточно включить лог медленных запросов и задать длительность запроса, после которой он считается медленным. Но в MS SQL все не может быть настолько просто! Итак, зачастую на SQL-серверах медленные запросы возникают по причине большого количества операций чтения с диска. Если данных необходимо вычитать много, лежат они в разных концах диска (или рэйд-массива), да и параллельно с этим есть еще десяток-другой читающих потоков, время выполнения запроса может измеряться десятками секунд. Неплохо было бы такие запросы оптимизировать. А первый шаг оптимизации — их поиск.

Ползая по интернету именно с целью поиска запросов, которые укладывают (ненадолго) на лопатки SQL-сервер, я наткнулся на замечательную статью: «Optimizing SQL Server Query Performance«. Если вы хотите всерьез заняться оптимизацией запросов — ее стоит прочитать полностью. Но меня в данном случае заинтересовал только один запрос, который позволяет получить из статистических данных «самые-самые» запросы:

SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1, 
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1), 
qs.execution_count, 
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC

По результатам выполнения этого запроса вы получите список запросов, которые считали больше всего данных (суммарно на все выполнения). Именно с этих запросов и стоит начать оптимизацию.

Решение проблемы «The trust relationship between this workstation and the primary domain failed» без вывода ПК из домена

Active Directory, Windows,

По самым разным причинам можно столкнуться с проблемой невозможности входа в систему на компьютере, включенном в домен. Если это происходит на обычном клиентском ПК — ничего не мешает вывести его из домена и добавить заново — проблема решается гарантированно. Но если дело касается сервера, на котором крутятся приложения, завязанные на AD — рисковать выводом сервера из домена не очень хочется. К счатью, способ «возврата» к нормальному состоянию есть.

Вообще, проблема с невозможностью залогиниться в домен с такой ошибкой, сопровождается записью в системном логе следующего содержания:

 This computer could not authenticate with DomainController’ a Windows domain controller for domain DOMAIN, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

Т.е., как обычно у майкрософта, ничего конкретного о способах решения в ошибке не сказано. Корни проблемы уходят в доменную авторизацию: по умолчанию, пароль для учетной записи компьютера имеет срок жизни в 30 дней. Если ОС не связывалась с доменом в течение этого срока или, например, вы восстановили из бэкапа 30-дневной давности сервер/виртуалку — вы не сможете залогиниться на него под доменной учетной записью. Для исправления этой ситуации необходимо:

1. Залогиниться на сервер под локальной учетной записью с администраторскими полномочиями;

2. Выполнить команду klist purge для очистки кэша Kerberos на сервере.

3. Выполнить команду  «netdom resetpwd /s:x.x.x.x  /ud:domain\User /pd:*», где x.x.x.x — IP-адрес контроллера домена, domain\User — учетная запись администратора домена с указанием имени домена.

4. После запроса пароля — ввести пароль от учетной записи администратора домена.

5. Перезагрузить сервер и залогиниться под учетной записью администратора домена.

Если это не помогло — вам поможет только вывод компьютера из домена и повторное его туда включение. Или техподдержка Майкрософта :)

Перезапуск процесса восстановления Exchange 2010 в случае ошибки

Exchange 2010, ,

При переносе сервера MS Exchange 2010 в конфигурации отличной от единственного сервера, могут возникать непредвиденные проблемы. Даже несмотря на то, что установщик выполняет большое количество проверок, бывают непредвиденные обстоятельства, из-за которых процесс установки прерывается. Казалось бы, нет ничего проще, чем запустить восстановление заново. Но если бы все пошло хорошо — это был бы не тот майкрософт :)

Если при установке все проверки пройдены и начался собственно этап установки, то после сбоя и повторного запуска, вы увидите примерно такую ошибку: «Setup previously failed while performing the action DisasterRecovery. You can’t resume setup by performing the action install». При этом, запустить Uninstall тоже нельзя. Да и вообще ничего нельзя сделать при помощи этого инсталлятора.

И, что характерно для майкрософта, решение проблемы находится в реестре. Для возобновления работы установщика, необходимо перейти в ветку:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14

Найти там разделы с именами ролей сервера (HubTransportRole, MailboxRole и др.) и удалить из них все ключи с именами «Watermark» и «Action». После этого установка перезапустится без проблем.

Сброс пароля root в mysql без рестарта сервиса

mysql,

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

Впрочем, есть одно решение для таких случаев. Оно, конечно, не рекомендуемое (а при отсутствии должного внимания так и совсем противопоказано), но все же оно есть.

1) Запускаем второй экземпляр mysql-сервера. Как это сделать, я писал ранее здесь. Разница только в том, что сейчас не надо копировать базу mysql. Необходимо подготовить конфиги и запустить команду

mysql_install_db --datadir=/dbdata/datadir/ --user=mysql

2) Логинимся на новый сервер под учеткой root.

3) Копируем таблицу user из базы данных mysql старого сервера на новый.

4) Заставляем сервер переоткрыть таблицы командой

flush tables;

5) Меняем пароль для пользователя root:

update mysql.user set password=PASSWORD('I-will-never-forget-root-password') where user like 'root';

6) Выполняем еще раз команду flush privileges.

7) Пробуем залогиниться повторно с новым паролем.

8) Если все ок, то останавливаем второй сервер (не основной!) и копируем файлы таблицы user из базы данных в обратном направлении (т.е. на основной сервер).

9) Осталось заставить сервер перечитать таблицу с пользователями. Это можно сделать, послав процессу сигнал SIGHUP. Делается это командой

kill -1 12345

где, 12345 — pid процесса mysqld.

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