Jump to content
Froxlor Forum

Exploit

Members
  • Posts

    67
  • Joined

  • Last visited

Posts posted by Exploit

  1. Now I have had a look at the HTTP requests. What happens is not the same as when I try to log in with the wrong password. In summary, the following happens:

    Request: POST index.php, what is striking here is the cookie line of the request, in which the PHPSESSID variable is set twice with two different values!
    Response: 302 to customer_index.php, Set-Cookie: PHPSESSID=(new value)

    Request: customer_index.php, Cookie: PHPSESSID set twice again
    Response: 302 to index.php

    No error message appears, as after entering an incorrect password,

    After deleting the cookies in the browser, the login also worked under Windows!

    Conclusion: something messes up the Session Cookie.

  2. Same I have here with an account from a client. From my linux machine the login works fine, from a windows machine not. I didn't dive into the used login procedure, but I guess that the cause is something with the character set.
    I've noticed issues with an previous froxlor version from the last year, where it helped to remove the browser cache. On both machines, Linux and Windows, I've been using Firefox.

  3. Jetzt habe ich diesen Fehler auch bekommen. (Version 2.0.19-1)

    Zwei Dinge:

    1. Wenn man nach der Fehlermeldung wieder zum Formular geht, ist alles wieder leer, das ist kein Problem, aber etwas ärgerlich.

    2. Wenn eine Neue Domain angelegt wird und die DNS-Einträge von Froxlor angelegt werden müssen, geht das in die Hose.

    Letzteres habe ich mit einem 'Workaround' gelöst, indem ich die domain zuerst ohne Let's Encrypt angelegt habe.
     

  4. Hello, I'm trying to provide an SSH shell access to customers on an Debian Bullseye.

    So far the usernames are shown properly in the system but the loggin in with SSH is rejected. The path in "/var/lib/extrausers/passwd" is always set to "/bin/false" even if I set the "List of available shells" in Froxlor on "/bin/bash", while the cronjob does create the files.

    Any Idea, why the path is not what I would expect to be set in the passwd file?

  5. On 6/7/2019 at 8:35 AM, proman said:

    Nochmal ne Nachfrage...

    Versucht mich da einer zu HACKEN..?

    Jun  7 08:31:44 con2 postfix/smtpd[15150]: warning: unknown[185.137.111.77]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
    ..............


    Das geht seit gestern im Sekundentakt... was kann ich dagegen tun..?

     

    Ja, das sind Bots, irgendwelche gehackte / mit Viren infizierte Zombies die wörterbucher, etc. ausprobieren. Das ist ganz normal und nichts besorgnis erregendes, vorrausgesetzt das sichere Passwörter verwendet werden.

    Dagegen kannst du Fail2ban installieren, damit werden Angreifende IP-Adressen nach ein paar Fehlversuche für eine Zeit blockiert. Das spart Speicherplatz und schont die Festplatten. Sei aber nicht zu übereifrig mit dem ändern der standard Configs zum Blockieren, wärst nicht der erste der sich selber damit ausgesperrt hat ?

  6. 12 hours ago, d00p said:

    mod_php wieder aktivieren, alle generierten vhosts löschen und http://ip/froxlor - jast du doch selbst im ersten post geschrieben wie du das wieder erreicht hast 

    Das wollte ich meinen Kunen am Montag Morgen nicht unbedingt antun Habe dan doch noch einen anderen weg gefunden...

    Die alte .conf für den Froxlor Host aus "/etc/php5/fpm/pool.d/" von einem Backup nach "/etc/php/7.0/fpm/pool.d" hochgeladen und dann ein "systemctl restart php7.0-fpm" und das Controlpanel lief (der rest hatte dann gepasst).

    Dann im Controlpanel den php-fpm Hacken gesetzt, den Cronjob ausgeführt und die hochgeladene Datei aus dem Backup wurde nun von Froxlor überschrieben, also neu angelegt, was ja auch so sein soll.

    Irgendwo hat Froxlor da aber auch einen kleinen Fehler, denn es ergibt ja keinen Sinn das er in der "10_froxlor_ipandport_xx.xx.xx.xx.443.conf" auf ein Socket zeigt ohne die .conf dazu in der "pool.d" an zu legen.

  7. Habe jetzt /etc/php/7.0/fpm/pool.d gefunden und eingestellt, es hat wohl doch einen Unterschied gemacht, Die Seiten sind wieder online!

    Keine Ahnung wie ich dieses Verzeichnis den ganzen Tag übersehen konnte, obwohl ich sogar nach so etwas gesucht hatte. Auf jeden Fall vielen Dank für die Hilfe. Die Kundenseiten sind online, nur Froxlor ist jetzt wieder weg. Wahrscheinlich läuft es noch unter mod-php. Die Häckchen liessen sich nicht ändern, waren grau mit einen hinweis das anderswo etwas konfiguriert ist, das dies nicht zulässt.

  8. Da sind aber nur Dateien drinn, die von Froxlor erzeugt wurden, wass soll da passieren wenn ich den umbenenne?

    Irgendwas ist aber passiert, in /var/lib/extrausers/ sind nun User angelegt worden. Diesmal hatte ich den Cronjob nach einem erneuten Error, nochmal ausgeführt und dann war die Fehlermeldung weg. Scheint also irgendwas mit der Reihenfolge gewesen zu sein.

    Ein kleiner Schritt für einen Menschen, aber ein großer Sprung für einen Server zum Ether.

    Jetzt muss nur noch der 503 weg.

  9. Die sehen bei mir so aus:

    Kurzbeschreibung:
    Kommando zum Neustarten von php-fpm:
    Pfad zu php-fpm-Konfigurationen:
    Prozess Manager Control (PM): dynamic
     

    "/etc/php5/fpm/pool.d" scheint mir nur ein Name zu sein und ist egal, oder?

     

    php.ini-Einstellungen:

    allow_call_time_pass_reference = Off
    allow_url_fopen = 1
    asp_tags = Off
    disable_classes =
    disable_functions = exec,passthru,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,show_source,system
    display_errors = Off
    display_startup_errors = Off
    enable_dl = Off
    error_reporting = E_ALL & ~E_NOTICE
    expose_php = Off
    file_uploads = On
    cgi.force_redirect = 1
    gpc_order = "GPC"
    html_errors = Off
    ignore_repeated_errors = Off
    ignore_repeated_source = Off
    include_path = ".:{PEAR_DIR}"
    log_errors = On
    log_errors_max_len = 1024
    magic_quotes_gpc = Off
    magic_quotes_runtime = Off
    magic_quotes_sybase = Off
    max_execution_time = 30
    max_input_time = 60
    memory_limit = 128M
    {OPEN_BASEDIR_C}open_basedir = "{OPEN_BASEDIR}"
    output_buffering = 4096
    post_max_size = 32M
    precision = 14
    register_argc_argv = Off
    register_globals = Off
    report_memleaks = On
    sendmail_path = "/usr/sbin/sendmail -t -i -f {CUSTOMER_EMAIL}"
    session.auto_start = 0
    session.bug_compat_42 = 0
    session.bug_compat_warn = 1
    session.cache_expire = 180
    session.cache_limiter = nocache
    session.cookie_domain =
    session.cookie_lifetime = 0
    session.cookie_path = /
    session.entropy_file = /dev/urandom
    session.entropy_length = 16
    session.gc_divisor = 1000
    session.gc_maxlifetime = 1440
    session.gc_probability = 1
    session.name = PHPSESSID
    session.referer_check =
    session.save_handler = files
    session.save_path = "{TMP_DIR}"
    session.serialize_handler = php
    session.use_cookies = 1
    session.use_trans_sid = 0
    short_open_tag = On
    suhosin.mail.protect = 1
    suhosin.simulation = Off
    track_errors = Off
    upload_max_filesize = 32M
    upload_tmp_dir = "{TMP_DIR}"
    variables_order = "GPCS"
    
    opcache.restrict_api = "{DOCUMENT_ROOT}"
    

     

  10. Was muss denn für PHP7 geändert werden?

    Webserver-Reload-Command: /etc/init.d/apache2 reload
    ist doch OK, oder?

    FastCGI IPC Verzeichnis: /var/lib/apache2/fastcgi/
    drwxr-xr-x 3 www-data www-data 4.0K Apr 14 04:35 fastcgi
    sollte doch gehen? Hier werden aber keine Sockets angelegt, woran könnte das liegen?

    Verwende libnss-extrausers anstatt libnss-mysql: hat einen Hacken

    # a2dismod
    Your choices are: access_compat actions alias auth_basic authn_core authn_file authz_core authz_groupfile authz_host authz_user autoindex cgi cgid deflate dir env fcgid filter headers mime mpm_itk mpm_prefork negotiation passenger proxy proxy_fcgi python reqtimeout rewrite setenvif socache_shmcb ssl status suexec
    Which module(s) do you want to disable (wildcards ok)?

    Ist alles vorhanden.(?)

     

    Mit php5 habe ich folgendes, wüsste aber nicht was da hin soll, die Verzeichnisse existieren schon noch...

    Cron Startbefehl (php Programm): /usr/bin/nice -n 5 /usr/bin/php5 -q

    Globale PEAR Verzeichnisse: /usr/share/php/:/usr/share/php5/

  11. Hallo, lange habe ich es vor mich hinaus geschoben, aber nun fürht einfach kein Weg mehr drum herum, das Update von Jessie auf Stretch!

    Das Update schien einwandfrei zu laufen, nur sehr wenige Fragen wurde gestellt zu manuell geänderten configs. Im Vergleich zum Update von Wheezy auf Jessie, war ich sehr positiv überrascht. Dann aber die böse Überraschung, Das Froxlor-panel war offline und alle anderen Seiten auch. Das Froxlor-panel habe ich wieder zum laufen bekommen unter mod-php und durch das löschen von allen configs in /etc/apache2/sites-enabled/ welche anfangen mit 29*, 35*, 40*, aber nur bis Froxlor sie wieder neu schreibt!

    Einmal wieder im Panel drinne habe ich alle Vorlagen unter System->Konfiguration abgearbeitet.

    Habe alles versucht was ich hier im Forum finden konnte, dieser Thread kommt der Sache sehr nahe:

    Lösen konnte ich das Problem damit leider nicht.

    Das Problem habe ich soweit identifizieren können das keine Sockets mehr erstellt werden in /var/lib/apache2/fastcgi/.

    Wenn ich alle dateien die anfangen mit 29*, 35*, 40* Lösche in /etc/apache2/sites-enabled/
    und in 10_froxlor_ipandport_xx.xx.xx.xx.443.conf
    "/var/lib/apache2/fastcgi/1-froxlor.panel-xxlspace.net-php-fpm.socket" ändere in "/run/php/php7.0-fpm.sock"

    Dann läuft nach einem Restart von Apache2 das Froxlor-Panel wieder bis der Cronjob das natürlich wieder überschreibt.

    Aus irgendeinen Grund legt er nach dem Update auf Stretch einfach keine Sockets mehr an. Bin seit heute Nacht den Fehler an suchen und wüsste nicht was ich noch ausprobieren könnte.

    Nebenbei wird das Verzeichnis /etc/php5/fpm/pool.d auch noch verwendet, PHP5 unter Stretch aber nicht mehr unterstützt, was ja auch wenig Sinn hätte, da es dafür keine Sicherheits-Updates mehr gibt.

    Wie kann ich die Sockets in /var/lib/apache2/fastcgi/ wieder zum Leben erwecken, oder mus ich irgendwo die Pfade ändern?

×
×
  • Create New...