Introducción
Este documento describe cómo configurar y configurar la inserción de copia segura (SCP) de registros de correo (u otros tipos de registros) desde un dispositivo de seguridad de correo electrónico (ESA) de Cisco a un servidor syslog externo.
Antecedentes
Es posible que un administrador reciba notificaciones de error que indiquen que los registros no se pueden enviar mediante SCP o que haya registros de error que indiquen que las claves no coinciden.
Prerequisites
En el servidor syslog en el que el ESA enviará los archivos de registro SCP:
- Asegúrese de que el directorio que se va a utilizar está disponible.
- Revise '/etc/ssh/sshd_config' para ver la configuración de AuthorizedKeysFile. Esto indica a SSH que acepte claves_autorizadas y busque en el directorio de inicio del usuario una cadena de nombre_clave escrita en el archivo .ssh/authorized_keys:
AuthorizedKeysFile %h/.ssh/authorized_keys
- Compruebe los permisos del directorio que se va a utilizar. Es posible que tenga que realizar cambios en los permisos:
- Los permisos de '$HOME' están establecidos en 755.
- Los permisos de '$HOME/.ssh' se establecen en 755.
- Los permisos de '$HOME/.ssh/authorized_keys' se establecen en 600.
Restricciones y permisos de nivel de archivo en UNIX/Linux
Existen tres tipos de restricciones de acceso:
Permission Action chmod option
======================================
read (view) r or 4
write (edit) w or 2
execute (execute) x or 1
También hay tres tipos de restricciones de usuario:
User ls output
==================
owner -rwx------
group ----rwx---
other -------rwx
Permisos de carpeta/directorio:
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
Notación numérica:
Otro método para representar los permisos de Linux es una notación octal como se muestra en stat -c %a. Esta notación consta de al menos tres dígitos. Cada uno de los tres dígitos situados más a la derecha representa un componente diferente de los permisos: propietario, grupo y otros.
Cada uno de estos dígitos es la suma de sus bits componentes en el sistema numérico binario:
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
Para el paso #3, la recomendación para establecer el directorio $HOME en 755 sería: 7=rwx 5=r-x 5=r-x
Esto significa que el directorio tiene los permisos predeterminados -rwxr-xr-x (representados en notación octal como 0755).
Configuración de SCP push of mail logs en ESA
- Ejecute el comando CLI logconfig.
- Seleccione la opción new.
- Elija el tipo de archivo de registro para esta suscripción, que será "1" para IronPort Text Mail Logs, o cualquier otro tipo de archivo de registro de su elección.
- Introduzca el nombre del archivo de registro.
- Seleccione el nivel de registro adecuado. Por lo general, deberá seleccionar "3" para Informativo o cualquier otro nivel de registro que desee.
- Cuando se le pregunte 'Elija el método para recuperar los registros', seleccione "3" para SCP Push.
- Introduzca la dirección IP o el nombre de host DNS al que desea enviar los registros.
- Introduzca el puerto al que desea conectarse en el host remoto.
- Introduzca el directorio en el host remoto para colocar los registros.
- Introduzca el nombre de archivo que se utilizará para los archivos de registro.
- Configure, si es necesario, identificadores únicos basados en el sistema como $hostname, $serialnumber para anexar al nombre de archivo del registro.
- Defina el tamaño máximo del archivo antes de transferir.
- Configure la reversión basada en tiempo de los archivos de registro, si corresponde.
- Cuando se le pregunte "¿Desea activar la comprobación de claves de host?", introduzca "Y".
- Luego se le presenta el mensaje "Por favor, coloque las siguientes claves SSH en su archivo authorized_keys de modo que los archivos log puedan ser cargados."
- Copie esa clave, ya que necesitará poner la clave SSH en su archivo 'authorized_keys' en el servidor Syslog. Pegue la clave dada desde logconfig al archivo $HOME/.ssh/authorized_keys en el servidor Syslog.
- Desde el ESA, ejecute el comando CLI commit para guardar y confirmar los cambios de configuración.
La configuración del registro también se puede realizar desde la GUI: Administración del sistema > Suscripciones de registro
Nota: Revise el capítulo Registro de la Guía del Usuario ESA para obtener detalles completos e información adicional.
Confirmación
Hostkeyconfig
Ejecute el comando logconfig > hostkeyconfig. Debería ver una entrada para el servidor syslog configurado como "ssh-dss" con una clave abreviada similar a la clave proporcionada durante la configuración.
myesa.local > logconfig
...
[]> hostkeyconfig
Currently installed host keys:
1. 172.16.1.100 ssh-dss AAAAB3NzaC1kc3MAAACBAMUqUBGztO0T...OutUns+DY=
Registros del sistema
Los registros del sistema registran lo siguiente: información de arranque, alertas de expiración de licencias de dispositivos virtuales, información de estado de DNS y comentarios que los usuarios escribieron mediante el comando commit. Los registros del sistema son útiles para solucionar problemas relacionados con el estado básico del dispositivo.
La ejecución del comando tail system_logs desde la CLI le proporcionará una visión en directo del estado del sistema.
También puede elegir el comando CLI rollover now y seleccionar el número asociado al archivo de registro. Verá esto en el archivo de registro SCP a su servidor syslog en 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
Solución avanzada de problemas
Si hay problemas continuos con la conectividad al servidor syslog, desde el host local y usando ssh, ejecute "ssh testuser@hostname -v" para probar el acceso del usuario en el modo verbose. Esto puede ayudar a la resolución de problemas para mostrar dónde la conexión ssh no está teniendo éxito.
$ 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
Comentarios