Cualquiera puede conseguir con facilidad una root-shell y cambiar sus contraseñas al introducir "(nombre-de-imagen-de-arranque) init=/bin/sh" en el prompt de inicio. Tras cambiar las contraseñas e reiniciar el sistema, esa persona tiene acceso ilimitado como root y puede hacer lo que quiera con el sistema. Después de ésto, usted ya no tendrá acceso como root al sistema, puesto que no conoce la contraseña.
Para asegurarse que ésto no pueda ocurrir, debería establecer una contraseña para el cargador del sistema operativo. Puede elegir entre una contraseña global o una contraseña para una imagen en concreto.
Para LILO necesita modificar el fichero de configuración /etc/lilo.conf y añadir las líneas "password" y "restricted", como en el ejemplo siguiente.
image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted
Una vez hecho, vuelva a ejecutar lilo. La omisión de la línea "restricted" hace que lilo pida siempre una contraseña, sin importar si se le han pasado parámetros. Cuando añada una contraseña, asegúrese de que solamente el usuario root pueda leer el fichero de configuración de lilo, es decir, chmod 600 /etc/lilo.conf ### comentario: si esto es así por omisión en Debian dílo o quita esto, jfs
Si usa GRUB en vez de LILO, modifique el fichero /boot/grub/menu.lst y añada las dos líneas siguientes al comienzo. Esto establecerá una contraseña de arranque y arrancará la opción por omisión después de tres segundos:
timeout 3 password hackme
El MBR por omisión en Debián antes de la versión 2.2 no actuaba como un master boot record corriente y dejaba abierto un método para forzar con facilidad la entrada al sistema:
Este comportamiento se puede cambiar introduciendo: lilo -b /dev/hda Ahora LILO se pone en el MBR. También se puede conseguir esto añadiendo "boot=/dev/hda" a lilo.conf. Hay otra solución que desabilitará el prompt del mbr completamente: install-mbr -i n # ¿es ésta install-mbr /dev/hda? jfs # # comprueba que realmente esto es cierto para 2.2 o ¿era 2.1? INFO: los discos de arranque de Debian 2.2 NO instalan mbr sino sólo LILO.
Cuando monta una partición ext2 tiene algunas opciones adicionales a aplicar a la llamada de montaje o a /etc/fstab. Por ejemplo, esta es mi entrada en fstab para una partición /tmp:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Se puede ver la diferencia en la sección de opciones. La opción nosuid ignora los bits setuid y setgid, mientras que noexec prohibe la ejecución de cualquier programa en ese punto de montaje, y nodev ignora los dispositivos. Suena genial, pero
La opción noexec evita que los binarios puedan ser ejecutados directamente, pero se puede saltar fácilmente:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
Sin embargo, muchos script kiddies tienen exploits que intentan crear y ejecutar ficheros en /tmp. Si no tienen idea no saldrán de aquí.
PAM permite a los administradores de sistemas elegir cómo las aplicaciones autentifican al usuario. Observe que PAM no hace nada a menos que una aplicación haya sido compilada con soporte para PAM. La mayoría de las aplicaciones que se entregan con Debian 2.2 tienen este soporte incorporado. Observe, también, que Debian no tenía soporte de PAM antes de la versión 2.2. Hay un fichero de configuración en /etc/pam.d para cada aplicación. PAM le ofrece la posibilidad de pasar varias etapas de autentificación de una vez sin que el usuario lo sepa. Puede autentificar contra una base de datos Berkeley y la contraseña y el usuario solamente entra si se autentifica correctamente dos veces.
Con PAM, puede restringir muchas cosas, de la misma manera que puede abrir las puertas de su sistema. Así que tenga cuidado. La línea típica de conficuración tiene como tercer elemento un campo de control. Generalmente debería establecerse como "requisite", que devuelve un fallo de login si un módulo falla. La primera cosa que me gusta hacer es añadir soporte MD5 para las aplicaciones PAM, ya que esto ayuda a protegerse contra los ataques de diccionario. Las siguientes dos líneas deberían añadirse a todos los ficheros en /etc/pam.d/ que garantizan el acceso a la máquina, como 'login' y 'ssh'.
password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
Entonces, ¿qué función tiene este mito? La primera línea carga el módulo PAM cracklib, que proporciona fuerza de chequeo a las contraseñas, pide una nueva contraseña con una longitud mínima de 12 caracteres, una diferencia de al menos 3 caracteres con la antigua contraseña, y permite tres intentos. La segunda línea introduce el módulo de autentificación estándar con contraseñas md5 y permite una contraseña de longitud cero. La directiva use_authtok es necesaria para transmitir la contraseña desde el módulo anterior. Para asegurarse de que el usuario root puede entrar en el sistema solamente desde terminales locales, se debería habilitar la siguiente línea en /etc/pam.d/login: auth reguisite pam_securetty.so. Después debería añadir las terminales desde las que el usuario root puede acceder al sistema en el fichero /etc/security/access.conf. En último lugar, pero no por ello menos importante, debería habilitar la siguiente línea, si quiere establecer límites a los usuarios: session required pam_limits.so. Esto restringe los recursos del sistema a los usuarios autorizados. Por ejemplo, podría restringir el número de login concurrentes que pueden tener los usuarios. Modifique, ahora, el fichero /etc/pam.d/passwd y cambie la primera línea. Debería añadir la opción "md5" para usar contraseñas md5, cambiar la longitud mínima de 4 a 6 (o más) y establecer una longitud máxima, si lo desea. La línea resultante se parecería a esta: password required pam_unix.so nullok obscure min=6 max=11 md5. Si queremos proteger "su" de manera que solo alguna gente pueda usarlo para convertirse en root en su sistema, necesitamos añadir un grupo "wheel" nuevo al sistema (que es el método más limpio, ya que ningún fichero tiene todavía ese permiso de grupo). Añada root a este grupo y los otros usuarios que podrán hacer "su" al usuario root. Luego, añada la siguiente línea a /etc/pam.d/su: auth requisite pam_wheel.so group=wheel debug. Esto asegura que solamente los miembros del grupo wheel pueden usar su para convertirse en root. Si otros lo intentan, obtendrán un mensaje diciéndoles que el acceso está prohibido. Por último, cree /etc/pam.d/other e introduzca las siguientes líneas:
auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so
Estas líneas le darán una buena configuración por defecto para todas las aplicaciones que soportan PAM (el acceso se niega por defecto)
Realmente debería echar una mirada seria a este fichero. Aquí puede definir los límites de recursos para usuarios. Si usa PAM, este fichero no es válido y debería usar /etc/security/limits.conf. ARRÉGLAME: Get a good limits.conf up here
Debería parar todos los servicios que no sean necesarios en su sistema, como echo, discard, daytime, time, talk, ntalk y los servicios r- (rsh, rlogin y rcp), considerados ALTAMENTE inseguros (utilice ssh). Tras desabilitar los anteriores, debería comprobar que realmente necesita el demonio inetd. Mucha gente prefiere usar demonios en vez de llamar a los servicios via inetd. Existen posibilidades de Denegación de Servicios contra inetd, lo cual puede incrementar enormemente la carga de la máquina. Si aún quiere hacer correr algún tipo de servicio inetd, cámbiese a un demonio inet más configurable, como xinetd o rlinetd.
Puede conseguir ésto modificando inetd.conf directamente, aunque Debian ofrece una alternativa: update-inetd. Puede quitar el demonio telnet haciendo:
# /usr/sbin/update-inetd --disable telnet # /etc/init.d/inetd restart
El siguiente paso es modificar la configuración y acción básicas sobre el login de usuarios. FAIL_DELAY 10 Esta variable debería establecerse con un valor más alto para hacerla más dura al usar la terminal para entrar al sistema usando la fuerza bruta. Si se teclea una contraseña errónea, tiene que esperar 10 segundos para obtener una nuevo prompt de login, que es un consumo bastante grande de tiempo si está probando contraseñas. Preste atención al hecho de que ésto es inútil si se usa un programa que no sea getty, como puede ser mingetty. FAILLOG_ENAB yes Si habilita esta variable, los login fallidos quedarán registrados. Es importante seguirles la pista para coger a alguien que intenta un ataque de fuerza bruta. LOG_UNKFAIL_ENAB yes Si establece la variable FAILLOG_ENAB a yes, también debería darle el valor de yes a esta variable. Registrará los nombres de usuario desconocidos si el login falla. Si hace ésto asegúrese de tener los permisos adecuados (por ejemplo 640, con un grupo apropiado como adm), porque los usuarios a menudo introducen accidentalmente su contraseña como nombre de usuario y no queremos que otros lo vean. SYSLOG_SU_ENAB yes Ésto habilita el registro de los intentos de su en syslog. Bastante importante en máquinas serias, pero tenga en cuenta que tambin puede originar conflictos de privacidad. SYSLOG_SG_ENAB yes Lo mismo que SYSLOG_SU_ENAB, pero aplicable a la llamada sg. MD5_CRYPT_ENAB yes Como ya fue expuesto antes, las contraseñas md5 sum reducen en gran medida el problema de los ataques con diccionarios, porque es muy difícil realizar un crack contra contraseñas MD5. Al menos es difícil hacerlo con éxito. Si usa usted slink, lea los documentos sobre MD5 antes de habilitar esta opción. Si no lo hace estará establecido en PAM. PASS_MAX_LEN 50 Si se han activado las contraseñas MD5 en su configuración PAM, entonces esta variable debería tener el mismo valor que se usó en aquella.
Este fichero contiene una lista de los usuarios a los que no les está permitido entrar en el servidor usando ftp. Use solamente este fichero en el caso de que realmente quiera permitir ftp (lo cual no es recomendable en general, porque usa contraseñas en claro). Si su demonio soporta PAM, puede usarlo para permitir o negar ciertos servicios a los usuarios.
Los TCP wrappers fueron desarrollados cuando no había filtros de paquetes y era necesario tener control de acceso. Los TCP wrappers le dan la posibilidad de permitir o denegar un servicio para un host o para un dominio y define unas reglas de permiso y denegación por defecto. Si quiere más información, consulte la página del manual de hosts_access(5). Ahora, aquí tiene un pequeño truco, probablemente el sistema más pequeño de detección de intrusiones disponible. En general debería tener una política de cortafuegos decente como primera línea de defensa y tcp wrappers como segunda línea. Un pequeño truco es establecer una orden spawn en /etc/hosts.deny que envíe un mensaje a root siempre que un servicio denegado dispare los wrappers:
ALL: ALL: spawn ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /bin/mail -s "Connection to %d blocked" root)
Precaución: El ejemplo de arriba se puede adaptar para usar como DoS (Denegación de Servicio) haciendo muchas conexiones en un período corto de tiempo. Muchos mensajes electrónicos implican mucha Entrada/Salida de ficheros mandando solamente unos cuantos paquetes. #¿Podría este ejemplo ser más interesante? #Se relaciona también con la sección siguiente jfs #
#ALL: ALL: spawn ( \ # /usr/local/sbin/send_syslog %u %c %d ) #
# Whit send_syslog as: ##!/usr/bin/perl -w # #use Sys::Syslog qw(:DEFAULT setlogsock); # #$user=shift(@ARGV) || 'unkown'; #$host=shift(@ARGV) || 'unkown'; #$service=shift(@ARGV) || 'unkown'; #setlogsock('unix'); #openlog("alert",'', 'user'); #syslog('warning', 'Connection from %s at %s to %s blocked.', ($user, $host, $service) ); #closelog(); # #exit 0;
Un tema importante en un sistema seguro es cómo se tratan los registros y las alertas. Es muy fácil ver que, incluso si un sistema está perfectamente configurado y supuestamente es seguro al 99%, si ese 1% llega a ocurrir y no hay establecidas medidas de seguridad para, en primer lugar, detectarlo y, en segundo lugar, lanzar alarmas, el sistema no es en absoluto seguro.
Debian viene con una configuración de syslog estándar (en /etc/syslog.conf) que registra los mensajes en los ficheros adecuados dependiendo del sistema. Si tiene la intención de mantener un sistema seguro debería ser precavido de a dónde se mandan estos mensajes de manera que no pasen inadvertidos.
Por ejemplo, mandar mensajes a la consola es una configuración interesante para muchos sistemas en producción. Pero para muchos de esos sistemas es también importante añadir una nueva máquina que sirva de almacén de registros (recibe registros de todas las demás máquinas).
Se debería considerar también el correo de root; muchos controles de seguridad (como snort mandan alertas al buzón de root. Este buzón normalmente apunta al primer usuario que se creó en el sistema (compruebe /etc/aliases). Asegúrese de mandar el correo de root a algún lugar donde se pueda leer (tanto local como remótamente). #Nota: Sería interesante contar como manda un sistema Debian tramas SNMP #relacionado con problemas de seguridad jfs # comprueba: snmptraglogd, snmp y snmpd
Un host de registro es un host que recoge datos syslog remotamente de la red. Si una de sus máquinas es craqueada, el intruso no puede cubrir sus huellas, a menos que hackee el host de registro también. Así, el host de registro debería ser especialmente seguro. Convertir una máquina en host de registro es simple. Simplemente lance syslodg con 'syslogd -r' y nace un nuevo host de registro. Seguidamente, configure las otras máquinas para que envíen datos al host de registro. Añada una entrada como ésta a /etc/syslog.conf
facility.level @your_loghost
facility debería ser uno de estos: authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp y local1 hasta local7. level debería ser alert, crit, err, warning, notice, info debug. Si quiere registrar todo en remoto, simplemente escriba:
*.* @your_loghost
en su syslog.conf. Hacer registros tanto remota como localmente es la mejor solución (el atacante puede asumir que ha cubierto sus huellas tras borrar los ficheros de registro locales). Vea la página del manual de syslog(3), syslogd(8) y syslog.conf(5) si quiere información adicional.
No sólo es importante decidir cómo se usarán las alertas, sino que también quién tiene acceso a ellas, ésto es, quién puede leer o modificar los ficheros de registro (si no usamos un host de registro remoto). Así pues, en el caso de una intrusión, incluso con las alertas de seguridad en su sitio, si un atacante es capaz también de cambiarlas, la seguridad se reduce a la nada.
#Se debería explicar porqué tras la instalación esto no queda ya hecho, jfs Algunos permisos de ficheros de registro no quedan perfectos tras la instalación. En primer lugar, no es necesario que los usuarios normales puedan leer /var/log/faillog y /var/log/lastlog. En el fichero de lastlog podemos ver quién entró en el sistema por última vez y en faillog vemos un sumario de los logins fallidos. El autor recomienda hacer chmod 660 a ambos. Eche una breve mirada a sus ficheros de registro y decida con mucho cuidado qué ficheros de registro hace legíbles/escribibles para un usuario con un UID diferente a 0 o un grupo que no sea 'adm' o 'root'.
Quisiera enfatizar que los permisos de los ficheros de registro de apache son realmente deficientes debido al hecho de que el usuario apache es el propietario de los ficheros de registro de apache. Si un usuario consigue una shell con una puerta trasera en apache, puede quitar los ficheros de registro con facilidad. #Esto es bastante personal, EMHO, ya que se debe al hecho de que los #privilegios de root caen al arranque. Prefiero que un hacker borre los #ficheros de registro de un servicio a que borre todos los registros del #sistema. De todas maneras, esto se puede mejorar cambiando los permisos # de usuario después de rotar.
Debian tiene un proceso cron que corre diariamente en /etc/cron.daily/standard. Este proceso ejecutará el script /usr/bin/chechsecurity, que guardará la información sobre estos cambios. # Qué hay por defecto para ésto en el paquete cron? jfs
Para realizar esta comprobación debe establecer en /etc/checksecurity.conf
CHECKSECURITY_DISABLE="FALSE"
# ¿Se envía ésto a root? jfs
Si realmente necesita convertirse en el superusuario de su sistema, por ejemplo para instalar paquetes o para añadir usuarios, puede usar la orden su para cambiar su identidad. Debería intentar evitar cualquier login como usuario root y usar en su lugar su. Realmente la mejor solución es quitar su y cambiarse a sudo, ya que tiene más características que su. Sin embargo, su es mucho más usado en muchos otros Unixes.
sudo permite al usuario ejecutar órdenes definidas bajo la identidad de otro usuario, incluso como root. Si el usuario se añade a /etc/sudoers y se autentifica correctamente, puede ejecutar órdenes que se han definido en /etc/sudoers. Las violaciones, tales como contraseñas incorrectas o intentos de ejecutar un programa para el que no tiene permisos, se registran y se envían por correo a root.
chroot es una de las posibilidades más potentes para restringir un demonio o un usuario u otro servicio. Simplemente imagine una cárcel alrededor de su objetivo, de la que el objetivo no puede escapar (en teoría, pero existen aún muchas condiciones que le permiten a uno escapar de esa cárcel). Si no confía en un usuario, puede crear un cambio de entorno de root para él. Ésto puede utilizar bastante espacio ya que necesita copiar todos los ejecutables que le sean necesarios, así como las librerías, dentro de la cárcel. Incluso si el usuario hace algo malicioso, el alcance del daño está limitado a la cárcel. Un buen ejemplo de este caso es si no se autentifica contra /etc/passwd, sino contra LDAP o MySQL. Así, su demonio ftp necesita un binario y quizás unas cuantas librerías. Un entorno chroot será una excelente mejora de seguridad si se conoce un nuevo exploit para este demonio ftp. Solamente será posible usar el exploit contra el UID del usuario del demonio ftp y nada más. Por supuesto, muchos otros demonios se pueden beneficiar también de ésto.
Una nota adicional, el BIND (el servicio de nombres) por defecto de Debian no viene con chroot, de hecho ningún demonio viene con chroot. Espero que esto cambie con la salida de woody.
ARRÉGLAME - Content missing Muchas características del núcleo se pueden modificar mientras están ejecutándose haciendo echo a algo en el sitema de ficheros /proc o usando sysctl. Al introducir sysctl -A puede ver lo que puede configurar y qué opciones hay. Solamente en casos extraños necesitará modificar algo aquí, pero puede incrementar la seguridad de esa manera también. net/ipv4/icmp_echo_ignore_broadcasts = 0 Esto es un emulador de windows, porque actúa como windows cuando emite ping con el valor de 1. De otra manera, no hace nada. net/ipv4/icmp_echo_ignore_all = 0 Si no quiere bloquear ICMP en su cortafuegos, habilite ésto.
SVGAlib es muy bonito para los amantes de la consola como yo, pero se ha probado ya varias veces que es muy inseguro. Han salido exploits contra zgv, y era simple convertirse en root. Intente evitar el uso de programas SVGAlib siempre que sea posible.
Se pueden copiar ficheros de una manera segura de un host a otro usando 'scp', que se incluye en el paquete ssh. Funciona como rcp, pero está completamente cifrado, así que los chicos malos no pueden ni siquiera averiguar qué copia usted.
Tener una buena política de cuotas es importante, ya que evita que los usuarios llenen el/los disco/s duro/s.
Puede usar dos sistemas diferentes de cuotas -cuotas de usuario y cuotas de grupo. Como probablemente habrá adivinado, las cuotas de usuario limitan la cantidad de espacio que un usuario puede utilizar; las cuotas de grupo hacen el equivalente con los grupos. Tenga esto en mente cuando decida el tamaño de las cuotas.
Hay unos cuantos puntos a considerar cuando se establece un sistema de cuotas:
Cada partición/directorio al que los usuarios tienen acceso con permiso de escritura debería tener cuotas establecidas. Así que busque esas particiones y directorios y calcule un tamaño de cuota adecuado. En primer lugar necesita comprobar si ha habilitado soporte de cuotas en el núcleo. Si no es así, necesitará recomplilarlo. Tras ésto, controle si el paquete 'quota' está instalado. Si no lo está, lo necesitará también. Establecer cuotas para los respectivos sistemas de ficheros es tan fácil como modificar la configuración 'defaults' por 'defaults,usrquota' en su fichero /etc/fstab. Si necesita cuotas de grupo, sustituya 'usrquota' por 'grpquota'. También puede usar ambos. Luego cree ficheros vacíos quota.user y quota.group en las raíces de los sistemas de ficheros en los que quiere usar quota (por ejemplo, touch /home/quota.user,touch /home/quota.group para un sistema de ficheros /home). Reinicie quota haciendo /etc/init.d/quota stop;/etc/init.d/quota start. Ahora quota debería estár ejecutándose, y los tamaños de quota se pueden establecer. Modificar cuotas para un usuario específico (digamos 'ref') se puede hacer con edquota -u ref. Las cuotas de grupo se pueden modificar con edquota -g (grupo). Después establezca la cuota de software y de hardware según sus necesidades. Para obtener más información sobre cuotas, lea la página del manual sobre quota y el mini-howto de quota.
Estas dos órdenes son muy útiles, pero funcionan solo con el sistema de ficheros ext2. Con 'lsattr' puede listar los atributos de un campo, y con 'chattr' puede cambiarlos. Note que los atributos no son la misma cosa que los permisos. Hay muchos atributos, pero aquí se mencionarán solo los más importantes para incrementar la seguridad. Hay dos flags que solamente las puede establecer el superusuario. En primer lugar está la flag 'a'. Si se establece para un fichero, este fichero puede ser abierto solamente para añadir. Este atributo es útil para algunos ficheros en /var/log/, aunque podría considerar que fuesen quitados algunas veces debido la la rotación de scripts de registro. La segunda flag es 'i', en corto immutable. Si se establece en un fichero, no puede ser modificado o borrado o renombrado y no se creará ningún link hacia él. Si no quiere que los usuarios puedan mirar en sus ficheros de configuración puede establecer esta flag y quitar el permiso de lectura. Más aun, ésto puede darle un poco más de seguridad contra intrusos, porque el cracker puede confundirse al no ser capaz de borrar un fichero. De todas maneras, nunca debería asumir que el crácker es ciego. Después de todo, entró en su sistema.
¿Está usted seguro de que el /bin/login en su disco duro es todavía el binario que instaló allí hace unos meses? ¿Qué pasaría si es una versión hackeada, que guarda la contraseña introducida en un fichero oculto o la envía por correo en claro por toda internet? El único método para tener alguna protección es comprobar sus ficheros cada día/hora/mes (yo prefiero cada día) comparando la vieja md5sum y la actual. Dos ficheros no pueden tener la misma md5.sum, de modo que anda sobre seguro aquí, excepto s alguien hackeó el algoritmo para crear md5sums en esa máquina; lo cual es, bueno, pegajoso. Realmente debería considerar que auditar sus binarios es muy importante, ya que es un modo fácil de reconocer los cambios en sus binarios. Las herramientas que comúnmente se usan para ésto son sXid, AIDE (Advanced Intrusion Detection Environment) y TripWire (no es libre, la nueva versión será GPL).
Más aún, puede intercambiar su paquete 'locate' con 'slocate'. slocate es una versión mejorada para seguridad de GNU locate. Cuando usa slocate, el usuario solamente ve los ficheros a los que él tiene acceso y puede excluir cualquier fichero o directorio del sistema.
COMO-Asegurar-Debian
v1.1 27 april 2002Thu, 7 Dec 2000 19:10:13 +0100ar@rhwd.net (Alexander Reelsen)