[PYTHON] Version 2019: Trendanalyse für nicht autorisierten Zugriff (Beispiel eines Allzweckservers in der Cloud)

Einführung

Dieser Artikel wurde von unseren Ciscos-Kollegen als Tag 23 von Cisco Systems Japan Adventskalender 2018 </ B> </ font> veröffentlicht.

Ausgabe 2017 </ B>: https://qiita.com/advent-calendar/2017/cisco Ausgabe 2018 </ B>: https://qiita.com/advent-calendar/2018/cisco Ausgabe 2019 </ B>: https://qiita.com/advent-calendar/2019/cisco

Ich denke, es gibt viele Netzwerk- / Infrastruktur- / Serveringenieure, die Heimlabore bauen. Auf diese Weise hatte ich mehrere Jahre lang eine tatsächliche Maschine zu Hause, aber vor ungefähr anderthalb Jahren hatte ich keine Geräte mehr zu Hause und wechselte zu mehreren Cloud-Diensten. Es ist fast ein Jahr her, seit ich einige Software- und Verwaltungstools ausprobiert habe, um den Server zu stärken, und ihn schließlich losgelassen habe, während ich die Einstellungen wiederholt geändert habe. Daher war dies im letzten Jahr illegal Ich möchte die Zugangstrends zusammenfassen.

Das in diesem Eintrag behandelte Thema ist " Ausgabe 2019: Trendanalyse für nicht autorisierten Zugriff (Beispiel eines Allzweckservers in der Cloud) </ B>". In diesem,

  • Jährliche Statistik über nicht autorisierten Zugriff </ font> </ B>
  • Umgebungsannahmen und Fail2ban-Optimierungsbeispiel </ font> </ B>
  • Tipps zur Untersuchung böswilliger Punkte bei nicht autorisierten Zugriffsverbindungsquellen (Umbrella Investigate API) </ font> </ B>

Ich werde die drei Hauptpunkte von zusammenfassen. Als die Zeit seit der Veröffentlichung des Adventskalenders im Jahr 2018 verging, war es ein Thema, das ich eines Tages als Geschichte zusammenfassen wollte.

Jährliche Statistik über nicht autorisierten Zugriff </ font>

--Zeitraum

  • 2019/01/01 ~ 2019/11/31 --Artikel
  • Monatliche Anzahl nicht autorisierter ssh-Zugriffsversuche (von ssh-sasl gesperrt) </ B>
  • Monatliche SSH-Root-Anmeldeversuche (Root-Anmeldung fehlgeschlagen) </ B>
  • Monatliche Postfix-Anzahl nicht autorisierter Zugriffsversuche (von postfix-sasl gesperrt) </ B>
  • Durchschnitt der monatlichen Ban Table-Einträge (ssh, postfix) </ B>
  • Anzahl der nicht autorisierten ssh-Zugriffsversuche nach Zeit (von ssh-sasl gesperrt) </ B>
  • Ländercode für nicht autorisierten Zugriffsquellen Top26 </ B>
  • Monatliche nicht autorisierte Zugriffsquelle IP-Adresse Domain Reverse Lookup möglich </ B>
  • SSH-Konto Top20 </ B>
  • Taubenschlag-Konto Top14 </ B>
  • Nicht autorisierte Zugriffsquelle RiskScore (insgesamt) </ B>
  • Nicht autorisierte Zugriffsquelle RiskScore (Japan) </ B>
  • Postfix RBL-Zugriffsverletzungsstatistik </ B> --Statistische Quelldaten & Tool -Aktionsmail gesendet von fail2ban </ B> (Mail gesendet von Aktion bei Verbot) -Statistische Berichte, die von logwatch </ B> gesendet werden (/ vat / log / maillog, / var / log / Secure, / var / log / messages, / var / log / dovecot / dovecot.log)
  • Cisco Umbrella Investigate </ B> (zur Untersuchung der böswilligen Bewertung von nicht autorisierten Zugriffsquellen (RiskScore))

Monatliche nicht autorisierte SSH-Zugriffsversuche (von ssh-sasl gesperrt), monatliche SSH-Root-Anmeldeversuche (Root-Anmeldung fehlgeschlagen)

1-1.png 1-2.png Monatliche nicht autorisierte SSH-Zugriffsversuche und monatliche SSH-Root-Konto-Versuche während der 12 Monate des Zeitraums.

Aufgrund der Einstellung fail2ban / iptables kann die Quell-IP-Adresse, die innerhalb von 1800 Sekunden dreimal fehlgeschlagen ist, mindestens 36000 Sekunden (10 Tage) lang nicht erneut verbunden werden. Die Anzahl der nicht autorisierten Zugriffsversuche in diesem Diagramm gibt die Anzahl der ersten und zweiten Zugriffe an, bei denen ein Round-Robin-Angriff fast automatisch ausgeführt wird. Normalerweise wird in einem System ohne solche Zugriffskontrolle davon ausgegangen, dass eine große Menge an Zugriff mit unterschiedlichen Ziffern durchgeführt wird.

Vor Dezember 2018 haben wir häufig den Strom abgeschaltet, um die Umwelt zu verbessern, und um November 2018 wurde der kontinuierliche Betrieb in vollem Umfang aufgenommen. Seitdem hat die Anzahl der SSH-Zugriffsversuche zugenommen, aber seit Mai 2019 hat sich die Anzahl der Zugriffe auf einmal verringert.

Monatliche Postfix-Anzahl nicht autorisierter Zugriffsversuche (durch postfix-sasl gesperrt), monatlicher Durchschnitt der Ban-Table-Einträge (ssh, postfix)

2-1.png 2-2.png Monatliche Postfix-Authentifizierung nicht autorisierte Zugriffsversuche während der 12 Monate des Zeitraums und monatliche Durchschnittswerte der aktiven Ban-Tabelle.

In diesem Zielsystem wird SMTP-AUTH als Teil der Maßnahmen gegen Relay von Drittanbietern beim Senden von E-Mails per Postfix aktiviert. Das Maillog zählt, wie oft dieser SMTP-AUTH-Versuch fehlgeschlagen ist. Wie bei ssh wird die IP-Adresse der Verbindungsquelle, die innerhalb von 5400 Sekunden zweimal fehlgeschlagen ist, in iptables eingegeben, sodass ein Authentifizierungsfehler zum Zeitpunkt der ersten Verbindung als Ziel ausgewählt wird. Obwohl die Gesamtzahl erheblich kleiner als die von ssh ist, kann bestätigt werden, dass die Gesamtzahl ab dem Zeitpunkt, an dem der Zugriff auf ssh abnimmt, allmählich zunimmt.

Ban Table-Einträge sind das Ergebnis von Festkomma-Beobachtungen der Gesamtzahl der von logwatch (3 Uhr morgens) gemeldeten ssh- und postfix Active Banned Table-Einträge. Sie können sehen, dass es proportional zur Anzahl der SSH-Zugriffe ist.

Anzahl der nicht autorisierten ssh-Zugriffsversuche nach Zeit (von ssh-sasl gesperrt)

3.png Dies ist die Häufigkeit des Auftretens von nicht autorisierten SSH-Zugriffsereignissen nach japanischer Zeit während der 12 Monate des Zeitraums. Nicht autorisierter Zugriff auf den Mail-Dienst wird nicht gezählt.

Die Anzahl der Zugriffe nach japanischer Zeit ist nicht verzerrt. Es wird angenommen, dass es fast mechanisch von Zugangsquellen auf der ganzen Welt ausgeführt wird.

Nicht autorisierter Zugriff Quellland-Ländercode Top26

4.png Es ist das Top-26-Land (bis Japan dazu gehört) der Verbindungsquellen für ssh-Ereignisse mit nicht autorisiertem Zugriff während der 12 Monate des Zeitraums. Nicht autorisierter Zugriff auf den Mail-Dienst wird nicht gezählt.

Überwiegend China </ font> </ B>, Amerika </ font> </ B>, gefolgt von Sie können sehen, dass es viele Zugriffe von B> Frankreich </ font> </ B> gibt.

Monatliche IP-Adresse der nicht autorisierten Zugriffsquelle Domain Reverse Lookup möglich

5.png Die monatliche Anzahl der nicht autorisierten SSH-Zugriffsversuche in 12 Monaten innerhalb des Zeitraums ( blaue vertikale Linie </ font> entspricht der vorherigen Grafik </ B> der monatlichen Anzahl der nicht autorisierten SSH-Zugriffsversuche </ B>). Dies ist ein Vergleich mit der IP-Adresse, mit der die Hostdomäne von der IP-Adresse der Verbindungsquelle umgekehrt werden konnte.

Bei allen nicht autorisierten 65507 ssh-Zugriffsversuchen hatten 43% der IP-Adressen der Verbindungsquelle einen registrierten vollqualifizierten Domänennamen. Es gibt keinen großen Unterschied in der monatlichen Quote. (39% ~ 43%)

SSH-Konto Top20, Taubenschlag-Konto Top14

6.png Dies ist eine Tabelle mit den höchsten Nutzungsraten von Nicht-Root-Konten, die verwendet werden, um den unbefugten Zugriff auf SSH- und Mail-Dienste während der 12 Monate des Zeitraums zu erzwingen.

Es gibt viele Konten, die man sich vorstellen kann, dass ssh leicht erstellt werden kann, und es gibt eine Tendenz in der Häufigkeit. In Dovecot und Postfix können viele Zugriffe mit einzelnen Konten bestätigt werden, die weniger voreingenommen sind und nicht in der Grafik angezeigt werden und weniger häufig verwendet werden.

Nicht autorisierte Zugriffsquelle RiskScore (insgesamt), Nicht autorisierte Zugriffsquelle RiskScore (Japan)

7-1.png 7-2.png Verteilung von Predictive Severity Assessment (RiskScore) </ B> durch Cisco Umbrella Investigate </ B> aus nicht autorisierten SSH-Zugriffsquellen über einen Zeitraum von 12 Monaten.

Ich habe versucht, es aus Umbrella Investigate als Reputationsinformationen der Verbindungsquelle zu extrahieren, die betrügerische Aktivitäten ausführt. Die Punktzahl ist 0-100, 100 ist die höchste Punktzahl. Sie können sehen, dass die meisten Quellen mit relativ guten Ergebnissen sind.

Postfix RBL-Zugriffsverletzungsstatistik

8.png Postfix-Verbindungsverletzungsstatistik nach RBL-Regeln für 12 Monate innerhalb des Zeitraums.

  • RBL: 1 </ B>: Reputationsprüfung durch zen.spamhaus.org
  • RBL: 2 </ B>: Reputationsprüfung durch bl.spamcop.net
  • No Service : Name or service not known
  • No Address : Address not listed for hostname

Ich habe zen.spamhaus.org, bl.spamcop.net als Junk Mail Source Reputation Blacklist RBL (Echtzeit-Blackhole-Liste) festgelegt, die diese Liste beim Herstellen einer Verbindung mit MTA überprüft und die der Liste entsprechenden Verbindungsquellen ablehnt. Machen. Die Anzahl der Treffer auf zen.spamhaus.org wird im Juni 2019 bzw. Oktober 2019 erhöht.

Umgebungsannahmen und Fail2ban-Optimierungsbeispiel </ font>

Dies ist eine Voraussetzung für jährliche Statistiken über nicht autorisierten Zugriff. Die Anzahl selbst, die im Diagramm der Statistiken über nicht autorisierte Zugriffe angezeigt wird, ist nicht die Gesamtzahl der Zugriffsversuche, sondern das Analyseergebnis, nachdem es vom verwendeten Tool ausreichend gefiltert wurde. Lassen Sie uns einige der Bedingungen klären.

Zusätzlich zu ssh werden auf dem zu analysierenden System eine Remotedesktopumgebung mit XRDP + GNOME und ein Mail-Dienst mit Postfix + Dovecot erstellt. Wir verwenden keine anderen Dienste wie Webserver. Offene Ports sind 22 / tcp (ssh) </ B>, 25 / tcp (SMTP) </ B>, 993 / tcp (imaps) </ B>, 995 / tcp (pop3s) </ B>, 3389 / tcp (RDP) </ B>.

Der Remotedesktopdienst wird einfach durch statische Iptables geschützt, die die Verbindungsquelle sperren, und die SSH- und Mail-Dienste verwenden fail2ban </ B>, um dynamische Iptables-Einträge gemäß den angegebenen Regeln zu registrieren und zu schützen. Das Ergebnis wird jedes Mal an die E-Mail gesendet, wenn die gesperrte Tabelle von fail2ban eingegeben wird, das Sicherheitsereignis wird alle 24 Intervalle analysiert und das Ergebnis wird von logwatch </ B> gesendet. Jeder Dienst verwendet keine erweiterten Tools wie IPS / IDS, um Schwachstellen zu beheben, sofern diese regelmäßig aktualisiert werden. Dieses Mal besteht der Hauptzweck darin, die Tendenz eines nicht autorisierten Zugriffs basierend auf den Informationen auszugeben, die von diesem traditionellen fail2ban </ B> blockiert werden.

fail2ban fail2ban ist überhaupt kein neues Tool. Die Protokolldatei, die durch die Einstellung angegeben wird, die nicht autorisierten Zugriff auf den Dienst meldet, z. B. "/ var / log / apache / error_log", wird in Echtzeit gescannt, und die IP-Adresse der Verbindungsquelle basiert auf dem böswilligen Vorzeichen in der Protokolldatei. Das Verbot (automatisches Hinzufügen / Aktualisieren von iptables) der Adresse zum angegebenen Zeitpunkt schützt das System vor dem Versagen des Anmeldekennworts und der Verwendung von Exploit. Fail2ban funktioniert zwar gut, um die Häufigkeit wiederholter Versuche wie des Brutefoce-Angriffs zu verringern, verringert jedoch nicht den Zugriff auf die schwache Authentifizierung selbst.

jail.local Verhindern Sie im Fall von ssh, dass aufeinanderfolgende "Fehlgeschlagene Passwörter" von derselben IP-Adresse an "/ var / log / Secure" ausgegeben werden, und im Fall von Postfix die aufeinanderfolgende "Login-Authentifizierung fehlgeschlagen" von derselben IP-Adresse so weit wie möglich. Passen Sie die Einstellung für eine Weile an, um die Ausgabe von / var / log / mail / maillog und schließlich findtime = 1800 / maxentry = 3 bzw. findtime = 5400 /maxentry = 2 zu verhindern. Ich bin zu dem Schluss gekommen, dassdas Beste ist. Mit anderen Worten, wenn im Fall von Postfix innerhalb von 90 Minuten dreimal ein Anmeldefehler von derselben Verbindungsquelle auftritt, wird dieser auf Ban gesetzt. In vielen Fällen versuchten sie, innerhalb von 17 bis 18 Minuten erneut auf dieselbe Quelle zuzugreifen.

jail.local


[DEFAULT]
ignoreip = x.x.x.0/24
backend = polling
bantime = 360000
maxretry= 3
usedns = yes

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
         sendmail-whois[name=ssh-sasl, dest=root, [email protected]]
logpath = /var/log/secure
findtime = 1800

[sasl-iptables]
enabled = true
filter = postfix-sasl
action = iptables-multiport[name=postfix-sasl, port="smtp,smtps", protocol=tcp]
         sendmail-whois[name=postfix-sasl, dest=root, [email protected]]
logpath = /var/log/mail/maillog
maxretry= 2
findtime = 5400

Tipps zur Untersuchung böswilliger Punkte durch nicht autorisierte Zugriffsverbindungsquelle (Umbrella Investigate API) </ font>

Cisco Umbrella Investigate Umbrella </ B> verwendet Public Recursive DNS, um potenzielle bösartige Domänen und IP-Adressen zu bewerten, die automatisch aus mehr als 180 Milliarden Anfragen pro Tag als prädiktive Indikatoren analysiert werden. Die statistische Sicherheitsanalyse für diese DNS- und IP-Adressen ist eine Funktion von Umbrella Investigate </ B>, und Score-Informationen können aus vielen Perspektiven abgerufen werden. Für diese bestimmte Domäne generierte Scores und IP-Adressen können von fortgeschrittenen Sicherheitsbetreibern und Sicherheitsforschern in erster Linie verwendet werden, um Vorhersageanalysen zu unterstützen und Informationen zu Netzwerkaktivitäten zu finden, die als verdächtig gelten. Ist möglich.

Umbrella Investigate Risk Score Der Umbrella Investigate Risk Score ist ein prädiktiver potenzieller Score im Bereich von 0 bis 100, der auf den lexikalischen Merkmalen von Domainnamen (Zusammensetzungszeichenfolgen), Domainabfragen an die Umbrella-Infrastruktur und der Analyse von Anforderungsmustern basiert. Dieser Wert ist nicht unbedingt direkt mit dem Malignitätsurteil aufgrund früherer betrügerischer Aktivitäten verbunden, sondern wird als prognostizierter Risikowert positioniert. Diese Informationen werden auch in Bezug auf frühere Botnet-, Phishing-Domains-, Malvertising- und Ransomware-Informationen zu den untersuchten Informationen verknüpft und bewertet.

pyinvestigate (Umbrella Investigate API Python-Modul)

Umbrella Investigate wurde als Information zur Risikobewertung von Statistiken über nicht autorisierte Zugriffsinformationen verwendet. Umbrella Investigate kann sowohl von der REST-API als auch von der Web-Benutzeroberfläche abgefragt werden. Wir haben pyinvestigate </ B> verwendet, ein Python-Modul für Umbrella Investigate, um gemeinsam RiskScore von der REST-API von mehr als 65.000 erworbenen nicht autorisierten Zugriffsquellen-IP-Adressen und Host-FQDNs abzurufen.

1. Installieren Sie pyinvestigate

# pip3 install investigate
# pip3 install pytest
# pip3 install pytest-django
# pip3 install pytest-pythonpath

2. Untersuchen Sie die API-Schlüsselerfassung

  • Melden Sie sich bei https: // dashboard.umbrella.com / an --Investigate> Navigieren Sie zu Investigate API Access
  • CREATE NEW TOKEN Token.png Token2.png Beziehen Sie sich auf das erstellte Token und kopieren Sie es

3. Führen Sie pyinvestigate aus

pyinvestigate kann über den Python-Interpreter ausgeführt werden. Geben Sie den kopierten API-Schlüssel an und fragen Sie die IP-Adresse / Domäne der Forschung ab. Für die Untersuchung nicht autorisierten Zugriffs wird ein separates Skript erstellt und in einem Stapel erfasst.

# python36

Python 3.6.8 (default, Aug 10 2019, 06:52:10)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-23)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import investigate

>>> import datetime
>>> api_key = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
>>> inv = investigate.Investigate(api_key)
>>>
>>> inv.risk_score('xxx.com')
{'features': [{'feature': 'Geo Popularity Score', 'normalizedScore': 50, 'score': 0}, {'feature': 'Keyword Score', 'normalizedScore': 26, 'score': 0.26108091120959626}, {'feature': 'Lexical', 'normalizedScore': 89, 'score': 0.898}, {'feature': 'Popularity 1 Day', 'normalizedScore': None, 'score': None}, {'feature': 'Popularity 30 Day', 'normalizedScore': None, 'score': None}, {'feature': 'Popularity 7 Day', 'normalizedScore': None, 'score': None}, {'feature': 'Popularity 90 Day', 'normalizedScore': None, 'score': None}, {'feature': 'TLD Rank Score', 'normalizedScore': 0, 'score': 0.007835250367488503}, {'feature': 'Umbrella Block Status', 'normalizedScore': 0, 'score': False}], 'riskScore': 71}
>>>

{'features': [{'feature': 'Geo Popularity Score', 'normalizedScore': 3, 'score': -3.1797661699999997}, {'feature': 'Keyword Score', 'normalizedScore': 0, 'score': 0.005737760395203566}, {'feature': 'Lexical', 'normalizedScore': 50, 'score': 0.504}, {'feature': 'Popularity 1 Day', 'normalizedScore': 95, 'score': 95.59}, {'feature': 'Popularity 30 Day', 'normalizedScore': 96, 'score': 96.94}, {'feature': 'Popularity 7 Day', 'normalizedScore': 96, 'score': 96.26}, {'feature': 'Popularity 90 Day', 'normalizedScore': 96, 'score': 96.41}, {'feature': 'TLD Rank Score', 'normalizedScore': 0, 'score': 0.00562125007281412}, {'feature': 'Umbrella Block Status', 'normalizedScore': 0, 'score': False}], 'riskScore': 1}
{'features': [{'feature': 'Geo Popularity Score', 'normalizedScore': 84, 'score': 1.68891283}, {'feature': 'Keyword Score', 'normalizedScore': 50, 'score': 0.5030948281811238}, {'feature': 'Lexical', 'normalizedScore': 75, 'score': 0.751}, {'feature': 'Popularity 1 Day', 'normalizedScore': 11, 'score': 11.45}, {'feature': 'Popularity 30 Day', 'normalizedScore': 8, 'score': 8.72}, {'feature': 'Popularity 7 Day', 'normalizedScore': 9, 'score': 9.59}, {'feature': 'Popularity 90 Day', 'normalizedScore': 10, 'score': 10.8}, {'feature': 'TLD Rank Score', 'normalizedScore': 28, 'score': 0.28834641075042694}, {'feature': 'Umbrella Block Status', 'normalizedScore': 0, 'score': False}], 'riskScore': 29}
{'features': [{'feature': 'Geo Popularity Score', 'normalizedScore': 86, 'score': 1.8171738299999998}, {'feature': 'Keyword Score', 'normalizedScore': 50, 'score': 0.5030948281811238}, {'feature': 'Lexical', 'normalizedScore': 99, 'score': 0.991}, {'feature': 'Popularity 1 Day', 'normalizedScore': None, 'score': None}, {'feature': 'Popularity 30 Day', 'normalizedScore': None, 'score': None}, {'feature': 'Popularity 7 Day', 'normalizedScore': None, 'score': None}, {'feature': 'Popularity 90 Day', 'normalizedScore': None, 'score': None}, {'feature': 'TLD Rank Score', 'normalizedScore': 28, 'score': 0.28834641075042694}, {'feature': 'Umbrella Block Status', 'normalizedScore': 0, 'score': False}], 'riskScore': 94}

Referenz

[1] fail2ban https://www.fail2ban.org/wiki/index.php/Main_Page [2] Umbrella Investigate REST API - Security Information for a Domain https://docs.umbrella.com/investigate-api/docs/security-information-for-a-domain-1#section-risk-score-for-a-domain [3] pyinvestigate https://github.com/opendns/pyinvestigate

Recommended Posts