[ERLEDIGT] PMA besser absichern

[Rene]

fulltilt Wrote:habe gerade bemerkt dass die failregex noch erweitert werden muss, weil PMA auch unter:

/tools/pma/index.php

erreichbar ist.

ja, daran habe ich nicht gerade, hast recht das muss noch geändert werden

fulltilt Wrote:Die fail2ban logs sind bei mir vorhanden:

Code:

2008-02-10 14:26:56,803 fail2ban.actions: WARNING [pma] Ban 192.168.0.5
2008-02-10 14:27:03,993 fail2ban.actions: WARNING [pma] 192.168.0.5 already banned

Kann die Loginseite aber weiterhin aufrufen ...
Könnte das daran liegen das ich hier eine VM verwende?

hm, das ist komisch. also ich kann dann gar keine seite mehr aufrufen.
kann das bitte noch jmd. testen?

[Rene]

fulltilt Wrote:Die fail2ban logs sind bei mir vorhanden:

Code:

2008-02-10 14:26:56,803 fail2ban.actions: WARNING [pma] Ban 192.168.0.5
2008-02-10 14:27:03,993 fail2ban.actions: WARNING [pma] 192.168.0.5 already banned

so habe die selbe meldung produziert und zwar wie folgt:
in der jail.conf habe ich den port https festgelegt.
so gebe ich da das passwort 3 mal falsch ein, bin ich gesperrt, jedoch nur auf dem port!
öffne ich die seite über den port 80 geht es noch, gebe ich da dreimal das passwort falsch ein, kommt die meldung im log das der user schon gebanned ist.
also muss man noch eine regel erstellen für den port 80. dann geht es.

ich weiß ja nicht über welche ports du gehst...
fulltilt, trifft es denn bei dir zu?

[fulltilt]

Stimmt die Ports müssen auch noch gesetzt werden ...
oder ein zweiter Eintrag pma2 für https ...

Hier auf der virtuellen Maschine, blockt überhauot nix ... auch nicht ssh, die log Einträge sind aber vorhanden.

Rene Wrote:

fulltilt Wrote:Die fail2ban logs sind bei mir vorhanden:

Code:

2008-02-10 14:26:56,803 fail2ban.actions: WARNING [pma] Ban 192.168.0.5
2008-02-10 14:27:03,993 fail2ban.actions: WARNING [pma] 192.168.0.5 already banned

so habe die selbe meldung produziert und zwar wie folgt:
in der jail.conf habe ich den port https festgelegt.
so gebe ich da das passwort 3 mal falsch ein, bin ich gesperrt, jedoch nur auf dem port!
öffne ich die seite über den port 80 geht es noch, gebe ich da dreimal das passwort falsch ein, kommt die meldung im log das der user schon gebanned ist.
also muss man noch eine regel erstellen für den port 80. dann geht es.

ich weiß ja nicht über welche ports du gehst...
fulltilt, trifft es denn bei dir zu?

[Rene]

welche ip hat denn der server, auch eine private?

[fulltilt]

yes - private ip

Klappt auf einem anderen System jetzt ...
Bin mir aber noch am überlegen, ob es nicht doch sicherer ist von auth cookie auf http auth umzustellen ...
Hatte das vorher in vhcs auf auth http - ist das mit der neuen Konfiguration machbar?

[joximu]

Hm den 302 greppen... mag sein, dass dies bei falschem einloggen passiert, da bei pma alle Anfragen übr die index.php läuft, hab ich das dumpfe Gefühl, dass man da ggf. auch mal unschuldig gesperrt werden könnte:
302 ist ja kein Fehler, nur, dass die Seite eine andere URL hat, aber der £Browser sich das nicht merken soll...
http://www.w3.org/Protocols/rfc2616/rfc2...#sec10.3.3

naja, vielleicht sind meine Bedenken auch unbegründet...

Umstellen auf http auth sollte gehen, nur wird es dann auch nicht mehr direkt aus ispcp heraus aufrufbar sein (mit Anmeldedaten) - ohne es gleich in die URL zu hausen....

/J

Edit: sorry, sollte heissen, ohne gleich die Anmeldedaten in die URL zu hauen...

[fulltilt]

Ist soweit eine schöne Sache mit fail2ban und kann man sicherlich noch für andere Seiten so einsetzen, allerdings meiner Meinung nicht zuverlässig genug um das hier richtig abzusichern.
Ich denke hier auch eher an auth http in pma.
Das der direkte Aufruf von PMA aus der GUI dann nicht mehr klappt, sollte man dann lieber in Kauf nehmen.

joximu Wrote:Hm den 302 greppen... mag sein, dass dies bei falschem einloggen passiert, da bei pma alle Anfragen übr die index.php läuft, hab ich das dumpfe Gefühl, dass man da ggf. auch mal unschuldig gesperrt werden könnte:
302 ist ja kein Fehler, nur, dass die Seite eine andere URL hat, aber der £Browser sich das nicht merken soll...
http://www.w3.org/Protocols/rfc2616/rfc2...#sec10.3.3

naja, vielleicht sind meine Bedenken auch unbegründet...

Umstellen auf http auth sollte gehen, nur wird es dann auch nicht mehr direkt aus ispcp heraus aufrufbar sein (mit Anmeldedaten) - ohne es gleich in die URL zu hausen....

/J

[fulltilt]

joximu Wrote:Umstellen auf http auth sollte gehen, nur wird es dann auch nicht mehr direkt aus ispcp heraus aufrufbar sein (mit Anmeldedaten) - ohne es gleich in die URL zu hausen....

Fehlt da noch etwas?
So klappts mit dem Login nicht:

Code:

/* Server 1 (session) [1] */
$i++;

/* Authentication type */
$cfg['Servers'][$i]['auth_type']        = 'http';

und:

/* Server 2 (cookie) [2] */
$i++;

/* Authentication type */
$cfg['Servers'][$i]['auth_type']         = 'config';

[fulltilt]

Nun so richtig komme ich mit dem absichern von PMA nicht weiter ...

Einfache aber auch effektive Lösung um von aussen PMA für nicht Kunden unzugänglich zu machen:

Den PMA Alias ändern in z.B.
/pma3564tfganzlangerblahblahgeheimundsoweiter

Code:

Dazu habe ich geändert in:
/etc/ispcp/ispcp.conf
PMA_PATH = ../pma3564tfganzlangerblahblahgeheimundsoweiter

dann ändern in:
/etc/ispcp/apache/00_master.conf
Alias /pma3564tfganzlangerblahblahgeheimundsoweiter      {ROOT_DIR}/gui/tools/pma/

dann in:
/etc/apache2/sites-available/00_master.conf
Alias /pma3564tfganzlangerblahblahgeheimundsoweiter      /var/www/ispcp/gui/tools/pma/

Allerdings ist dann immer noch IPadresse/tools/pma möglich.
Kann man das irgendwie verhindern?

[joximu]

Umbenennen des Verzeichnisses /var/www/ispcp/gui/tools/pma

oder ggf. mit einem anderen Alias in der Apache überschreiben
/tools/pma -> irgendwohin...

/J