How to secure phpMyAdmin

 ( andrasf | 2019. június 28., péntek - 13:28 )

Sok helyen a következőt ajánlják:


location /phpmyadmin {
  auth_basic "Admin Login";
  auth_basic_user_file /etc/nginx/pma_pass;
}

Ez azért jó, mert ugyan a szerverem/phpmyadmin címen valóban bekéri a jelszót, de a szerverem/phpmyadmin/index.php címen már nem. Ennek ellenére még a DigitalOcean howto-iban is így szerepel.

Azért ez vicces :) Esetleg ajánlható lenne helyette:

location ~ /phpmyadmin/.*

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

> How to secure phpMyAdmin

rm -rf
az egyetlen biztos megoldas

Vagy Adminer?

En szerintem egyik SQL editor se production kornyezetbe valo.
Otthon fejleszteshez, de nem productionbe. Ha valahol direktbe sql-t kell irni, akkor
az a weboldal meg nincs kesz:)

Barmit csinalsz ez plusz egy belepesi pont. Altalaban defaulton telepitve es hagyva:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Igaz, de azért azt az egy darab php fájlt nem nagy kaland letörölni mondjuk egy migráció után. :)

Meg fogsz lepődni, de a PHPMyAdmin és az Adminer nem csak arra való, hogy „direktben írj SQL-t”, hanem hogy pl. gyorsan áttekintsd az éles rendszer adatbázisát.
Amúgy én az Adminert preferálom, még ha kevesebbet is tud. Egy fájl, könnyen átnevezhető, törölhető.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

vajon miert nem lehet a napi mentest
"attekinteni"?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Mert lehet, hogy a napi mentés túl nagy, esetleg még nem került bele a keresett adat.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Gyakorlatban irtó sokszor jól jönnek ezek. Csak más ne menjen be. Akkor se, ha utána ír egy szóközt. Persze értem én a gondokat, meg minden, csak nem emberszerű.

> az Adminert preferálom, még ha kevesebbet is tud

Az Adminer saját összehasonlítása szerint max. az export formátumok számában marad alul. Van "ellen-összehasonlítás" is? Most egy gyors kuglizás nem hozott eredményt.

Felhasználói felületben nem olyan kényelmes és egyszerű. De tény, hogy mindent tud, amire szükség lehet, gyors és ha már nincs rá szükség, könnyen törölhető.

Ui.: a phpMyAdmin csak MySQL/MariaDB, míg az Adminer több más adatbáziskezelőhöz is használható.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

> Felhasználói felületben nem olyan kényelmes és egyszerű.

A kényelem szubjektív, az egyszerűséget meg nem értem pontosan mire mondod. Ha többet tud és ezért több funkció van a kezelőfelületen, az bonyolultabb kezelőfelületet eredményez, az tény, de még ennek ellenére is gyorsabb, mert nincs agyonverve felesleges vackokkal.

> Ui.: a phpMyAdmin csak MySQL/MariaDB, míg az Adminer több más adatbáziskezelőhöz is használható.

Ezt én is tudom, benne volt az összehasonlításban, amit linkeltem; miért emelted ki?

+1

+1

+1 - de ha nagyon-nagyon-nagyon kell, akkor a külön DB-szerveren legyen egy szál webszerverrel, amit ip meg cert alapon korlátozottan lehet elérni https-en. Mondjuk. A prod. webszerverre semmiképp nem raknám fel.
Anno csináltam olyat, hogy egy phpmyadmin szerver volt, ahonnan n+1 mysql-t lehetett tutujgatni - erre a szerverre pont cer/ip alapon lehetett beesni, a phpmyadmin meg valami ssl-tunnelbe csomagolt módon beszélgetett a db-szerverekkel. A /verzió az volt benne, hogy az n+1 mysql felé n+1 -talán stunnel-t kellett felhúzni és életben tartani :-)

Profinak tűnsz, how to secure wordpressre is volna tipped? :))

A WP telepitesek kb. fele nincs frissitve valami 2017-es statisztika szerint, viszont a tobbseg gondolkodas nelkul teszi fel a 3rd party plugineket - igen, lenne tippem arra is. :)

+1. De inkább +1000

En amikor ilyen bizonytalan cuccot kell kitennem, akkor
ele szoktam tenni egy nginx-et, http basic auth-tal.

De phpmyadmin-t kerulom. Az legyen a fejleszto gepen, ha ohajtja.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A fenti példa (location /whatever) az nginx prefix matchinget használja, azaz nem exact matching van, hanem minden azzal kezdődő URL-re (azaz a /whatever/foo/bar alakúakra is) illeszkedik. Nem azt nézed be, hogy ha egyszer egy adott URL-re basic auth adatokat megadtál, akkor a browsered azt cache-eli és az adott szerverhez tartó requestekhez elküldi?

Ez nekem is furcsa volt, pont azt próbáltam ki hogy ez így jó-e. Ha nem a /whatever címet nyitottam meg, hanem egy olyan linket, ami már azon belül volt, nem kért jelszót.

Az mondjuk elképzelhető, hogy a konfiguráció miatt van, a sorrenden múlik, vagy ilyesmi.

Az biztos hogy valami nem ugyanaz, mert:


location /whatever {
  auth_basic "Admin Login";
  auth_basic_user_file /etc/nginx/pma_pass;
}

ez után lefut a php, viszont


location ~ /whatever/.* {
  auth_basic "Admin Login";
  auth_basic_user_file /etc/nginx/pma_pass;
}

ebbe már kell a fastcgi_pass, nélküle nem működik. A következő location pedig:


location ~ \.php$ {
  include snippets/fastcgi-php.conf;
  fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
}

Lehet benézek valamit, érdekelne :)

Na, a 3. blokkról eddig még nem volt szó. :) Az nginx dokumentáció alapján egyértelmű, hogy a regex match legyőzi a prefix matchet.

http://nginx.org/en/docs/http/ngx_http_core_module.html#location

"""A location can either be defined by a prefix string, or by a regular expression. [...] If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used."""

Bővebben:

http://nginx.org/en/docs/http/request_processing.html

Én ilyesmit csinálnék:

location ^~ /phpmyadmin {
    auth_basic direktívák
    location ~ \.php$ {
        fastcgi config
    }
}

Ha van más location alatt is php alkalmazásod, akkor az eredeti fastcgi related configot is tartsd meg.

Nagyjából így csináltam. Mondjuk furcsa, mert egyszerűen fastcgi_pass -oltam, location ~ \.php$ nélkül, és működik. Most inkább ezt nem értem, hogy miért működik :)

Úgy tűnik, hogy mivel a képekre, css, js fájlokra már korábban van regexes location cache-sel, ide már csak a php-s requestek jutnak el. Tehát részben a véletlen műve.