WebServer sperrt mich aus - warum? [erledigt]

[doktorknow]

Hallo,

ich habe in der letzten Zeit einen Webserver (Apache2) mit PHP und MysQl im heimischen Netzwerk aufgesetzt (auf einem Iconnect), der aber auch über eine Portfreigabe der FritzBox von außen erreichbar ist.
Ich habe dort meine ersten Gehversuche in Punkto Homepage und Datenbanken ausprobiert. Leider tritt derzeit das Phänomen auf, dass nach einer gewissen Zeit immer vom System ausgesperrt werde.
Die Homepage ist weder von innen (interne Netzwerkadresse noch über die DynDNS zu erreichen). Außerdem wird mir der Zugriff über Putty mittels ssh verweigert.

Woran kann ich erkennen, welche Ursache das hat?
Gibt es irgendwelche Logs, die mir das dokumentieren?
Gruß
doktokrnow

[trg2889]

Was sagt denn das auth log ?

[doktorknow]

Da steht bei mir Folgendes:

Mar 26 11:06:01 iconnect CRON[30983]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:06:01 iconnect CRON[30982]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:06:01 iconnect CRON[30983]: pam_unix(cron:session): session closed for user root
Mar 26 11:06:01 iconnect CRON[30982]: pam_unix(cron:session): session closed for user root
Mar 26 11:09:01 iconnect CRON[31371]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:09:03 iconnect CRON[31371]: pam_unix(cron:session): session closed for user root
Mar 26 11:12:01 iconnect CRON[31784]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:12:01 iconnect CRON[31783]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:12:01 iconnect CRON[31784]: pam_unix(cron:session): session closed for user root
Mar 26 11:12:01 iconnect CRON[31783]: pam_unix(cron:session): session closed for user root
Mar 26 11:15:01 iconnect CRON[32165]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:15:01 iconnect CRON[32165]: pam_unix(cron:session): session closed for user root
Mar 26 11:17:01 iconnect CRON[32414]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:17:01 iconnect CRON[32414]: pam_unix(cron:session): session closed for user root
Mar 26 11:18:01 iconnect CRON[32548]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:18:01 iconnect CRON[32547]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 11:18:02 iconnect CRON[32548]: pam_unix(cron:session): session closed for user root
Mar 26 11:18:02 iconnect CRON[32547]: pam_unix(cron:session): session closed for user root

hier geht es so weiter und am Anfang steht:
Mar 26 12:06:01 iconnect CRON[4081]: pam_unix(cron:session): session closed for user root
Mar 26 12:06:01 iconnect CRON[4080]: pam_unix(cron:session): session closed for user root
Mar 26 15:46:23 iconnect sshd[1513]: Server listening on 0.0.0.0 port 22.
Mar 26 15:46:23 iconnect sshd[1513]: Server listening on :: port 22.
Mar 26 15:46:24 iconnect systemd-logind[1520]: New seat seat0.
Mar 26 15:46:39 iconnect sshd[1714]: Accepted password for root from 192.168.1.2 port 51647 ssh2
Mar 26 15:46:39 iconnect sshd[1714]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 26 15:46:40 iconnect systemd-logind[1520]: New session c1 of user root.
Mar 26 15:46:40 iconnect systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Mar 26 15:48:01 iconnect CRON[2507]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 15:48:01 iconnect CRON[2508]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 26 15:48:01 iconnect CRON[2508]: pam_unix(cron:session): session closed for user root
Mar 26 15:48:01 iconnect CRON[2507]: pam_unix(cron:session): session closed for user root

Gruß
doktorknow

[DeletedUserReAsG]

Anpingen lässt es sich noch, wenn der Rest nicht mehr erreichbar ist?

[doktorknow]

das habe ichehrlich gesagt noch nicht ausprobiert.

Mir ist nur aufgefallen, dass meine Homepage nicht mehr erreichbar ist (weder intern noch extern), phpmyadmin nicht mehr erreichbar ist, kein Puty bzw. Mosh Zugriff funktioniert.
Die Iconnect hat sich aber nicht aufgehängt - andere Dienste laufen weiter...

Gruß
doktorknow

PS Hier noch ein fail2ban.log:

2017-03-26 15:46:48,509 fail2ban.server [2330]: INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.13
2017-03-26 15:46:48,516 fail2ban.jail [2330]: INFO Creating new jail 'ssh'
2017-03-26 15:46:48,770 fail2ban.jail [2330]: INFO Jail 'ssh' uses pyinotify
2017-03-26 15:46:49,052 fail2ban.jail [2330]: INFO Initiated 'pyinotify' backend
2017-03-26 15:46:49,067 fail2ban.filter [2330]: INFO Added logfile = /var/log/auth.log
2017-03-26 15:46:49,079 fail2ban.filter [2330]: INFO Set maxRetry = 6
2017-03-26 15:46:49,100 fail2ban.filter [2330]: INFO Set findtime = 600
2017-03-26 15:46:49,106 fail2ban.actions[2330]: INFO Set banTime = 600
2017-03-26 15:46:50,091 fail2ban.jail [2330]: INFO Jail 'ssh' started
2017-03-26 15:46:50,232 fail2ban.actions.action[2330]: ERROR iptables -N fail2ban-ssh
iptables -A fail2ban-ssh -j RETURN
iptables -I INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh returned 100

da scheint auf jeden Fall auch etwas mit ssh nicht zu funktionieren...

[doktorknow]

So, jetzt wurde ich wieder rausgeschmissen...

Hier mal ein ping auf die IP des Servers:

C:\Users\acky>ping 192.168.1.25

Ping wird ausgeführt für 192.168.1.25 mit 32 Bytes Daten:
Antwort von 192.168.1.25: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.25: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.25: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.25: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 192.168.1.25:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\Users\acky>

[kira12]

Hallo,

schau erst mal ob die Dienst auf dem Server noch laufen. Weiterhin ist es eine ganz schlechte Idee zugriff auf den User root von außen zu zulassen, weiterhin noch per Passwort. Login nur unprivilegierten Usern erlauben und ausschließlich per key, niemans per Passwort. Außerdem solltest du nicht unbedingt Port 22 dafür verwenden. Der unprivilegiert User kann nach erfolgreichem login auf dem Server sich per su zu root machen.

Gruß ré

[doktorknow]

Vielen Dank für die Rückmeldungen!
Ich habe zunächst das System "sicherer" gemacht. Ich habe den RootLogin verboten und bei AllowUsers meinen internen Netzwerkbereich eingestellt. Das müsste ja schon deutlich besser sein... oder?

Mein Problem habe ich etwas genauer eingrenzen könne und festgestellt, dass es weniger mit dem Server als vielmehr mit dem Vlient-Rechner zu tun hat. Wenn mir nämlich nach ein paar Stunden der Zugriff verweigert wird, dann schafft ein Neustart des Client-Rechners Abhilfe... warum auch immer.

Ich denke, dass ich hiermit zunächst gut arbeiten kann und werde meine Zeit vornehmlich in die Absicherung des Webservers und das Erlnernen von PHP stecken!

Vielen Dank für die Hilfe!
doktorknow

[scientific]

Pam-googleauthenticator kann ich zum Absichern des ssh-Servers sehr empfehlen.

Lg scientific

[doktorknow]

So, ich musste nun feststellen, dass mein Problem doch nicht erledigt ist. Es handelt sich aber nicht nur um eine Blockade des SSH Zugriffs, sondern insgesamt eine Zugriffsbeschränkung.
Wenn ich auf meinen Server zugreifen möchte, so erhalte ich

Forbidden

You don't have permission to access / on this server.
Apache/2.4.10 (Debian) Server at 192.168.1.25 Port 80

Andere Dienste, die auf dem Server laufen, machen aber weiterhin ihren Dienst (es ist also kein Absturz).
Sind das irgendwelche Apache-Einstellungen, die eine Blockade nach einiger Zeit aktivieren?

Gruß
doktorknow

[DeletedUserReAsG]

Das ist die typische Meldung, wenn die Dateisystemrechte nicht ausreichen. Welches Verzeichnis das im lokalen Verzeichnisbaum ist, solltest du selbst wissen (DocumentRoot) oder halt im Log nachschauen können. Kann natürlich auch sein, dass Indexing deaktiviert und keine index.html o.Ä. vorhanden ist. Auch in dem Fall wird das Log dir weiterhelfen.

[weshalb]

Probiere mal rein prophylaktisch

Code: Alles auswählen

service fail2ban stop

und schau, ob du dann zugreifen kannst. Wenn nicht, starte fail2ban wieder.

Du kannst dir natürlich auch die letzten Ban's auflisten

Code: Alles auswählen

zgrep -h "Ban " /var/log/fail2ban.log* | awk '{print $NF}' | sort | uniq -c

Desweiteren wäre interessant, was du da zu laufen hast, also schau mal in deine Apache Konfiguration.

Laut Fehlermeldung würde ich auch eher dort suchen.

[doktorknow]

@niemand
So die index.html ist in folgendem Verzeichnis:

root@iconnect:/var/www/html# ls
index.html Logo_WebUntis.jpg Untis_Mobile_Logo.jpg
root@iconnect:/var/www/html# cd ..
root@iconnect:/var/www# ls -l
total 8
drwxrwxrwx 2 root root 4096 Mar 23 20:37 html
-rw-r--r-- 1 acky acky 616 Mar 21 00:06 index.html

Da ich ja für mehrere Stunden auf die Homepage zugreifen kann, kann ich mir nicht vorstellen, dass es ein Problem bei den "Grundeinstellungen" ist - ich bin da aber gerne bereit weiter zu testen. Ich teste hier gerade einmal zwei oder drei Wochen mit einem LAMP herum.

@weshalb
ich versuche mal mit einer "sauberen" Konfiguration den Webserver neu aufzusetzen...

[DeletedUserReAsG]

Ich denke, du solltest die Sachen prüfen, die ich geschrieben habe. Insbesondere solltest du ins Log schauen, wo genau der Fehler auftaucht. Und dann in deiner Config schauen, wie’s dazu kommt. Schuss ins Blaue: verschiedene vHosts, von denen einer funktioniert und ein anderer nicht, wobei aufgrund äußerer Umstände (ServerName, etc.) nicht immer auf den nichtfunktionierenden vHost zurückgegriffen wird. Aber ohne Logs ist das halt Kaffeesatzleserei.

[doktorknow]

So, ich habe die Sache nun doch noch etwas beobachtet und glaube festgestellt zu haben, dass die Abstürze mit meiner angehängten Festplatte zu tun haben.
Wenn ich die Festplatte nicht anschließe, mounte und per nfs-kernel-server freigebe, dann läuft der WebServer tagelang ohne Absturz.
Wenn ich die Festplatte anhänge, dann ist nach einigen Stunden Ende. Ich habe vorgestern das dateisystem der Festplatte überprüft (hat 14 Stunden gedauert) - in der Zeit lief der Server... anschließend (ich vermute, als sich die Festplatten schlafen gelegt hat) ist der Server wieder in die Knie gegangen.
Ich liefere gerne Logs dazu, nur welche soll ich hier posten?
fail2ban liefert exakt das Log, das oben bereits gepostet ist.

hier mal das syslog

Apr 23 22:25:01 iconnect CRON[12977]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Apr 23 22:30:01 iconnect rsyslogd-2007: action 'action 17' suspended, next retry is Sun Apr 23 22:31:31 2017 [try http://www.rsyslog.com/e/2007 ]
Apr 23 22:30:01 iconnect CRON[13328]: (root) CMD (wget --delete-after "http://www.meinehomepage> /dev/null)
Apr 23 22:30:01 iconnect CRON[13330]: (root) CMD (wget --delete-after "http://www.meinehomepage2 > /dev/null)
Apr 23 22:30:01 iconnect CRON[13321]: (CRON) info (No MTA installed, discarding output)
Apr 23 22:30:01 iconnect CRON[13320]: (CRON) info (No MTA installed, discarding output)
Apr 23 22:35:01 iconnect rsyslogd-2007: action 'action 17' suspended, next retry is Sun Apr 23 22:36:31 2017 [try http://www.rsyslog.com/e/2007 ]
Apr 23 22:35:01 iconnect CRON[13655]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Apr 23 22:36:01 iconnect CRON[13734]: (root) CMD (wget --delete-after "http://www.meinehomepage1> /dev/null)
Apr 23 22:36:01 iconnect CRON[13735]: (root) CMD (wget --delete-after "http://www.meinehomepage2" > /dev/null)
Apr 23 22:36:01 iconnect CRON[13726]: (CRON) info (No MTA installed, discarding output)
Apr 23 22:36:01 iconnect CRON[13725]: (CRON) info (No MTA installed, discarding output)
Apr 23 22:39:01 iconnect rsyslogd-2007: action 'action 17' suspended, next retry is Sun Apr 23 22:40:31 2017 [try http://www.rsyslog.com/e/2007 ]
Apr 23 22:39:01 iconnect CRON[13938]: (root) CMD ( [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)

Bin für jeden Hinweis dankbar!
Gruß
doktorknow

[DeletedUserReAsG]

Ich liefere gerne Logs dazu, nur welche soll ich hier posten?

Da es um den httpd geht, wären dessen Logs ein guter Anfang ….

[doktorknow]

Vielen Dank, dass du die Flinte noch nicht ins Korn geworfen hast!!

Ich habe folgende Log-Dateien:

ls
alternatives.log debug.1 lastlog mysql.log.7.gz
alternatives.log.1 debug.2.gz lpr.log news
alternatives.log.2.gz debug.3.gz mail.err ntpstats
apache2 debug.4.gz mail.info php
apt dmesg mail.log proftpd
auth.log dpkg.log mail.warn syslog
auth.log.1 dpkg.log.1 messages syslog.1
auth.log.2.gz dpkg.log.2.gz messages.1 syslog.2.gz
auth.log.3.gz fail2ban.log messages.2.gz syslog.3.gz
auth.log.4.gz fail2ban.log.1 messages.3.gz syslog.4.gz
boot fail2ban.log.2.gz messages.4.gz syslog.5.gz
bootstrap.log fail2ban.log.3.gz mod_evasive syslog.6.gz
btmp faillog mysql syslog.7.gz
btmp.1 fontconfig.log mysql.err sysstat
daemon.log fsck mysql.log user.log
daemon.log.1 iconnect-install.log mysql.log.1.gz vsftpd.log
daemon.log.2.gz kern.log mysql.log.2.gz vsftpd.log.1
daemon.log.3.gz kern.log.1 mysql.log.3.gz warn
daemon.log.4.gz kern.log.2.gz mysql.log.4.gz watchdog
dbconfig-common kern.log.3.gz mysql.log.5.gz wtmp
debug kern.log.4.gz mysql.log.6.gz wtmp.1

und in apache2:

access.log access.log.12.gz access.log.5.gz access.log.9.gz error.log.11.gz error.log.3.gz error.log.7.gz
access.log.1 access.log.2.gz access.log.6.gz error.log error.log.12.gz error.log.4.gz error.log.8.gz
access.log.10.gz access.log.3.gz access.log.7.gz error.log.1 error.log.13.gz error.log.5.gz error.log.9.gz
access.log.11.gz access.log.4.gz access.log.8.gz error.log.10.gz error.log.2.gz error.log.6.gz other_vhosts_access.log

Eine ausgewiesene httpd.log finde ich nicht - vermutlich ist das aber in der error.log von apache2, richtig?
Die sieht so aus:

[Tue Apr 25 06:25:11.651701 2017] [mpm_prefork:notice] [pid 1959] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations
[Tue Apr 25 06:25:11.651920 2017] [core:notice] [pid 1959] AH00094: Command line: '/usr/sbin/apache2'

Das error.log.1 sieht so aus:

[Sun Apr 23 06:25:11.180222 2017] [mpm_prefork:notice] [pid 1952] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations
[Sun Apr 23 06:25:11.180433 2017] [core:notice] [pid 1952] AH00094: Command line: '/usr/sbin/apache2'
[Mon Apr 24 17:20:10.534464 2017] [mpm_prefork:notice] [pid 1959] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations
[Mon Apr 24 17:20:10.535943 2017] [core:notice] [pid 1959] AH00094: Command line: '/usr/sbin/apache2'
[Tue Apr 25 06:25:09.835143 2017] [mpm_prefork:notice] [pid 1959] AH00171: Graceful restart requested, doing restart
[Tue Apr 25 06:25:11.149570 2017] [alias:warn] [pid 1959] AH00671: The Alias directive in /etc/phpmyadmin/apache.conf at line 3 will probably never m$
[Tue Apr 25 06:25:11.150081 2017] [alias:warn] [pid 1959] AH00671: The Alias directive in /etc/phpmyadmin/apache.conf at line 3 will probably never m$
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to $

Hilft das weiter?
Gruß
doktorknow

[DeletedUserReAsG]

Du solltest den ServerName setzen. Zum Posten von Logs am besten via cat ausgeben lassen, dann fehlen die wichtigen Teile auch nicht. Außerdem könntest du statt quote code in das Tag schreiben, dann geht auch die Formatierung nicht kaputt.

[doktorknow]

So, hier nun ein neuer Versuch....

Dies ist die 000-default.conf aus /sites-available

Code: Alles auswählen

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ServerName doktorknow.dyndns2.net
        <Directory /var/www/html/oktonauten>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

Und hier das error.log mit cat -A

Code: Alles auswählen

root@iconnect:/var/log/apache2# cat -A error.log
[Tue May 02 06:25:11.788447 2017] [mpm_prefork:notice] [pid 1976] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations$
[Tue May 02 06:25:11.788631 2017] [core:notice] [pid 1976] AH00094: Command line: '/usr/sbin/apache2'$
[Tue May 02 15:54:21.939224 2017] [mpm_prefork:notice] [pid 1959] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations$
[Tue May 02 15:54:21.940862 2017] [core:notice] [pid 1959] AH00094: Command line: '/usr/sbin/apache2'$

und hier das error.log.1:

Code: Alles auswählen

root@iconnect:/var/log/apache2# cat -A error.log.1
[Mon May 01 06:25:11.147765 2017] [mpm_prefork:notice] [pid 2003] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations$
[Mon May 01 06:25:11.148007 2017] [core:notice] [pid 2003] AH00094: Command line: '/usr/sbin/apache2'$
[Mon May 01 13:23:01.700468 2017] [mpm_prefork:notice] [pid 1976] AH00163: Apache/2.4.10 (Debian) configured -- resuming normal operations$
[Mon May 01 13:23:01.708008 2017] [core:notice] [pid 1976] AH00094: Command line: '/usr/sbin/apache2'$
[Tue May 02 06:25:10.074740 2017] [mpm_prefork:notice] [pid 1976] AH00171: Graceful restart requested, doing restart$
[Tue May 02 06:25:11.271146 2017] [alias:warn] [pid 1976] AH00671: The Alias directive in /etc/phpmyadmin/apache.conf at line 3 will probably never match because it overlaps an earlier Alias.$
[Tue May 02 06:25:11.271655 2017] [alias:warn] [pid 1976] AH00671: The Alias directive in /etc/phpmyadmin/apache.conf at line 3 will probably never match because it overlaps an earlier Alias.$
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message$

Für mich deutet hier aber nichts auf die angeschlossene Festplatte als Übeltäter hin. Ich habe aber zugegebenermaßen keine Ahnung .

Gruß
doktorknow

[doktorknow]

Okay, ich muss bei der Fehlersuche doch noch einmal ganz von vorne anfangen.
Jetzt hatte ich die Festplatte gestern nicht angeklemmt und heute komme ich mit ssh nicht mehr auf den Server - Homepage ist auch nicht mehr erreichbar...

Scheint also doch nicht nur an der Festplatte zu liegen.
Vielleicht muss ich mir doch mal einen aktuellen Raspberry zulegen... die Iconnect ist schon etwas in die Jahre gekommen...

Kann ich diesen Beitrag irgendwo schließen?
Gruß
doktorknow

[TRex]

Kann ich diesen Beitrag irgendwo schließen?

Nein, musst du auch nicht - [gelöst] im Titel reicht. Grabschänder werden gevierteilt.