Bueno, voy a continuar con una serie de consejos con objeto de asegurar
Linux un poco mas en ambiente de servidor, aclaro que algunos de estos
consejos son adaptaciones de implementaciones en otros Unixes libres
(me reservo nombres para no herir susceptibilidades :) ).
Veamos.
1-. Empezare por recomendar que si se tiene un servidor (en un ambiente de
poca confianza) lo primero que hay que hacer es deshabilitar la
inicializacion del sistema desde el "diskette", eso lo hacemos yendonos al
BIOS del sistema y modificando la seccion "boot" que debe estar en alguna
parte del menu (una solucion drastica es remover la unidad, digo drastica
porque de necesitarse habria que volver a instalarla).
2-. Otro consejito es el de "DESHABILITAR LOS BOTONES DE "RESET Y
APAGADO", a veces abundan los "atlantes", no vaya a ser que apaguen el
servidor porque "pense que estaba apagado".
3-. Deshabilitar el Ctrl-Alt-Del para reiniciar la maquina, eso se hace
editando el archivo /etc/inittab y comentamos la linea respectiva para
que quede asi.
Cambiemos la seccion:
# Trap CTRL-ALT-DELETE
#ca::ctrlaltdel:/sbin/shutdown -t3 -r now
4-. Siguiendo, es buena idea ponerle una clave al inicio del sistema en
modo monousuario(algunas distribuciones de linux no piden clave al
pasarle el parametro "linux single" a lilo. Esto se hace simplemente
poniendo el parametro "password=xxxx" en la seccion de configuracion
global de lilo, xxxx es la palabra clave que se quiera usar. Luego en la
seccion de inicio de cada imagen se escribe "restricted", mas o menos asi.
#vim /etc.lilo.conf
se modifica lilo.conf para que luzca mas o menos asi (sus parametros
particulares de seguro son diferentes).
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=Linux-2.2.14
password=mi-clave
vga=normal
image=/boot/vmlinuz-2.2.14-5.0
label=Linux-2.2.14
read-only
root=/dev/hda1
restricted # <------
image=/boot/vmlinuz-2.2.14-5.0smp
label=Linux-smp
read-only
root=/dev/hda1
restricted # <------
No hay que olvidar ejecutar lilo una vez modificado este archivo a fin de
cargar los cambios, al hacer esto lilo le pedira que cambie los permiso de
ese archivo, asi que hacemos algo como
#chmod 000 /etc/lilo.conf , o menos drastico #chmod 600 /etc/lilo.conf
5-. Deshabilitemos todos los servicios que no necesitamos, telnet, ftp,
figerd, netstat, tftp,systat,talk,shell,exec,login son buenos canditados,
y en el caso de que sean estrictamente necesarios puede instalarse
versiones mas seguras de esos servicios, quizas substituir sendmail (con
todo y que me gusta y me he acostumbrado su configuracion, un dia de
estos voy a escribir algo sobre configuraciones "seguras" de sendmail) con
postfix o qmail, proftpd en lugar del wu_ftpd que viene con muchas
distribuciones, sshd en lugar de telnet,rsh,rcp, etc tambien puede usarse
tcp_wrapper, o un filtro de paquetes para autenticar accesos.
Esos servicios los habilitamos o deshabilitamos editando
#vim /etc/inetd.conf
una vez hechos los cambios hay que reiniciar el servicio
#killall -1 inetd
6-. Nos aseguramos de la maquina siempre resuelva direcciones mediante
DNS, para ello modificamos el archivo /etc/hosts y le incluimos la llave
"order" asi.
# vim /etc/hosts
order bind,hosts
multi on # Solo si tenemos "aliases" (una interfaz con varias IPs)
nospoof on # Nos evitamos el problema de maquinas que pretenden ser lo
# que no son
7-. Una de las cosas que tienen los BSD unix, tanto comerciales como
libres es la restriccion del comando "su", eso no significa que tal cosa
no se pueda hacer en unix con "sabor" a sistema V como Linux con soporte
PAM (Slackware es un poco mas "bsdsado") , eso lo hacemos asi:
#vim /etc/pam.d/su
Y agregamos este par de lineas, todos los usuarios del grupo
"wheel" seran los unicos permitidos a hacer su
auth sufficient /lib/security/pam_rootok.so debug
auth required /lib/security/Pam_wheel.so group=wheel
8-. Si es estrictamente necesario que los usuarios tengan una
"shell" entonces hay que restrinjirlos, eso se hace en "bash" asignando al
usuario una "shell" como /bin/rbash (es lo mismo que usar bash -r), tiene
la desventaja de que los procesos hijos de esa sesion no seran
restrinjidos, en otras palabras, la jaula se abre con solo cambiar el
shell en uso(hay que sehabilitar el comando "chsh" aunque no ayude mucho),
o simplemente escribiendo "bash" (la shell no restrinjida), etc,etc,etc,
lo mejor en este caso es recompilar bash restrinjido y deshabilitar
cualquier otro "shell", aunque tampoco eso ofrece mayores garantias, hay
sin embargo otra posibilidad que discutire proximamente.
9-. Enjaular el ftp, si se usa proftpd eso es trivial, si usamos wu_ftpd
es un poquito mas laborioso aunque no mucho,
si se usa proftpd hay que editar el archivo de configuracion de proftpd
y meter en la configuracion "global" o virtual la variable
DefaultRoot para que quede asi:
ServerName "su.servidor.net"
ServerType inetd
DefaultServer on
DefaultRoot ~ <---- Enjaula la sesion de ftp a la cuenta de usuario
ServerIdent On "BIENVENIDO A su.servidor.net"
ServerIdent Off <---- Se oculta informacion sobre el "demonio"
Dependiendo de como este ejecutando el servicio(mediante inetd o
"standalone", se debe reiniciar el inetd o el servicio de ftpd mismo.
En Wu_ftpd basta con meter un ./ enfrente del directorio raiz del usuario
En el caso mio, mi entrada en el archivo de passwords luce asi:
jmejia:*:500:500:Jimmy Mejia F:/home/./jmejia:/bin/tcsh
10. Para terminar (por hoy), yo nunca uso menos de 8 caracteres en la
clave(en lugar del valor predefinido de 6), para ello se edita el archivo
#vim /etc/login.defs
y cambiamos la linea
PASS_MIN_LEN 6
a
PASS_MIN_LEN 8
La proxima vez seguire con otros consejitos, simples pero que ayudan a
asegurar un poco mas nuestro sistema.
JImmy
--
�Desea desuscribirse? Escriba a [EMAIL PROTECTED] con
el tema "unsubscribe".
Asegurando Linux (PARTE 2)
=?x-unknown?q?JImmy_M=2E_Fern=E1ndez=2E?= Tue, 17 Oct 2000 20:00:39 -0700
- Re: Asegurando Linux (PARTE 2) =?x-unknown?q?JImmy_M=2E_Fern=E1ndez=2E?=
- Re: Asegurando Linux (PARTE... Ignacio Solis
- Re: Asegurando Linux (P... JImmy Mejia
- Sera cierto ? Eduardo J.Vega Arguedas
- Re: Sera cierto... Eduardo J.Vega Arguedas
- Re: Sera c... Alfredo Figueroa
- Re: Se... Alberto Brealey
- Re: Asegurando Linux (P... JImmy Mejia
- Re: Asegurando Linux (PARTE... Jeffrey Esquivel
