Eigenartige OpenSSL-Logeinträge

marneus

Registered User
Servus!

Nachdem mein Webserver seit 04.00 Uhr down war, hab ich heute morgen mal in die messages geschaut und folgende Einträge erhalten (Source-IP ist natürlich bekannt - "Angreifer" steht bei S4Y):
Jan 14 21:05:32 h9x stunnel[9472]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:32 hxxxxxx stunnel[9472]: stunnel connected from {source}:44449
Jan 14 21:05:32 hxxxxxx stunnel[9474]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:32 hxxxxxx stunnel[9474]: stunnel connected from {source}:44452
Jan 14 21:05:38 hxxxxxx stunnel[9472]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
Jan 14 21:05:38 hxxxxxx stunnel[9476]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:38 hxxxxxx stunnel[9476]: stunnel connected from {source}:44500
Jan 14 21:05:38 hxxxxxx stunnel[9476]: SSL_accept: Peer suddenly disconnected
Jan 14 21:05:38 hxxxxxx stunnel[9477]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:38 hxxxxxx stunnel[9477]: stunnel connected from {source}:44501
Jan 14 21:05:38 hxxxxxx stunnel[9477]: Connection closed: 233 bytes sent to SSL, 0 bytes sent to socket
Jan 14 21:05:38 hxxxxxx stunnel[9474]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
Jan 14 21:05:38 hxxxxxx stunnel[9479]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:38 hxxxxxx stunnel[9479]: stunnel connected from {source}:44503
Jan 14 21:05:43 hxxxxxx stunnel[9479]: SSL_accept: Peer suddenly disconnected
Jan 14 21:05:43 hxxxxxx stunnel[9486]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:43 hxxxxxx stunnel[9486]: stunnel connected from {source}:44536
Jan 14 21:05:43 hxxxxxx stunnel[9486]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 14 21:05:43 hxxxxxx stunnel[9488]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:43 hxxxxxx stunnel[9488]: stunnel connected from {source}:44538
Jan 14 21:05:43 hxxxxxx stunnel[9488]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 14 21:05:43 hxxxxxx stunnel[9490]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:43 hxxxxxx stunnel[9490]: stunnel connected from {source}:44539
Jan 14 21:05:43 hxxxxxx stunnel[9490]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 14 21:05:43 hxxxxxx stunnel[9493]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:43 hxxxxxx stunnel[9493]: stunnel connected from {source}:44541
Jan 14 21:05:43 hxxxxxx stunnel[9493]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 14 21:05:43 hxxxxxx stunnel[9495]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:43 hxxxxxx stunnel[9495]: stunnel connected from {source}:44543
Jan 14 21:05:43 hxxxxxx stunnel[9495]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
Jan 14 21:05:43 hxxxxxx stunnel[9498]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:43 hxxxxxx stunnel[9498]: stunnel connected from {source}:44545
Jan 14 21:05:50 hxxxxxx stunnel[9498]: SSL_accept: Peer suddenly disconnected
Jan 14 21:05:50 hxxxxxx stunnel[9503]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:51 hxxxxxx stunnel[9503]: stunnel connected from {source}:44606
Jan 14 21:05:51 hxxxxxx stunnel[9503]: SSL_accept: Peer suddenly disconnected
Jan 14 21:05:51 hxxxxxx stunnel[9505]: stunnel 4.07 on i686-suse-linux-gnu PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004
Jan 14 21:05:51 hxxxxxx stunnel[9505]: stunnel connected from {source}:44609
Was zum Teufel ist das? Google liefert nur unbefriedigende Ergebnisse. Danke für Eure Mühe!
 
stunnel wird eingesetzt, um die Verbindung zu Diensten via SSL zu sichern, die das selbst nicht unterstützen, z. B. qpopper. Ich vermute, dass du einen entsprechenden Eintrag in deiner (x)inetd-Konfiguration hast, der stunnel (+ den entsprechenden Dienst) bei Verbindungsanfrage startet.
Laut den Logs versucht jemand völlig planlos darauf zuzugreifen und irrt sich ab und zu im Protokoll...
 
Last edited by a moderator:
Erstmal Danke für die Erklärung. In der Tat nutzt qpopper den stunnel. Meine Frage wäre nun, ob ich mir a) Sorgen machen muss und vor allem b) wie ich das unterbinden kann.
 
Hm, abschalten klingt so unbefriedigend :) Könnte Schaden durch diese Art von "Spielerei" angerichtet werden?
 
IMHO nicht, außer du hast so schöne Passwörter wie "Passwort" oder "12345". Außerdem treffen "die Bösen" ja nichtmal das richtige Protokoll.
 
Ne, hab alphanumerische Passwörter mit Groß- und Kleinschreibung: Password1 :D

Kleiner Scherz am Rande. Also Passwörter für den Serverzugang sind alle den aktuellen Gegebenheiten angepasst. Für meine Emailpostfächer würde ich mir keine Gedanken machen. Bei meinen Kunden kann ich natürlich nicht meine Hand ins Feuer legen.
 
Könnte es theoretisch sein, dass diese Logmeldungen dadurch ausgelöst werden, dass jemand Marneus' Server als Idle-Host für einen indirekten Portscan missbraucht?
Deshalb auch mal http request und dann wieder unknown protocol... :confused:

Edit: oder umgedreht - ich komme gerade nicht damit klar, wer denn da nun wen anpingen/-scannen muss bei nem Idle-Host-Scan... -> even more :confused: ;)
 
Könnte es theoretisch sein, dass diese Logmeldungen dadurch ausgelöst werden, dass jemand Marneus' Server als Idle-Host für einen indirekten Portscan missbraucht?
Wenn man auf die Portnummern schaut, könnte das durchaus der Fall sein, wobei man dann eigentlich nichts in den Logs sehen würde. Es geht ja nur darum, die Sequenznummer der TCP-Pakete zu ermitteln. Dazu muss es keine vollständige Verbindung geben.

Edit: oder umgedreht - ich komme gerade nicht damit klar, wer denn da nun wen anpingen/-scannen muss bei nem Idle-Host-Scan... -> even more :confused: ;)
Ne, die erste Beschreibung passt schon. Angreifer schickt Pakete mit gefälschter Source IP an Opfer, Opfer antwortet an Server der die gefälschte IP-Adresse hat. Allerdings wundert es mich, dass dann auch mal HTTP ankam. ;)
 
Jungs, ihr seid gerade ein wenig ausserhalb meines Wissensbereichs. Ich hab leider gerade nicht die Zeit mir den Sachverhalt, den ihr gerade ausdisktutiert zu ergooglen, da ich kurz vor den Klausuren stehe.

Idle-Host - ich drop alle Ping-Packages mit iptables. Nützt Euch der Hinweis etwas? Deswegen auch die FTP-Connection am Anfang, um zu schauen, ob mein Host überhaupt up ist.
 
Ohne naeher im Thema zu sein ...
Ich habe mit den gegebenen Stichwoertern diesen meiner Meinung nach brauchbaren Text gefunden :
heise Security | Heimliche Scans und falsche Fährten
2ter Abschnitt; Wenn Die Klausuren so dicht anliegen und Du SSH bis dahin nicht unbedingst brauchst (weiss ja nicht, was Du so be-treibst ;) ), dass Du fuer den Artikel keine Zeit hast, dann empfehle ich dringendst das Problem bis nach den Klausuren zu vertragen.
Unter Druck, Stress und Zeitnot hast Du beste Chancen alles nur zu verschlimmbessern und Besuch von Murphy zu bekommen.
Da heisst es, Prioritaeten setzen.
Ansonsten ist der Artikel denke ich sehr sachdienlich und auch nicht sehr lang (es geht nur um den zweiten Abschnitt).
Laesst sich leider nicht sonderlich ueber die Konsequenzen aus und fuer mich ist's auch zu frueh davon abgesehen habe ich mit der Materie besonders wenn es darum geht, was das in juristischer Hinsicht bedeutet, nicht viel zu tun.
=> aber vielleicht nimmst Du noch das Schlagwort "Idle-host" ins topic auf?
==> Und vielleicht hat DJRick dazu ja Kenntnisse? PN ihn doch mal zu diesem Thread ;> nun wo das Phaenomen dezent eingekreist zu sein scheint.

Ciao,
Mercy.
 
Hi Mercy,

vielen Dank für den Hinweis. Abschalten kann ich den Server leider nicht, da dort 14 Präsenzen drauf laufen, wo ich Geld für kriege, dass sie laufen.

Der Server ist heute wieder um 04:00 Uhr down gewesen. Jedoch finde ich keinerlei Hinweise für irgendwas. Alle Logdateien sind clean. Das einzige, was ich noch nie vorher in meinen "messages" gefunden habe ist folgendes:
Jan 16 04:00:21 hxxxxxx crontab[28097]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:21 hxxxxxx crontab[28104]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:22 hxxxxxx crontab[28108]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:22 hxxxxxx crontab[28114]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:23 hxxxxxx crontab[28118]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:23 hxxxxxx crontab[28122]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:23 hxxxxxx crontab[28125]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:24 hxxxxxx crontab[28132]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:24 hxxxxxx crontab[28136]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:25 hxxxxxx crontab[28140]: (root) LIST (Domain auf meinem Server)
Jan 16 04:00:25 hxxxxxx crontab[28144]: (root) LIST (mailman)
Überprüfung der crontab ergab keine Änderungen :confused:

Im Apache Log finde ich folgendes:
qmail-inject: fatal: mail server permanently rejected message (#5.3.0)
[Tue Jan 16 04:00:12 2007] [warn] child process 26711 still did not exit, sending a SIGTERM
[Tue Jan 16 04:00:12 2007] [warn] child process 14238 still did not exit, sending a SIGTERM
[Tue Jan 16 04:00:12 2007] [warn] child process 14239 still did not exit, sending a SIGTERM
[Tue Jan 16 04:00:12 2007] [warn] child process 26711 still did not exit, sending a SIGTERM
[Tue Jan 16 04:00:12 2007] [warn] child process 14238 still did not exit, sending a SIGTERM
[Tue Jan 16 04:00:12 2007] [warn] child process 14239 still did not exit, sending a SIGTERM
[Tue Jan 16 04:00:14 2007] [notice] caught SIGTERM, shutting down
Und dann verabschiedet er sich. Ich werde mir den Artikel wohl morgen irgendwie zu Gemüte ziehen. Hilft ja nix...
 
Back
Top