[PYTHON] Version 2019: analyse des tendances des accès non autorisés (exemple de serveur polyvalent sur le cloud)

introduction

Cet article a été publié le 23ème jour du Calendrier de l'Avent Cisco Systems Japan 2018 </ B> </ font> par nos collègues Ciscos.

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

Je pense que de nombreux ingénieurs réseau / infrastructure / serveur construisent des laboratoires à domicile. J'avais une vraie machine à la maison de cette façon pendant plusieurs années, mais il y a environ un an et demi, j'ai arrêté d'avoir du matériel à la maison et je suis passé à plusieurs services cloud. Cela fait presque un an que j'ai essayé des logiciels et des outils de gestion pour fortifier le serveur, et j'ai finalement abandonné tout en modifiant à plusieurs reprises les paramètres, donc c'est illégal depuis un an. Je voudrais résumer les tendances d'accès.

Le thème abordé dans cette entrée est " Édition 2019: Analyse des tendances des accès non autorisés (exemple d'un serveur à usage général sur le cloud) </ B>". Dans ce,

  • Statistiques annuelles sur les accès non autorisés </ font> </ B>
  • Hypothèses d'environnement et exemple de réglage fail2ban </ font> </ B>
  • Conseils d’enquête sur les scores malveillants de source de connexion d’accès non autorisé (API Umbrella Investigate) </ font> </ B>

Je vais résumer les trois principaux éléments de. Au fil du temps depuis la publication du calendrier de l'Avent en 2018, c'était un thème que je voulais résumer un jour comme une histoire.

Statistiques annuelles sur les accès non autorisés </ font>

--Période

  • 2019/01/01 ~ 2019/11/31 --Article
  • Nombre mensuel de tentatives d'accès non autorisées ssh (interdites par ssh-sasl) </ B>
  • Tentatives mensuelles de connexion root ssh (échec de connexion root) </ B>
  • Nombre mensuel postfix de tentatives d'accès non autorisées (banni par postfix-sasl) </ B>
  • Moyenne d’entrée de la table d’interdiction mensuelle (ssh, postfix) </ B>
  • Nombre de tentatives d'accès non autorisé ssh par heure (banni par ssh-sasl) </ B>
  • Code pays source d'accès non autorisé Top26 </ B>
  • Adresse IP source d'accès non autorisé mensuel Recherche inversée de domaine possible </ B>
  • compte ssh Top20 </ B>
  • compte dovecot Top14 </ B>
  • Source d'accès non autorisé RiskScore (global) </ B>
  • Source d'accès non autorisé RiskScore (Japon) </ B>
  • statistiques de violation d'accès RBL postfix </ B>
  • Données de source statistique et outil -Action mail envoyé par fail2ban </ B> (mail envoyé par action à l'interdiction)
  • Rapports statistiques envoyés par logwatch </ B> (/ vat / log / maillog, / var / log / secure, / var / log / messages, / var / log / dovecot / dovecot.log)
  • Cisco Umbrella Investigate </ B> (pour une enquête sur le score de risque de source d'accès frauduleux)

Tentatives mensuelles d'accès non autorisé SSH (interdites par ssh-sasl), tentatives mensuelles de connexion racine SSH (échec de la connexion root)

1-1.png 1-2.png Tentatives mensuelles d'accès non autorisé ssh et tentatives mensuelles de compte root ssh pendant les 12 mois de la période.

En raison du paramètre fail2ban / iptables, l'adresse IP source qui a échoué 3 fois en 1800 secondes ne peut pas être reconnectée pendant au moins 36000 secondes (10 jours). Le nombre de tentatives d'accès non autorisées dans ce graphique est un enregistrement du nombre de premier et deuxième accès dans lesquels une attaque à tour de rôle est exécutée presque automatiquement. Normalement, dans un système qui ne dispose pas d'un tel contrôle d'accès, on considère qu'une quantité énorme d'accès avec différents chiffres est effectuée.

Avant décembre 2018, nous coupions fréquemment l'alimentation pour améliorer l'environnement et le fonctionnement continu à grande échelle a commencé vers novembre 2018. Depuis lors, le nombre de tentatives d'accès ssh a augmenté, mais depuis mai 2019, le nombre d'accès a diminué à un moment donné.

Nombre mensuel de postfixes de tentatives d'accès non autorisées (interdites par postfix-sasl), moyenne mensuelle des entrées de la table d'interdiction (ssh, postfix)

2-1.png 2-2.png Authentification Postfix mensuelle Tentatives d'accès non autorisées au cours des 12 mois de la période et moyennes mensuelles de la table d'interdiction active.

Dans ce système cible, SMTP-AUTH est activé dans le cadre de mesures contre le relais tiers lors de l'envoi de courrier par Postfix. Le maillog compte le nombre d'échecs de cette tentative SMTP-AUTH. Comme avec ssh, l'adresse IP de la source de connexion qui a échoué deux fois en 5400 secondes est entrée dans iptables, donc l'échec d'authentification au moment de la connexion initiale est ciblé. Bien que le nombre total soit considérablement plus petit que celui de ssh, il peut être confirmé que le nombre total augmente progressivement à partir du moment où l'accès à ssh diminue.

Les entrées de table d'interdiction sont le résultat d'une observation en virgule fixe du nombre total d'entrées de table d'interdiction active ssh et postfix rapportées par logwatch (3 heures du matin). Vous pouvez voir qu'il est proportionnel au nombre d'accès ssh.

Nombre de tentatives d'accès non autorisées ssh par heure (interdite par ssh-sasl)

3.png Il s'agit du taux d'occurrence d'événements d'accès non autorisé ssh par le Japon au cours des 12 mois de la période. L'accès non autorisé au service de messagerie n'est pas compté.

Il n'y a pas de biais dans le nombre d'accès par heure du Japon. Il est considéré comme exécuté presque mécaniquement à partir de sources d'accès partout dans le monde.

Code pays source d'accès non autorisé Top26

4.png Ce sont les 26 premiers pays (jusqu'au classement du Japon) à partir desquels les événements d'accès non autorisé ssh sont connectés au cours de la période de 12 mois. L'accès non autorisé au service de messagerie n'est pas compté.

Dans une très grande majorité Chine </ font> </ B>, Amérique </ font> </ B>, suivi de Vous pouvez voir qu'il existe de nombreux accès depuis B> France </ font> </ B>.

Adresse IP de source d'accès non autorisé mensuel Recherche inversée de domaine possible

5.png Nombre mensuel de tentatives d'accès non autorisé ssh en 12 mois au cours de la période ( ligne verticale bleue </ font> est identique au graphique précédent ' nombre mensuel de tentatives d'accès non autorisé ssh </ B>') Est une comparaison avec l'adresse IP qui a pu inverser le domaine hôte de l'adresse IP de la source de connexion.

Dans toutes les tentatives d'accès non autorisé 65507 ssh, 43% des adresses IP de source de connexion ont un FQDN enregistré. Il n'y a pas de grande différence dans le ratio mensuel. (39% ~ 43%)

compte ssh Top20, compte dovecot Top14

6.png Il s'agit d'un tableau présentant les taux d'utilisation les plus élevés des comptes non root utilisés pour imposer l'accès non autorisé aux services ssh et de messagerie au cours des 12 mois de la période.

Il existe de nombreux comptes qui peuvent être imaginés que ssh est créé facilement, et il y a un biais dans le nombre de fois. Dans dovecot et postfix, de nombreux accès peuvent être confirmés avec des comptes individuels qui sont moins biaisés et ne sont pas affichés dans le graphique et sont utilisés moins fréquemment.

Source d'accès non autorisé RiskScore (global), Source d'accès non autorisé RiskScore (Japon)

7-1.png 7-2.png Distribution des estimations de gravité prédictive (RiskScore) </ B> par Cisco Umbrella Investigate </ B> à partir de sources d'accès non autorisées ssh sur une période de 12 mois.

J'ai essayé de l'extraire d'Umbrella Investigate en tant qu'information de réputation de la source de connexion qui effectue une activité frauduleuse. Le score est de 0 à 100, 100 est le score le plus élevé. Vous pouvez voir que la plupart sont des sources avec des scores relativement bons.

statistiques de violation d'accès RBL de postfix

8.png Statistiques de violation de connexion Postfix par règles RBL pendant 12 mois au cours de la période.

  • RBL: 1 </ B>: contrôle de réputation par zen.spamhaus.org
  • RBL: 2 </ B>: contrôle de réputation par bl.spamcop.net
  • No Service : Name or service not known
  • No Address : Address not listed for hostname

J'ai défini zen.spamhaus.org, bl.spamcop.net comme liste noire de réputation de source de courrier indésirable RBL (Realtime Blackhole List), qui vérifie cette liste lors de la connexion à MTA et rejette les sources de connexion qui correspondent à la liste. Faire. Le nombre de visites sur zen.spamhaus.org a augmenté en juin 2019 et octobre 2019, respectivement.

Hypothèses d'environnement et exemple de réglage de fail2ban </ font>

C'est une condition préalable aux statistiques annuelles sur les accès non autorisés. Le décompte lui-même affiché dans le graphique des statistiques d'accès non autorisé n'est pas le nombre total de tentatives d'accès, mais le résultat de l'analyse après avoir été suffisamment filtré par l'outil utilisé. Essayons de régler certaines des conditions.

En plus de ssh, un environnement de bureau distant utilisant XRDP + GNOME et un service de messagerie utilisant postfix + dovecot sont construits sur le système à analyser cette fois. Nous n'utilisons pas d'autres services tels que les serveurs Web. Les ports ouverts sont 22 / tcp (ssh) </ B>, 25 / tcp (SMTP) </ B>, 993 / tcp (imaps) </ B>, 995 / tcp (pop3s) </ B>, 3389 / tcp (RDP) </ B>.

Le service de bureau à distance est simplement protégé par des iptables statiques qui verrouillent la source de connexion, et les services ssh et de messagerie utilisent fail2ban </ B> pour enregistrer et protéger les entrées iptables dynamiques selon les règles spécifiées. Le résultat est envoyé au mail chaque fois que la table interdite est saisie par fail2ban, l'événement de sécurité est analysé tous les 24 intervalles et le résultat est envoyé par logwatch </ B>. Chaque service n'utilise pas d'outils avancés tels que IPS / IDS pour traiter les vulnérabilités en partant du principe qu'il sera mis à jour régulièrement. Cette fois, l'objectif principal est de sortir la tendance des accès non autorisés sur la base des informations bloquées par ce traditionnel fail2ban </ B>.

fail2ban fail2ban n'est pas du tout un nouvel outil. Le fichier journal spécifié par le paramètre qui signale un accès non autorisé au service tel que / var / log / apache / error_log est analysé en temps réel et l'adresse IP de la source de connexion est basée sur le signe malveillant dans le fichier journal. L'interdiction (ajout / mise à jour automatique à iptables) de l'adresse à l'heure spécifiée protège le système de l'échec du mot de passe de connexion et de l'utilisation d'Exploit. Bien que fail2ban fonctionne bien pour réduire le taux de tentatives répétées comme les attaques brutales, il ne réduit pas l'accès à l'authentification faible elle-même.

jail.local Dans le cas de ssh, évitez autant que possible que les «mots de passe échoués» consécutifs de la même adresse IP soient émis vers «/ var / log / secure». Dans le cas de postfix, «l'authentification de LOGIN a échoué» consécutivement à partir de la même adresse IP autant que possible. Nous avons continué à faire des ajustements pour empêcher la sortie de / var / log / mail / maillog pendant un certain temps, et enfin findtime = 1800 / maxentry = 3 et findtime = 5400 / `maxentry = 2, respectivement. Je suis arrivé à la conclusion que «est le meilleur. En d'autres termes, dans le cas de postfix, s'il y a un échec de connexion de la même source de connexion trois fois en 90 minutes, il est défini sur Interdire. Dans de nombreux cas, ils ont tenté d'accéder à nouveau à partir de la même source dans les 17 à 18 minutes.

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

Conseils d'enquête sur les scores malveillants de source de connexion d'accès non autorisé (API Umbrella Investigate) </ font>

Cisco Umbrella Investigate Umbrella </ B> utilise le DNS récursif public pour évaluer les domaines malveillants potentiels et les adresses IP qui sont automatiquement analysés à partir de plus de 180 milliards de requêtes par jour en tant qu'indicateurs prédictifs. L'analyse statistique de sécurité pour ces adresses DNS et IP est une fonction de Umbrella Investigate </ B>, et les informations de score peuvent être obtenues à partir de nombreuses perspectives. Les scores générés pour ce domaine particulier, l'adresse IP peuvent être utilisés par les opérateurs de sécurité avancés et les chercheurs en sécurité principalement pour aider l'analyse prédictive et trouver des informations sur l'activité du réseau considérées comme suspectes. Est possible.

Umbrella Investigate Risk Score Le score de risque Umbrella Investigate est un score potentiel prédictif compris entre 0 et 100 basé sur les caractéristiques lexicales des noms de domaine (chaînes de composition), les requêtes de domaine vers l'infrastructure Umbrella et l'analyse des modèles de demande. Cette valeur n'est pas nécessairement directement liée au jugement de malignité en raison des activités frauduleuses passées sous enquête, mais se positionne comme une valeur de risque prévue. Ces informations sont également liées à la pertinence du botnet, des domaines de phishing, du malvertising et des ransomwares du sujet de l'enquête.

pyinvestigate (module python de l'API Umbrella Investigate)

Umbrella Investigate a été utilisé comme information sur la distribution du score de risque des statistiques d'informations sur les accès non autorisés. Umbrella Investigate peut être interrogé par l'API REST ainsi que par l'interface utilisateur Web. Nous avons utilisé pyinvestigate </ B>, qui est un module python pour Umbrella Investigate, pour acquérir collectivement RiskScore à partir de l'API REST à partir de plus de 65 000 adresses IP de sources d'accès non autorisées et des noms de domaine complets d'hôte.

1. Installez pyinvestigate

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

2. Enquêtez sur l'acquisition de la clé API

--Connectez-vous à https: // dashboard.umbrella.com / --Investigate> Naviguez pour enquêter sur l'accès API

  • CREATE NEW TOKEN Token.png Token2.png Reportez-vous au jeton créé et copiez-le

3. Exécutez pyinvestigate

pyinvestigate peut être exécuté à partir de l'interpréteur python. Spécifiez la clé API copiée et interrogez l'adresse IP / le domaine de recherche. Un script distinct est créé pour une enquête sur les accès non autorisés et acquis dans un lot.

# 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}

référence

[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