.
21 Декабрь 2016

Скрипт проверки изменений файлов на сервере

Говорят «лучшее — враг хорошего», и в этом есть смысл.

Под впечатлениями от скрипта в предыдущей статье, решил поставить «следилку» на сайты нескольким своим клиентам, и чуток разочаровался — скрипт у одного не запустился т.к. версия PHP была мягко говоря устаревшей, на мои призывы обновиться сказал «работает — не трогай» (и в этом тоже есть своя правда), у другого довольно сильно подвесил систему т.к. файловая структура составляла сотни! тысяч файлов, а режима «быстрой» проверки (только по атрибутам файла — размер, даты, режим доступа, владельцы) отсутствовал.

Собственно, пришлось сделать простенький скриптик, практически моментально сравнивающий изменения из файлов, содержащих информацию о файловой структуре сайта.
Снимать дампы можно консольно (мне так удобнее), желающие могут дописать скрипт.
Скрипт «голый» — без интерфейса, отправки на мыло изменений и других наворотов — как есть.
Пользоваться так:
ls -alR > file1.txt
ls -alR > file2.txt
fdiff.php file1.txt file2.txt > diff.txt
скрипт кидает результат в поток, в моём случае перенаправленный в diff.txt

Кого заинтересовало — качаем.

рубрики: security, Администрирование, взлом и безопасность, Полезности, Программирование | Комментарии (0)

20 Декабрь 2016

Скрипт проверки изменений на сайте — Анти Шелл

Просто скопирую сюда письмо, которое отправил создателям данного очень полезного скрипта!

Приветствую коллеги!

Недавно наткнулся на ваше творение Скрипт проверки изменений на сайте — Анти Шелл — сам уже подобный скрипт писал под свои нужны много лет назад — а тут всё красиво — ООП, гит + интерфейс + основной функционал по созданию снимка и отправка на мыло изменений = молодцы!
Хотел своё творение облагородить, но всё руки не доходили …

Отписал на блоге позитив 🙂

Единственно — думаю есть смысл добавить FAST режим (без проверки по содержимому файла — только по атрибутам (размер + дата модификации).

А то на больших проектах не работает по памяти (пока явно не пропишешь поболе) и работает долго, нагружая всю систему.

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


С наилучшими пожеланиями,
Алексей
gtalex.ru

GitHub

Скачать v.1.2.2

На всякий случай Зеркало версии 1.2.2

рубрики: security | Комментарии (0)

10 Ноябрь 2016

Лечение зараженных сайтов. Аудит безопасности.


Лечение зараженных сайтов. Аудит безопасности.

Время от времени, а точнее когда в очередной раз натыкаюсь на ломаные сайты, публикую подобные посты а ля «вылечу Ваш сайт», проведу аудит безопасности и самое главное — установлю систему контроля на взлом Вашего сайта!
Вот и сейчас пример поломанных 4х сайтов с файловыми и php иньекциями, тематика фармацевтика — т.к. её часто смотрю:
Сайт www.mgrad-putilkovo.ru — инъекция Где можно купить дженерик сиалис
Сайт www.catalog-max.ru — инъекция Где можно купить таблетки виагра
Сайт pearl-zelenograd.ru — инъекция Не дорого преобрести левитра — взломщик видимо не особо грамотный попался 🙂
Сайт za-vidnoe.ru — инъекция Женская виагра купить в аптеке Москва

Как видно хакеры уже ломают с умом и с конкретной целью — монетизировать взломанный ресурс, путём продажи через партнерку фарма препаратов (если конечно дорвей долго проживёт и поймает поисковый трафик — проиндексируется и «повисит» в выдаче Яндекса некоторое время на хороших позициях).
Так же видим, что по сути прямого вреда сайту данная иньекция не наносит — информация на сайте остаётся нетронутой, но всё же я думаю вред всё таки есть — страницы генерируются доргеном, текст на таких страничках создаётся роботизированный — не имеющий смысла, подобные страницы как правило не нравятся поисковикам — и на сайт накладываются штрафные санкции понижающие его в поисковой выдаче — что может быть хуже ? (конечно кроме порчи информации)
Так что, если Ваш сайт резко начал снижаться в позициях в ТОПах — проверьте его на зараженность, если сами не умеете — обратитесь к профессионалам или например я мог бы глянуть (гораздо дешевле чем у профи).

P.S.
К сожалению на мои посты и письма никто внимание не обращает — видимо люди заводят сайты просто так, и им плевать что с ними дальше будет.

рубрики: security, Администрирование, взлом и безопасность | Комментарии (0)

7 Сентябрь 2016

Взломаные сайты в поисковой выдаче Яндекса

Анализ поисковой выдачи конкурентных запросов — неиссякаемый источник информации к размышлению для оптимизатора!
Собственно, даже толком не понимаю зачем этот пост пишу — просто бесит блин когда в выдачу лезут подобными методами (я ведь не хакер, был бы хакером наверное не бесило бы).
Итак, ближе к телу — мониторил региональную выдачу «купить сиалис в Томске» и обалдел от количества лома в выдаче, причем на довольно ТОПовых позициях! что ещё больше раздражает!

То ли хакеры взялись за фарму, то ли вебмастера у хакеров лом скупают — не понятно.
Лом брать рискованно — во первых незаконно, теоретически могут и «подтянуть», а во вторых — недолговечно — как только хозяин узнает, сразу прибъёт — деньги улетят на ветер, но идея заманчива 🙂
Ломать самому — ещё более рискованно, и трудно досягаемо — пока этому научишься пройдёт время, Яша уже может научиться бороться за чистоту выдачи — всё время выкинуто на ветер.
А ничего не делать — вообще бесит! 🙁

лом в выдаче Яндекса

Ещё скриншотик с выдачи:
Читать полностью »

рубрики: security, партнерки, Партнерские програмы, Размышления | Комментарии (1)

11 Февраль 2016

Блокировка ботов по user-agent — blacklist список

Итак, имея инструмент блокировки по black-list и вручную ковыряя логи, обнаружил что практически DDOS устраивают куча всяких «левых» ботов.
Например «SemrushBot www.semrush.com/bot.html» — какой то иностранный SEO инструмент — думаю мой сайт ему вообще не пригодится, собирает всё на автомате создавая лишнюю нагрузку.
«megaindex.com» туда же — я на мегаиндексе ни ссылки ни статьи не закупаю, и не продаю.
«libcurl» — кто, то парсит curl-ом — тоже в сад
Анализ своих логов может проявить ещё много ненужных вам ботов.
Блокировать можно в 2 уровня — дописать в анализаторо логов по вхождению в user-agent, а так же непосредственно в nginx в начало секции server { … } добавляем:
if ($http_user_agent ~ SputnikBot|Crowsnest|PaperLiBot|peerindex|ia_archiver|Slurp|Aport|NING|JS-Kit|rogerbot|BLEXBot|MJ12bot|Twiceler|Baiduspider|Java|CommentReader|Yeti|discobot|BTWebClient|Tagoobot|Ezooms|igdeSpyder|AhrefsBot|Teleport|Offline|DISCo|netvampire|Copier|HTTrack|WebCopier) {
return 403;
}

Список проверяем вручную!
Как видно в списке присутствуют программы качающие сайт целеком — они так же создают сильную нагрузку! Вот ещё Список ботов и программ качающих сайт целиком.

рубрики: security, Администрирование | Комментарии (1)

10 Февраль 2016

Защита от DDOS — анализ логов nginx и блокировка IP по blacklist фаерволом

В посте Защита от DDOS — первые шаги я закончил фразой «Теперь вот жду второго пришествия» — собственно, второе пришествие недавно заглянуло в виде очень дохленького DDOSa который все же забил канал так, что провайдерам пришлось отрубили порт.
Кэширование nging вообще тут не участвовало т.к. ддосили POST запросами.
Ограничение зоны на количество запросов с одного IP NGINX — защита от DDOS с одного IP. Параметры limit_zone и limit_req тоже не спасли!

Принял решение — полностью задействовать фаервол в связке с nginx, в моём случае фаервол ipfw т.к. операционная система FreeBSD, но это не суть, т.к. смысл остаётся тем же:
Анализируем логи, вычисляем злодеев, загоняем IP злодеев в blacklist который кушает фаервол.
Читать полностью »

рубрики: NIX, security, Администрирование | Комментарии (1)

13 Январь 2016

Как узнать версию Joomla

Собственно перед взламыванием сайта зачастую собирают информацию о платформе и её версии.
Если это джумла — добавляем к имени домена /language/en-GB/en-GB.xml и вуаля!

P.S.
Запись для себя, чтоб не забыть 🙂

рубрики: Joomla, security | Комментарии (0)

13 Январь 2016

Пример анализа взлома сайта Joomla и устранение причины проникновения com_contenthistory

Собственно, может кому интересно будет — небольшой пример из текущего (буду краток).
Гемор: джумла, за безопасностью которой особо никто не следит, потому что джумла!
По знакомству данный гемор лежит на моём серваке, где у меня ночью отрабатывает самописный скриптик по отлову изменений в скриптах, и информирует меня в случае оных.
Вот и проинформировал меня вчера о появлении нового скрипта » /images/stat.php < 92427 " Излюбленное место хранения бэкдоров и наиболее популярное для бэкдора название 🙂 Смотрим файло глазами:

видим обфусицированный код (если есть желание посмотреть исходный код — пробуем) исходник бэкдора
запускаем — форма пост запроса (вероятно пароль к бэкдору)
search

search


Зараза 100% — убиваем её!
Осталось одно НО! — если зараза проникла единожды, проникнет и вторично!
Первое, что делаем — меняем все пароли доступа (т.к. скорее всего они уже у хакера в базе).
Второе, нужно анализировать логи веб-сервера и искать непосредственно дыру: как именно был внедрён бэкдор?
Дату создания и модификацию файла бэкдора подменили (бывает и не меняют — искать в логах гораздо проще).
Далее недолгий анализ, насторожил меня GET запросами вида

"/?option=com_contenthistory&view=history&list[ordering]=&item_id=&type_id=&list[select]=polygon%28%28/*!00000select*/*/*!00000from*/%28/*!00000select*/*/*!00000from*/%28/*!00000select*/concat_ws%280x7e3a,%28/*!00000select*/concat_ws%280x7e3a,0x534b4f54494e4b494e,username,password,0x505343%29/*!00000from*/fot6h_users%20where%20id%20=%20710%29%29as%20mk%29%60%60%29%60%60%29%29"

С какого это перепугу, в запросе иньекции SQL кода ?! явно используя дыру хотят чего то из базы поиметь — админские пароли, куки и т.д. и т.п.
Далее гуглим про дыры в «com_contenthistory» и сразу всё становится на свои места 🙂
Искать заплатки по данной дыре — дело хозяина джумлы, я же на скорую руку просто затыкаю любые запросы с вхождением com_contenthistory в параметры через .htaccess

RewriteCond %{QUERY_STRING} com_contenthistory
RewriteRule .* - [F]

рубрики: Joomla, security | Комментарии (1)

12 Январь 2016

Скрытое выполнение в PHP скриптах

Статья настолько мне понравилась, что с указанием источника сделал полный репост!
Знания необходимы для возможности определить «заразу» визуально для дальнейшего его уничтожения.
Далее от автора:

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

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

Данный подход с одной стороны значительно усложняет анализ исходного кода, а с другой — позволяет хранить код в текстовых данных. Например, часть вредоносного кода может загружаться со стороннего сайта, из базы данных и мета-данных jpeg/png/gif или передаваться в запросе к скрипту. Кроме того, часть кода, представленная в виде обычной текстовой строки, может быть очень надежно зашифрована.

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

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

echo «Test»

которая выводит слово «Test» на странице. Естественно, имена переменных и функций, а также исполняемый код не хранятся в открытом виде и в большинстве случаев обфусцированы.

Вариант 1: косвенный вызов функции


<?php
    $a = "var_dump";
    $b = "Test";
    $a($b);
?>

Вариант 2: выполнение кода через eval


<?php
  eval('$a = "Test"; echo $a;');
?>

Вариант 3: выполнение кода через assert


<?php
  assert('print("Test")');
?>

Вариант 4: выполнение кода через array_map


<?php
  function evil($a) {
    echo $a;
  }
  array_map('evil', array("Test"));
?>

Вариант 5: выполнение кода через preg_replace(‘/.*/e’)


<?php
  preg_replace('/.*/e', 'print("Test")', '');
?>

Вариант 6: выполнение кода через preg_replace_callback


<?php
  $a = function () { echo "Test"; };
  preg_replace_callback('/.*/', $a, '');
?>

Вариант 7: выполнение кода через usort, uasort, uksort


<?php
  $a = function ($x, $y) { echo "Test"; };
  $b = array(1 => '1', 2 => '2');
  usort( $b, $a);
?>

Вариант 8: скрытое объявление функций и передача параметров через extract


<?php
   extract($_REQUEST);
   $a($b);
?>

При запуске http://site.ru/script.php?a=system&b=ls выполнит системную функцию system(«ls»)

 

Вариант 9: через регистрацию функции завершения (можно сделать exit() или die() для немедленного выполнения)


<?php
   register_shutdown_function(create_function('', "echo 'Test';"));
?>

Такой же подход можно использовать со всеми вызовами, принимающими в качестве аргумента callable функцию: call_user_func_array(), call_user_func(), forward_static_call_array, forward_static_call(), register_tick_function(). Хотя в реальных шеллах и бэкдорах вызовы через данные функции мы не встречали, обычно используются варианты с 1 по 8.

 

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

 

Кстати, бОльшая часть данных вызовов успешно детектируется сканером вредоносного кода AI-BOLIT. Это отличает его от обычных сканеров, выполняющих поиск вредоносного кода по хэшу.

Источник

рубрики: security, Полезности | Комментарии (0)

4 Сентябрь 2015

NGINX — запрещаем доступ к служебным файлам .git .bak .old .htaccess и других по расширению

Нередко, в движках используют в скриптах подключаемые файлы с расширением отличным от php, что имхо очень неправильно и опасно.
Например в одном из движков (не буду тыкать пальцем каком именно) в темлейте подключают файлы с расширением .tpl которые не являясь активкой по умолчанию (интерпретатор настроен по умолчанию как правило на htm html php php5 и подобные), которые спокойно открываются в браузере в исходных кодах! а там уже есть чего поанализировать «плохим парням» 🙂
Другой пример — служебные файлы .git, старые резервные копии .bak .old … всё это часто забывают запретить в настройках аппача или nginx-а.

Соответственно, добавляем в nginx следующие строки, и спим спокойно

404

рубрики: security, Администрирование | Комментарии (0)

  • Календарь
  • Октябрь 2018
    Пн Вт Ср Чт Пт Сб Вс
    « Сен    
    1234567
    891011121314
    15161718192021
    22232425262728
    293031  
  • Архивы
  • Статистика LI
Яндекс.Метрика