eko nº4:(Eko#04PD-11.txt):11/07/2002 << Back To eko nº 4
<-[-]-[-]-[E]-[Z]-[K]-[R]-[A]-[C]-[H]-[O]-[ ]-[T]-[E]-[A]-[M]-[-]-[-]-> > Eko Magazine #04 Post Devaluation, La Odisea del Patacon 2002 < <------- [ SiS_d0wn #Col ] ------------ [ sisdown@server.com.ar ] ----> > Configurando APACHE (v1.3.x) < 1- Introduccion Se trata de un servidor web(para linux y otros UNIX, que hace temblar a microsoft), que tambien puede servir para intercambiar info en una red local y en internet. Mas del 60% de los sitios web corren sobre APACHE y el resto corren sobre otros en los que se incluye el maldito IIS(Internet Information Service de microsoft). Ademas: es gratis...es poderoso, flexible y muy configurable. Se encuentra en todas las distribuciones GNU/Linux y generalmente corre automaticamente cuando carga Linux, sino lo pueden bajar de www.apache.org, ademas este texto les puede llegar a servir de motivacion para seguir averiguando. 2- Empezando... Probemos como anda yendo a http://localhost/ o http://127.0.0.1/ , si esta corriendo nos aparece un mensaje de binvenida, sino pude ser que no este instalado o no este el script en /etc/rc.d. APACHE nos probee de una herramienta llamada apachectl que nos permite realizar algunas pruebas y se debe ejecutar en consola, no en XWindows. Algunos comandos son: start para iniciar el servidor apache . stop para detener el apache(manda una se±al SIGKILL al proceso padre) . restart para reiniciar apache(manda una se±al SIGHUP) . graceful para reiniciar (se~al SIGWINCH)pero con mas "onda" para los clientes. fullstatus muestra el estado de todos los procesos de apache (se necesita Lynx, y el modulo status: mod_status habilitados) . status como fullstatus pero mas reducido . configtest comprueba los archivos de configuracion de apache . help el nombre lo dice. No voy a hablar de las opciones del binario de apache en si (httpd) ya que todas pueden ser controladas del archivo de configuracion en /etc/httpd o en /etc/apache/conf. El archivo de configuracion httpd.conf tiene 3 partes en las que se describen diferentes aspectos del servidor: - contiene directivas que controlan aspectos globales del servidor - directivas que controlan aspectos del host no virtual, es decir, el host por defecto administrado por apache. - directivas para la configuracion de hosts virtuales . Existen muchas directivas, de las cuales se usan solo algunas. OJO(por ojo te como), para las directivas en que tengamos que poner un directorio hay que anteponer una barra(/) porque sino se le agrega adelante el contenido de la directiva ServerRoot, formando asi un path aboluto y no relativo, pero bue, sigamos...en que estabamos mm a ...en la mayoria de los casos, a menos que seamos expertos, no se justifica meter mano en el archivo de configuracion. Ahora tratemos de configurar algunas cosas inportantes. Debemos editar las directivas ServerName y ServerAdmin. En ServerName debemos poner el nombre completo del dominio(ej www.lammer.com) y en ServerAdmin la direccion mail del Webmaster(yo@lammer.com), puede ser culquier direccion de mail, incluso las que no son del tipo @nombredelservidor.com. Tambien tenemos que modificar ServerRoot (es el directorio raiz de apache, de donde descenderan los directorios conf y logs, con los registros de uso del servidor). Luego debemos editar el DocumentRoot(que es el path que llega a htdocs, donde se guardan los .html, jpg, etc.). Podriamos modificar tambien LogLevel(donde definimos lo que apache tiene que guardar en el log de errores, definido en la directiva ErrorLog). Podemos definir el archivo donde se grabara el regitro de uso en CustomLog. 3- Hosts virtuales Cuando en un mismo servidor hay diferentes sitios a esto se lo llama "virtual hosting". Podemos agregar varios hosts virtuales en la parte tres (lo antes explicado) del archivo de configuracion de apache. La primera definicion de un host virtual es la que se usa cuando alguien pone directamente nuestra IP en su navegador, en lugar del nombre de nuestro dominio. Un ej de agregar un virtual host seria: <VirtualHost*> ServerAdmin yo@lammer.com DocumentRoot /www/docs/lammer.com ServerName lammer.com ErrorLog logs/lammer.com-error_log CustomLog logs/lammer.com-access_log common </VirtualHost> <VirtualHost_default_:*> </VirtualHost> Asi podemos agregar tantos grupos <VirtualHost> </Virtualhost> como se nos cante...eee...una cancion. 4- Temas de Seguridad Todos piensan que por tener Linux, tienen un sistema operativo mas que SEGURO. Y estan en un error404 (jaja, es el mas comun, que chistoso que soy) nada es seguro. Lo que si es que hay que tener un poquito de ganas y probar o averiguar sobre seguridad en linux y apache. Por ej pueden bajarse la guia de ca0s de como asegururar tu linux (que cubre los aspectos mas importantes), o la guia de polos sobre ipchains (firewall del kernel), de la pagina www.ezkracho.com.ar (faaa, mira que lindo chivo). Ademas esta lleno de tutoriales por la web, ponganse las pilas y que no les caiga todo de arriba que es donde estoy yo, arriba en lo mejor jaja (si arriba, en el piso de arriba de tu casa, mmmmm chiste malo). Bue pongamonos serios :)...a continuacion, los principales puntos para asegurar apache. -Proteccion de archivos Este es el primer aspecto que debemos tener en cuenta. Generalmente, cuando se inicia apache tiene privilegios de administrador, que luego se abandonan y los procesos funcionan bajo el usuario definido con la directiva "User". Las aplicaciones que el root corre deben estar protegidas contra escritura de terceros. Imaginen que algun usuario sin privilegios pudiera remplazar el comando login, por una version que guarde la clave de todos los usuarios un archivo...feo, muy feo, pero divino a la vez :). Entonces dejemos de hablar y coloquemos correctamente los permisos en el directorio que especificamos la directiva ServerRoot (generalmente /usr/local/apache): root@SiS_d0wn~# mkdir /usr/local/apache root@SiS_d0wn~# cd /usr/local/apache /usr/local/apache~# mkdir bin conf logs /usr/local/apache~# chown root. . bin conf logs /usr/local/apache~# chmod 755 . bin conf logs Ahora demosle los privilegios root al binario httpd: /usr/src/apache-1.3/src~# cp httpd /usr/local/apache/bin /usr/src/apache-1.3/src~# chown root /usr/local/apache/bin/httpd /usr/src/apache-1.3/src~# chmod 511 /usr/local/apache/bin/httpd Otra situacion vulnerable es cuando tenemos el archivo /root/public_html como un vinculo simbolico a la raiz del sistema de archivos. Si apache esta configurado para que cada usuario pueda tener un sitio dentro de su subdirectorio public_html, la URL http://localhost/~root apuntaria a la raiz del sistema y cualquier navegante podria navegar todo nuestro sistema de archivos (que lindo no? lastima que la gente de apache ya lo penso eso), ahora agregemos el siguiente bloque al httpd.conf para solucionar el problemilla: <Directory /> Order Deny,Allow Deny from all </Directory> Ahora debemos permitir el acceso a las areas del sist. de archivos que deseemos: <Directory /home/*/public_html> Order Deny,Allow Allow from all </Directory> <Directory /usr/local/apache> Order Deny,Allow Allow from all </Directory> -Scripts CGI y SSI SSI (Server Side Includes o Agregados del lado del servidor), si esta mal configurado puede llegar a permitir que cualquier usuario pueda ejecutar cualquier programa en el server. La solucion es muy simple: agregamos el parametro IncludesNOEXEC a la directiva options de httpd.conf y listo el pollo (ahora escupilo). Pasemos ahora a los scripts CGI, que son el principal motivo para protejer su sitio o el servidor. La mayoria de las secuencias CGI estan basadas en shell ya que utilizan los programas interpretados perl o C-shell en vez de programas compilados. Por esto, muchos de los ataques estan referidos a explotar utilidades de estos shells. Con esto no pretendo explicar al maximo la seguridad en CGI pero va a ser una ayuda. Las contramedidas para esto serian la practica de codificacion segura. Un tipico ataque por Common Gateway Interface(aunque esta un poco anticuado). http://www.lammer.com/cgi-bin/phf?Qualias=x%0a/bin/cat%20/etc/passwd con esto conseguiriamos el deseado archivo de contrase~as, como vemos es una vulnerabilidad muy da~ina. Una de las contramedidas conocidas para esta vulneravilidad (tambien llada phf) es borrar el archivo de comandos de nuestro servidor web (cosa que no recomiendo), en cuanto a prevencion esta lleno de programas asi que con un poco de ganas los consiguen... -Los usuarios Bue, eee digamos que nosotros configuramos muy bien el sistema, le ponemos directivas muy piolas y todo, pero viene un usuario, crea un archivo .htaccess en su directorio public_html y lo configura de tal forma que se puede saltar algunas de nuestras medidas de seguridad. Bien, esto es posible porque apache permite que se coloquen directivas en sus archivos .htaccess, pero como la gente de apache no es boluda, crearon directivas para que lo anterior no se pueda hacer, simplemente debemos escribir esto en httpd.conf y luego se deben configurar los demas directorios tal como se vio antes: <Directory /> AllowOverride None Options None Allow from all </Directory> La mejor manera de correr apache es con un usuario con pocos privilegios y asegurandonos de que tenga acceso por debajo del minimo aceptable para un usuario comun (a esto me referia cuando hablaba de que el root abandone los procesos y pase a funcionar apache con un administrador con menos privilegios "User"), todo esto sirve por si en algun momento quiebran la seguridad de nuestro sistema a traves de apache, solo dispongan de una cuenta con tan pocos privilegios que (les dara lastima y se van) veran limitada la posibilidad de hacer algo sin que nosotros nos demos cuenta. Aunque hagamos todos estos esfuerzos el atacante con el metodo de escalar privilegios igual podria hacernos algo, por eso hay que reducir al maximo la cantidad de aplicaiones que el usuario pueda correr. -Generales Apache posee una opcion llamada Indexado Automatico de Directorios, esto hace que cuando un cliente solicita un directorio que no contiene ningun tipo de archivo index.html, se muestran todos los archivos de el directorio (cosa que no permite una privacidad total :) ), para desactivar esto le cambiamos los permisos al directorio (SOLO al directorio, NO a los archivos): root@SiS_d0wn~# chmod 411 /directorio/protegido pero si lo que queremos es que los clientes no vean ciertos archivos utilizamos IndexIgnore: IndexIgnore */.??* *~ *# */HEADER* */README* en el index no apareceran ni archivos de backup, ni de header ni de readmes. Tambien se pueden poner conbinacion y clave a ciertas areas del sitio, el metodo seria crear un archivo .htaccess en el directorio que se quiere proteger, por ej: AuthName restricted stuff AuthType Basic AuthUserFile /usr/local/apache/users require valid-user con esto cuando el usuario quiera ingresar al directorio se le pedira nombre de usuario y clave. Para crear y agregar un usuario a esta base de datos tambien podemos usar el htpasswd: root@SiS_d0wn~# htpasswd -c /usr/local/apache/users usuario_a_agregar y de ahora en mas si queremos seguir agregando usuarios, NO deberemos usar el modificador -c. Los metodos para autentificar pueden ser muy variados. Pueden ser bases de datos de tipo archivo plano: MySQL o DBM. Tambien es posible utilizar el sistema PAM o /etc/passwd. Si queremos que se pueda acceder a un directorio que se encuentra fuera del directorio especificado en DocumentRoot, debemos crear un alias en el archivo httpd.conf: alias /nombre_alias/ /directorio/al/cual/acceder Aunque esta no es una practica muy segura, debemos conocerla para saber evitarla y/o asegurarla en caso de necesidad. -Logs de Apache Apache nos provee de dos registros, uno corresponde al uso de servidor web y el otro a los errores: access_log y error_log. El access_log: Generalmente se encuentra en /usr/local/apache/logs/access_log y contiene informacion sobre nuestros visitantes. Una linea comun del registro access_log seria: 127.0.0.1 --- [18/Nov/2001:02:21:46 -0300] "GET /HTTP/1.0" 200 4571 Este es el formato por defecto, si lo queremos modificar utilizamos la directiva LogFormat en httpd.conf. Por ej: LogFormat "%hl%ll%ul%tl%rl%sl%b" Algunos de los codigos % mas usados son: %b Bytes enviados %f Archivo %h Host que se conecto %l Usuario remoto(si usa inetd) %r Primera linea de la solicitud http %t La hora en formato comun %T Tiempo que se tardo en la solicitud %s Estado de la solicitud %u Usuario, en caso de .htaccess %U URL solicitada %{user-agent}i Naveador utilizado El error_log Este registro contiene todos los errores que surgieron durante la sesion con apache, tambien tiene mensajes de diagnostico y avisos de inicio y deteccion del server. Cuando tenemos un problema que no sabemos de donde viene, lo mejor es poner la directiva LogLevel en "debug", para obtener info de lo que esta pasando. Los mensajes de error de CGI son los que el programador del script introdujo en la salida de errores estandar (stderr). Tambien estan los errores relacionados con los documentos (del tipo 400: el tipico 404 o el 403, relacionado con lo antes visto sobre contrase~as en directorios). Para finalizar con el tema de los logs les dejo direcciones de algunos programas que controlan el access_log: Analog(www.statslab.cam.ac.uk/~sret1/analog/), este programa es utilizado por el 29% de los servidores web. Nos provee de muchisima informacion y de un "reporte ejecutivo" listo para mostrarle al jefe de sistemas. Buenisimo(pero no lo probe) . WWWStat(www.ics.uci.edu/pub/websoft/wwwstat/), es rapido completo y libre. Que mas podemos pedir. Tambien en la pagina hay un paquete adicional que genera lindos graficos. 5-Apache Toolbox Hay una sigla que claramente refleja la tendencia actual sobre servidores: LAMP (Linux,Apache,MySQL y PHP, Perl o Phyton). Estos tres ultimos son lenguajes de scripting, como el ASP, pero mucho mas poderosos y que tambien estan disponibles para plataformas UNIX. Piensen que el 62% de los servidores web no solo utilizan apache sino la combinacion LAMP. Con respecto a las letras "LA" de LAMP, no hay problema... MySQL viene con toda buena distribucion . Pero la letra "P"...es un problema aparte, (segun me comentaron) instalar PHP es un terrible dolor de neuronas, no se si es mejor drogarse o instalar PHP. Pero existe un script llamado Apache ToolBox mas que util que se encarga de este proceso. Esta dise~ado y escrito por Bryan Andrew, y nos provee de un menu que nos permite, automaticamente, bajar y compilar una instalacion LAMP completa. Soporta Apache, SSL, PHP, MySQL, OpenLDAP y mod_gzip. Es tan util como nmap para un hacker o un pedo para el intestino (que?). Existen dos versiones de Apache Toolbox: una completa que trae todos (pero todos) los programas y modulos que soporta, y el script para ayudarnos en la instalacion. El programa se ejecuta simplemente desde la linea de comandos y debe ser ejecutado somo root, para poder instalar los componentes deseados en los directorios del sistema. El primer paso es elegir los componentes a instalar, desde el menu principal. Los comandos se escriben y los cursores no se utilizan. Para marcar o desmarcar una opcion, simplemente tipeamos el numero o palabra que corresponda y presionamos la tecla <ENTER>. El comando 99 puede sernos util ya que nos brinda las descripciones de los paquetes. El primer paso, luego de ejecutar el comando GO (que inicia el proceso de descarga e instalacion), es el de chequear posibles conflictos RPM. A continuacion nos pide que indiquemos en que directorio se instalara (o esta instalado) Apache (generalmente, /usr/local/apache). Si algun paquete no se encuentra y resulta necesario, el script nos da la opcion de bajarlo automaticamente. Luego, el verdadero proceso de configuracion e integracion entre los diferentes modulos y Apache comienza. De todo esto somos bien informados en pantalla. Generalmente, todos los programas de GNU/Linux nos informaran que es lo que estan haciendo exactamente. El mejor ejemplo es el inicio del sistema o no? Bueno como ultimos dos pasos, el script nos da la posibilidad de editar el archivo de configuracion de la compilacion de apache, y luego de hacer esto, debemos ejecutar: root@SiS_d0wn~# cd apache ~/apache# make ~/apache# make test (con esto vemos si todo va bien y luego si va bien le damos al...) ~/apache# make install ...y listo... 6-Conclusion Como pudimos ver, APACHE, no es un simple programita para levantar un site, sino un completo y poderoso (como me gusta esa palabra) paquete que ofrece la ultima tecnologia disponible, se preocupa por la seguridad y brinda (y solicita) a los usuarios apoyo de diferentes formas. No por nada es el servidor web mas utilizado en el mundo. No tomen este texto como el escrito final ya que es solo un introduccion, pero pueden seguir averiguando en los HOW-TO e internet. Igualmente escribire la segunda parte de este texto con otras tecnicas avanzadas, etc. Tambien voy a escribir sobre hackeo de servidores web, y voy a hacer enfasis en APACHE e IIS. Cualquier comentario o critica constructiva: yo@mimail.com.ar Saludos: A TODO el eko team, al dr_fdisk^ y a todos aquellos que como yo, tienen ansias de aprendisaje... > Eko Magazine #04 Post Devaluation, La Odisea del Patacon 2002 < > Configurando APACHE (v1.3.x) < [EOF]