Mindig a jó gyakorlatok barátja voltam, még inkább, ha ezek segítenek nekünk szervereink, szolgáltatásaink vagy egyszerűen csak információink biztonságának fenntartásában.
Sok rendszergazda vagy felhasználó szokása (rossz szokása), hogy használja a hozzáférést gyökér minden adatbázis esetében, vagyis ... telepítenek egy webhelyet a WordPress CMS segítségével, és az adatbázis elérési adataként (hogy a WP használhassa a MySQL szervert és a DB-jét) a MySQL szerver adminisztrációs felhasználót: root
Ezenkívül telepítenek bármilyen más webalkalmazást (chatet, beillesztést, fórumot stb.), És ugyanezt teszik, mindig a MySQL root felhasználóját használják ...
HIBA!!!
Ez egyszerűen végzetes szokás.
Tegyük fel, hogy a következő szolgáltatásokkal rendelkezünk egy szerveren:
- Webhely vagy portál a WordPress használatával.
- Támogatási fórumunk, beszélgetéseink stb. ... egy egész közösség.
- Olyan FTP, amely MySQL adatbázist használ a felhasználók és a jelszavak tárolására.
- Az e-mail felhasználókat (felhasználókat és jelszavakat) egy MySQL adatbázis tárolja.
- Egy kis WebChat, amelyet telepítünk, hogy beszélgethessünk valakivel, akit ismer.
És mindegyikben az 5 szolgáltatásban a MySQL root felhasználóját használjuk, hogy minden szolgáltatás elérje és elmentse az adatokat a megfelelő adatbázisába.
Egy szép napon a sok troll közül bármelyik odakinn van, de ez nemcsak troll, hanem elsajátít néhány kihasználást, sebezhetőséget, hackelést stb. ... úgy dönt, hogy valami károsat tesz nekünk.
Keressen egy hibát a WebChatban, amelyet használunk, kihasználva ezt a hibát, képes elérni a WebChat fájlokat, beleértve a WebChat konfigurációs fájlt is, és ... ebben a fájlban nyilvánvalóan az a felhasználónév és jelszó, amelyet a WebChat használ a MySQL szerver, és kitalálod? ... Ez nem több és nem kevesebb, mint a GYÖKÉR FELHASZNÁLÓ!
Ezen információk megszerzésével a troll nagyon egyszerű módon:
- Töröljön minket és / vagy lopjon el mindent, ami a mi webhelyünkkel vagy portálunkkal kapcsolatos (WordPress).
- Törölhet és / vagy ellophat információkat tőlünk ÉS a Fórumot használó felhasználóinktól, az általunk létrehozott közösségtől.
- Ellophatja mindazon felhasználók felhasználónevét és jelszavát is, akiknek van e-mail fiókjuk a szerverünkön, valamint lophatjuk el az információkat az e-mailjeikről, megszemélyesíthetjük stb.
- És most végre használhat egy fiókot az FTP-kiszolgálónkon, és feltölthet minden olyan fájlt, amely rosszindulatú programokat tartalmaz, ami lehetővé tenné számunkra, hogy abszolút és ÖSSZESEN irányítsák szerverünket.
Nos ... mit gondolsz? … 🙂
Lát mindent, ami történhet, ha nem hoz létre független felhasználókat minden egyes adatbázisunkhoz?
Ez NEM túlzás, barátok, ez elképesztő könnyedséggel történhet ... nos, a katasztrófa kiváltásához csak a telepített webalkalmazások hibája szükséges.
Most…
Hogyan lehet külön MySQL felhasználókat létrehozni minden webalkalmazáshoz?
Először be kell lépnünk a MySQL szerverbe a root felhasználóval, mivel ő jogosult adatbázisok létrehozására, engedélyek létrehozására, felhasználók létrehozására stb .:
mysql -u root -p
Amikor megírják a fentieket és megnyomják [Belép] Megkérdezik tőlük a MySQL root felhasználó jelszavát, kiírják és megnyomják [Belép] ismét azonnal valami ilyesmit mutat:
Most létrehozunk egy adatbázist «webchatdb„:
CREATE DATABASE webchatdb;
Kész, már létrehozta az adatbázist, most folytassuk a felhasználó létrehozásával «webkiszolgáló«Jelszóval«jelszódelputowebchat„:
CREATE USER 'webchatuser'@'localhost' IDENTIFIED BY 'passworddelputowebchat';
Most a varázslat ... megadjuk az összes kiváltságot (olvasás és írás) webkiszolgáló CSAK a DB-ben webchatdb:
GRANT ALL PRIVILEGES ON webchatdb.* TO 'webchatuser'@'localhost' WITH GRANT OPTION;
És voila, a felhasználónak már megvannak az engedélyei abban az adatbázisban ... most már csak a MySQL engedélyeinek frissítése marad, vagyis mondja meg a MySQL-nek, hogy olvassa át a felhasználók privilégiumait, mert most változtattunk rajtuk:
FLUSH PRIVILEGES ;
És ez minden volt. Ezzel az egyes általunk használt webalkalmazásokra garantáljuk, hogy amennyiben sikerül megsérteniük az egyik webalkalmazást, a többi biztonságban lesz (legalábbis a MySQL szempontjából)
Mi a jó gyakorlat? 😉
Remélem, hogy ez ugyanolyan hasznos volt számodra, mint nekem, mivel megpróbáltam a lehető legegyszerűbben elmagyarázni.
Üdvözlet
Jó bejegyzés KZKG, ha a fórumban lenne, ragacsot kérnék!
Köszönöm 😀
A webchat-hez megadott jelszó jó, egy másik dolog, ami a mysql-hez kapcsolódik, az a memória használata
Hehehe, köszönöm, hogy emlékeztetett a MySQL parancsokra, most nézzük meg, hogy "Biztosítottam-e némi biztonságot" a LAN-on lévő World of Warcraft szerver DB-ken.
nulla tudásom erről, de majdnem megegyezik a MySQL használatával az Amarok esetében?
ADATBÁZIS LÉTREHOZÁSA amarokdb;
MINDEN PRIVILÉG MEGADÁSA AZ amarokdb-n. * A „jelszóval” azonosított „amarokuser” -re; FLUSH PRIVILEGES;
Hosszú-hosszú ideig nem használtam az Amarok-ot, de ha olyan DB-t használsz, amely MySQL, akkor elméletileg ennek is így kellene működnie.
Helló, jó lenne, ha létrehoznál egy bejegyzést a webszerverek elleni biztonságról a linuxban, sokuknak nincs megfelelő biztonsága, és ennek rendszergazdája nem megfelelően szakértő, csak megkönnyítik a dolgokat, például a A szervereken található symlink lehetővé teszi más fiókok konfigurációs fájljainak olvasását ugyanazon a kiszolgálón, sok rendszergazda nincs tudatában ennek, és ezért szaporodnak a weboldalak
Üdvözlet
Szia, hogy vagy,
Üdvözöljük a 🙂 oldalon
Messze nem tartom magam igazán szakértőnek ebben a kérdésben, de megpróbálok hozzájárulni ahhoz a kevés tudáshoz, amelyet az évek során megszereztem 🙂
Egy másik dolog, amit nem sok hálózati rendszergazda tesz, az az, hogy az apache-okkal rendelkező webhelyeknek külön-külön jogosultságokat adnak, vagyis a felhasználói és csoportos www-adatokat (vagy hasonlóakat), amelyek mindegyik webhelyhez más és más, és ezek mindegyikét ketrecbe helyezik.
Üdvözlet
Jó tipp
Üdvözlet
Köszönöm
Utálom a terminálod megjelenését, a háttérbetűk kivesznek a koncentrációomból. Kibaszott őrült vagy xD
Ezen kívül érdekes, mert láttam szánalmas eseteket a szolgáltatás kimaradásáról ezekből a dolgokból.
Most nem csak ettől függ, a biztonság abban rejlik, hogy az adatbázis hogyan épült fel - magyarázta nekem egy tanár -, de még nem vagyok nagyon elmerülve a DB-ben ... össze kell kavarni a MongoDB = D-vel napok
pont ez történt velem ma a bérelt szerveremmel
Követtem a lépéseit, beléptem a cpanelbe, és megkerestem a MYSQL adatbázist, amely azt mondja nekem, hogy nincs rendben.
Nem tudom, hogyan kell most belépni a root felhasználó alá
Újdonság vagyok ebben, de itt olvasva sokat tanulsz, remélem, hogy eligazítasz a hozzáféréshez
Helló 🙂
Mi az a tárhely (SharedHosting) vagy egy VPS (virtuális szerver)?
Ha van tárhelye, és nem VPS, akkor meg kell néznie, hogy a tárhely rendelkezik-e SSH hozzáféréssel (vegye fel a kapcsolatot annak a cégnek a technikai támogatásával, amelyik eladta Önnek a tárhelyet, és kérdezze meg tőlük, hogyan lehet hozzáférni az SSH-n keresztül), miután belépett az SSH-n, a felhasználó NEM lesz root, de azt a felhasználót kell használnia, amelyet az adott webalkalmazás telepítésekor adott meg.
Valójában a tiéd egy bonyolult téma, mert a változatok és a lehetőségek annyira túl sokak, azt javaslom, hogy nyiss egy új témát a fórumunkban, ott kényelmesebb lesz segíteni neked - » http://foro.desdelinux.net
Üdvözlet 😀
Jó,
Megértem, hogy jó gyakorlat, ha a root kivételével egyetlen felhasználónak sem adunk meg minden jogosultságot. A phpmyadmin telepítése óta azonban létrehozták az új "phpmyadmin" felhasználót minden jogosultsággal. Logikusnak tűnik, hogy ez a helyzet, mivel ez csak egy grafikus változat az adatbázisok kezelésére a MySQL-ben. Mindenesetre szeretnék megbizonyosodni arról, hogy ez rendben van-e, vagy módosítanom kellene a "phpmyadmin" felhasználó jogosultságait.
Üdvözlet és köszönöm!
Kiváló…
Azok közé tartozom, akik mindent gyökérrel csinálnak, de te kinyitottad a szemem, barátom ..
Nagyon köszönöm…