PDF de programación - Referencia rápida de seguridad en Linux

CONTROL DE PERMISOS DE ARCHIVOS Y ATRIBUTOS


Monitorear los permisos del sistema de archivos, es crucial para mantener la integridad del
sistema.

Revise el sistema periódicamente, en busca de permisos “setuid” o “setgid”, no
autorizados o innecesarios. Considere que los programas con “setUID root”, se corren
como superusuario independientemente de quién los ejecute, y son causa frecuente de
“buffer overflows”. SetUID root se usa normalmente, para permitir que cualquier usuario
pueda realizar ciertas acciones, que de otro modo sólo podrían ser ejecutadas por el
administrador. Busque programas sospechosos, y quíteles setuid o setgid, usando chmod:

root# find / -type f -perm +6000 -ls
59520 30 -rwsr-xr-x 1 root root 30560 Apr 15 2001 /usr/bin/chage
59560 16 -r-sr-sr-x 1 root lp 15816 Jan 6 2001 /usr/bin/lpq
root# chmod -s /usr/bin/chage /usr/bin/lpq
root# ls -l /usr/bin/lpq /usr/bin/chage
-rwxr-xr-x 1 root root 30560 Apr 15 2001 /usr/bin/chage
-r-xr-xr-x 1 root lp 15816 Jan 6 2001 /usr/bin/lpq

Los archivos con atributos de escritura para todos, pueden ser alterados o borrados con
facilidad, búsquelos todos:

root# find / -perm -2 ! -type l –ls

En el transcurso de la operación, verá varios archivos; entre ellos varios dentro de /dev/, e
incluso el directorio /tmp. Busque e identifique los archivos que no tienen un dueño o
pertenecen a un grupo. Podrían haber sido creados por algún intruso:

root# find / -nouser -o –nogroup

Si utiliza los comandos lsattr y chattr, el superusuario puede modificar las características
de archivos y directorios, incluyendo su alteración o borrado, mejor que al usar chmod.
Utilizar los atributos “appendonly” (sólo agregar contenido) e immutable, pueden ser
bastante efectivos para proteger los logs (registros de actividad) de ser borrados, o evitar
que pueda incorporarse código malicioso, a los binarios críticos del sistema. Aunque esto
no garantiza que los archivos no puedan ser modificados, exige al menos que se tenga
cuenta de root para hacerlo. El comando chattr se usa para fijar o quitar estos atributos,
mientras que lsattr se usa para listarlos. Fijando el modo “append-only”a los logs del
sistema, los datos que se agregan, no se podrán borrar. Aunque esta práctica requiere
modificar los scripts de rotación de logs, puede ayudar a evitar que un eventual intruso,
borre sus huellas. Una vez que se rotan los logs, deberían ponerse en modo “immutable”.
Es util modificar en este sentido, aquellos archivos que no se cambian a menudo, como
/bin/login, /bin/rpm o /etc/shadow.

# chattr +i /bin/login
# chattr +a /var/log/messages
# lsattr /bin/login /var/log/messages
----i--- /bin/login
-----a-- /var/log/messages

Ningún usuario, debiera poder correr programas con setuid, desde su directorio home.
Utilice la opcion nosuid en el archivo /etc/fstabs, para las particiones que puedan ser
escritas por usuarios distintos de root. Puede usar tambien nodev y noexec, en particiones
que contengan homes de usuarios, o incluso en /var, lo cual impide la ejecución de
programas y la creación de dispositivos de caracteres o de bloques, lo cual nunca debiera
ser necesario. Consulte las páginas del manual de mount, para obtener más información.

SERVICIOS INNECESARIOS




Una de las mejores maneras de evitar compromisos remotos de seguridad, es deshabilitar
los servicios que no es necesario proveer. Muchos de los servicios que se dejan
habilitados por defecto en la configuración del metademonio inetd, no se usarán casi
nunca. Desactive los que no necesite, comentando la línea correspondiente en el archivo
/etc/inetd.conf

Encontrará scripts de ejecución de servicios por runlevel, en
/etc/rc.d/rc* -según la distribución-. Mueva esos enlaces, renombre o borre, o
incluso desinstale el paquete correspondiente. En RedHat puede usar /sbin/chkconfig
--list para ver qué servicio corre en cada
runlevel. Para quitarlos, use
/sbin/chkconfig --del servicio. Válgase de netstat -a -p --inet, de ps, y
de los port scanners, para determinar qué servicios corre.



/etc/rc*.d o en




USO DE RPM Y DPKG


El uso de /bin/rpm en RedHat u otras basadas en aquella, y de /usr/bin/dpkg en Debian y
derivadas, es la clave en la administración de los paquetes de software del sistema. Sea
cauto al utilizar las correspondientes herramientas de actualización automática, como
AutoRPM, AptRPM, Up2date o AptGet.

- Para quitar un paquete:
#rpm -e <paquete>
#dpkg -r <paquete>

- Listar los contenidos del paquete:
#rpm -qvl <paquete.rpm>
#dpkg -c <paquete.deb>

- Listar los paquetes con su información:
#rpm -qvia
#dpkg –l

- Ver la información de un paquete:
#rpm -qpi <paquete.rpm>
#dpkg -I <paquete.deb>

- Verificación básica de integridad:
#rpm -Va
#debsums –a

- Averiguar a qué paquete pertenece un archivo:
#rpm -qf </trayecto/al/archivo>
#dpkg -8 </trayecto/al/archivo>

- Instalar un nuevo paquete:
#rpm -Uvh <paquete.rpm>
#dpkg -i <paquete.deb>

CONFIGURACIÓN DE TCP WRAPPERS





Estas reglas se usan a menudo para monitorear y controlar, el acceso a los servicios
listados en el archivo /etc/inetd.conf. Si algún servicio se corre como “standalone”, sin
depender del superdemonio, tcpwrapers no podrá controlar su actividad. Si necesita por
ejemplo, “recubrir” (horrible traducción de wrapear :) su
in.ftpd:

ftp tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i –o

Antes de que un demonio de servicios sea invocado ante una petición, tcpd se asegurará
de verificar que el origen del paquete, es un host permitido. Los intentos de conexión, se
envían al syslogd. Todos
los servicios deben estar deshabilitados en el archivo
host.deny:

ALL:ALL
Para enviar un mail al administrador del sistema cada vez que se note un intento fallido de
conexión:

ALL: ALL: /bin/mail -s “%s intento de conexión de %c”
[email protected]

Habilite servicios en específico en /etc/host.allow usando el nombre del servicio, seguido
por la información del host:

sshd: clienta24.seguros.com, ripper.seguros.com
in.ftpd: 192.168.1.

El punto al final, indica que toda esa red estará autorizada. Use tcpdchk para verificar
sus archivos de acceso. El control de acceso funciona asi:

1- El acceso a un servicio se garantiza, si el host encaja en las definiciones de
host.allow.

2- Si el servicio está especificamente denegado para el host en cuestión, se rehusará la
conexión

3- De otro modo, se garantizará el acceso al servicio.

Si en su sistema no se han creado archivos de control de acceso, se interpretará su
contenido como vacío, de modo que el control de acceso al host, quedará desactivado!!!



CONFIGURACIÓN DE SYSLOG


El syslogd, es un demonio encargado de capturar y llevar registro, de los mensajes
generados por los diferentes procesos durante su ejecución, mientras que por su parte,
klogd es el responsable de hacer lo propio, pero con los mensajes generados por el kernel.
Los registros de actividades (también puede encontrarlos como bitácoras, cuadernos, o
nombres peores ;) serán en la mayoría de los casos, indicadores primarios de los
problemas que pudieran presentarse en su sistema. Incluso hay quienes guardan sus
logs... en /dev/lp0.

Ajuste su archivo de configuracion de syslogd, /etc/syslog.conf, para que envíe información
de tipo específico a archivos específicos, para que pueda ser leída y analizada con más
sencillez y velocidad.

#monitorear intentos de autentificación
auth.*; authpriv.* /var/log/authlog

#auditar todos los mensajes del kernel
kern.* /var/log/kernlog

#monitorear todas las advertencias y mensajes de error
*.warn; *.err /var/log/syslog

#enviar una copia a un host de logs remoto. Configure el script #de
inicio de syslogd para que corra con las opciones -r -s
#dominio.com en su servidor de logs. Asegúrese de que el nivel #de
seguridad en su servidor de logs, sea bueno, cuando menos.
*.info @loghost
auth.*; authpriv.* @loghost

Restrinja el acceso a los directorios de logs y de syslog a sus usuarios normales, usando:

#chmod 751 /var/log /etc/logrotate.d
#chmod 640 /etc/syslog.conf /etc/logrotate.conf
#chmod 640 /var/log/*.log

SEGURIDAD EN DNS





Las
transferencias de zona, sólo debieran permitirse en servidores maestros que
actualizan la información de zona (dominio), es sus servidores esclavos. No hacerlo de
ese modo, puede permitir que hosts no autorizados, obtengan información de nombres de
hosts e Ips. Restrinja las peticiones sólo a dominios públicos. Configuración para un
servidor con zonas públicas y privadas:

<Directory />
Options None
// Permite trasnferencias solo a su servidor de nombres esclavo.
// Solo permite peticiones de la red 192.168.1.0.
zone “midominio.com” {
type master;
file “master/db.midominio.com”;
allow-transfer {192.168.1.6; };
allow-query {192.168.1.0/24; };
};

Rechaze y guarde un registro, de las peticiones de versión que se le hagan, excepto
desde su propio host. Obtener el número de versión de BIND que corre, ayudará a los
intrusos a determinar qué tipo de ataque dará buenos resultados con su servidor de
nombres:

// Impi