archivo

seguridad

Ahora que se informó de la vulnerabilidad de GRUB2 bautizada “BootHole”, la cual permite a un atacante insertar y ejecutar código malicioso durante el arranque del sistema, talvez consideren apropiado monitorear cambios al archivo /boot/grub/grub.cfg, que a su vez solo pueden ser realizados por un usuario privilegiado (comprometido) del sistema operativo o si tu proveedor de nube/infraestructura ha sido comprometido.

Read More

Un error que suele pasar después de aplicar parches de seguridad que requieren reinicio de Sistema Operativo es él no aplicar dicho reinicio de manera inmediata en casos como:

  • No tener alta disponibilidad en el servicio que ofrece un servidor en cuestión.
  • No tener ventana de mantenimiento autorizada.
  • No notar que se requiere reinicio.
  • Simplemente olvidarlo.

No aplicar el reinicio termina siendo tan grave como no actualizar los paquetes, puesto que el Sistema sigue usando la versión anterior del paquetes, llamese este linux-image-generic, linux-headers-generic, linux-generic, glibc, etc.

Read More

Hoy 8 de Junio de 2018 -en medio de la crisis que afecta al país- me reportan amigos y familiares que el SSID de su router aDSL que les provee el ISP CLARO ha sido cambiado a “QUITEN LOS TRANQUES”. No se trata únicamente de los routers con la configuración por defecto, si no también en routers con SSID personalizados, passphrase cambiada e inclusive filtro de MAC activo. Read More

La suite colaborativa zimbra en su versión community ofrece las opciones de tener direcciones de reenvío de correo visibles y configurables por usuario -conocidas como User specified- así como también direcciones para reenvío ocultas al mismo.

Al configurar la clase de servicio por defecto está la opción de permitir -o no- a los usuarios el definir estas direcciones de reenvío, pero se debe evaluar el riesgo que supone para la fuga de información el hecho de que un usuario pueda enviar todo el correo entrante a su bandeja de entrada hacia una cuenta externa en caso de no tener políticas en otros módulos que lo impidan. Read More

El valor ignorespace o ignoreboth (el cual equivale a ignorespace + ignoredups) en la variable de entorno HISTCONTROL es incluido por defecto en la mayoría de distribuciones hoy en día y normalmente se le presta muy poca atención al riesgo de tenerla configurada de esta manera.

La variable se usa para tener un historial de comandos menos repetitivo, en el caso de ignoredups (ignore duplicates) no se agregan al historial comandos repetidos que son ejecutados de manera consecutiva. ignorespace por su parte no añade al bash_history comandos que empiecen por uno o más espacios en blanco.

El historial además de referencia puede ser usado con fines de auditoría y cualquier usuario podría pasar por encima de este control con solo agregar un espacio en blanco antes de comandos que no quiera que otros usuarios vean que ejecutó. Por ello me parece un tema delicado en equipos en los que se comparten las credenciales de acceso como las del usuario root.

Por ahora en los VPS o equipos de uso compartido recomiendo modificar el valor por defecto para que únicamente ignore duplicados:

echo “HISTCONTROL=ignoredups” >> /etc/enviroment

Al parecer alguien mas ya se había cuestionado lo mismo en las lista de correo de bash:
http://lists.gnu.org/archive/html/bug-bash/2010-02/msg00024.html

Acá el feature request en openSUSE: https://features.opensuse.org/316634