eko nº3:(Eko3R-15.txt):10/11/2001 << Back To eko nº 3
<- [ Eko Magazine 3 Revange ] ----- [ La Venganza del Oso Arturo.... ] -> <---- [ GiBa #Ezkracho ] -------------- { GiBa@Ezkracho.com.ar } -------> <---------------- [ Seguridad en servidores Linux ] --------------------> <------------ [ Capitulo 1 - El Server y las conexiones ] -------------> Indice: _-_-_-_ -=[ Capitulo 1 ]=- [x] Preambulo [x] Archivos de Configuracion en /etc. [x] Servicios de inet. |____ Respecto a los servicios y demonios. \___ Cuidado !! con. [x] Secure Shell. [x] TCPWrapers. [x] Firewalls ipchains. [x] Fin del Capitulo 1 -=[ Capitulo 2 ]=- [x] Scripts. [x] PHP Preambulo: _-_-_-_-_-_ Este documento esta orientado a administradores novatos de servers que tienen problemas para mantener alejados a visitantes indeseados. Cada tema esta explicado como una introduccion, en el caso de que sea util, recomiendo leer las paginas del manual, la documentacion del paquete y el HOWTO que seguro hay. No tiene sentido que copie lo mismo que ya esta ahi. Cualquier error que sea detectado, me gustaria que me lo comuniquen por mail para poder solucionarlo lo antes posible. Espero que sea entendible :-) GiBa. Archivos de Configuracion: _-_-_-_-_-_-_-_-_-_-_-_-_ /etc/securetty: -=-=-=-=-=-=-=- Este archivo no hace nada mas ni nada menos que especificar en que ttys puede logearse el root. Por ejemplo si nuestra compu tiene especificadas consolas en las tty1 hasta la tty10, podemos hacer que sean seguras desde la tty5 hasta la tty8. Lo que se lograria con esto es si alguien con acceso fisico a la computadora intenta logearse como root en tty1, por mas que escriba bien el passwd, el syslog marcara un login failed y esta persona recibira error. Tambien se puede especificar como segura pts/0 por ejemplo, con lo cual una sesion de telnet, o mejor dicho, la primer sesion de telnet abierta hacia la maquina permite logeos del root directamente. Esto NO es recomendable!! Tambien se puede especificar como seguros los ttySx para permitir logeos de root en terminales montadas sobre los puertos serie. De todas maneras, siempre es posible hacer un su - ;-) /etc/inittab: -=-=-=-=-=-=- Este archivo no tiene tanto que ver con la seguridad, pero aqui se pueden especificar las consolas que se quiere tener agregandolas o quitandolas: 21:2345:respawn:/sbin/getty 38400 tty21 /* Para alcanzar las consolas superiores a la 12, utilizaremos el alt de la derecha, asi para la consola en la tty13 tocamos alt derecho y F1. */ Tener en cuenta que por cada consola estamos utilizando un poco mas de memoria para el getty que esta esperando en ella. /etc/syslog.conf: -=-=-=-=-=-=-=-=- En este archivo especificamos unas cosillas respecto a la forma de loggar. Se elige en que archivo se loggea cada cosa. Estaria muy bien, cambiar los archivos de lugar, que por defecto estan en /var/log, asi algunos programas cuya funcion es borrar o filtrar los logs desde la direccion absoluta /var/log no funcionan. Tambien estaria bueno poner algunos archivos "se~uelo" o loggear tanto aqui y consarvar una copia en otro lugar. De esta forma, cuando el atacante hace un ls /var/log/ ve que hay algo y luego cuando haga algo asi rm -F /var/log/* no borrara ninguna de sus huellas. Es posible mandar los mensajes del syslog a una tty: Si ponemos como archivo /dev/tty12 con alt F12 veremos los ultimos mensajes. /etc/inetd.conf: -=-=-=-=-=-=-=- Este es uno muy importante, aca definimos los servicios de red que provee nuestra computadora y es un blanco muy utilizado para dejar algun que otro backdoor en el sistema. Su configuracion completa se ve en la seccion ->Servicios de Inet /etc/anacrontab /etc/crontab /etc/cron.*/* /etc/cron.d/*: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Esta es la configuracion para los servicios que se ejecutan regularmente. Si se especifica algun comando dentro de estos archivos de configuracion, sera ejecutado cuando llegue al momento. Este es otro posible blanco para backdoors, un atacante podria agregar a nuestro simpatico /etc/cron.daily/exim una linea que instala un backdoor. Asi, si se detecta el backdoor, y es desinstalado, no importa, ma~ana se instalara automaticamente otra vez. /etc/at.deny: -=-=-=-=-=-=- Este archivo contiene una lista de usuarios que NO pueden utilizar el servicio at (ejecucion diferida de un programa). Aqui estan por defecto los usuarios que crean demonios, ej. qmaild, ftp, y otros que por su funcion no tienen por que utilizar este servicio. /etc/chatscripts /etc/ppp: -=-=-=-=-=-=-=-=-=-=-=-=-= En estos directorios se guarda la informacion necesaria utilizada para conexiones de tipo ppp con otros servidores, llamese numero de telefono nombre de usuario y contrase~a. Todo escrito en texto plano sin encriptar. /etc/checksecurity.conf: -=-=-=-=-=-=-=-=-=-=-=-= Esta es la configuracion para la script checksecurity. La configuracion completa se ve en la seccion ->Scripts /etc/hosts.allow /etc/hosts.deny: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Estos son los archivos de configuracion de tcpwrapers. Sirven para seleciconar que hacer cuando un determinado ip utiliza un determinado servicio. La configuracion completa se ve en la seccion -> TCPWrapers /etc/hosts.equiv: -=-=-=-=-=-=-=-=- Aqui se definen los hosts y usuarios que pueden utilizar el sistema sin necesidad de contrase~a, a traves de rcp rlogin y rsh. Suele ser blanco para algunos backdoors y hay exploits que lo utilizan. Hay que tener mucho cuidado si se desean utilizar estos servicios, pero lo mas recomendable es NO utilizarlos. /etc/login.defs: -=-=-=-=-=-=-=- En este archivo se configuran cosas como el tiempo de espera luego de un intento fallido de loggeo o la cantidad de intentos de loggeo permitidos. Aumentar el tiempo de espera sirve para realentar ataques por fuerza bruta convirtiendolos en eternos (no se si tanto, pero unos cuantos a~os seguro) Servicios de Inet: _-_-_-_-_-_-_-_-_ En los linuxos es utilizado el demonio inetd para administrar los servicios que son proveidos a la red. Asi, en lugar de tener un demonio para cada servicio, inetd escucha en los puertos de estos demonios y los llama cuando son solicitados. Asi se reduce el uso de memoria. Los servicios que provee el demonio son definidos en el archivo de texto /etc/inetd.conf. Respecto a los servicios y demonios: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Cerrar todos los servicios que no cumplen ninguna funcion importante en el server. Recien instaladas, algunas linuxas, dejan corriendo un monton de servicios, desde el echo hasta el ssh. Hay que tener bien claro el uso que se le va a hacer al server, asi se puede configurar optimamente para estos servicios y anular otros. Si esta esta como server de red para una oficina, el servicio de finger puede ser util para comprobar si llego o no ese mail pidiendo alguna reposicion; en este caso (oficina) no tiene sentido tener el ftp funcionando porque no es algo necesario para este tipo de actividad. De esta misma forma, en un server que hostea sites en el cual el ftp es necesario, no se recomienda el finger, porque los usuarios no lo necesitan y posibles atacantes lo pueden utilizar para obtener nombres de usuario y datos personales que luego pueden ser utilizados para intentar acceder al ftp. Cuidado !! con: -=-=-=-=-=-=-=- Los servidores de correo siempre fueron blancos faciles, cada dos por tres sale un nuevo exploit para el pop o el sendmail. El telnet es un problema debido a que realiza conexiones sin encriptar, lo cual le da la posibilidad a un invasor a obtener cuentas de este u otro server dejando algun sniffer. La solucion es utilizar ssh como se explica en la seccion -> Secure Shell Afectado por los mismos problemas estan las conexiones de rlogin y sus derivados rcp y rsh pero lo que es aun peor, que estas son conexiones del tipo confiadas, por lo cual pueden ser utilizadas sin utilizar ninguna contrase~a. El unico motivo por el cual deben estar habilitadas seria el uso de algun programa que necesite utilizarlas, si no, fuera! De mas esta recomendar cerrar el echo y el chargen, utilizados mediante tecnicas de spoofing de paquetes para sobrecargar redes hasta dejarlas inaccesibles. El finger tambien es un problema porque provee informacion personal de los usuarios, como ya se explico anteriormente. El ftp es victima dia a dia de exploitsiones, hay que tratar de tenerlo al dia con los parches. Secure Shell: _-_-_-_-_-_-_ El secure shell es un reemplazo para el telnet, que permite realizar conexiones encriptadas con un server. En realidad es mucho mas que solo un telnet, es posible realizar cualquier tipo de conexion estableciendo un canal encriptado contra un server, en dicho canal es posible establecer una comunicacion de cualquier tipo (ftp, http, irc, etc ), siempre encriptando los datos que viajan haciendo vano cualquier sniffeo (captura de paquetes) que se haga. Lo mas comun es hacer ssh a un server y ejecutar un shell. El ssh utiliza tecnicas de encriptacion con un par de llaves, una de encripcion publica y una de desencripcion privada que es utilizada con la pass frase, nada de password con esto :^). Establecer un canal seguro es muy simple, se logra con las opciones -R y -L del ssh. Utilizando TCPWrapers y ssh se pueden lograr cosas maravillosas, tales como levantar un servidor de chat en el cual todas las conexiones esten encriptadas individualmente. Que tiene que ver el tcpwrapers? Si levanto un server comun y conrriente de chat, pero en el puerto 3456, al cual mediante tcpwrapers limito las conexiones solo a localhost y hago un tunel o forward con ssh -L 6667:localhost:3456 obtengo un server de chat bajo un canal encriptado. Un cliente tiene que hacer un tunel hacia mi, posiblemente con el comando ssh -R 5555:servercrypto:6667 y luego de levantada la conexion, utiliza al cliente de chat comun pero usando de server localhost:5555. Asi se conecta al tunel seguro. Si se dispone de ssh, deshacerse del telnet. TCPWrapers: _-_-_-_-_-_ El tcpd es un ayudante genial que funciona como filtro a los servicios que provee un server. A travez de este se puede cortar el acceso a cierto servicio a cierto host o habilitarlo. Pero como si esto fuera poco, da la posibilidad de tomar acciones utilizando informacion de la conexion que se intenta realizar. Hay dos archivos de configuracion muy sencillos de utilizar: /etc/hosts.allow: -=-=-=-=-=-=-=-=- Aca se definen los servicios que SI pueden ser utilizados y por quien. /etc/hosts.deny: -=-=-=-=-=-=-=-=- Aca se definen los servicios que NO pueden ser utilizados y por quien. El formato de archivo es el siguiente: SERVICIO : HOST : MEDIDA Respecto al servicio y el host, recomiendo mirar la pagina del manual, pero la mas interesante es la de medida debido a los parametros que se pueden utilizar. Hay dos medidas interesantes, spawn y twist. Con la primera, se acepta la conexion y ademas es ejecutado un comando. Con twist, se niega la conexion y es ejecutado un comando. Para dar un ejemplo concreto: En /etc/hosts.allow: ALL : LOCAL : SPAWN (/etc/scripts/aceptada %h %d) En aceptada: #!/bin/sh echo Aceptada conexion desde "$1" en "$2" >> /root/mislogs.log date +"Dia: %D Hora: %T" >> /root/mislogs.log traceroute "$1" >>/root/mislogs.log nmap "$1" >> /root/mislogs.log echo "------------------------------------------------" >> /root/mislogs.log Esto da como resultado que cada vez que se acepta una conexion, se ejecute la script aceptada, pasandole como parametros el IP (%h) que pide el servicio local (%d). La script guarda en el archivo /root/mislogs.log el IP, el demonio, la hora y el dia, la ruta que siguen los paquetes y el resultado de un escaneo de puertos. Las posibilidades de respuesta son enormes. Firewalls ipchains: _-_-_-_-_-_-_-_-_-_ Dentro del kernel de linux se manejan los paquetes de red que van o vienen a la red. Si esta configurado, es posible que depende de donde venga, a donde va o de que tipo es, un paquete sea aceptado, descartado o negado. Esto permite controlar el trafico de la red, especialmente si este linux esta actuando de gateway entre una red y la internet. Para decidir el destino de un paquete, el kernel tiene una lista de reglas, en las que se especifica el origen del paquete, el destino, el tipo, el puerto y que accion tomar. El programa que maneja estas reglas o cadenas se llama ipchains, y sirve para agregar y borrar cadenas. Es importante el orden en que estan las cadenas, asi que tambien se pueden insertar cadenas o reemplazarlas. Una cadena puede pertenecer a tres grupos: * input : refiere a paquetes que llegan a la red. * forward: refiere a paquetes que son traspasados por la maquina. * output : refiere a paquetes que se envian desde la red. Las acciones a tomar pueden ser accept, deny y reject. La diferencia entre deny y reject es que reject informa al que envia el paquete que este fue ignorado. Una buena forma de entenderlo es a travez de ejemplos. ipchains -A input -p icmp -j DENY Agrega una cadena de entrada que se fija si el protocolo especificado en el paquete es icmp y los que lo son, son denegados. Esta cadena impide, entre otras cosas, que se respondans los ping. ipchains -A output -p tcp -s localhost -d 192.168.1.7 23 -j ACCEPT Esta cadena indica que se permitan mandar paquetes TCP desde localhost hacia 192.168.1.7 al puerto 23, lo que no seria nada del otro mundo a menos que agreguemos luego la siguiente cadena: ipchains -A output -p tcp -d 192.168.1.7 -j DENY Que impide que cualquier paquete salga hacia esa misma maquina. Con estas dos cadenas estamos logrando que SOLO se hagan conexiones al telnet de 192.168.1.7 ipchains -A forward -i ppp0 -j MASQ Esta es una cadena muy usada dado que permite que cualquier maquina envie y reciva paquetes a travez de la interfase ppp0. Y no solo hace este forward de paquetes sino que los enmascara de tal forma que cada una de estas maquinas es tomada como si fuera la que posee ppp0. Esto es llamado IP masquerading. ipchains -A input -s ! 192.168.0.1/24 22 -j REJECT Con esta cadena rechazamos todas las conexiones de tipo ssh (puerto 22) que se hagan desde cualquier maquina exexpto las que estan dentro del rango 192.168.0.1/24, que podria ser la red interna. Fin del capitulo 1 _-_-_-_-_-_-_-_-_-_ ** Espero haberle abierto la mente aunque sea a una sola persona ** Recordar que para mas detalles, estan los respectivos HOWTOS, las paginas del manual, y la documentacion propia del paquete. Saludos, GiBa. <$[ Eko Magazine 3 Revange EOF. ]$> <$$[ Seguridad en Servidores Linux, Capitulo 1: El Server y las Conexiones ]$$>