SIWECOS / siwecos-business-layer

SIWECOS Main API and Business Layer Application
https://siwecos.de
0 stars 1 forks source link

Integration des Crawlers #133

Closed Lednerb closed 4 years ago

Lednerb commented 5 years ago

Crawler-Integration Thread

Dieses Issue ist ein Sammel-Thread für alle Notizen / Fragen und Belange zum Thema Integration des Crawlers.

Es sollen die 10 potentiell interessantesten URLs einer Domain zusätzlich zur Haupt-URL gescannt werden.

Für die integration gilt der folgende aktualisierte Programmablauf:

Crawler - 2019-06-30


CC @MacMic @y-ates

Lednerb commented 5 years ago

Zeitpunkt des Crawlens

Der Crawler soll einmal nach der Verifizierung der Domain gestartet werden. Es ist klug, den Crawler nach einem Zeitinterval erneut zu starten und die Liste der URLs zu aktualisieren.

Ändert sich die Liste der zu scannenden Seiten, so ist es wahrscheinlich, dass sich auch der Gesamt-Score der Domain durch die Scan-Ergebnisse ändern wird.

Hierbei sollten wir den Nutzern deutlich mitteilen, bspw. über eine E-Mail Mitteilung, dass sich die zu untersuchenden URLs geändert haben und sich dadurch der Score evtl. anpasst.

Probleme / Fragen

  1. Soll eine Mitteilung an die Nutzer erfolgen? -> Nein
  2. Nutzer einer 3rd-Party Integration (#100) müssen nicht zwangsläufig auch Nutzer von siwecos.de sein, sprich wir erhalten keine E-Mail Adresse, sodass eine Benachrichtigung nicht möglich ist. Wie soll hiermit umgegangen werden? -> 3rd-Party Problem
  3. ~Wie verbinden wir eine Mitteilung über neue URLs mit der Low-Score Benachrichtigung (#97)~
  4. Nach welchem Zeitintervall soll neu gecrawlt werden? Theoretisch könnte man täglich crawlen und die jeweils 10 interessantesten speichern. Ändert sich an der Webseite nichts, sollten die gleichen URLs vom Crawler zurückgeliefert werden und es ändert sich für den Nutzer nichts, wir schließen aber auch Scans von fehlenden Seiten (HTTP 404) und dadurch ein Abfallen des Scores aus.
Lednerb commented 5 years ago

Score-Berechnung über mehrere Scan-Ergebnisse

Ein gewichteter Score ist bereits implementiert (#125) und steht für jeden Scan zur Verfügung. Es liegt nahe, den Gesamt-Score als arithmetisches Mittel über die gesamten Scans (bei 10 vorhandenen, gerawlten URLs + Haupt-URL = 11 Scans pro Domain) zu berechnen.

Probleme / Fragen

  1. Welche Methode soll zur Berechnung des Gesamt-Scores genutzt werden?
  2. Eine Domain könnte weniger als 10 gecrawlte URLs aufweisen.
  3. Sollen fehlgeschlagene Scans mit in den Gesamt-Score einberechnet werden? Falls ja, wie?
Lednerb commented 5 years ago

Auszuführende Scanner bei gecrawlten URLs

Momentan wird in v2 der BLA und der CA vorgegangen, wie eingangs in der Grafik aufgezeigt: Die BLA sendet eine zu scannende URL an die CA und erhält ein Scan-Ergebnis zurück.

Probleme / Fragen

  1. Es gibt Scanner, die vorhersagbar jeweils die gleichen Antworten liefern werden, für jede gescannte URL. MAIL-Scanner (Für eine Domain jeweils die gleichen E-Mail-Server), TLS-Scanner (Hinter einer Domain wird jeweils der gleiche TLS-Server stehen), PORT-Scanner (gleicher Host = gleiche Ports)
  2. ~Ein Umprogrammieren der Core-API sodass nur bestimmte Scanner gestartet werden, erhöht massiv den Implementierungs- und Wartungsaufwand bei BLA und CA (die BLA muss wissen, welche Scanner vorhanden sind, welche Scanner wie gestartet werden sollen, etc; die CA muss Einzelheiten über die Scanner kennen und entscheiden, welche Scanner gestartet oder welche Ergebnisse gecached werden sollen)~
  3. ~Eine unterschiedliche Anzahl an Scannern führt bei der Score-Berechnung (siehe auch Kommentar) zu Problemen, da keine Durchschnitts-Berechnungen mehr vorgenommen werden können, ohne die Berechnung zu verzerren.~ Da alle Nicht-Haupt-URLs eine gleiche Anzahl von Scan-Ergebnissen erhalten, kann weiterhin ein gewichtetes Mittel errechnet werden, von welchem dann wiederum ein arithmetisches Mittel über alle Scan-Scores gebildet werden.

Lösungsvorschlag

~Scanner, die lediglich eine Domain (=Hostname) scannen und nicht eine URL individuell, sollten die Ergebnisse für eine Zeit von ca. 12 Stunden cachen und bei erneuter Anfrage lediglich das zwischengespeicherte Ergebnis zurückliefern, um den Zielserver nicht unnötig zu belasten und die allgemeine Scan-Zeit zu reduzieren.~

~Dadurch würden keine Änderungen an der BLA und CA im Umgang mit den Scannern erforderlich sein und die Scanner würden darüberhinaus im Einsatz außerhalb der SIWECOS-Infrastruktur eine bessere Performance aufweisen.~

Edit: Lösungsvorschlag von @SniperSister ist am besten geeignet: Die CA wird um einen optionalen Parameter erweitert, sodass nur bestimme Scanner gestartet werden können. Dies wird in der BLA hinterlegt und für URLs mit Außnahme der Haupt-URL genutzt.

Scanner, die lediglich einmal pro Domain ausgeführt werden:

SniperSister commented 5 years ago

Zeitpunkt des Crawlens Soll eine Mitteilung an die Nutzer erfolgen?

Wie verbinden wir eine Mitteilung über neue URLs mit der Low-Score Benachrichtigung Ich sehe die theoretische Möglichkeit, dass sich der Score durch die URL-Änderungen ändert, ich bin mir aber unsicher ob das Problem so groß ist, dass sich daraus die Notwendigkeit einer technischen Lösung (=Mitteilungsversand) ergibt. Vor allem im Zusammenhang mit der Low-Score-Benachrichtigung halte ich das auch technisch für nicht trivial.

Nutzer einer 3rd-Party Integration

Darum muss sich die 3rd-Party kümmern, das ist nicht unsere Baustelle.

Nach welchem Zeitintervall soll neu gecrawlt werden?

Ein mal pro Woche erscheint mir ausreichend.

Score-Berechnung über mehrere Scan-Ergebnisse Welche Methode soll zur Berechnung des Gesamt-Scores genutzt werden? Arithmetisches Mittel über die gesamten Scans (bei 10 vorhandenen, gerawlten URLs + Haupt-URL = 11 Scans pro Domain)

Eine Domain könnte weniger als 10 gecrawlte URLs aufweisen.

Kein Problem, wir verwenden ja den Durchschnitt

Sollen fehlgeschlagene Scans mit in den Gesamt-Score einberechnet werden? Falls ja, wie?

Wie behandeln wir das beim Score eines individuellen Scans? Analog sollte es imho dann auch beim Gesamtscore sein

Auszuführende Scanner bei gecrawlten URLs

Wir sind uns alle einig, dass die CA eine klare Aufgabenstellung hat: Auftrag erhalten, Scans dispatchen, Result zurückmelden. Gleiches gilt für die Scanner, auch hier ist die Aufgabe klar: Auftrag erhalten, Auftrag abarbeiten, Result zurückmelden. Die BLA aber soll ja genau den Teil der Businesslogik realisieren, der SIWECOS auszeichnet – und das schließt für mich die Frage, welche Scanner bei welcher URL-Art getriggert werden müssen, mit ein. Ich würde daher eher vorschlagen, der CA eine kleine Erweiterung zu verpassen, mit der die BLA auf Wunsch die zu verwendenden Scanner angeben kann. Die BLA kann dann, je nach URL-Art unterschiedliche Scanner ansprechen.

Skeeve commented 5 years ago

Frage zum "gewichteten Mittel" @Lednerb: Was meinst Du damit? Ich habe nur gefunden, daß ein Score bei 20 gekappt wird, sobald ein "Critical" gefunden wird. Meintest Du das damit?

Ich habe gewichtetes Mittel eher so verstanden:

  1. Jeder Scanner hat ein "Gewicht" G(s), das in BLA hinterlegt ist
  2. Jeder Scanner liefert für eine Domain einen Score S(s, d)
  3. Der Gesamtscore einer Domain berechnet sich zu Summe( G(s) * S(s, d) ) / Summe( G(s) )
Lednerb commented 5 years ago

@Skeeve ist genau so integriert:

https://github.com/SIWECOS/siwecos-business-layer/blob/1435fee724f8612fa92457d12f815fdd76bcf54a/app/Scan.php#L78-L103

Gewicht des Scanners lässt sich über Umgebungsvariablen anpassen, standardmäßig auf 1 für alle Scanner:

https://github.com/SIWECOS/siwecos-business-layer/blob/1435fee724f8612fa92457d12f815fdd76bcf54a/config/siwecos.php#L87-L108

Lednerb commented 5 years ago

Durch @ic0ns Anpassungen und Erweiterungen des DomainValidators ist es möglich, komplett auf den siwecos-crawler zu verzichten.

Hierdurch sparen wir uns ein Modul zur Integration. Der DomainValidator wird in jedem Fall benötigt, da dort die entsprechenden MX-Domain-Einträge für den Mail-Scanner extrahiert werden müssen.

Der neue Ablauf wäre daher wie folgt:

SIWECOS-DomainValidator

Lednerb commented 4 years ago

Fahrplan zum Abschluss

Lednerb commented 4 years ago

Arbeiten sind abgeschlossen soweit.

@SniperSister Die webapp kann nun in production aktualisiert werden und somit dann das neue Frontend veröffentlicht werden.