• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Frage, PEN Test und die Rechtsgrundlagen

Domi

Member
Hallo Leute, ich habe mal eine Frage an euch... ob "pen test" nun das korrekte Wort ist, will ich mal so dahin gestellt lassen. Es geht um folgendes, bei uns in der Firma haben wir einen Server direkt für einen Kunden. Dieser Server wurde allerdings von deren Mutterkonzern überprüft... Port Scans, Webseite gescannt etc.

Angeblich sind "browsable directories" vorhanden, aber ich finde keine und in der Config des Servers ist das auch deaktiviert. Nun kam ich auf die Idee, vielleicht finde ich ja selbst ein Tool zum testen, ab dann noch einen guten Bekannten gefragt und er riet mir davon ab... §202c STGB und als ich hier im Forum ein wenig suchte, fand ich zusätzlich auch §303b (Computersabotage)... meine Quellen, z.B. hier und hier!

Alles verständlich, ich musste nicht mal groß überlegen und mir viel ein, klar... um einen Sicherheitsdienst der Geld ausliefert zu überprüfen, müsst ich einen Raub fingieren und selbst das wäre ja schon eine Straftat. Es kamen dann von dem Kunden und deren Mutterkonzern ein / zwei Argumente wie "ja, aber muss ja geprüft werden" und ich meinte nur "ne ne ne, Server steht im RZ von Hetzner!", ihr habt Portscans gemacht und die Dienste auf Herz und Nieren getestet indem sogar Kennwörter oder sonstige Abfragen versucht wurden (z.B. Test der Kennwort Übergabe zum FTP, Port 21).

Ich traue mich nun gar nicht zu fragen, aber gibt es denn einen rechtlich sicheren Weg wie ich selbst meine eigene Webseite und dessen Server prüfen kann? Denn die Rückmeldung der "browsable directorie" kann und möchte ich so nicht stehen lassen. Oder sollte ich das Thema abhaken und fertig ist?!

Gruß, Domi

p.s. Da ich nicht wusste ob es eher was für Linux, den Servern oder sonstigen Bereichen ist, hab ich das hier im Smalltalk unter gebracht. Wenn falsch, bitte in die korrekte Ecke verschieben :)
 
Vorweg; Rechtsauskunft kannst und solltest du nur von Anwalten beziehen.

Hier liegt laut Beschreibung ein Sonderfall vor; es ist kein eigenes Serversystem sondern das eines Kunden ABER der Kunde scheint gewillt dass ihr die Überprüfung durchführt. Damit liegt ein Auftrag vor, was die Rechtslage massiv ändert - du kannst für die Straftat des unerlaubten Zugangs ja nur bestraft werden wenn der Zugang tatsächlich unerlaubt war. Andernfalls würde bspw ein Schlüsseldienst sich für Türöffnungen für den Hausbesitzer ja auch strafbar machen.

Wichtig ist hier aber dass du schriftlich vereinbarst was du vornehmen darfst und was nicht - und dass du für Schäden oder Datenverlust aus Scans nicht haftbar bist; einige Scans verwenden gezielt "böse" Anfragen um Sicherheitslücken zu testen was Applikationen zum DoS, Absturz oder schlimmer bringen kann.

Nebenbei ist es hier eine besondere Situation dass du den "Angriff" nicht innerhalb eines Kunden-LAN durchführst sondern in einem öffentlichen Netzwerk. Hierbei musst du also sicherstellen dass die Angriffe nicht Dritte oder den RZ-Betreiber selber betreffen können. zB "Last-Tests" à la DDoS sind damit logischerweise bis auf applikative Angriffe (Slowloris, ...) ausgeschlossen.
Aber das gilt nicht nur für dich sondern auch den Kunden selber.

Angeblich sind "browsable directories" vorhanden
Am einfachsten wäre es wenn die IT des Mutterkonzerns einfach den Scan-Report raus rückt. Nessus, OpenVAS oder ähnliches wird ja zum Zug gekommen sein und die Reports sind sehr detailliert =)
 
Moin, dein "Vorweg" verstehe ich, wäre auch nicht von Nöten gewesen, denn für Rechtsauskünfte selbst hätte ich nen Rechtsanwalt zur Hand. Aber vielen Danke... kann ja auch andere Leute betreffen, und darum erwähnst du es :)

Also es ist wie folgt, wir (IT Dienstleister) haben einen Server im RZ von Hetzner gebucht, darauf läuft eine "Webapplikation" (ist ja eine Homepage) die wir für den Kunden aufgebaut haben. Die Webseite unseres Kunden wurde nun von dem Mutterkonzern geprüft (mit uns, Serverbetreiber) nicht abgesprochen und ich gehe stark davon aus dass sie Hetzner auch nicht darüber informiert haben.

An sich spricht nichts dagegen, mich interessiert so etwas ja auch... darum hatte ich ja auch geschaut, was es da so gibt und bin dann auf die rechtlichen Hürden gestoßen. Nessus oder OpenVAS hatte ich sogar schon irgendwo gelesen, alternativ hätte ich ein "kali linux" auf einem USB Stick hier, welches (wenn ich mich nicht irre) auch solche Tests durchführen kann. Wollte jetzt aber selbst nicht los schießen, den von uns gebuchten Server im RZ von Hetzner befeuern.

Dazu kommt (es ist schon über 10 Jahre her), dass ja bei solchen Tests auch "port scans" durchgeführt werden und ich weiß, dass die Telekom so etwas von den haushaltsgebräuchlichen DSL Anschlüssen nicht witzig findet :D

Aber schon mal vielen Dank für deine Anteilnahme, ich habe denen (unserem Kunden) auch gesagt, dass deren "Tool" mal ein detaillierteres Log raus rücken möchte. Zumal mich ja auch interessiert, in wie fern sie den SSH Port beanstanden... der liegt im Bereich über 10.000 und kann "nur" key auth, wurde aber wohl auch aufgeführt. Nur ist da die Frage ob das negativ von den beanstandet wurde, oder eben nicht.

Sobald ich eine genauere Information habe, würde ich noch mal Feedback geben.

Gruß, Domi
 
kann ja auch andere Leute betreffen, und darum erwähnst du es
Nebenbei auch Eigenschutz, nicht dass es als Rechtsberatung fingiert wird :p Ich meine, in einem Land wo es Kunden-Hausdurchsuchungen wegen Geldwäsche gibt, nur weil man eine Office-Lizenz im Edeka gekauft hat...

Die Webseite unseres Kunden wurde nun von dem Mutterkonzern geprüft (mit uns, Serverbetreiber) nicht abgesprochen und ich gehe stark davon aus dass sie Hetzner auch nicht darüber informiert haben.
Meistens schaut man als Anbieter über "Angriffe" des Kunden hinweg solange sie nicht beeinträchtigen. Eigentlich ist es ja lobenswert wenn sie die Sicherheit seriös nehmen wollen. Mit einer halbwegs vernünftigen WAF auf dem Server (und sei es nur 0815 mod_security mit kostenfreien Feeds von bspw Comodo) kommt aber ungeachtet der tatsächlichen Sicherheitsprobleme nicht sehr viel über HTTP durch.



Nessus oder OpenVAS hatte ich sogar schon irgendwo gelesen, alternativ hätte ich ein "kali linux" auf einem USB Stick hier, welches (wenn ich mich nicht irre) auch solche Tests durchführen kann.
Kali ist ein Paket an unterschiedlichen Werkzeugen. Openvas (Nessus Fork) ist afaik nicht vorinstalliert, dafür aber Metasploit was schon eher in Richtung Ausnutzen geht. Ich kann regelmässige Scans mit OpenVAS für alle eigenen und Managed-Systeme nur anraten, inklusive "authenticated Scan" über SSH erhält man eine sehr ausgiebige Liste bekannter Probleme mit wenigen Falscherkennungen. Der Feed ist aber ausserhalb der Community-Edition nicht unbedingt günstig.

Dazu kommt (es ist schon über 10 Jahre her), dass ja bei solchen Tests auch "port scans" durchgeführt werden und ich weiß, dass die Telekom so etwas von den haushaltsgebräuchlichen DSL Anschlüssen nicht witzig findet :D
Das Problem bei grossen Anbieter (sei es DSL-Betreiber oder ein Server) ist schlicht dass die Entsperrung entweder unmöglich oder sehr langwierig ist. Ich würde also sowas auf einem (v)Server betreiben und im Voraus abklären ob diese Nutzung erlaubt ist oder die automatischen Schutzmechanismen des Anbieters potentiell anspringen.

Zumal mich ja auch interessiert, in wie fern sie den SSH Port beanstanden... der liegt im Bereich über 10.000 und kann "nur" key auth, wurde aber wohl auch aufgeführt.
Jeder offener Port wird generell als potentielles Risiko gesehen. Portwechsel ist kein Sicherheitsgewinn sondern entfernt nur Grundrauschen.
Allerdings ist es bei Server klar dass SSH erreichbar sein muss sofern man keine alternative Lösung (internes Vlan, ...) hat.

Nicht zu vergessen ist; sichere Server gibt es nicht, die Frage ist WIE sicher der Server sein muss. Wenn du eine "standardisierte" Paranoia-Referenz für sichere Umgebungen haben willst, empfehle ich nach PCI-DSS zu scannen, bspw mit https://www.hackerguardian.com/ (ab 90$/Jahr zu haben), und einen PCI-DSS SAQ Fragebogen aus zu füllen. Wenn beides OK ist, darfst du Kreditkartendaten begrenzt verarbeiten :cool:
 
Meistens schaut man als Anbieter über "Angriffe" des Kunden hinweg solange sie nicht beeinträchtigen.
Als ich vorhin mit dem IT'ler unseres Kunden telefoniert habe, sagte ich auch "wo kein Kläger, da kein Henker" und hatte ihn halt darum gebeten, dem Mutterkonzern mal zu sagen, dass sie genauere Informationen raus rücken möchten. Es gibt ja auch nessus Essentials, dass ist auf 16 IPs begrenzt, würde für mich ja als kleiner IT'ler ausreichen und bei uns im Büro (sind auch nur ein drei Mann Verein) könnte das auch ausreichend sein.

Die nessus Professional sieht gut aus, aber da passt der Kosten- / Nutzen Faktor nicht mehr und würde uns somit auffressen. Wenn man nun als Dienstleister in die "Security" Schiene gehen möchte, würde sich dieses anbieten, aber dafür habe ich in meiner Selbstständigkeit und wir bei uns im Büro einfach nicht die Auftragslage dass sich das lohnen würde :D

Habe dennoch mal ein 7-Tage Test für die "Prof" gestartet um mal Informationen zu erhalten. Am ende kochen wir alle nur mit Wasser, nur wäre interessant was dieses Wasser gefunden hat :)

Portwechsel ist kein Sicherheitsgewinn sondern entfernt nur Grundrauschen.
Allerdings ist es bei Server klar dass SSH erreichbar sein muss sofern man keine alternative Lösung (internes Vlan, ...) hat.
Für uns im Büro hätte ich einen Plan B, da wir eine statische IP haben, wäre dies eine Option... wollte das aber vermeiden, denn es kann ja auch mal was passieren wenn ich nicht im Büro bin. Dann möchte ich schnell von zuhause via SSH auf den Server kommen, ohne das ich erst VPN ins Büro und dann RDP öffnen muss, um DANN via SSH auf die Server zu kommen. Natürlich könnte man sich auch einen ganz billigen Server bei Hetzner oder Netcup buchen, VPN darauf einrichten und diese IP von außen für SSH, SQL etc. frei geben, aber die Frage ist, ob das sein muss?! Glaube, Putty oder andere SSH Tools können sogar einen Proxy verwenden, dann müsste man nicht mal mit VPN arbeiten... aber da führen ja bekanntlich viele Wege nach Rom :)

Generell find ich das mit dem Test gar nicht doof! Es ist nur doof, wenn es heißt "da ist was" aber nicht sagt wo genau. Man selbst wird auch irgendwann "betriebsblind", versucht und macht, am Ende kommt dann doch nichts bei raus. Perfekt bin ich auch nicht, keine Frage... darum kribbelt es auch immer, wenn einer sagt "der Profi (oder Experte) ist da" und zeigt auf mich.

Nebenbei auch Eigenschutz, nicht dass es als Rechtsberatung fingiert wird :p Ich meine, in einem Land wo es Kunden-Hausdurchsuchungen wegen Geldwäsche gibt, nur weil man eine Office-Lizenz im Edeka gekauft hat...
Vollkommen verständlich, da möchte man sich schon mal im Vorfeld absichern, bevor auf einen mit dem Finger gezeigt wird ;)
 
Moin, ich bin zwar kein Fan von "Doppelposts", wollte aber mal etwas zu dem Thema schreiben :)

Nach Rücksprache mit Hetzner, darf ich auf dem Server einen "pen test" machen, die juckt es wohl nicht. Das einzige was ich bedenken möchte ist, dass mich Abuse anschreibt und ich denen das erklären soll... verständlich! Von daher, gesagt getan... Hab ja eine "Nessus Pro" für 7 Tage zum testen und hab das Teil mal über den Server drüber laufen lassen der bemängelt wurde und parallel habe ich meinen eigenen Server auch mal geprüft. Bin ja neugierig!

Mein eigener Server läuft mit ISPconfig, und die Server habe ich selbst benannt nach folgendem Schema,
- srv01.domain.tld
- srv02.domain.tld

Das interessante ist, Nessus bemängelt die Apache Default Domain. Insbesondere auf "browsable directories", nannte er mir folgende Beispiele...
- srv01.domain.tld/manual/images/
- srv01.domain.tld/manual/style/
- srv01.domain.tld/manual/style/css/

Meine vHosts haben alle die Parameter "Options -Indexes -Includes +FollowSymLinks" wobei ich den "includes" nachträglich eingefügt habe, da ich von Nessus auch die Meldung "CGI Generic SSI Injection (HTTP headers)" erhalten habe. Allerdings hat sich dieser Fehler noch gar nicht erledigt und ich bekomme ihn aktuell noch nicht weg.

Dann wird unter anderem mein SSL Zertifikat für den FTP bemängelt, weil es ja ein selbst signiertes Zertifikat ist. Da könnte ich via Letsencrypt eines erstellen und mit einem Skript das Zertifikat zusammen bauen, hab dieses aber noch nicht gemacht. Dann meldet Nessus auch "POP3 Cleartext Logins Permitted" aber da könnte ich ja SSL / TLS erzwingen, womit das Problem auch weg wäre.

Was ich jetzt noch nicht gemacht habe, Nessus alle 65.000 Ports scannen, denn mein SSH Port liegt nicht auf 22 (Stichwort Grundrauschen), da würde mich nämlich mal interessieren wie er das einordnet... Wenn er einen offenen SSH Port als "high" oder "critical" ansieht, wäre das halt eine komische Geschichte, denn dank "key auth" fühle ich mich relativ sicher :) Es ist schon 10 Jahre her, da gab es mal "port knocking" oder so ähnlich, könnte man bestimmt auch wieder einführen... sehe aber die "key auth" Variante als relativ sicher.
 
Wie du festgestellt hast bringen die Scans durchaus sinnvolles Feedback (Deaktivieren unverschlüsselter Ports, ...) aber es gibt auch "Ramsch" dazwischen wie das Kritisieren offener Ports (was generell LOW sein sollte)

Dann wird unter anderem mein SSL Zertifikat für den FTP bemängelt, weil es ja ein selbst signiertes Zertifikat ist.
Die Wahl ist dir überlassen, es bringt keinen grösseren Sicherheitsvorteil und sogar ein Sicherheitsrisiko. Da die meisten FTP-Clients inkl. Filezilla keiner CA vertrauen und in jedem Fall dich um Validierung des Zertifikates bitten bevor es als trusted angesehen wird, ist jeder Zertifikatwechsel mit einem Popup verbunde. Es würde dem Client schlicht nicht auffallen wenn jemand die LetsEncrypt CA mit MITM-Angriff fälscht, es fällt ihm aber auch wenn ein bereits vertrautes Zertifikat ausgetauscht wird.
Hier kann ein weniger oft aber dafür kommunizierter Zertifikat-Tausch sicherheitsmässig sinnvoller sein, auch wenn Nessus das generell als MEDIUM ansieht.

Es ist schon 10 Jahre her, da gab es mal "port knocking" oder so ähnlich, könnte man bestimmt auch wieder einführen...
"Security by obscurity is no security at all". Natürlich kann man es einführen, imho sinnvoller ist aber tatsächliche Versuche auf einem offenen Port zu erkennen und fail2ban-blocken und Anomalien zu melden. Dann weiss man wenigstens dass jemand versucht an zu greifen, und SSH Zeroday aussen vor... viel Spass beim Erraten eines Key.


Generell begutachte ich in meinen regelmässigen OpenVas Scans (Nessus Fork) nur HIGH und CRIT genauer, Medium sehr sporadisch.
Man darf nicht vergessen; Nessus ist kein Gutachter sondern ein Werkzeug das dir helfen soll mögliche Probleme zu finden.
 
Deinen Satz "Nessus ist kein Gutachter sondern ein Werkzeug das dir helfen soll mögliche Probleme zu finden." finde ich gut. Das ist ja ähnlich wie die Beschreibung eines Werkzeugs... Hab zwar kein 100% treffendes Beispiel, aber der Bohrer ist ja nicht dazu da um das Loch ohne dich zu bohren, sondern dazu da um es dir zu erleichtern. Also grob sinnbildlich gesprochen :)

Vielleicht schaue ich mir "OpenVas" auch noch mal an, da du dieses gerade erwähnst. Die "Nessus Essentials" Version würde aber wohl für meine Zwecke auch ausreichend sein, denke ich mal... sind ja nur ein paar Server die man ab und an mal prüfen wollen würde.

Da die meisten FTP-Clients inkl. Filezilla keiner CA vertrauen
Das wusste ich allerdings noch gar nicht und hatte da nicht so drauf geachtet... Klar, mein FlashFXP ploppt auf, weil er halt ein Zertifikat sieht und fragt "soll ich vertrauen?", aber da bin ich halt von ausgegangen dass er dieses tut, weil es selbst signiert ist. Auch FileZilla ist da aufgegangen und meldete dies... aber auch hier, gleicher Gedanke (selbst signiert!).

Was die Überwachung mittels "fail2ban" angeht, auf meinem eigenen Server habe ich die Regeln dafür sogar etwas angepasst. Der Server ist ja mittels ISPconfig aufgesetzt und irgendwann hatte ich mir dann die Regeln mal genauer angeschaut. Wenn ich mich nicht irre, erstellt fail2ban einen 'iptables' Eintrag nach dem fünften Versuch für (Beispiel) Postfix und entfernt den Eintrag nach ca. 15 Minuten wieder. Das hatte ich mal hoch geschraubt.

Bei sshd, dovecot oder dem ftpd das gleiche, aber wenn ich mir so die Logfiles anschaue, sind da halt die üblichen Verdächtigen aus dem "Ostblock". Diese haben versucht sich bei Postfix anzumelden, sind dann aber geblockt worden und seit dem ist wieder Ruhe... ist auch schon ein paar Wochen her :)

Ein Bekannter von mir, mit dem ich viel zusammen mache (durch die Selbstständigkeit) hat sich mal 'tarpit' eingerichtet um zu schauen was da passiert. Die üblichen verdächtigen auf Port 22, aber das ist ein anderes Thema und eine nette Spielerei :D

War es nicht so, dass die beste Firewall oder die beste Software nichts bringt, wenn der Mensch dahinter das System nicht bedienen kann?! :) Natürlich bin ich nicht perfekt, keine Frage... aber bis jetzt gab es keine Probleme (auf Holz klopf) und angefangen habe ich grob 2003. Da wurde man stumpf erst einmal gesteinigt, wenn man in einem Forum sagte, dass man einen eigenen Server seit kurzem besitzt und Fragen hat. Stichwort, Open Relay etc.

So, fertig mit "schwafeln" und schon mal vielen Dank für den Informationsaustausch.
 
Da wurde man stumpf erst einmal gesteinigt, wenn man in einem Forum sagte, dass man einen eigenen Server seit kurzem besitzt und Fragen hat. Stichwort, Open Relay etc.
Fast jeder von uns hat so angefangen, egal wie klug man jetzt sagt dass man es nicht machen darf :p
Üben auf einem lokalen Rechner ist doch etwas anderes als ein Server, und Paravirtualisierung war noch nicht wirklich verbreitet.

Auch FileZilla ist da aufgegangen und meldete dies... aber auch hier, gleicher Gedanke (selbst signiert!).
Direktes Zitat des Filezilla-Hauptautors dass er Chains of trust für Blödsinn hält:
"I do not trust these so-called certificate authorities. Establishing trust through monetary payment? Bah, humbug! As such FileZilla Client always presents the certificate to the user for explicit validation, regardless if it's self-signed or signed by some third party."
( https://forum.filezilla-project.org/viewtopic.php?t=11961 )

Vielleicht schaue ich mir "OpenVas" auch noch mal an, da du dieses gerade erwähnst
Entgegen dem Namen ist OpenVas mittlerweile auch kommerziell, allerdings gibt es noch eine Community-Edition mit ein paar Einschränkungen (kein Version-Update möglich, ...)
Der Haupt-Wert der Scanner-Suiten kommt natürlich aus der regelmäßigen und zeitnahen Aktualisierung der Plugins zur Erkennung neu(s)ter Sicherheitslücken.
 
Hab mir jetzt nicht alles durchgelesen aber um welche art "browsable directories" geht es? Shell, Http, Ftp??? Der Sinn eines Audits ist es eigentlich einem mitzuteilen was wo aufgedeckt wude.

Stumpf "browsable directories" zu sagen ist gleich dem als würde ich sagen "Das System akzeptiert Nutzereingaben".
 
Moin, leider hab ich deinen Kommentar erst heute gesehen... war zwar die Tage ab und an noch hier, aber da ist mir der Kommentar nicht aufgefallen. Also ich habe noch keine Rückmeldung zu den "browsable directories" erhalten. Hab auf jeden Fall alles was bemängelt wurde, zusammengefasst und meinen Senf dazu gegeben.

Eine Aussage dieses Mutterkonzerns war ja auch, dass POP3 Klartext Kennwörter akzeptiert... klar tut er das, hatte Dovecot vorsichtshalber installiert, wurde nicht gebraucht, ich hab ihn nicht deaktiviert und Accounts gibt es auch keine mit denen man sich anmelden oder einloggen könnte. Nun hab ich Dovecot gesagt "listen = 127.0.0.1" und fertig ist.

Auch wurde der offene MySQL (3306) Port bemängelt. Wobei das auch nicht viel zu sagen hat (finde ich), wenn die User die alle hinterlegt sind nur über "localhost" verbinden dürfen, wäre doch der offene 3306 "obsolet", lasse ich da aber auch gerne eines besseren belehren :)
 
Wenn Dovecot nicht benötigt wird, dann deinstalliere es. Auch wenn es nur auf localhost lauscht, kann es potentiell ein Sicherheitsrisiko darstellen. Bezüglich MySQL sollte Port 3306 nach extern nur offen sein, wenn er auch für den Zugriff von externen Systemen benötigt wird. Ansonsten an localhost binden. Auch wenn es keine User gibt, die sich von extern verbinden können, können ja ggfl. vorhandene Lücken ausgenutzt werden, die ohne Authentication übers Netz funktionieren.
 
Back
Top