Я работаю в среде, где несколько веб-сайтов будут использовать одну и ту же точную копию PHP, хотя со своими экземплярами баз данных MySQL. Это, очевидно, подразумевает учетные данные для каждого веб-сайта, тем больше пользователей больше паролей и, следовательно, более желательной целью для хакеров. Просто чтобы убедиться, что все находятся на одной странице, это учетные данные, о которых я говорю …
$user = 'user';// not actual user, not root either $pass = 'pass';// not actual password $server = 'localhost'; $database = mysql_connect($server,$user,$pass,true|false); Поэтому я говорю о паролях, используемых для подключения к базе данных, а не о паролях в базе данных (которые для выяснения я хэшировал солью и перцем).
Я не читал ничего, что, по моему мнению, отдаленно предполагает, что вы можете иметь 100% -ную защиту от несанкционированного доступа, так как серверу необходимо подключиться к базе данных и получить контент для посетителей 24/7; если я ошибаюсь, мне хотелось бы услышать, как это будет возможно.
Итак, давайте предположим, что у хакера есть root-доступ (или если это не подразумевает доступ к PHP-коду, давайте просто скажем, тогда получим доступ ко всему исходному коду PHP), и они (в этом случае) хотят получить доступ / изменить / etc базы данных. Если мы не сможем предотвратить их, если у них будет доступ к источнику PHP, мы хотим как можно меньше их замедлить. Я могу сохранить каждый пароль подключения к сайту / базе данных в отдельных файлах (может, как через несколько недель после завершения поддержки нескольких доменов) для каждого сайта, а не внутри public_html (очевидно). Я использую serialize и unserialize для хранения определенных переменных, чтобы обеспечить определенный уровень отказоустойчивости, когда база данных становится недоступной на общем хостинге (предотвращение того, чтобы сайт A выглядел и действовал как сайт B и наоборот), поскольку база данных иногда может быть недоступна несколько раз в день (мои журналы ошибок базы данных записываются, когда служба SQL снова становится доступной и улавливает эти «пропущенные» ошибки). Одна мысль, которая перешла мне на ум, – это определение способа хранения паролей в одном хеше и без их использования для подключения к базе данных с помощью PHP, хотя мне бы хотелось также получить некоторые мнения об этом.
Если у кого-то есть предложение с точки зрения базы данных (например, наличие возможности ограничить пользователей SELECT, INSERT, DELETE, UPDATE и т. Д. И не позволяя DROP и TRUNCATE в качестве примеров), моя главная задача – убедиться, что я нейтрален SQL, поскольку я планирую в конечном итоге перейти от MySQL к PostgreSQL (это может быть или не быть актуальным, хотя, если лучше упомянуть об этом). В настоящее время я использую phpMyAdmin и cPanel, а phpMyAdmin показывает, что подключенный пользователь не совпадает с именами пользователей базы данных сайта, поэтому в этом отношении я могу по-прежнему использовать определенные команды (DROP и TRUNCATE в качестве примеров снова) с этим пользователем и ограничивать разрешения пользователя SITE, если Я почему-то ошибаюсь?
Есть ли способ настроить контекст, в котором приняты учетные данные подключения? Для разъяснения хакер, имеющий доступ к исходному коду, не будет обращаться к сайту так же, как это делают законные пользователи.
Еще одна идея, которая перешла мне на ум, – это шифрование на основе системы, существует ли почти универсальная (как на каждой или почти каждой настройке веб-хостинга LAMP) технология веб-хостинга, где система может читать / записывать файл через Apache, который вводит новую слой, который хакеру нужно будет определить, как обходить?
Конечно, я использую разные пароли для каждого пользователя.
В настоящее время я нахожусь на совместном хостинге, хотя, надеюсь, моя настройка в конечном итоге увеличится до выделенного хостинга.
Итак, каковы мысли по моим концепциям безопасности и какие другие концепции я могу попробовать, чтобы сделать мои учетные данные для подключения к базе данных более безопасными?
Уточнение: я ищу идеи, которые я могу преследовать. Если есть какие-либо разногласия с любыми предложениями, попросите разъяснения и объясните свою озабоченность вместо обсуждения данного подхода, поскольку я могу или, возможно, даже не рассматривал, не говоря уже о том, чтобы начать использовать данную концепцию. Благодаря!
От попыток замедлить злоумышленника, у которого уже есть root-доступ к вашей системе, мало что можно сделать. Даже если вам удастся скрыть учетные данные достаточно хорошо, чтобы отговорить их, они уже имеют доступ к вашей системе и могут нанести ущерб миллионам способов, включая изменение кода, чтобы делать все, что захочет.
Лучше всего сосредоточиться на том, чтобы препятствовать тому, чтобы злодеи никогда не проникали в вашу внешнюю защиту, беспокоиться об остальном только после того, как вы убедились, что сделали все возможное, чтобы держать их у ворот.
Сказав, что ограничение учетных записей пользователей базы данных только определенным подмножеством привилегий, определенно, не является плохим делом, если это позволяет ваша архитектура.
Вы хотите подходить к безопасности в слоях. Да, если у злоумышленника есть root-доступ, вы находитесь в очень плохом месте, но это не значит, что вы не должны защищать себя от более низких уровней проникновения. Большинство этих рекомендаций может быть трудно сделать на общем хостинге …
Предполагая, что вы используете достойного хостинг-провайдера и последние версии LAMP, усилия, необходимые для получения доступа root, существенны – если вы не очень прибыльная цель, это не ваше самое большое беспокойство.
Я предполагаю, что вы соответствующим образом затвердели свой сервер и инфраструктуру и убедитесь, что они настроены правильно. Вам также необходимо отключить службы, которые вам не нужны – например, если у вас запущен FTP-сервер, злоумышленник, который может принудительно использовать пароль, не нуждается в root, чтобы войти.
Первое, что вы, вероятно, должны сделать, это убедиться, что код приложения не имеет уязвимостей и что у вас есть надежная политика паролей. Большинство «хаков» не являются результатом злого гения, беспокоящегося на вашем сервере в течение нескольких месяцев, пока у них не будет «root» – они являются результатом глупых ошибок (например, SQL-инъекций) или слабых паролей («admin / admin»)? ,
Затем вы хотите убедиться, что если ваш веб-сервер взломан, но не на уровне «root» – вы можете запретить злоумышленнику выполнять произвольные SQL-скрипты. Это означает, что ограничения вашего веб-сервера позволяют «читать и выполнять», если это вообще возможно, чтобы они не могли загружать новые файлы PHP. Это также означает удаление таких вещей, как CPanel и phpMyAdmin – злоумышленник, который может поставить под угрозу ваш производственный сервер, может скомпрометировать эти приложения и украсть у вас пароли (запустите их на другом сервере, если они вам понадобятся).
Это определенно стоит посмотреть на то, как настроены ваши разрешения на базу данных, хотя это может быть сложно и может не дать дополнительной дополнительной безопасности. По крайней мере, создайте «веб-пользователя» для каждого клиента и дайте этому пользователю только «вставить, обновить и удалить» в своей собственной базе данных.
Как говорит code_burgar, как только ваша коробка дает root, уже слишком поздно. При этом мне пришлось реализовать дополнительные меры безопасности в проекте, с которым я был связан некоторое время назад. Решение хранить файлы конфигурации в зашифрованном разделе, чтобы люди с прямым доступом к машине не могли вытащить пароли, подключив диск к другому ПК. Конечно, это было в дополнение к разрешениям файловой системы, чтобы люди не могли прочитать файл из самой ОС.
Еще одна деталь стоит подняться, если вы действительно параноик по безопасности:
$user = 'user';// not actual user, not root either $pass = 'pass';// not actual password $server = 'localhost'; $database = mysql_connect($server,$user,$pass,true|false); unset($user, $pass, $server); // Flush from memory.
Вы можете unset критические переменные после использования, гарантируя, что они не могут быть var_dumped или извлечены из памяти.
Удачи, надеюсь, что это поможет.
Я нашел решение для PHP (Linux). В корне создайте каталог, скажем db и создайте класс и определите все переменные подключения к базе данных и методы доступа в классе, скажем, DBConnection.php теперь ваш сайт example.com вы храните свой файлы в каталоге public_html создают файл php в этом каталоге для подключения и выполнения всех операций с базой данных и включают файл DBConnection.php используя следующий оператор
require('../db/DBConnection.php');
к этому файлу нельзя получить доступ с помощью «www.example.com/db/DBConnection.php»
вы можете попробовать это на своем веб-сайте.