Всем привет, пишу сообщение-предупреждение про взлом сайтов.
Позавчера получил я от гугла письмо следующего содержания:
Мы обнаружили, что Ваш сайт был взломан и на нем разместили вредоносный контент. Посетители перенаправляются на страницы с нерелевантным или опасным содержанием, а также на его положении в результатах поиска. Рекомендуем как можно скорее проверить взломанные страницы и удалить посторонний контент. Если Вы обнаружите и удалите спам, мы узнаем об этом во время индексирования страниц.
При просмотре кода страниц был обнаружен невидимый левый HTML код с ссылкой на какой-то сайт торгующий кроссовками.
Надо сказать, что в сайтостроении, PHP и безопасности я не силен.
Бэкапы сайта я делал как попало, с разной периодичностью, однако все же делал.
Развернул у себя на компе ранний бэкап и завел его на HG. Потом накатил туда текущий код сайта и посмотрел диф. Нашел статический HTML внедренный в footer.php файл темы wordpress. Удалил.
Повезло, инсталяхи были не тронуты.
Удалил и накатил wordpress и все темы, поменял пароли. Переделал пару своих PHP для устранения возможности SQL injection. Поставил плагин безопасности wordfence.
За день посещаемость сайта упала где-то на 20% но покупки были. Сейчас посещаемость восстанавливается но покупок нет.
Для защиты сайта на Wordpress рекомендую следующее:
1. Файл wp-config.php вынести на уровень выше (в родительскую папку). Wordpress его автоматически найдет там. Также проверить права доступа к нему.
2. Установить плагин All In One WP Security и выполнить все его базовые рекомендации (он проверит правильность прав доступа к файлам, включит ограничение на подбор пароля и блокировка скажем после 3 неудачных попыток).
3. Защитить папку /wp-admin паролем. Тогда не зная пароля никогда не получить доступ к админке Wordpress'а. Это пожалуй самая важная мера безопасности.
4. Регулярно обновлять Wordpress, темы, и все плагины. Это тоже очень важно.
5. Ну и конечно достаточно сложный пароль администратора, а имя желательно не admin, а что-то другое.
С этими мерами сайт будет взломать намного труднее.
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Надо сказать, что в сайтостроении, PHP и безопасности я не силен. NW>Бэкапы сайта я делал как попало, с разной периодичностью, однако все же делал. NW>Развернул у себя на компе ранний бэкап и завел его на HG. Потом накатил туда текущий код сайта и посмотрел диф. Нашел статический HTML внедренный в footer.php файл темы wordpress. Удалил. NW>Повезло, инсталяхи были не тронуты.
Я в свое время пришел к решению загружать страницы на сайт только через svn + отдельное место для больших файлов. Т.е. commit на девелоперских машинах и update на боевом сайте и тестовой VM. Порты пробрасываются через SSH и после единоразовой настройки получается решение, где "все ходы записаны" просто by design. Только не забудьте доступ к .svn в правилах забанить.
B>Я в свое время пришел к решению загружать страницы на сайт только через svn + отдельное место для больших файлов. Т.е. commit на девелоперских машинах и update на боевом сайте и тестовой VM. Порты пробрасываются через SSH и после единоразовой настройки получается решение, где "все ходы записаны" просто by design. Только не забудьте доступ к .svn в правилах забанить.
А смысл в svn? Кстати, давно хотел спросить. У тебя на сайте своя CMS или статические страницы?
Ок, как я понял нашли какую-то дырку в Вордпрессе или плагинах. А на сервер как зашли? Нужно ведь знать ssh credentials. Или они средствами Вордпресса модифицировали файлы?
Здравствуйте, Олег К., Вы писали:
NW>>Короче будьте бдительны.
ОК>Ок, как я понял нашли какую-то дырку в Вордпрессе или плагинах. А на сервер как зашли? Нужно ведь знать ssh credentials. Или они средствами Вордпресса модифицировали файлы?
Это дыры в WordPress, перехват ftp паролей тут не приделах. И еще совет — не размещайте на одном уровне доступа wordpress и нормальный сайт, чтобы нельзя было скриптами из каталога Wordpress модифицировать файлы на другом сайте.
Здравствуйте, marcopolo, Вы писали:
M>Здравствуйте, Олег К., Вы писали:
NW>>>Короче будьте бдительны.
ОК>>Ок, как я понял нашли какую-то дырку в Вордпрессе или плагинах. А на сервер как зашли? Нужно ведь знать ssh credentials. Или они средствами Вордпресса модифицировали файлы?
M>Это дыры в WordPress, перехват ftp паролей тут не приделах. И еще совет — не размещайте на одном уровне доступа wordpress и нормальный сайт, чтобы нельзя было скриптами из каталога Wordpress модифицировать файлы на другом сайте.
Размещение на разных уровнях не может помешать модификации файлов.
Здравствуйте, Олег К., Вы писали:
NW>>Короче будьте бдительны.
ОК>Ок, как я понял нашли какую-то дырку в Вордпрессе или плагинах. А на сервер как зашли? Нужно ведь знать ssh credentials. Или они средствами Вордпресса модифицировали файлы?
Самый распространенный случай — этот дырка в одном из плагинов.
Загружается и исполняется скрипт который заражает все остальное.
Никакой FTP/SSH при этом не нужен.
Здравствуйте, Supporter, Вы писали:
S>Самый распространенный случай — этот дырка в одном из плагинов. S>Загружается и исполняется скрипт который заражает все остальное. S>Никакой FTP/SSH при этом не нужен.
Как взломали я не нашел (да и не искал особо), но думаю что тоже через устаревший wordpress или плагин. Поскольку через утечку\взлом паролей маловероятно.
Походу сейчас ломают все то что можно сломать.
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Как взломали я не нашел (да и не искал особо), но думаю что тоже через устаревший wordpress или плагин. Поскольку через утечку\взлом паролей маловероятно. NW>Походу сейчас ломают все то что можно сломать.
PHP не забывайте апгрейдить, так тоже дыр навалом.
Здравствуйте, Олег К., Вы писали: ОК>А смысл в svn?
Да тот же, что и для кода:
1) Если что-то сломалось, то можно легко откатить назад.
2) Все ходы записаны. Спустя полгода можно быстро понять, зачем был добавлен стиль или функция
3) Автоматически всегда есть актуальный бэкап
4) Крупные изменения делаются в бранчах, тестируются на отдельной машине и потом мерджатся в trunk
OK>Кстати, давно хотел спросить. У тебя на сайте своя CMS или статические страницы?
Гремучая смесь из статики, генеренной статики, PHP и двух разных CMS.
Не используйте WP/Joomla/Drupal/etc. в серьёзных проектах.
Это их дыра by design в принципе иметь доступ к исполняемым файлам на запись.
В идеале поставить права r-x------ на директорю сервера, но многие CMS же туда что-то пишут сами, не позволяя сделать это только после ввода какого-то пароля. Например, плагин WP нельзя установить, введя пароль, который WP передаст Apache (и тот уже проверит... нет, CMS всё делает сама, она по умолчанию имеет права на собственную модификацию, что абсурдно для вебсайта). Но это частности.
Самый правильный способ — система развертки Ruby On Rails: деплой на сервер файлов по SSH/GIT, и уже потом администратор перезапускает сервер. А все эти попытки изменять систему прямо из самой системы заведомо ведут к проблемам безопасности.
WordPress — только для пилотной версии.
