Seite nicht Erreichbar obwohl Apache2 läuft

X4r3

New Member
Hallo,

ich habe seit gestern das Problem dass plötzlich meine Seite nicht mehr erreichbar ist.

Plesk zeigt dass der Webserver Apache Dienst gestoppt ist, Nach starten ist der Dienst wieder gestoppt.

Apache2 läuft aber definitiv und lässt sich per command problemlos starten, stoppen, restarten:

Code:
~# ps ax | grep apache2
22460 ?        Ss     0:00 /usr/sbin/apache2 -k start
22461 ?        S      0:00 /usr/sbin/apache2 -k start
22462 ?        S      0:00 /usr/sbin/apache2 -k start
22463 ?        S      0:00 /usr/sbin/apache2 -k start
22464 ?        S      0:00 /usr/sbin/apache2 -k start
22465 ?        S      0:00 /usr/sbin/apache2 -k start
22466 ?        S      0:00 /usr/sbin/apache2 -k start
22467 ?        S      0:00 /usr/sbin/apache2 -k start
22468 ?        S      0:00 /usr/sbin/apache2 -k start
22469 ?        S      0:00 /usr/sbin/apache2 -k start
22470 ?        S      0:00 /usr/sbin/apache2 -k start
22471 ?        S      0:00 /usr/sbin/apache2 -k start
22472 ?        S      0:00 /usr/sbin/apache2 -k start
22473 ?        S      0:00 /usr/sbin/apache2 -k start
22485 pts/0    R+     0:00 grep apache2

Die Serverlast liegt nahezu bei 0, was im Normalfall nicht sein kann da die Seite doch recht gut besucht ist.


error.log:
Code:
...
[Fri Jan 14 17:13:34 2011] [notice] child pid 25522 exit signal Segmentation fault (11)
[Sat Jan 15 13:15:43 2011] [notice] child pid 27946 exit signal Segmentation fault (11)

[Sat Jan 15 19:27:01 2011] [notice] caught SIGTERM, shutting down
[Sat Jan 15 19:27:06 2011] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Sat Jan 15 19:27:06 2011] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Sat Jan 15 19:27:06 2011] [warn] Init: SSL server IP/port conflict: default-xx-xx-xx-xx:443 (/etc/apache2/conf.d/zz010_psa_httpd.conf:80) vs. horde.webmail:443 (/etc/apache2/conf.d/zzz_horde_vhost.conf:41)
[Sat Jan 15 19:27:06 2011] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
[Sat Jan 15 19:27:06 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Sat Jan 15 19:27:06 2011] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Sat Jan 15 19:27:06 2011] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Sat Jan 15 19:27:06 2011] [warn] Init: SSL server IP/port conflict: default-xx-xx-xx-xx:443 (/etc/apache2/conf.d/zz010_psa_httpd.conf:80) vs. horde.webmail:443 (/etc/apache2/conf.d/zzz_horde_vhost.conf:41)
[Sat Jan 15 19:27:06 2011] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
[Sat Jan 15 19:27:06 2011] [notice] Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations
...
Ab 'Sat Jan 15 19:27:01 2011' war die Seite nicht mehr erreichbar und dieser Block tritt nach jedem Apache2 neustart auf.


Debian 5.0
Parallels Plesk Panel v9.5.4
 
Last edited by a moderator:
Hast Du evtl mal den Servernamen überprüft, denn anscheinend hats was mit dem Zertifikat auf sich....

19:27:06 2011] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
 
Das ist bei Plesk normal. Wenn man kein eigenes Zertifikat einbindet, wird per Default eines mit CN=plesk erstellt.
ServerName wird auf den iin Plesk eingestellten Haupt-Hostnamen eingestellt, zudem gibt es einen zweiten SSL-Vhost webmail.*.
Allerdings gibt Plesk in der Config nicht '*', sondern direkt die eingetragenene IPs für die vHosts an.

Was sagt denn 'netstat' zu Port 80?
 
Code:
~# netstat --tcp --listening --programs
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 *:imaps                 *:*                     LISTEN      2084/couriertcpd
tcp        0      0 *:pop3s                 *:*                     LISTEN      2103/couriertcpd
tcp        0      0 *:poppassd              *:*                     LISTEN      2155/xinetd
tcp        0      0 *:mysql                 *:*                     LISTEN      1742/mysqld
tcp        0      0 *:submission            *:*                     LISTEN      2155/xinetd
tcp        0      0 *:pop3                  *:*                     LISTEN      2093/couriertcpd
tcp        0      0 *:imap2                 *:*                     LISTEN      2073/couriertcpd
tcp        0      0 *:ssmtp                 *:*                     LISTEN      2155/xinetd
tcp        0      0 *:ftp                   *:*                     LISTEN      2155/xinetd
tcp        0      0 MEINDOMAINNAME:domain     *:*                     LISTEN      1650/named
tcp        0      0 localhost.locald:domain *:*                     LISTEN      1650/named
tcp        0      0 *:ssh                   *:*                     LISTEN      1665/sshd
tcp        0      0 localhost.lo:postgresql *:*                     LISTEN      1814/postgres
tcp        0      0 *:smtp                  *:*                     LISTEN      2155/xinetd
tcp        0      0 localhost.localdoma:953 *:*                     LISTEN      1650/named
tcp6       0      0 [::]:www                [::]:*                  LISTEN      2290/apache2
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      1665/sshd
tcp6       0      0 [::]:https              [::]:*                  LISTEN      2290/apache2

Dann sind noch ein paar Dutzend Verbindungen mit Status 'SYN_RECV' auf DOMAINNAME:www


Hab gerade noch in die syslog geschaut und was entdeckt was vor dem Problem noch nicht war:

Code:
Jan 15 19:27:05  /opt/psa/admin/bin/websrvmng[9748]: Unable connect to host 127.0.0.1:80: Connection refused
Jan 15 19:27:05  /opt/psa/admin/bin/websrvmng[9748]: Unable connect to host 127.0.0.1:443: Connection refused

Plesk ist jetzt nach nem Server-reboot auch nicht mehr erreichbar und muss manuell gestoppt und gestartet werden.


In Plesk braucht die Seite Dienstverwaltung auch ewig zum laden. Hier den gestoppten apache zu starten hilft auch nichts, ist gleich wieder als gestoppt.
 
Last edited by a moderator:
Es sind ein paar verschiedene IP's aber mehrfach mit unterschiedlichen Ports.

Nur 3 sind auf tcp6 mit dem Status 'TIME_WAIT' Alle anderen mit tcp auf 'SYN_RECV'.
 
Es sind ein paar verschiedene IP's aber mehrfach mit unterschiedlichen Ports.
Unterschiedliche Ports ist normal da jede ausgehende Verbindung einen neuen Port aus der User-Portrange kriegt.

Eventuell bist du Opfer einer Synflood-Attacke, entsprechende Gegenmassnahmen solltest du bei einer kurzen Forensuche finden.
Slowloris schliesse ich aufgrund der sehr kleinen Anzahl an aktiven Verbindungen aus.
 
Hm, wenn ich opfer einer Attacke wäre dann würde die CPU Last nicht bei 0.00 und RAM Auslastung bei ~5% liegen.
 
AUfgrund des Arts des Angriffes schon. Das ist ja das genial-gefaehrliche an Angriffen wie Synflood und Slowloris; extrem niedriger Ressourcenverbrauch auf beiden Machinen sowie sehr niedriger Traffic aber ohne / bei ungenuegender Absicherung stundenlange Downtimes problemlos moeglich.
 
Wie die netstat-Ausgabe zeigt, lauscht der Apache nur noch an den IPv6 Ports und ist deshalb über den üblichen Weg mit IPv4 nicht erreichbar. Ich denke, dass da eher eine Konfigurationsänderung als Ursache in Frage kommt. Entweder paßt da etwas mit den konfigurierten IP-Adressen nicht, oder der Apache hat widersprüchliche Konfigurationseinstellungen und ignoriert deshalb den Teil. Eventuell kann auch die Meldung über den Konflikt zwischen Plesk und Horde damit zusammenhängen (ich kenne beides nicht).
 
Hm krass, bin zuerst den Artikel bei Heise durchgegangen: http://www.heise.de/security/artikel/Unter-Beschuss-271208.html

Code:
echo 1 > /proc/sys/net/ipv4/tcp_synack_retries
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Brachte fast gar nichts, ausserdem sind die Einstellungen nach nem reboot wieder weg.

Dann bin ich den Thread von d4f durchgegangen:

Code:
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 2 --hitcount 10 -j DROP

Das brachte erheblich was. Die Seite ist wieder erreichbar.
Nur die Frage sind die Einstellungen nach nem reboot noch vorhanden?

THX d4f :)
 
Back
Top