Меня недавно взломали. Похоже, что взлом перенаправляет любой сайт на моем сервере на поддельный вирусный сайт. Поэтому я удалил все файлы своего сайта, и взлом, казалось, исчез. Примерно через неделю он вернулся - такой же. я никогда удалил мои базы данных, но никогда не загружал сайты, которые их использовали. Могут ли одни только базы данных, без каких-либо связанных с ними веб-сайтов, каким-то образом поддерживать взлом?
Вы действительно нашли и защитили себя от причины атаки [например, дыра в cms / форуме / любом другом веб-приложении, которое у вас было]?
вероятно, хакер оставил бэкдор в вашей системе для себя, и он находится на более низком уровне, чем веб-приложение.
Что касается вашего вопроса - да и нет - все зависит от того, какая информация хранится в БД. если у вас есть скриптовое веб-приложение, которое хранит [по какой-то причине] исполняемый код [например, код плагинов] в базе данных - тогда там может остаться какой-то бэкдор. даже если это не так - у вас есть шаблоны, хранящиеся в db - тогда, например, xss-атака может повториться против вас, даже если вы восстановите все остальное.
Сервер базы данных может содержать взлом, или база данных тоже может, если сервер базы данных настроен на выполнение чего-либо (например, процедуры / сценария в БД).
По правде говоря, все, что может выполнять код и имеет небольшое (крошечное) пространство памяти, может содержать взлом. Были случаи, когда люди взламывали сети через принтер postscript, поскольку postscript - это полный по Тьюрингу язык.
В вашем случае, однако, мне кажется, что происходит нечто гораздо более банальное, чем взлом базы данных. Не удаляйте просто файлы на своем сайте - это просто удаляет доказательства преступления. Это все равно, что сметать тела друзей, когда кто-то стреляет в них, и не ожидать, что их больше не застрелят. Что вам нужно сделать, так это посмотреть на тела, спросить, кто они такие, как где они убили, кто хотел бы их убить, как они это сделали и как вы можете их остановить.
Вам нужно будет проверить все используемые вами веб-скрипты. Узнайте о веб-безопасности и убедитесь, что любой написанный вами код безопасен; узнайте об установленных вами веб-приложениях и убедитесь, что у вас установлены последние версии, и что новые версии выходят всякий раз, когда сообщается о проблемах с безопасностью. Если новые версии не выходят для решения проблем, удалите приложение и НИКОГДА не устанавливайте его повторно; найти лучшую альтернативу.
Кроме того, убедитесь, что ваша операционная система обновлена (обновление Windows и т. Д.), Что у вас установлен и обновлен антивирус, работает, правильно настроен, безопасен, обновлен брандмауэр и т. Д.
Думаю, чтобы кто-нибудь мог точно ответить на ваш вопрос, нужна дополнительная информация. В частности, если предположить, что вы удалили ВСЕ веб-сайты со своего сервера, первый вопрос, который приходит на ум, исходя из опасений, связанных с вашей базой данных: можно ли получить доступ к вашему серверу базы данных через Интернет?
т.е. слушает ли он общедоступный IP-адрес? Быстрый netstat -nuptl должен предоставить вам эту информацию.
Кроме того, просто перевод содержимого вашего веб-сайта в автономный режим не означает, что ваш веб-сервер еще недоступен, как и множество других сетевых приложений. Вы необходимость быть в курсе все ваша система выставлена в сети.
Кроме того, как говорили другие, когда вы не знаете, откуда взялось вторжение, лучше всего переустановить с нуля: ОС, библиотеки, приложения, службы и т. Д. В противном случае вы потратите драгоценное время на запуск вокруг ищет любой возможный эксплойт.
После того, как вы перестроили с использованием последних исправлений, насколько это возможно, не вызывая проблем с зависимостями, удалите ненужные службы или подключите их к сокету Unix, где это возможно, вместо сокета TCP. И серьезно подумайте о какой-то форме IDS. Их много, но можно Помощник, который работает так же, как Tripwire, - проверяет наличие изменений файловой системы на базе данных, которую он компилирует.
PS: Резервное копирование, резервное копирование, резервное копирование и удачи.
Чтобы добавить к тому, что уже сказали другие. БД может «разместить» взлом, но более вероятно, что заражена ОС, а не ваша БД.
Как правило, однако, как только ваш хост заражен, лучше всего удалить сервер из Интернета, провести судебно-медицинское расследование инцидента и перестроить сервер, а не просто удалять файлы и надеяться, что вы их все получили.
В дополнение к ответу pQd:
Некоторые продукты баз данных позволяют выполнять любую системную команду с использованием функций SQL (например, «система»), если у пользователя есть достаточные привилегии.
Ваш единственный шаг к очистке скомпрометированной системы - удаление файлов сайта? Вам следует изменить все пароли и восстановить данные из надежной резервной копии.
Вы говорите о крэке, как о вирусе, а не работаете внутри системы самостоятельно. Есть вероятность, что для взлома вашего сайта использовался вирус, но, скорее всего, он был взломан извне.
Восстановление файлов вашего веб-сайта удалило только результат взлома, а не дыру в безопасности, которая позволила это сделать. Вот почему это может повториться на следующей неделе, и поэтому это будет продолжаться, пока вы не исправите это.
Два распространенных способа получить доступ: межсайтовый скриптинг (XSS) и SQL-инъекция. Оба варианта возможны, если вы неправильно кодируете текст для того, где он используется.
Если вы не кодируете HTML-код, который вы пишете на веб-странице, клиентский сценарий может быть выполнен и собрать информацию, такую как, например, значение Cooke, аутентифицирующее ваш административный логин.
Если вы неправильно кодируете строковые значения при создании SQL-запросов, значение может изменить ваш запрос, чтобы вернуть другой результат, или оно может содержать другой запрос, который может изменить данные в вашей базе данных.