Как изменить префикс базы данных
Таблицы базы данных Вордпресс сайта имеют по умолчанию префикс wp_. Многие специалисты по безопасности рекомендуют изменить этот префикс для увеличения безопасности сайта. Нужно ли менять префикс, или это изменение лишь ненамного увеличит безопасность сайта?
Суть этого способа защиты в том, что изменение префикса поможет избежать исполнения SQL запросов к базе данных. Обычно хакботы используют стандартные запросы с префиксом wp_ в своих атаках, но если вы измените префикс базы данных на уникальный, то бот получит ошибку.
Префикс базы данных можно изменить во время установки Вордпресс, но если у вас уже есть работающий сайт, то в этой статье вы узнаете, как изменить префикс базы данных вручную или при помощи плагинов.
Чтобы изменить префикс БД вручную, надо сделать изменения в приложении phpMyAdmin при помощи SQL запросов, и изменить запись о префиксе в файле wp-config.php.
В плагинах безопасности префикс базы данных меняется в несколько кликов.
Содержание:
Зачем менять префикс базы данных
Аргумент Против
Аргументы За
Сделайте бэкап
- Изменение префикса в базе данных
- Изменение в wp-config.php
- Изменения в базе данных
- Изменения внутри таблиц
- Записи в таблице Options
- Записи в таблице Usermeta
- Решение проблем
- Плагины
Сделайте бэкап
Заключение
Зачем менять префикс базы данных
Многие специалисты рекомендуют изменить префикс БД для того, чтобы не дать возможность хакеру получить контроль над базой данных при помощи SQL запросов.
Существует 2 типа SQL внедрений. Обычное SQL внедрение — когда хакер получает возможность посылать команды базе данных и получать ответы от базы данных. Слепое SQL внедрение — когда хакер может посылать команды базе данных, но не получает ответов от нее.
В обоих случаях хакер может сделать SQL запрос к вашему сайту без вашего ведома. Если хакер может выполнить такой запрос, у него появится доступ к базе данных сайта, то есть он может изменить записи в базе данных.
После получения контроля над базой данных злоумышленники обычно меняют логин и пароль администратора. Администратор сайта больше не может войти в админку сайта, а хакеры продолжают делать с сайтом что хотят, от рассылки спама с этого сайта и кражи личной информации до заражения других сайтов и рассылки спама с них и кражи другой информации.
Аргумент Против
Причина не менять префикс базы данных состоит в том, что если база данных выполняет какие-то запросы злоумышленника, то в итоге он все равно может получить доступ к базе данных.
Если первая попытка хакера получить ответ от базы данных оказывается неудачной, он может создать новый запрос к базе данных для поиска второй части названий таблиц, которые имеют стандартные имена.
Например, второй запрос может запрашивать имена, содержащие usermeta или postmeta в названии. Эти имена являются именами двух стандартных таблиц Вордпресс. Поиск вернет полное имя таблицы вместе с новым префиксом таблицы.
Хотя может показаться, что нет смысла менять префикс базы данных, есть несколько аргументов с другой стороны.
Аргументы За
Изменение префикса рекомендовано в руководстве по увеличению безопасности в Кодексе Вордпресс.
Эта рекомендация попала туда после устранения разработчиками Вордпресс уязвимостей, связанных с SQL внедрениями.
Причина в том, что хакеры редко ищут уязвимости сайтов, посещая сайты в браузере вручную. Хакеры создают ботов, которые автоматически обходят сотни или тысячи сайтов и ищут в них известные уязвимости по имеющимся у них спискам уязвимостей, которые находятся в открытом доступе.
После того, как на сайте находится уязвимость, например такая, которая позволяет выполнять SQL запросы злоумышленника, боты взламывают такие сайты, отправляют сообщение хакеру и идут дальше.
Если вы измените префикс базы данных, боты получат ответ с ошибкой от базы данных, так как они запрограммированы создавать стандартные запросы, в котором содержится префикс wp_.
Если ваш сайт попадется такому боту, то бот получит ошибку и пойдет дальше на тот сайт, где база данных даст ответ на запрос с префиксом wp_.
Изменение префикса wp_ на что-нибудь уникальное поможет отбить первую волну автоматических атак, но не поможет, если хакер вручную попробует получить доступ к базе данных, поэтому кроме изменения префикса нужно иметь другие способы защиты сайта.
- Руководство по безопасности Вордпресс
Сделайте бэкап
Так как вы будете работать с глубокими настройками базы данных и файлом wp-config.php, сделайте бэкап всего сайта и базы данных. Если что-то пойдет не так, вы сможете восстановить сохраненную версию.
- Бэкап Вордпресс
1. Изменение в wp-config.php
Этот файл находится в корневой папке сайта, скачайте его на компьютер с помощью ftp-клиента или менеджера файлов на хостинге.
Откройте файл, найдите эту строку:
Измените wp_ на что-нибудь уникальное, но рекомендуется оставить нижнее подчеркивание в конце.
Префикс может содержать цифры, буквы и знак подчеркивания, например, db14_, fr23br17_, a01_b01_ и так далее.
Сохраните файл и закачайте обратно на сервер. Если теперь вы попробуете зайти на сайт, он будет недоступен. Так и должно быть, потому что теперь данные в базе данных не соответствуют данным в файле wp-config.php.
Чтобы изменить префиксы в базе данных переходим к следующему шагу:
2. Изменения в базе данных
Зайдите на хостинг и откройте базу данных.
В базе данных нужно поменять префиксы главных таблиц, это делается с помощью SQL запросов на вкладке SQL. Структура запроса для изменения всех таблиц такая:
RENAME table `wp_название-таблицы` TO `новый-префикс_название-таблицы`;
Замените название-таблицы на нужное название таблицы, и новый-префикс на ваш новый префикс, который вы сохранили в файле wp-config.php.
1. Для одиночной установки Вордпресс измените префиксы в стандартных таблицах Вордпресс:
Можете скопировать и выполнить сразу все запросы, не забудьте заменить новый-префикс на ваш новый префикс.
2. Для мультисайт установки добавьте эти префиксы:
Измените новый-префикс на новый префикс.
Также измените эти таблицы:
wp_#_commentmeta
wp_#_comments
wp_#_links
wp_#_options
wp_#_postmeta
wp_#_posts
wp_#_terms
wp_#_term_relationships
wp_#_term_taxonomy
Замените # на ID вашего подсайта. Например, запрос к таблице wp_commentmeta подсайта с ID 2 будет wp_2_commentmeta
Кроме этих запросов нужно изменить префикс в таблицах, которые создали установленные плагины, и таблицы плагинов, которые были созданы для подсайтов в Мультисайт установке. Посмотрите в левой колонке какие еще таблицы остались со старым префиксом, измените их вручную тем же способом.
3. Изменения внутри таблиц
После того, как вы изменили названия таблиц, нужно изменить некоторые записи в таблицах options и usermeta.
Записи в таблице Options
В этой таблице надо изменить несколько записей.
Для облегчения поиска можно использовать поисковый запрос. Замените новый-префикс на ваш новый префикс:
Поиск должен показать все записи, которые соответствуют запросу. Для редактирования кликните два раза или нажмите Карандаш на каждой записи.
Записи в таблице Usermeta
Как в таблице Options, в таблице Usermeta надо заменить несколько записей. Чтобы не искать их вручную, можно использовать запрос:
Замените новый-префикс на новый префикс, который вы добавили в wp-config.php.
После этого сайт должен начать работать с новым префиксом базы данных.
Решение проблем
Если вы получили ошибку прав доступа, или ошибку установления соединения с базой данных, это значит, что вы забыли переименовать одну из таблиц или префикс записи. Вернитесь в phpMyAdmin и найдите таблицу или запись, которую вы пропустили.
Некоторые плагины предполагают, что префикс базы данных стандартный, и если вы уверены, что переименовали все таблицы и плагины, попробуйте деактивировать все плагины, и включать их по одному, чтобы найти, какой из них делает сайт недоступным.
Удалите плагин или найдите ему альтернативу.
Плагины
Если вы не хотите делать это вручную, можно сделать это с помощью одного из плагинов безопасности. Вы можете использовать маленький плагин, который делает только эту работу, например, Brozzme DB Prefix, или большой плагин, где эта функция находится среди многих других, например All in One WordPress Security.
Перед изменением префикса сделайте бэкап сайта и базы данных.
Поставьте галочку, чтобы плагин сгенерировал новый префикс, или придумайте свой вариант. Плагин сделает изменения в базе данных и в файле wp-config.
Префикс базы данных изменен на xvi0f_. Изменены префиксы 34 таблиц и сделаны изменения в таблицах options и usermeta. Процесс такой же, как в ручном режиме, но занимает меньше секунды.
В других плагинах изменение префикса базы данных делается аналогично.
Сделайте бэкап
После того, как вы изменили префикс базы данных вручную или автоматически, сделайте еще один бэкап.
Заключение
Изменение префикса базы данных помогает избежать только один вид автоматических атак. Чтобы защитить сайт от других атак, установите какой-нибудь плагин безопасности и читайте Руководство по безопасности Вордпресс.
Читайте также:
- Подробное описание плагина Sucuri Security
- Как настроить мощную защиту сайта на основе бесплатного плагина Sucuri Security
- Подробное описание Security Ninja Pro
Надеюсь, статья была полезна. Оставляйте комментарии.
Управление префиксами таблиц — Windows drivers
Twitter LinkedIn Facebook Адрес электронной почты
- Статья
- Чтение занимает 2 мин
RDBSS определяет структуры данных, которые позволяют использовать таблицы префиксов для каталогов SRV_CALL, NET_ROOT и имен V_NET_ROOT.
Текущая реализация управления именами в RDBSS использует таблицу со следующими компонентами:
Очередь вставленных имен
Метка версии
Ресурс блокировки таблицы, управляющий доступом к таблицам
Значение, указывающее, совпадает ли имя с именем без учета регистра
Контейнер записей хэш-значений для этой таблицы префиксов
Ресурс блокировки таблицы используется обычным образом: Shared для операций уточняющего запроса, монопольно для операций изменения.
Отметка версии изменяется при каждом изменении. Причиной очереди является то, что пакет таблицы префиксов позволяет перечислять несколько вызывающих объектов за раз. Очередь вставленных имен и отметок версий позволяет перечислять несколько вызывающих объектов одновременно. Очередь может использоваться для ускорения поиска имен файлов, но таблица префиксов определенно подходит для структур NET_ROOT.
Эти префиксные подпрограммы управления таблицами используются внутри RDBSS в ответ на вызов из MUP для утверждения имени или для формирования пути создания для структуры NET_ROOT.
Получить общую блокировку путем вызова рксаккуирепрефикстаблелоккшаред.
Найдите имя, вызвав ркспрефикстаблелукупнаме.
Освободите общую блокировку, вызвав рксрелеасепрефикстаблелокк
обратите внимание, что некоторые подпрограммы реализуются только в Windows XP и предыдущих версиях Windows. Ркспрефикстаблелукупнаме — это единственная подпрограммы управления таблицами префиксов, реализованная во всех версиях Windows
К подпрограммым управления таблицами с префиксом RDBSS относятся следующие.
ркспаккуирепрефикстаблелоккексклусиве | Эта подпрограммы получает монопольную блокировку на таблицу префиксов, используемую для каталога SRV_CALL и имен NET_ROOT. эта подпрограммы доступна только в Windows XP и Windows 2000. Эта подпрограммы используется для внутренних целей RDBSS и не должна использоваться сетевыми мини-перенаправителями. |
ркспаккуирепрефикстаблелоккшаред | Эта подпрограммы получает общую блокировку для таблицы префиксов, используемой для каталога SRV_CALL и имен NET_ROOT. эта подпрограммы доступна только в Windows XP и Windows 2000. Эта подпрограммы используется для внутренних целей RDBSS и не должна использоваться сетевыми мини-перенаправителями. |
Процедура ищет имя в таблице префиксов, используемой для каталогизации SRV_CALL и NET_ROOT имен и преобразовывает базовый указатель на содержащую его структуру. | |
ркспрелеасепрефикстаблелокк | Эта подпрограммы снимает блокировку на таблицу префиксов, используемую для каталога SRV_CALL и имен NET_ROOT. эта подпрограммы доступна только в Windows XP и Windows 2000. Эта подпрограммы используется для внутренних целей RDBSS и не должна использоваться сетевыми мини-перенаправителями. |
начиная с Windows Server 2003, подпрограммы, упомянутые в предыдущей таблице, за исключением ркспрефикстаблелукупнаме, заменяются макросами. Определяются следующие макросы, которые вызывают подпрограммы таблицы префиксов с меньшим числом параметров.
Рксаккуирепрефикстаблелоккексклусиве (Таблица, Ожидание) | Этот макрос запрашивает блокировку таблицы префиксов в монопольном режиме для операций изменения. |
Рксаккуирепрефикстаблелоккшаред | Этот макрос запрашивает блокировку таблицы префиксов в общем режиме для операций уточняющего запроса. |
Рксиспрефикстаблелоккаккуиред (Таблица) | Этот макрос указывает, была ли блокировка таблицы префикса получена в монопольном или общем режиме. |
Рксиспрефикстаблелоккексклусиве (Таблица) | Этот макрос указывает, была ли блокировка таблицы префикса получена в монопольном режиме. |
Рксрелеасепрефикстаблелокк (Таблица) | Этот макрос освобождает блокировку префиксной таблицы. |
mysql — Что такое префикс таблицы?
Спросил
Изменено 7 месяцев назад
Просмотрено 98 тысяч раз
24
Новинка! Сохраняйте вопросы или ответы и организуйте свой любимый контент.
Узнать больше.
Что такое префикс таблицы и каковы их преимущества и недостатки? Это что касается MySQL.
- mysql
- база данных
- дизайн базы данных
- префикс
2
Часто используется, чтобы отличить разные установки одного и того же скрипта друг от друга. Например, предположим, что у вас есть две установки Joomla с разным содержимым на вашем сервере, но только одна база данных MySQL.
Теперь, по очевидным причинам, обе установки Joomla не могут совместно использовать одни и те же таблицы базы данных, так как это приведет к тому, что обе установки будут отображать одно и то же содержимое. И здесь в дело вступает префикс.
Используя различные префиксы таблиц, вы можете сообщить установке Joomla #1, что предполагается использовать всю таблицу с префиксом JOS_, а установке Joomla #2 следует использовать все таблицы с префиксом JOS2_
Таблицы не требуют префиксов.
Это зависит только от вас.
Однако мы ставим перед таблицами префикс, соответствующий МОДУЛЯМ в приложении, которому они принадлежат, просто для того, чтобы упростить группировку таблиц.
Некоторые люди поддерживают tbl или tbl_ (например, tbl_MyTable или tblMyTable), в то время как другие используют суффикс, такой как MyTable_T.
Лично я избегаю префиксов/суффиксов. Я могу заменить представление на таблицу, если схема меняется с течением времени, поэтому я не различаю два типа объектов.
Самое главное, чтобы ваши правила именования были задокументированы внутри вашей команды, и вы все придерживались одного и того же набора правил для согласованности.
Странно, никто не упомянул, что вы также можете использовать префиксы таблиц для использования обычно зарезервированных ключевых слов в качестве имен таблиц.
Напр. t_user или t_order теперь возможны.
1
В небольшом количестве случаев, например, когда сценарии вредоносных программ были созданы для определенных типов сайтов, таких как WordPress и т.
д., изменение префиксов таблиц было полезно в качестве дополнительной меры безопасности.
Например, добавление префиксов таблиц скрывает общие имена таблиц, что затрудняет доступ хакеров к данным в вашей базе данных с помощью SQL-инъекций или других брешей в безопасности, поскольку им сначала нужно будет узнать, каковы имена ваших таблиц.
Однако обязательно рассматривайте префиксы таблиц как очень второстепенный уровень безопасности. Это НЕ должно быть вашим основным методом безопасности. Вам по-прежнему следует принимать другие более важные меры безопасности для предотвращения SQL-инъекций и других подобных угроз. Например, в зависимости от того, как настроен ваш код, хакер все еще может запустить команду «показать таблицы» с помощью SQL-инъекции, чтобы получить имена таблиц вашей базы данных.
6
Если у вас сложная структура веб-сайта и базы данных, префиксы таблиц могут помочь предотвратить конфликты имен в базе данных.
Вы часто видите префиксы таблиц в ситуациях, когда:
Несколько сценариев объединяются вместе в один веб-сайт, и готовый веб-сайт должен обмениваться данными, но имена таблиц будут конфликтовать без префикса, уникального для каждого сценария.
Вы добавляете функциональные возможности в приобретенный скрипт и хотите различать таблицы, встроенные в этот скрипт, и новые таблицы, которые вы создаете вручную. Таким образом, если вы создадите новую таблицу, она не будет конфликтовать с будущими обновлениями базового сценария, поскольку у нее будет другой префикс таблицы.
У вас есть план хостинга, который предоставляет вам только одну базу данных, и вы хотите использовать эту базу данных для обслуживания нескольких сценариев. (Это не рекомендуется по ряду причин, но я видел, как это делают пользователи.)
Когда вы пишете сценарий с нуля, префиксы таблиц обычно не нужны, поскольку вы контролируете все аспекты структуры базы данных.
Когда вы начинаете интегрировать несколько скриптов вместе, это становится полезным, а иногда даже необходимым. Он позволяет создавать уникальные представления данных, объединять таблицы и т. д. между несколькими сценариями, не беспокоясь о конфликтах имен в базе данных.
Это может помочь различать таблицы и представления в зависимости от вашего соглашения об именах.
Недостатком является то, что вы можете быть ограничены в том, что касается имени таблицы. Oracle имеет для этого ограничение в 30 символов. Если вы используете «Tbl_» в качестве префикса, вы автоматически теряете 4 символа. Это может быть проблемой.
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя адрес электронной почты и пароль
Опубликовать как гость
Электронная почта
Обязательно, но не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
префиксов таблиц базы данных0001
Спросил
Изменено 10 лет, 6 месяцев назад
Просмотрено 6k раз
У нас есть несколько рабочих дискуссий по поводу именования таблиц нашей базы данных.
Мы работаем над большим приложением с примерно 100 таблицами базы данных (хорошо, так что это не так уж и много), большинство из которых можно разделить на разные функциональные области, и мы пытаемся найти лучший способ именования / организация их в базе данных Oracle.
Три текущих параметра:
- Создайте различные функциональные области в отдельных схемах.
- Создайте все в той же схеме, но добавьте к таблицам префикс функциональной области
- Создать все в одной схеме без префиксов
У каждого из них есть свои плюсы и минусы, но мне было бы интересно услышать мнение каждого о том, какое решение является лучшим.
Редактировать: Спасибо за все ответы. Трудно выбрать правильный ответ, кажется, он очень субъективен, поэтому я выберу тот, который наберет наибольшее количество голосов (помогает, что он соответствует тому, что я думал! 😉
- база данных
- дизайн базы данных
- оракул
4
Определенно не называйте каждую таблицу префиксом.
Я попробовал это однажды, и это раздражает поддерживать и сохранять прямоту, особенно потому, что некоторые таблицы применяются к нескольким разделам.
В настоящее время я работаю с системой, в которой нет префикса именования для большинства таблиц, но есть префикс именования для таблиц, специфичных для модулей
Например, у нас есть обычное Пользователи , Customers , Products таблицы для большинства объектов, однако модуль, который специально разработан для работы с управлением взаимоотношениями с клиентами, может иметь префикс для своих специфичных для модуля таблиц с префиксом CRM_
Я бы использовал отдельные схемы для разделов, которые полностью отдельно друг от друга, однако, если между ними есть связи (например, модуль CRM_ , связанный с основной таблицей Customers ), то я, вероятно, просто добавлю таблицы, специфичные для модуля, в существующую схему и префикс их с чем-то
1
Создавать все в отдельных схемах — вот что имеет смысл, ИМО.
Он обеспечивает логическое разделение, а также позволит легко организовать то, чем вы занимаетесь.
Если ваше приложение разрастется, станет проще реплицировать данные на отдельные серверы чтения, так как вы можете выделить один или несколько серверов чтения для каждой схемы. Так будет намного проще отслеживать.
На мой взгляд, префиксы не имеют физической или логической ценности, за исключением таких случаев:
Чтобы отличить обычные таблицы от агрегированных сводных таблиц. Это сделано для устранения путаницы в сводных таблицах продаж и продаж без использования слова сводка .
Чтобы отличить представления от реальных таблиц
Когда вы имеете дело с деморализованной базой данных, где одна таблица должна появляться дважды, чтобы отличить данные промежуточной области от транзакционных данных.
Префикс таблиц невозможно сделать правильно, потому что общие таблицы часто встречаются в бизнес-функциях.
Например, такая таблица, как Страна, может быть частью функциональных областей: Заработная плата, Продажи, Счета, Безопасность и т. д.
Методология информационной инженерии способствует логической категоризации таблиц по так называемым предметным областям бизнеса. Однако в физической реализации такого деления нет и префикс имени не требуется.
Расширенные инструменты моделирования данных позволяют группировать таблицы в отдельные группы от основной модели и разрешать админ. основной модели для предоставления прав доступа, чтобы каждую подмодель можно было просматривать и изменять контролируемым образом.
Еще одна проблема с префиксами заключается в том, что они удлиняют имена, не предоставляя значения ни разработчику, ни администратору баз данных, ни конечному пользователю.
Здесь я должен упомянуть, что у Microsoft Dynamics есть другой подход к этому. Таблицы в MS Dynamics имеют префикс с некоторым префиксом, например:
- CustBankAccount
- BankAccountStatement
- BankAccountTrans
Опять же, лично я не вижу значения префиксов, за исключением случаев, упомянутых выше.
Я использовал схемы, потому что они также упрощают обеспечение безопасности таблиц: вы можете определить тип доступа каждого пользователя или группы пользователей в общей схеме.
У меня также есть таблица, такая как Пользователи или Валюты , которые используются для каждого отдела, и я создал для нее схему Common .
Я думаю, что это имеет смысл, и его определенно легче поддерживать.
- Префиксы лучше, если вы:
а) Хотите иметь возможность устанавливать несколько копий одного и того же приложения в одной схеме или базе данных
б) Необходимо обеспечить защиту от SQL-инъекций, особенно для распространенных платформ CMS
Однако я нахожу их проблемой . Ваши таблицы должны быть названы таким образом, чтобы их имена определяли их содержимое, точно так же, как @Emmad Kareen описал выше из Microsoft Dynamics.
Я из мира MySQL, где приложения, использующие несколько баз данных, не так распространены, хотя они есть в Oracle и других базах данных.
Также распространено то, что вы используете одного пользователя приложения для подключения приложения к базе данных, а затем используете безопасность приложений для управления тем, что пользователь может видеть или получать к нему доступ.
Мой совет, держитесь от них подальше, так как они усложняют разработку и отображение ORM
Я бы не стал этого делать. Более того, если вы можете четко разделить свое приложение на разные разделы, каждый из которых обрабатывает свою функциональность, вы можете просто полностью ориентироваться на шину сообщений и сделать их полностью отдельными приложениями, каждое с данными в отдельной схеме (или даже на сервере). ) все сообщения, проходящие через общую шину в рамках механизма публикации/подписки.
Короче говоря, не надо. Если вы попытаетесь угадать, где в это время будет использоваться таблица, вы, вероятно, ошибетесь и навсегда будете раздражены, потому что таблица crm_users неизбежно будет использоваться в диспетчере идентификации.