Назад | Перейти на главную страницу

Почему плохо иметь слабый пароль пользователя mysql?

Мне был представлен аргумент в пользу мелодии «вам не нужен надежный пароль пользователя mysql, потому что для его использования у них уже будет доступ к вашему серверу». Мы говорим о пароле из 4 цифр, который является стандартным словом английского словаря на реальном веб-сайте компании.

Не влияя на ответы своими знаниями и опытом, я хотел бы показать им несколько ответов из незаинтересованного стороннего источника. Кто-нибудь хочет вмешаться в это? Программирование / практические ответы будут оценены.

Кто бы ни выдвигал этот аргумент, похоже, он говорит: «Как только кто-то вставит ногу в дверь, вы можете дать ему полный доступ». По этой логике брандмауэр устраняет необходимость во всех паролях во внутренней сети.

Надежные пароли - это один из шагов к ограничению ущерба, наносимого вторжением в сеть. Нет причин опускать руки в поражении только потому, что одна небольшая часть вашей сети была взломана.

Это действительно восходит к идее "Глубокая оборона'чтобы хотя бы надежный пароль мог замедлить их работу, чтобы вы могли их обнаружить и заблокировать. Мне нравится аналогия с единственным ключом от закрытого жилого комплекса и ключом на двери каждого дома.

Есть ли в бухгалтерии блокировка ящика для мелкой кассы? Если да, то почему? Разве в здании нет физической безопасности?

Это во многом зависит от того, как настроен ваш сервер MySQL. Если он принимает запросы только с домашнего (127.0.0.1) IP-адреса, это делает его более безопасным.

Учитывая сценарий, в котором вы разрешаете удаленные IP-адреса, это становится гораздо более важным.

В дополнение к этому, всегда хорошо иметь надежную защиту на случай вторжения - лучше, чтобы они ушли с как можно меньшим количеством.

вам не нужен надежный пароль пользователя mysql, потому что для его использования у них уже будет доступ к вашему серверу

Это неправда, потому что mysql также может использоваться в межсетевой среде клиент-сервер, и по умолчанию единственное, что вам нужно, это пользователь / пароль для получения доступа к базе данных (вне курса, с открытым портом 3306 и общедоступным сервером ).

На самом деле может быть и наоборот: если у них есть доступ к mysql, они смогут получить доступ к самой серверной ОС.

  1. Запросы MySQL LOAD_FILE и SELECT ... INTO OUTFILE позволяют пользователям mysql читать и записывать файлы в базовой файловой системе. Любой файл, к которому пользователь mysql также имеет доступ (работает ли ваш MySQL как root?). Если в Linux / UNIX просто запросите SELECT LOAD_FILE ('/ etc / passwd') и увидите, как они усмехаются. Если mysqld запущен как root, вы можете попробовать SELECT LOAD_FILE ('/ etc / shadow') и посмотреть, как плачет ваш системный администратор.
  2. Часто под Linux пользователь mysql "root" имеет тот же пароль, что и пользователь сервера "mysql" (тот, который запускает mysqld). Затем, если этот пароль тривиален (или его можно найти автоматическими инструментами, такими как medusa / hydra), вы можете просто SSH / telnet напрямую подключиться к серверу базы данных и шутить.

Если кто-то получит корень доступ к вашему серверу, тогда им не понадобится пароль MySQL. Но если они могут выполнять приложения на вашем сервере только как пользователь без полномочий root и не в Интернете, то надежный пароль MySQL все равно может сохранить ваши данные. Но да, большинство взломов происходит из Интернета, это означает, что хакер получит доступ к вашей веб-учетной записи и, следовательно, сможет извлечь пароль БД из файлов PHP.

Все это предполагает, что ваш сервер MySQL не принимает соединения от кого-либо, кроме localhost. Если это так, то вам нужен сильный PW.

Здесь кое-что, кажется, упускается из виду: доверяете ли вы своим пользователям в доверенной сети?

Честно говоря, нет, потому что я знаю, каким я был, когда начинал заниматься ИТ. Я бы тыкал и протыкал в областях, на которые у меня не было права, и, честно говоря, слабый пароль MySQL был бы для меня удовольствием, так как я бы воспользовался шансом удачи и попал внутрь, и я мог бы нанести ущерб (случайно, конечно).

Что, если кто-то воспользуется социальной инженерией, чтобы попасть в вашу надежную сеть? Тогда что ты делаешь? Если они находятся на машине, защищенной брандмауэром, их убивает, ваша надежная безопасность брандмауэра нарушена, и они прямо в машине.

Надежные пароли настолько просты в использовании, и существует множество инструментов управления паролями, которые упростят сохранение паролей в безопасности, так что действительно нет оправдания тому, чтобы не делать этого.

Эх. Если ваш сервер заблокирован по IP, а ваш пользователь ограничен выбором SELECT в наборе таблиц, информация о которых вам не нужна, это не имеет большого значения.

С другой стороны, я устанавливаю свои пароли MySQL, нажимая на клавиатуру в течение минуты, и копирую, вставляя полученную тарабарщину в защищенный файл, на который я ссылаюсь в своем коде всякий раз, когда мне нужно войти в систему. Вот как это должно работать.

Зачем упрощать? Если пароль привязан к ограниченной локальной учетной записи (а все они должны быть), то зачем вы его вводите? В противном случае у него должен быть пароль, надежность которого зависит от ценности данных, которые вы защищаете.

Информация об учетной записи / доступе mySQLs хранится в отдельном файле от реальных баз данных. Таким образом, вы можете просто перетащить на его место другой файл. С mySQL, если у них есть доступ на запись к соответствующей части вашей файловой системы, игра окончена.

Потому что требования меняются ...

Таким образом, сервер, который сегодня ограничен приемом MySQL-подключений только к локальной машине, завтра может быть открыт, чтобы можно было использовать внешний инструмент для управления базой данных. Человек, выполняющий эту настройку, может не знать, что используются очень слабые пароли.

Если вашему пользователю неудобно запоминать хороший, надежный (например, длинный, случайный) пароль, подумайте о том, чтобы сделать его очень надежным, а затем сохранить его в .my.cnf - даже удобнее, чем иметь слабый пароль, который нужно вводить. Конечно, это также имеет последствия для безопасности, но вам придется где-то хранить свой пароль, например, приложения, которые к нему обращаются, поэтому вы уже защищаете копии пароля.

Но также прочтите, что сказал @meagar.

Предположение, что у них уже будет доступ, неверно. Однако, если у них есть доступ и непривилегированная учетная запись, они все равно могут легко взломать пароль mysql.

Кроме того, если сервер является действующим производственным сервером, вы рекламируете себя в Интернете. это означает, что в какой-то момент кто-то ВОЛЯ попробуйте атаку методом перебора на этом сервере, включая mysql, порт и учетную запись пользователя.

если вы заботитесь о данных, то основные шаги должны иметь другой пароль root для базы данных, чем для пользователя root. другие заявили, что у вас также должны быть самые низкие разрешения для пользователей и программ.

4-символьный пароль можно взломать за считанные минуты на довольно дешевом компьютере.

Возможно, я просто повторяю то, что говорили другие, но чем больше у вас боеприпасов для вашего менеджера, тем лучше.

Многие из причин, связанных с реальным сценарием, уже освещались в публикациях, поэтому я добавлю «философский». Использование надежных паролей и принятие мер предосторожности для повышения безопасности - это философия работы. Образ мышления.

Использование ненадежного пароля сейчас поскольку ваш mysql работает только на 127.0.0.1, и только пользователь root имеет к нему доступ, это показывает, что вы не думаете о будущем. Что произойдет, если однажды вам потребуется предоставить доступ по сети к вашему mysql. Не забудете ли вы прикрыть все оставленные вами службы безопасности?

Хороший администратор доводит худший сценарий до состояния паранойи.

Это зависит от того, какие права есть у пользователя, вы всегда должны блокировать вещи на нескольких уровнях. Также это зависит от данных, которые вы храните в своей базе данных. Также предположим, что в MySQL есть уязвимость, которая позволяет им управлять всей базой данных, но им просто нужно войти в любую учетную запись пользователя. Если бы ваш пароль был надежным, это отключило бы эту уязвимость. Но это действительно зависит от вашего конкретного случая.

В mysql очень легко выдать себя за кого-то другого. Учитывая идентификатор пользователя без пароля (самая слабая защита), просто используйте mysql -u userid. Если у него есть пароль, это немного сложнее, но слабый пароль упрощает. Если у root нет пароля, я могу получить доступ к root как mysql -u root. Затем я могу делать в базе данных все, что может делать root.

Использование спецификаций хоста для обеспечения безопасности также является хорошей идеей, особенно если удаленный доступ есть или может быть доступен.

Пароли в файлах могут и должны быть защищены разрешениями. Доступ root или владелец файла паролей тривиален. Если возможно, следует использовать шифрование пароля на диске. Это немного затрудняет доступ, но все же уязвимо.

Что ж, если вы сами не размещаете базу данных MySQL, но она находится на службе хостинга, и кто-то получает доступ к IP-адресу вашего сервера, имя пользователя и пароль являются вашей последней линией защиты. Всегда хорошо иметь надежное имя пользователя / пароль.