Introduction
Ce document décrit comment installer et configurer une copie sécurisée (SCP) des journaux de messagerie (ou d'autres types de journaux) à partir d'un appareil de sécurité de la messagerie électronique Cisco (ESA) vers un serveur syslog externe.
Informations générales
Un administrateur peut recevoir des notifications d'erreur indiquant que les journaux ne peuvent pas être envoyés à l'aide de SCP, ou qu'il peut y avoir des journaux d'erreurs indiquant une non-correspondance de clé(s).
Conditions préalables
Sur le serveur syslog auquel l'ESA enverra les fichiers journaux SCP :
- Assurez-vous que le répertoire à utiliser est disponible.
- Vérifiez '/etc/ssh/sshd_config' pour les paramètres AuthorizedKeysFile. Ceci indique à SSH d'accepter authorized_keys et de rechercher dans le répertoire de base de l'utilisateur la chaîne key_name écrite dans le fichier .ssh/authorized_keys :
AuthorizedKeysFile %h/.ssh/authorized_keys
- Vérifiez les autorisations du répertoire à utiliser. Vous devrez peut-être modifier les autorisations :
- Les autorisations sur '$HOME' sont définies sur 755.
- Les autorisations sur '$HOME/.ssh' sont définies sur 755.
- Les autorisations sur '$HOME/.ssh/authorized_keys' sont définies sur 600.
Restrictions et autorisations au niveau des fichiers sous UNIX/Linux
Il existe trois types de restrictions d'accès :
Permission Action chmod option
======================================
read (view) r or 4
write (edit) w or 2
execute (execute) x or 1
Il existe également trois types de restrictions utilisateur :
User ls output
==================
owner -rwx------
group ----rwx---
other -------rwx
Autorisations de dossier/répertoire :
Permission Action chmod option
===============================================================
read (view contents: i.e., ls command) r or 4
write (create or remove files from dir) w or 2
execute (cd into directory) x or 1
Notation numérique :
Une autre méthode de représentation des autorisations Linux est une notation octale, comme illustré par la stat -c %a. Cette notation se compose d'au moins trois chiffres. Chacun des trois chiffres les plus à droite représente un composant différent des autorisations : propriétaire, groupe et autres.
Chacun de ces chiffres est la somme des bits qui le composent dans le système de numération binaire :
Symbolic Notation Octal Notation English
============================================================
---------- 0000 no permissions
---x--x--x 0111 execute
--w--w--w- 0222 write
--wx-wx-wx 0333 write & execute
-r--r--r-- 0444 read
-r-xr-xr-x 0555 read & execute
-rw-rw-rw- 0666 read & write
-rwxrwxrwx 0777 read. write & execute
Pour l'étape #3, il est recommandé de définir le répertoire $HOME sur 755 : 7=rwx 5=r-x 5=r-x
Cela signifie que le répertoire dispose des autorisations par défaut -rwxr-xr-x (représentées en notation octale par 0755).
Configuration de la diffusion SCP des journaux de messagerie sur ESA
- Exécutez la commande CLI logconfig.
- Sélectionnez l'option new.
- Choisissez le type de fichier journal pour cet abonnement, il s'agira de « 1 » pour les journaux de messagerie texte IronPort ou tout autre type de fichier journal de votre choix.
- Entrez le nom du fichier journal.
- Sélectionnez le niveau de journalisation approprié. En règle générale, vous devez sélectionner « 3 » pour Information ou tout autre niveau de journal de votre choix.
- Lorsque vous êtes invité à choisir la méthode de récupération des journaux, sélectionnez « 3 » pour SCP Push.
- Entrez l'adresse IP ou le nom d'hôte DNS vers lequel envoyer les journaux.
- Saisissez le port auquel se connecter sur l'hôte distant.
- Entrez le répertoire de l’hôte distant où placer les journaux.
- Entrez un nom de fichier à utiliser pour les fichiers journaux.
- Configurez, si nécessaire, des identificateurs uniques basés sur le système tels que $hostname, $serialnumber à ajouter au nom du fichier journal.
- Définissez la taille de fichier maximale avant le transfert.
- Le cas échéant, configurez la substitution temporelle des fichiers journaux.
- À la question « Voulez-vous activer la vérification de la clé d'hôte ? », saisissez « Y ».
- Le message suivant s'affiche alors : « Veuillez placer la ou les clés SSH suivantes dans votre fichier authorized_keys afin que les fichiers journaux puissent être téléchargés. »
- Copiez cette clé, car vous devrez placer la clé SSH dans votre fichier 'authorized_keys' sur le serveur Syslog. Collez la clé fournie par logconfig dans le fichier $HOME/.ssh/authorized_keys sur le serveur Syslog.
- À partir de l'ESA, exécutez la commande CLI commit pour enregistrer et valider les modifications de configuration.
La configuration du journal peut également être effectuée à partir de l'interface GUI : Administration système > Inscriptions au journal
Remarque : veuillez consulter le chapitre Journalisation du Guide de l'utilisateur ESA pour obtenir des détails complets et de plus amples informations.
Confirmation
Hostkeyconfig
Exécutez la commande logconfig > hostkeyconfig. Vous devriez voir une entrée pour le serveur syslog configuré listé comme "ssh-dss" avec une clé abrégée semblable à la clé fournie lors de la configuration.
myesa.local > logconfig
...
[]> hostkeyconfig
Currently installed host keys:
1. 172.16.1.100 ssh-dss AAAAB3NzaC1kc3MAAACBAMUqUBGztO0T...OutUns+DY=
Journaux du système
Les journaux système enregistrent les informations suivantes : informations de démarrage, alertes d'expiration de licence d'appliance virtuelle, informations d'état DNS et commentaires des utilisateurs saisis à l'aide de la commande commit. Les journaux système sont utiles pour le dépannage de l'état de base de l'appliance.
L'exécution de la commande tail system_logs à partir de l'interface de ligne de commande vous donnera un aperçu en direct de l'état du système.
Vous pouvez également sélectionner la substitution de commande CLI maintenant et sélectionner le numéro associé au fichier journal. Vous verrez ceci dans le fichier journal SCP vers votre serveur syslog dans system_logs :
myesa.local > tail system_logs
Press Ctrl-C to stop.
Thu Jan 5 11:26:02 2017 Info: Push success for subscription mail_logs: Log mail_logs.myesa.local.@20170105T112502.s pushed via SCP to remote host 172.16.1.100:22
Dépannage avancé
Si des problèmes de connectivité au serveur syslog persistent, à partir de l'hôte local et à l'aide de ssh, exécutez « ssh testuser@hostname -v » pour tester l'accès utilisateur en mode détaillé. Cela peut faciliter le dépannage pour montrer où la connexion ssh ne réussit pas.
$ ssh testuser@172.16.1.100 -v
OpenSSH_7.3p1, LibreSSL 2.4.1
debug1: Reading configuration data /Users/testuser/.ssh/config
debug1: /Users/testuser/.ssh/config line 16: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to 172.16.1.100 [172.16.1.100] port 22.
debug1: Connection established.
debug1: identity file /Users/testuser/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/testuser/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to 172.16.1.100:22 as 'testuser'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-dss
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-dss SHA256:c+YpkZsQyUwi3tkIVJFXHAstwlkdewO1G0s7P2khV7U
debug1: Host '172.16.1.100' is known and matches the DSA host key.
debug1: Found key in /Users/testuser/.ssh/known_hosts:5
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: Skipping ssh-dss key /Users/testuser/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/testuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/testuser/.ssh/id_ecdsa
debug1: Trying private key: /Users/testuser/.ssh/id_ed25519
debug1: Next authentication method: password
testuser@172.16.1.100's password: <<< ENTER USER PASSWORD TO LOG-IN >>>
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).
Authenticated to 172.16.1.100 ([172.16.1.100]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_CTYPE = en_US.UTF-8
Commentaires