   <- [ 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 ]$$>
