Penetration Test

[bluestar]

Wenn *du* das aber selbst so eingerichtet hast, wirst *du* das Problem nicht mit Software finden, weil du ja gar nicht weißt, nach was du suchst.

Ich möchte das nochmal herausgestellt haben, weil genau dieser Gedankengang zu meiner initialen Antwort geführt hat.

Deine Argumentation ist vollkommen schlüssig und verständlich...
Schauen wir mal ob der TE anderer Meinung ist.

[Meillo]

Wenn es sich um ein wichtiges System handelt, fuer das man bereit ist Geld zu investieren, dann sollte man, wie niemand bereits vorgeschlagen hat, serioese Profis engagieren.

Andernfalls ist es am besten, sich selber zu informieren, dazuzulernen, Softwarehelferlein einzurichten, etc. Das bedarf Ernsthaftigkeit, Zeit und Lernaufwand. Man sollte zumindest mit der Geisteshaltung herangehen, rauszuinfinden, welche Blinden Flecken man haben koennte. Das ist natuerlich schwierig, aber wenn man kein Geld investieren will ist es wohl das Beste was man tun kann.

[reox]

Wenn *du* das aber selbst so eingerichtet hast, wirst *du* das Problem nicht mit Software finden, weil du ja gar nicht weißt, nach was du suchst.

Das ist zwar so vollkommen richtig, aber es gibt ja durchaus so Auditierungs - ich sag mal - Fragebögen, in denen man einfach nur nach Schema F vorgehen muss.
Bei uns wurde mal so eine App "pentested". Am Ende haben wir eine Excel Tabelle mit den Ergebnissen bekommen. Wirklich angestrengt haben die sich nicht
Sie haben den OWASP guide genommen und Punkt für Punkt abgearbeitet, ein paar Screenshots dazu und fertig.
Also es gibt ja durchaus Tools die einem nachher alles mögliche ausspucken. Wichtig ist dann, das man weiß was die Dinge bedeuten - denn auch eine Warnung kann mal kritisch sein und ein Kritischer Fehler manchmal unnötig zum ansehen.
Die größte Arbeit war dann denen zurück zuschreiben warum die x "kritischen Fehler" die sie da gefunden haben sowieso alle mitigiert waren.
Im Übrigen schlägt das gut den Bogen zu Firmen die sowas verkaufen. Meistens machen die eh a nix anderes. Die nehmen ein Auditierungsschema her, fahren mit ihrem Script da drüber und man bekommt einen hübschen bunten Auditierungsreport. Was man dann mit den Informationen anfängt ist meistens einem selber überlassen, außer die Firma verkauft auch gleich die Beratung mit dazu Dann kann es aber von schon teuer auf richtig teuer gehen (aus Haftungsgründen werden solche Firmen in so ein Dokument nur gegen Aufpreis reinschreiben was du tun sollst - wenn überhaupt bekommst du ne Empfehlung was du tun kannst) Ist jedenfalls meine Erfahrung damit.

[TRex]

Hab ich auch schon anders erlebt (Angriffsfläche gefunden und ausgelöffelt), ich würde das nicht pauschalisieren. Die ganzen low hanging fruits mit dem automatisierten Scanergebnissen waren da natürlich auch dabei, aber das bringt halt in 90% der Fälle keinen echten Gewinn.

[MSfree]

Sie haben den OWASP guide genommen...

Man könnte meinen, Hauptsache mal was auditiert.

Das schöne an so eine Schema-F für die Cracker ist, daß sie dann genau wissen, wo sie nicht anzugreifen brauchen.

[Meillo]

Egal wie man es dreht und wendet: Es ist ein Best-Effort-Vorgehen. Vollstaendige Sicherheit gibt es nicht, also gilt es moeglichst viele Sicherheitsprobleme zu vermeiden. Mit wenig Aufwand (z.B. Checklisten) die einfachsten Luecken zu schliessen ist schonmal gut. Dann kann man inkrementell mehr Aufwand/Zeit/Geld rein investieren. An welchem Punkt man aufhoert muss jeder fuer sich selber entscheiden. Aber egal wie weit man geht, einem gezielten Angriff von Profis, die wirklich reinkommen wollen, wird das System kaum standhalten. Das ist fuer die meisten Systeme aber auch nicht relevant. Wichtig ist aber, dass keine offensichtlichen Loecher offen sind.

Und man koennte sich auch ueberlegen:

1) Wie man erkennt, ob das eigene System geknackt ist.
2) Was man tut, wenn das System geknackt ist.

Diese Fragen zu bearbeiten erscheint mir ab einem gewissen Punkt sinnvoller als zu noch ein bisschen mehr abzusichern zu versuchen.

[reox]

Hab ich auch schon anders erlebt (Angriffsfläche gefunden und ausgelöffelt), ich würde das nicht pauschalisieren. Die ganzen low hanging fruits mit dem automatisierten Scanergebnissen waren da natürlich auch dabei, aber das bringt halt in 90% der Fälle keinen echten Gewinn.

Ja das stimmt. Gibt genug Firmen die das ganze auch ernsthaft betreiben. Man darf sich aber über deren Preise auch nicht wundern

Sie haben den OWASP guide genommen...

Man könnte meinen, Hauptsache mal was auditiert.

Ich war da nicht viel involviert aber irgendwie war das so, dass sie genau das machen mussten um irgendeine Zertifizierung zu bekommen die vorgeschrieben hat nach welchen Richtilinien ... Also ja, hauptsache irgendwas auditieren triffts da ziemlich gut

[HZB]

Ich war da nicht viel involviert aber irgendwie war das so, dass sie genau das machen mussten um irgendeine Zertifizierung zu bekommen die vorgeschrieben hat nach welchen Richtilinien ... Also ja, hauptsache irgendwas auditieren triffts da ziemlich gut

Ich behaupt mal das dies einer der Hauptgründe für die meisten solcher Tests ist. ISAE3402, ....
Irgendwer war halt schlau und hat bei einer Definition des internen IKS einen jährlichen PEN Test für Applikation X reingenommen.
Die Prüfer ( KPMG, PwC, ... ) schlagen so etwas selbst vor. Das kommt immer besonders gut an.
Sinnhaftigkeit lasse ich dahingestellt. Aber man muss zugeben, wenn man dann so einen Report liest klingt das schon sehr sexy. Die goße KPMG bestätigt das Service X / Applikation Y welches jährlich seitens eines unabhängigen Audits kontrolliert wird. Jeder der sich nicht mit IT Sicherheit beschäftigt wird das gut finden. Jeder der sich mit IT Sicherheit beschäftigt weiß, dass es sich hierbei meist um Augenauswischerei handelt.

Jede Firma ( oder viele davon ) die auf Security wert legen haben eigene Abteilung die hier am Werk sind ( Red Team / Blue Team, SIEM, etc pp ).

Meine Meinung

[Meillo]

Jeder der sich nicht mit IT Sicherheit beschäftigt wird das gut finden. Jeder der sich mit IT Sicherheit beschäftigt weiß, dass es sich hierbei meist um Augenauswischerei handelt.

Das kenne ich so auch: Es wird eine ganze Menge Papier erzeugt, getan wird aber nichts (man dreht sich die Antworten eher so zurecht, dass es im Report gut aussieht). Am Ende ist das dann noch schlimmer, weil die Systeme weiterhin unsicher sind, man sich nun aber sicherer fuehlt.

Dieses Zeug sollte man IMO klar abgrenzen, von dem um was es in diesem Thread eigentlich ging: Die Sicherheit wirklich zu erhoehen, egal auf welchem Weg. Zertifizierungen wuerde hierbei nur nuetzliche Checklisten liefern, mit denen man seine eigenen Blinden Flecken aufspueren kann.

[TRex]

Und man koennte sich auch ueberlegen:

1) Wie man erkennt, ob das eigene System geknackt ist.
2) Was man tut, wenn das System geknackt ist.

Diese Fragen zu bearbeiten erscheint mir ab einem gewissen Punkt sinnvoller als zu noch ein bisschen mehr abzusichern zu versuchen.

Ich kenn das andersrum:

* Was biete ich an? (offene Ports, Schnittstellen von und nach (!) außen)
* welche Daten fließen darüber?
* sind diese Schnittstellen gesichert (TLS, Authentifizierung), Authorisierung (gut abgeklärt und Prozess klar, wie da Änderungen reinkommen)
* welche Art von Daten fließen und sehr abgekürzt, sind Daten von Code separiert? (injection attack vector)

usw. - also wenn man dann ne Schnittstelle identifiziert hat, beispielsweise Beiträge im Forum erstellen, Meillo's Suchfunktion in seinem Blog oder SSH-Login, dann muss man sich alle Eigenschaften ansehen und versuchen, mit den richtigen Fragen die Angriffsvektoren zu skizzieren und abzusichern.

[HZB]

Und man koennte sich auch ueberlegen:

1) Wie man erkennt, ob das eigene System geknackt ist.
2) Was man tut, wenn das System geknackt ist.

Diese Fragen zu bearbeiten erscheint mir ab einem gewissen Punkt sinnvoller als zu noch ein bisschen mehr abzusichern zu versuchen.

Ich kenn das andersrum:

* Was biete ich an? (offene Ports, Schnittstellen von und nach (!) außen)
* welche Daten fließen darüber?
* sind diese Schnittstellen gesichert (TLS, Authentifizierung), Authorisierung (gut abgeklärt und Prozess klar, wie da Änderungen reinkommen)
* welche Art von Daten fließen und sehr abgekürzt, sind Daten von Code separiert? (injection attack vector)

usw. - also wenn man dann ne Schnittstelle identifiziert hat, beispielsweise Beiträge im Forum erstellen, Meillo's Suchfunktion in seinem Blog oder SSH-Login, dann muss man sich alle Eigenschaften ansehen und versuchen, mit den richtigen Fragen die Angriffsvektoren zu skizzieren und abzusichern.

Ja das wäre die richtige Vorgehensweise BEVOR man überhaupt das Service online schaltet.
Also erst mal überlegen, dann implementieren, dann testen, dann nachbessern, wieder testen, bis man aus eigener Sicht ( und Wissen ) das Endprodukt für in Ordnung befindet.
Erst dann sollte man online gehen. Aber wie viele, gerade im privaten Umfeld machen das schon.

Und nachdem der TE eher ein Hobbybastler ist ( siehe Thread - ich hab jetzt einen Server, was kann ich damit überhaupt machen ), wird halt einfach mal los installiert.
Ohne Hintergrundwissen, mit der erst besten Anleitung. Der Grundansatz sich über Sicherheit generell Gedanken zu machen ist dennoch löblich.

[Meillo]

Und man koennte sich auch ueberlegen:

1) Wie man erkennt, ob das eigene System geknackt ist.
2) Was man tut, wenn das System geknackt ist.

Diese Fragen zu bearbeiten erscheint mir ab einem gewissen Punkt sinnvoller als zu noch ein bisschen mehr abzusichern zu versuchen.

Ich kenn das andersrum:

* Was biete ich an? (offene Ports, Schnittstellen von und nach (!) außen)
* welche Daten fließen darüber?
* sind diese Schnittstellen gesichert (TLS, Authentifizierung), Authorisierung (gut abgeklärt und Prozess klar, wie da Änderungen reinkommen)
* welche Art von Daten fließen und sehr abgekürzt, sind Daten von Code separiert? (injection attack vector)

usw. - also wenn man dann ne Schnittstelle identifiziert hat, beispielsweise Beiträge im Forum erstellen, Meillo's Suchfunktion in seinem Blog oder SSH-Login, dann muss man sich alle Eigenschaften ansehen und versuchen, mit den richtigen Fragen die Angriffsvektoren zu skizzieren und abzusichern.

Das ist der strukturierte vorwaertsgerichtete Ansatz. Der macht grundsaetzlich Sinn. Man muss sich aber bewusst machen, dass man nie alle Luecken schliessen wird. Es kann sein, dass man trotz aller Sorgfalt etwas uebersieht. Es kann sein, dass die Programme Luecken haben. Die Grenzlinie zu zu machen ist gut, aber nur auf sie zu vertrauen ist nicht die beste Defensivstrategie.

Ich sage mal provokativ: Schlimmer als eine Sicherheitsluecke zu haben ist es einen erfolgreichen Angriff nicht zu erkennen.

Auch dem Notfallplan fuer den Fall eines (egal wie unwahrscheinlichen) erfolgreichen Angriffs wuerde ich einige Bedeutung geben.

Sicherheitsluecken sind weniger schlimm, wenn man Angriffe gleich erkennt und das System anschliessend wieder in einen definierten Zustand zurueckfuehren kann. Das bedeutet nicht, dass man die Aussenhuelle nicht moeglichst dicht halten sollte, diese Aspekte sind *auch* wichtig. Man sollte sie nicht vernachlaessigen.

Sicherheit sollte man nicht zu absolut und mathematisch begreifen, weil es in der Praxis einige Faktoren gibt, die diese Denkweise sprengen. Auch gegen die sollte man sich absichern, indem man -- parallel zu einer strukturierten Absicherung nach Lehrbuch -- weitere Fangnetze baut, in der Sichtweise eines Misstrauens gegen sich selber. Wie wenn eine Person versucht das System sicher zu machen und eine zweite Person, die an den Kompetenzen der ersten zweifelt, versucht moeglichst viel dafuer zu tun, dass es nicht schlimm ist, wenn die Muehen der ersten Person unzureichend sind. Das ist IMO praxisnah, schliesslich sind wir uns ja einig, dass die meisten Sicherheitprobleme menschliche Faktoren sind. Gegen die hilft der strukturierte Lehrbuchansatz nicht vollstaendig.