4. Встановлюємо Security Review:
drush en security_review -y
Можна і відразу все встановити.
drush dl drupalgeddon -y; drush dl site_audit --dev -y; drush dl hacked --dev -y; drush en hacked -y; drush en security_review -y
5. Запускаємо drupalgeddon в режимі перевірки (аудиту) сайту.
Що також запустить все вишеустановленние модулі і створить файл звіту 'report.html'. Ми його відкриємо і побачимо наші проблеми.
Видаляємо всі знайдені вломаннимі файли, Ноди, модулі.
drush aa --html --bootstrap --detail --skip = insights>. / report.html
Знаходимо всі підозрілі файли і директорії і видаляємо їх. Підсилюємо захист сайту.
6. Запускаємо Hacked в Drush.
Переглядаємо всі змінені проекти / модулі:
drush hacked-list-projects --force-rebuild
Після цього для кожного зміненого проекту / модуля, наприклад changedproject, запускаємо:
drush hacked-details changedproject
Також, після цього знаходимо всі файли / директорії, яких немає в проекті / модулі:
drush hacked-diff changedproject
7. Drupalgeddon
8. Видаляємо користувачів
drush user-cancel username
drush ucan username
9. Скидаємо пароль першого користувача / адміністратора
10. Змінюємо паролі користувачів
drush user-password username --password = "NEWPASS"
# або
drush upwd username --password = "NEWPASS"
Переходимо на сайті по / admin / reports / security-review /, дивимося, що у нас зламали.
11. Знаходимо і видаляємо зламані файли
find. -size 494c -name "* .php"
# Також можна так:
find. -size 494c -name "* .php" | xargs rm
12. Знаходимо файли з PCT4B ін'єкцією
grep -Rl PCT4BA6ODSE.
# і
grep -Rl q6ae4d5.
13. Визначаємо місцезнаходження різних заражених файлів
grep -Rl SOL_TCP.
grep -Rl SOCK_STREAM.
grep -Rl SOCK_DGRAM.
grep -Rl SOL_UDP.
grep -Rl SO_REUSEADDR.
grep -Rl SO_RCVTIMEO.
grep -Rl SO_SNDTIMEO.
cd / var / log / httpd /
grep -iR 'ІМЯ_ЗАРАЖЕННОГО_ФАЙЛА.php'.
Якщо Ви знайдете який-небудь заражений файл в модулі, то краще видалити весь модуль і повторно завантажити чистий.
14. Встановлюємо правильні права
cd / DRUPAL_DIR find. -type d -print0 | xargs - 0 chmod 755; find. -type f -print0 | xargs - 0 chmod 644; chmod 777 sites / default / files; find. / Sites / default / files -type d -print0 | xargs - 0 chmod 777; find. / Sites / default / files -type f -print0 | xargs - 0 chmod 666;
Або створюємо і запускаємо скрипт.
Копіюєш код скрипта в файл і називаєш його, наррімер "fix-permissions.sh" і запускаєш:
sudo bash fix-permissions.sh --drupal_path = your / drupal / path --drupal_user = your_user_name
тобто з нашими даними, це приблизно так:
sudo bash fix-permissions.sh --drupal_path =. / Директорія _ нашого _ сайту --drupal_user = www-data
Запускаємо його так:
/ Usr / local / bin / fix-permissions.sh --path = / home / USER / public_html --user = USER --group = GROUP
Запускаємо його так:
/ Usr / local / bin / fix-permissions-strict.sh --drupal_path = / home / USER / public_html --drupal_user = USER --httpd_group = GROUP
Зараз ще модуль для drush з'явився для правильної розстановки прав для файлів: File permissions
15. Перевіряємо лог файли
grep cwd / var / log / exim / mainlog | grep -v / var / spool | awk -F "cwd =" '' | awk '' | sort | uniq -c | sort -n/ Var / log / httpd / error_log
/ Var / log / httpd / access_log
/ Var / log / httpd / suexec_log
/ Var / log / httpd / fpexec_log
/ Var / log / httpd / domains / domain.com.error. log
/ Var / log / httpd / domains / domain.com. log
/ Var / log / messages # 40; generic errors # 41;
Багато питань про сенс різних дій, і застосовності їх в довільному випадку:
«11. Знаходимо і видаляємо зламані файли
find. -size 494c -name "* .php" »
І з чого б зламані файли повинні б мати саме такий розмір?
«13. Визначаємо місцезнаходження різних заражених файлів »
І що цими греп в якому випадку можна знайти? Відповідь: найімовірніше нічого.
«14. Встановлюємо правильні права »
Немає правильних прав. Є правильні права при певних налаштуваннях оточення.
«15. Перевіряємо лог файли »
RHEL | CentOS аж ніяк не у всіх, відповідно, шляхи будуть відрізнятися.
А хто ставить DirectAdmin той сам собі злий буратіно, і ймовірність, що зламаний НЕ друпал в цьому випадку, а DA вельми не нульова. =)
Список mysql не там де вказано лежать уже багато років. Швидше за все, у вашому дистрибутиві вони пишуться в syslog,
«16. Видаляємо підозрілі листи в exim »
Треба б пояснити, що це не треба тупо робити. І пояснити, навіщо, і в яких випадках знадобиться це робити. Також, postfix більш поширений ніж exim, до речі.
Наприклад timeout_frozen_after = 0 не варто робити. Варто розбиратися в чому справа, якщо frozen багато. Це може побут не спам, а проблеми з вашим поштовиком.
Взагалі, краще по можливості використовувати зовнішні сервіси для роботи з поштою - це значно спрощує обслуговування сервера і знімає масу головного болю зайвою.
З очищення від заражених файлів - якщо весь сайт лежить в гіті, то
git checkout -. # Відкотити змінені файли
git clean -f # видалити всі untrtacked файли
можуть врятувати батька російської демократії. Власне, ЕМНІП hacked так і працює - тягне з гіта код модуля і порівнює з ним.
З.И. Сайти на друпалі особисто у мене зламували два рази: один раз drupageddon, другий - через старий джумловскій сайт, який працював під тим же користувачем.
