Exemples d'installation
Le même installateur sur les hôtes qu'il rencontre d'habitude : un déploiement avec Ansible ou cloud-init, une image de référence, un serveur avec un panneau de contrôle, un hôte mail ou base de données, un conteneur LXC, et un VPS derrière un pare-feu cloud. Chaque exemple utilise les options et les variables que documente la page d'installation, rien ici n'est une seconde porte d'entrée.
Sans intervention, sur beaucoup d'hôtes
Trois choses font qu'une installation sans intervention fonctionne, et chaque exemple ci-dessous
repose dessus. Les conditions d'utilisation sont acceptées d'avance avec
REPORTEDIP_ACCEPT_TERMS=1, parce qu'il n'y a personne pour taper yes. La
clé voyage dans l'environnement et jamais en argument, parce que
/proc/<pid>/cmdline est lisible par tout utilisateur local et que l'environnement
ne l'est pas. Et les réponses aux questions qu'un terminal poserait sont données en variables, pour
qu'aucun hôte n'attende une réponse : REPORTEDIP_MODE, REPORTEDIP_BAN et
REPORTEDIP_NOTIFY_EMAIL. Omettez-en une et la valeur par défaut d'une configuration
neuve s'applique, c'est-à-dire drop, bannissements locaux activés, et pas de courrier.
L'exécution est idempotente. Sur un hôte qui a déjà /etc/reportedip-agent/config.yaml,
le script pose le binaire et s'arrête, et la configuration n'est pas touchée. Les mises à niveau
n'ont pas besoin du déploiement : l'agent se met à jour lui-même toutes les six heures à partir d'une
version signée. La seule chose à faire après chaque installation est la liste blanche :
l'installateur y met l'adresse d'où venait la session, et votre plage d'administration n'y est pas
tant que vous ne l'ajoutez pas.
Ansible
Une liste de tâches, pas un rôle, parce qu'il n'y a rien à mettre en template : l'installateur sonde l'hôte lui-même. La clé vient du vault, la tâche est sautée sur un hôte qui a déjà une configuration, et la tâche de liste blanche traite une adresse déjà présente comme inchangée, ce qui est exactement ce que l'agent rapporte.
- name: Install the ReportedIP Agent
ansible.builtin.shell: curl -fsSL https://reportedip.com/agent/install.sh | sh
args:
creates: /etc/reportedip-agent/config.yaml
environment:
REPORTEDIP_ACCEPT_TERMS: "1"
REPORTEDIP_KEY: "{{ reportedip_api_key }}"
REPORTEDIP_MODE: "drop"
REPORTEDIP_BAN: "true"
REPORTEDIP_NOTIFY_EMAIL: "ops@example.org"
no_log: true
- name: Whitelist the management range
ansible.builtin.command:
argv: [reportedip-agent, whitelist, add, "{{ management_range }}", "management"]
register: rip_whitelist
changed_when: rip_whitelist.rc == 0
failed_when: rip_whitelist.rc != 0 and "already in" not in (rip_whitelist.stderr ~ rip_whitelist.stdout)
- name: Confirm the host is healthy
ansible.builtin.command: reportedip-agent status
changed_when: false
no_log garde la clé hors de la sortie d'Ansible et de ses journaux ; l'installateur
lui-même la garde hors de la liste des processus. Un hôte de rebond qui n'est pas l'endroit d'où vous
administrez a besoin de
--admin-ip, qui n'existe que comme argument : REPORTEDIP_ADMIN_IP n'existe pas, et
install.sh ne transmet aucun argument à la configuration. Lancez le script avec
REPORTEDIP_NO_SETUP=1, puis reportedip-agent install --admin-ip 203.0.113.0/24
dans une seconde tâche, avec le même bloc d'environnement.
cloud-init
La même ligne dans runcmd. Ce qui change, c'est l'endroit où vit la clé : les user data
sont lisibles depuis l'intérieur de l'instance par tout processus qui atteint le service de
métadonnées, une clé placée là est donc une clé que chaque application de l'hôte peut lire. Là où
cela compte, récupérez-la au démarrage depuis un coffre de secrets et transmettez-la dans
l'environnement de cette seule commande.
#cloud-config
runcmd:
- [sh, -c, "curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=YOUR_API_KEY REPORTEDIP_NOTIFY_EMAIL=ops@example.org sh"]
- [reportedip-agent, whitelist, add, "203.0.113.0/24", "management"]
- [reportedip-agent, sync]Une image de référence
Placez le binaire dans l'image et rien d'autre. REPORTEDIP_NO_SETUP=1 télécharge,
vérifie et installe le binaire et s'arrête là : pas de configuration, pas d'unités, pas
d'enregistrement. La mise en place s'exécute une fois au premier démarrage, sur le vrai hôte, parce
que deux choses qu'elle écrit ne doivent pas être clonées : l'identifiant d'installation, qui est ce
par quoi le service distingue un serveur d'un autre, et la liste blanche automatique, qui porte
l'adresse de la session qui l'a lancée. Une image qui porte un identifiant d'installation fait de
chaque clone le même serveur dans le registre, et une licence est alors comptée une fois pour tous
et n'est attribuée de façon fiable à aucun d'eux.
# In the image build:
curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=YOUR_API_KEY REPORTEDIP_NO_SETUP=1 sh
# At first boot of the clone, once:
REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=YOUR_API_KEY reportedip-agent install --notify-email ops@example.org
reportedip-agent syncPanneaux de contrôle
reportedip-agent doctor nomme le panneau qu'il trouve sous /usr/local : ISPConfig, Plesk, cPanel
ou DirectAdmin. Ce que l'installateur configure au-delà du nom dépend du fait que la disposition des journaux par
site de ce panneau ait été mesurée ou non. Aujourd'hui, c'est ISPConfig ; pour les autres, le panneau
est nommé, les journaux standard sont trouvés, et les journaux par domaine sont à ajouter vous-même.
doctor liste aussi les
sources configurées avec les fichiers vers lesquels elles pointent, et reportedip-agent test <log> montre ce qu'un journal produirait
avant de l'ajouter.
ISPConfig
Mesuré sur des hôtes de production. L'installateur trouve les journaux par site sous
/var/log/ispconfig/httpd/*/access.log et error.log sous forme de glob, un
site ajouté plus tard est donc couvert sans rien changer, le journal de connexion au panneau
/var/log/ispconfig/auth.log comme source panel, et le journal mail,
pure-ftpd (qu'ISPConfig installe sous le nom pure-ftpd-mysql) et fail2ban quand ils
tournent. Sur un hôte d'hébergement, cela a donné 196 fichiers de journaux pour 62 lignes de
configuration. Les listes mail, web et
ftp suivent les services actifs et les ports qui n'écoutent pas seulement sur la boucle
locale ; ssh et edge sont toujours actives.
Plesk
Nommé par /usr/local/psa. Le journal mail standard est trouvé ; les journaux web par
domaine ne sont pas configurés, parce que leur disposition n'a pas été mesurée. Ils vivent d'habitude
sous /var/www/vhosts/system/<domain>/logs/ sous le nom access_log,
plus proxy_access_log là où nginx est devant Apache. Vérifiez avec ls, puis
ajoutez une source web avec un glob et une source web-error pour les
journaux d'erreurs. Un pare-feu de panneau qui réécrit les tables quand ses règles sont appliquées ne
retire pas l'agent pour de bon : la prochaine synchronisation remarque que la chaîne a disparu et la
reconstruit, et reportedip-agent sync le fait tout de suite.
sources:
- type: sshd
- type: postfix
path: /var/log/maillog
- type: dovecot
path: /var/log/maillog
- type: web
glob: "/var/www/vhosts/system/*/logs/access_log"
- type: web
glob: "/var/www/vhosts/system/*/logs/proxy_access_log"
- type: web-error
glob: "/var/www/vhosts/system/*/logs/error_log"cPanel
Nommé par /usr/local/cpanel. Trois choses diffèrent d'un hôte ordinaire. Les journaux
par domaine sont les domlogs, d'habitude /var/log/apache2/domlogs/ avec
/usr/local/apache/domlogs qui pointe dessus ; une source web avec un glob
les couvre. Le serveur de mail est Exim et son journal est /var/log/exim_mainlog, qui
n'est pas l'un des chemins que l'installateur cherche, la source exim s'ajoute donc à
la main. Et là où csf tourne, /var/log/lfd.log est une source à part entière,
csf, et chaque blocage que fait lfd est signalé par elle ; Imunify360 a une source par
interrogation, marquée expérimentale. Lancez d'abord test sur chaque journal : un domlog
avec un format personnalisé ne produit rien, et il vaut mieux l'apprendre dans un terminal que
devant un compteur vide une semaine plus tard.
sources:
- type: sshd
- type: web
glob: "/var/log/apache2/domlogs/*"
exclude: ["*-ssl_log", "*.bkup*"]
- type: exim
path: /var/log/exim_mainlog
- type: csf
path: /var/log/lfd.logDirectAdmin
Nommé par /usr/local/directadmin. Les journaux par domaine sont d'habitude sous
/var/log/httpd/domains/, un <domain>.log et un
<domain>.error.log chacun, et Exim écrit /var/log/exim/mainlog, qui
là encore n'est pas un chemin que l'installateur essaie. Deux globs et un chemin couvrent l'hôte.
Un serveur de mail, un serveur de base de données
Un hôte qui fait tourner Postfix et Dovecot n'a besoin de rien de plus. L'installateur voit les
services ou les ports en écoute et configure les deux sources sur le seul journal mail, et la liste
mail atterrit sur les ports mail fixes 25, 465, 587, 110, 995, 143 et 993. Les seuils sont par source d'événement et bas
à dessein, parce qu'un serveur de mail voit peu d'échecs légitimes : trois échecs SASL en une heure,
cinq destinataires rejetés, trois rejets amavis, dix échecs Dovecot. Un hôte qui fait tourner Exim à
la place reçoit la source exim quand le journal est à l'un des chemins Debian ou Red
Hat. Ce qui quitte la machine est identique partout : l'adresse,
les identifiants de catégorie, une phrase générée, et aucune ligne du journal.
Base de données
Un hôte de base de données qui n'écoute que sur SSH et sur le port de la base reçoit une seule
source, sshd, et deux listes qui comptent : ssh sur le port SSH et
edge, qui s'applique à chaque port et donc aussi au port de la base. L'agent ne lit
aucun journal de base de données, il ne verra donc pas une attaque par force brute contre la base
elle-même ; la réponse à cela n'est pas sur cette page, c'est une règle de pare-feu qui tient le
port à l'écart d'internet. Ce que l'agent ajoute, c'est qu'une adresse que le réseau connaît déjà
comme attaquant est rejetée avant sa première tentative de connexion, sur chaque port.
Conteneurs LXC et pare-feu cloud
Proxmox LXC
L'agent a besoin de deux choses d'un conteneur : systemd, qu'un conteneur LXC avec une distribution
systemd possède, et un backend de pare-feu qu'il peut utiliser, ce qui est la question ouverte. Que
nft ou ipset puisse créer un ensemble à l'intérieur du conteneur dépend
des privilèges du conteneur, et dans un conteneur non privilégié, ce n'est d'habitude pas possible.
L'installateur ne devine pas : le bloc des prérequis nomme le backend qu'il a trouvé, et une
installation sans backend passe en signalement seul, ce que doctor dit en toutes
lettres. Lancez un sync après l'installation et lisez status : une chaîne
qui est là est la réponse. Là où elle n'y est pas, le blocage se fait sur l'hôte Proxmox, et le
conteneur continue de détecter et de signaler.
Un VPS derrière un pare-feu cloud
Un pare-feu de fournisseur filtre avant que le paquet n'atteigne l'hôte. Ce qu'il rejette n'apparaît
jamais dans un journal, les compteurs et les ensembles de l'agent ne voient donc que ce que le
fournisseur a laissé passer ; ce n'est pas un défaut, c'est l'ordre des couches. Deux choses valent
la peine sur un VPS. Mettez la plage depuis laquelle vous administrez dans la liste blanche juste
après l'installation, parce que la liste blanche automatique ne contient que l'adresse d'où venait la
session. Et connaissez le chemin du retour avant d'en avoir besoin : la console du fournisseur est
hors bande, elle ne passe pas par les ensembles du noyau, une adresse d'administration bannie n'est
donc qu'à un reportedip-agent unban <address> de la console, et chaque
bannissement local expire de lui-même de toute façon.
Dernière mise à jour: · Maintenu par l’équipe ReportedIP