Небольшая история о нашем первом кейсе – визитка на Drupal 7

Маленькая история о большом друпале и маленьком сайте. 🙂

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

 

Предугадываю вопрос: почему юзается друпал на том проекте?

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

 

Короче, клиентос до нас страдал.

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

Клиент обратился в фирму, которая специализируется на защите сайтов (лол).

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

 

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

1) Вкорячили скрипт на bash, смысл которого в выставлении прав на папки и файлы (find + chmod)

2) Добавили скрипт protect.php для вызова этого bash (т.е. из–за того, что эти убеаны не умеют в PHP, тебе нужно добавить system или popen в вайтлист на серваке)

3) Добавили скрипт unprotect.php. Это тот же самый скрипт, что и protect, только $cmd_list у него такой — «find `pwd` -exec chmod u+w {} \;».

 

Ну, это ещё мелочь. Они намахали целый многоэтажный комплекс php говнокода. Эта хрень присобачивается с помощью директивы auto_prepend_file к каждому запросу и анализирует его. По факту, есть набор правил, которые они проверяют в запросе useragent, сверяются по своей базе не является ли ip забаненным (sic!), запрещают доступ к урлам и устанавливают некоторые http заголовки.

Весь этот бред эти дятлы сделали на PHP, хотя всё это решается на стороне web–сервера и настроек CMS. Самое смешное, их скрипт полезен только наполовину, т.е. 70% кода там — обслужка для вывода статистики и прочего говна.

А ещё приколола фича с антифлудом — они инжектят js код, который устанавливает в куках ok, а они потом проверяют эту куку. А если у меня не js, то сайт на втором запросе пошлёт меня далеко.

 

Ещё они добавили в htaccess запрос на базовую web авторизацию. Для адреса /admin. Это совсем не важно, что путь для логина в админку на сайте совсем другой.

 

Я так понял, денег за эту хрень взяли не мало, при этом, эти мудилы даже не удосужились проверить ОЧЕВИДНЫЕ файлы на зловреды! К нам сайт пришёл буквально через месяц после них, основной жалобой клиента была 502 ошибка через раз. Сразу видно, поработали профессионалы, хвала Элуне, что хостер не заблокировал сайт к эбеням.

 

Как мы помогли клиенту?

Всё началось банально. Сначала я выпилил все подозрительные файлы из default/files, их было довольно много, но пара скриптов сделали своё дело. После этого начал смотреть по логам, откуда идут 502 и стал точечно проверять эти файлы. Нашёл пару вредоносов, расшифровал насколько возможно и дальше уже по найденному паттерну стал проверять всё.

Выпилил всё это говно с сайта, карусель 502 сразу же прекратилась. По факту, сайт роняли file_get_contents на уже не существующие url.

 

Далее началось интересное. Когда я в первый раз залогинился, то прифигел от количества предустановленных модулей. Там их было что–то около 260 штук. 260 модулей для контентного сайта визитки, неплохо. 😀 Причём, модули довольно разношёрстные, от chaos tools до ecommerce модулей. Начался период активного удаления всего лишнего и правок шаблонов, завязанных на этом.

Завершилось всё обновлением drupal до последней на тот момент версии 7.22 и попутным обновлением всех модулей (это оказалось довольно геморно).

Итак, несколько суток работы, и хоп, сайт на друпале работает, не падает и показывает весьма приличную скорость работы. А когда я к херам выпилил подключение того говно–комплекса из htaccess, скорость увеличилась ещё заметнее.

 

Начался период восстановления в выдаче поисковиков

Те обезьяны, что взломали сайт, наделали кучу спам статей на китайском языке, поэтому сайт оооочень сильно просел. Несколько месяцев мы восстанавливали позиции практически с нуля.

За это время мы привелив порядок типографику, добавили CTA формы и кнопки, вкорячили мегакалькулятор, который я делал на Vue2 и интегрировал с друпаловским Webforms API, а на той неделе зафигачили пару красивостей, которые изначально подразумевали полный редизайн главной, но клиент, к сожалению, не согласился на столь радикальное решение.

 

Впереди ещё куча работы, однако, уже сейчас результат налицо.

comments powered by Disqus