Чому погано мати слабкий пароль користувача mysql?

Мені було подано аргумент на мелодію: "Вам не потрібен сильний пароль користувача mysql, оскільки для того, щоб ним користуватися, вони вже мали доступ до вашого сервера". Ми говоримо про чотиризначний пароль, який є стандартним словником англійського словника на веб-сайті, що працює в реальному часі.

Не впливаючи на відповіді власними знаннями та досвідом, я хотів би показати їм відповіді від незацікавленого стороннього джерела. Хтось хотів би передзвонити на цьому? Програмування / практичні відповіді будуть вдячні.

Той, хто висловлював цей аргумент, здається, говорить: "Як тільки хтось ступить у двері, ви можете також дати їм повний доступ". За цією логікою брандмауер заперечує необхідність усіх паролів у вашій внутрішній мережі.

Сильні паролі - це один крок до обмеження шкоди, завданої вторгненням у мережу. Немає підстав піднімати руки в поразці лише тому, що одна мала частина вашої мережі була порушена.

Це дійсно повертається до ідеї " Захист в глибині ", щоб принаймні надійний пароль міг уповільнити їх, щоб ви могли їх виявити та заблокувати. Мені подобається аналогія наявності єдиного ключа для громади із закритим будинком проти ключа у дверях кожного будинку.

Багато що залежить від налаштування вашого сервера MySQL. Якщо він приймає лише запити з дому (127.0.0.1) ip, це робить його помірно безпечнішим.

Враховуючи сценарій, коли ви дозволяєте віддалені IP-адреси, це стає набагато більшою угодою.

На додаток до цього, завжди добре мати міцну безпеку у випадку вторгнення - краще, щоб вони пішли з якомога менше.

Чи є замок на скриньці Petty Cash у бухгалтерському обліку? Якщо так, то чому? У будівлі немає фізичної безпеки?

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

Це неправда, тому що mysql також може бути використаний у середовищі міжсередовищного клієнта-сервера, і за замовчуванням єдине, що вам потрібно - це користувач / пас, щоб отримати доступ до бази даних (offcourse, відкритий порт 3306 та сервер загальнодоступним ).

Насправді це може бути інакше: якщо вони мають доступ до mysql, вони зможуть отримати доступ до самої ОС сервера.

1. MySQL LOAD_FILE та SELECT ... INOT OUTFILE запити дозволяють користувачам mysql читати та записувати файли в базовій файловій системі. Будь-який файл, до якого користувач mysql також має доступ (ваш MySQL працює як root?). Якщо під linux / UNIX просто запитайте SELECT LOAD_FILE ('/ etc / passwd') і побачите їх посмішкою. Якщо mysqld працює як root, ви можете спробувати SELECT LOAD_FILE ('/ etc / shadow') і спостерігати, як ваш sysadmin плаче.
2. Багато разів під Linux під користувачем mysql "root" є той самий пароль, що і у користувача "mysql" сервера (той, який працює з mysqld). Тоді, якщо цей пароль є тривіальним (або придатним для автоматизованих інструментів, таких як medusa / hydra), ви можете просто SSH / telnet безпосередньо на сервер бази даних і обдурити.

Якщо хтось отримує кореневий доступ до вашого сервера, він не потребуватиме будь-якого пароля MySQL. Але якщо вони можуть виконувати додатки на вашому сервері лише як користувачі, що не мають root, так і користувачі, які не користуються Інтернетом, то надійний пароль MySQL все ще може зберегти ваші дані. Але так, більшість хакків надходить з Інтернету, це означає, що хакер отримає доступ до вашого веб-облікового запису і тому може витягнути пароль DB з файлів PHP.

Все це, якщо ваш сервер MySQL не приймає з'єднання з будь-якого місця, крім localhost. Якщо це так, то вам потрібен сильний PW.

Щось, здається, тут не помічено, - чи довіряєте ви своїм користувачам у надійній мережі?

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

Що робити, якщо хтось використовує соціальну інженерію, щоб потрапити на вашу довірену мережу? Тоді що ти робиш? Якщо вони знаходяться на машині за брандмауером, вони звинувачуються, ваш надійний захист брандмауера руйнується, і вони прямо в машину.

Сильні паролі зробити настільки просто, і існує безліч інструментів управління паролем, щоб зробити безпеку паролів просто, тому насправді немає приводу для цього.

Е-е. Якщо ваш сервер заблокований IP-адресою, а ваш користувач обмежений функцією SELECT у наборі таблиць, де вам не важлива інформація, це не велика справа.

З іншого боку, я встановлюю свої паролі MySQL, натискаючи клавіатуру на хвилину, і копіюю вставляючи отриманий гібрид у захищений файл, на який я посилаюсь у своєму коді всякий раз, коли мені потрібно увійти. Ось як це має працювати.

Чому це зробити просто? Якщо пароль приєднаний до обмеженого локального облікового запису (як і всі вони повинні бути), то навіщо його вводити? Якщо це не так, він повинен мати пароль, міцність якого відповідає значенню даних, які ви захищаєте.

Інформація про обліковий запис / доступ до mySQL зберігається в окремому файлі від фактичних баз даних. Таким чином, ви можете просто перетягнути на своє місце інший файл. Якщо mySQL має доступ для запису до відповідної частини вашої файлової системи, гра закінчена.

Тому що вимоги змінюються ...

Отже, сервер, який обмежується прийняттям MySQL-з'єднань лише до локальної машини, може завтра відкритись, щоб зовнішній інструмент міг використовуватись для управління базою даних. Людина, яка проводить цю установку, може не знати, що в користуванні вкрай слабкі паролі.

Якщо вашому користувачеві незручно запам'ятовувати хороший, міцний (наприклад, довгий, випадковий) пароль, подумайте про те, щоб зробити його дуже сильним, а потім зберегти його в .my.cnf - навіть зручніше, ніж у слабкого пароля, який він повинен вводити. Звичайно, для цього є і наслідки для безпеки, але вам доведеться зберігати свій пароль десь, наприклад, програми, які отримують доступ до нього, тому ви вже закріплюєте копії пароля.

Але також прочитайте, що сказав @meagar.

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

Крім того, якщо сервер - це сервер живого виробництва, ви рекламуєте себе в Інтернеті. що означає , що в будь - то момент хто - то БУДУ спробувати перебором на цьому сервері, включаючи MySQL, як порт і обліковий запис користувача.

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

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

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

Багато причин із сценарію реального життя раніше висвітлювались повідомленнями, тому я додам «філософію». Використання надійних паролів та вживання запобіжних заходів для посилення безпеки - це філософія роботи. Спосіб мислення.

Використання слабкого пароля тепер, оскільки ваш mysql працює лише на 127.0.0.1, і лише користувач root має доступ до нього, це означає, що ви не думаєте наперед. Що станеться, якщо одного дня вам потрібно надати доступ до мережі mysql через мережу. Чи пам’ятаєте ви, щоб покрити всі цілі безпеки, які ви залишили?

Хороший адмін ставить найгірший сценарій спочатку до параної.

Залежно від прав, які має користувач, ви завжди повинні блокувати речі на кількох рівнях. Також це залежить від даних, які ви зберігаєте у вашій базі даних. Також гіпотетично скажіть, що в MySQL є вразливість, яка дозволяє їм забирати всю базу даних, але їм просто потрібно було увійти в будь-який обліковий запис користувача. Якщо ваш пароль був надійним, це призведе до відключення цієї вразливості. Але це дійсно просто залежить від вашого конкретного випадку.

Дуже легко видати себе в mysql когось іншого. Даний ідентифікатор користувача без пароля (найслабший захист) просто використовуйте mysql -u userid. Якщо у нього є пароль, це трохи складніше, але слабкий пароль полегшує його. Якщо у root немає пароля, я можу отримати доступ до root як mysql -u root. Тоді я можу зробити все, що всередині бази даних, що може root.

Використання специфікацій хоста в безпеці також є хорошою ідеєю, особливо якщо віддалений доступ є або може бути доступний.

Паролі у файлах можуть і повинні бути дещо захищені дозволами. Доступ через root, або власник файлу паролів, є тривіальним. По можливості слід використовувати шифрування пароля на диску. Це робить його трохи складнішим, але все ще вразливим.

Добре, якщо ви самі не розміщуєте сервер MySQL, але це служба хостингу, і хтось отримує доступ до IP-адреси вашого сервера, ім'я користувача та пароль - це ваш останній захист. Завжди добре мати захищене ім’я користувача / пароль.