Despliegue de aplicaciones web
Tutorial Apache
Revisado Noviembre 2024
Licencia
Reconocimiento – NoComercial - CompartirIgual (BY-NC-SA): No se permite un uso
comercial de la obra original ni de las posibles obras derivadas, la distribución de las cuales
se debe hacer con una licencia igual a la que regula la obra original.
Nomenclatura
A lo largo de este tema se utilizarán distintos símbolos para distinguir elementos importantes
dentro del contenido. Estos símbolos son:
📖 Importante
❕ Atención
💬 Interesante
ÍNDICE DE CONTENIDO
1. Introducción 4
2. Comandos 4
3. Cambios en la configuración por defecto 5
4. Virtual Hosts (Hosts virtuales) 9
5. HTACCESS 13
5.1 Impedir listar directorios 13
5.2 Redirecciones - DirectoryIndex 15
5.3 Redirecciones - Errores 15
5.4 Redirigir al dominio principal 16
5.5 Redirigir a una web de mantenimiento 17
6. HTTPS 18
7. CORS 22
8. Autenticación HTTP 25
9. Bibliografía 27
10. Autores (en orden alfabético) 27
04. SERVIDORES WEB
1. INTRODUCCIÓN
A continuación, iremos viendo de una forma más guiada algunos de los aspectos vistos en la teoría
sobre la configuración de apache, por lo tanto, inicia tu máquina virtual de Ubuntu y vamos a ello!
Antes de empezar MUY IMPORTANTE, cuando estamos trabajando con estas configuraciones, es
posible que el navegador almacene en caché cambios anteriores, por lo tanto, a la hora de realizar
pruebas y cuando tengas que refrescar una página en el navegador, te recomiendo que lo hagas
con la combinación de teclas “shift + ctrl + r”, esto hace que se elimine la caché y se refresque la
página en cuestión.
2. COMANDOS
Para empezar, vamos a ver los comandos básicos, concretamente uno de los más utilizados es el de
“status” comando que nos servirá para comprobar si el servicio de apache2 está funcionando:
Como vemos, el servicio está arrancado y funcionando correctamente, por lo tanto, podemos
continuar probando diferentes aspectos de Apache.
Vamos a navegar al directorio /etc/apache2 ya que vamos a tocar determinados aspectos de la
configuración:
3. CAMBIOS EN LA CONFIGURACIÓN POR DEFECTO
Vamos a editar el fichero de configuración general [Link] y vamos a visualizar este
apartado:
El directorio /var/www/ es el directorio principal donde trabajará Apache2 y que por lo tanto, este
directorio tiene que ser accesible como se indica con la directiva Require.
Si hacemos una prueba tanto desde la máquina virtual como desde la máquina anfitrión,
funcionará:
Vamos a hacer un pequeña prueba y vamos a permitir únicamente las conexiones desde la
máquina anfitrión, para ello, comprueba la IP de tu máquina anfitrión y haz el siguiente cambio:
Como puedes ver, he comentado las líneas que venían por defecto, de esa forma, cuando volvamos
a dejarlo como estaba no estoy perdiendo nada. Las líneas comentadas no afectan.
He añadido la línea “Deny from all” esto bloqueará las conexiones desde cualquier lugar.
Guarda los cambios e importante “Reinicia Apache” para que se apliquen los cambios.
● En este punto un aspecto importante, si utilizas “restart” se paralizarán
momentáneamente TODOS los servicios de apache hasta que arranque de nuevo, eso
significa que si tuvieras varias aplicaciones web funcionando en este servicio se pararán las
conexiones, imagínate que tienes una tienda online, reinicias el servicio y resulta que había
un cliente realizando un pedido, esto es crítico.
● Por lo tanto, utiliza mejor “reload” de esa forma se recargan los cambios pero sin cortar las
conexiones que hay activas.
Prueba de nuevo a acceder desde ambas máquinas.
Hemos bloqueado las conexiones con la directiva anterior, ahora vamos a permitir únicamente las
conexiones desde la máquina anfitrión:
Reinicia apache y verás que ahora sí puedes acceder:
Deja la configuración como estaba inicialmente.
Vamos a cambiar ahora el puerto por defecto, en lugar de ser ahora el 80 vamos a poner el 82:
Modifica el fichero “[Link]” y cambia esta línea.
Además, como bien indica el comentario de ese fichero, tendremos que modificar también el
puerto en el virtualhost por defecto, por lo tanto, modifica el VH [Link] y cambia
también el puerto:
Una vez hayas guardado los cambios y reiniciado apache, no podrás acceder ya que los
navegadores utilizan el puerto 80 por defecto:
Por lo tanto, si quisiéramos acceder, habría que especificar el nuevo puerto:
Vuelve a dejarlo todo como estaba.
4. VIRTUAL HOSTS (HOSTS VIRTUALES)
Vamos a crear ahora varios hosts virtuales de forma que vamos a tener varios sitios webs en un
mismo servidor. Vamos a crear los sitios web: [Link] y [Link]
Lo primero que vamos a hacer es crear estas webs, por lo tanto, en /var/www/html, crea una
carpeta para instituto y otra para tienda (recuerda crear la carpeta public_html), y un archivo
[Link], (añade algo al html para que se visualice posteriormente) deberá quedar de la
siguiente forma:
/var/www/html:
● instituto
○ public_html
■ [Link]
● tienda
○ public_html
■ [Link]
Vamos a probar que funcione accediendo directamente:
A continuación, vamos a configurar los VirtualHosts, vamos primero con el del instituto, para ello
en /etc/apache/sites-available, crea el archivo [Link], deberá tener el siguiente
contenido:
Como vemos, el dominio principal será el .com y hemos añadido varios alias porque vamos a
simular que hemos comprado más dominios, como el .es y el .org.
Ahora, vamos a habilitar esta configuración, por lo tanto, utilizamos el comando pertinente:
Comprueba que aparece en “sites-enabled”:
Y recarga apache.
Haz exactamente lo mismo para la web de la tienda, pero cambiando los datos a los de la tienda.
Ahora ya debería de funcionar, pero como vimos en teoría, si ponemos en el navegador el dominio,
como nuestro equipo no sabe resolver ese dominio, tenemos que especificarlo en el archivo
“hosts” de TODOS los equipos de los que queramos probar, por lo tanto, vamos a probar primero
desde la máquina virtual, para ello, modifica el archivo /etc/hosts y añade:
No es necesario reiniciar apache ya que /etc/hosts no es ninguna configuración de apache.
Ahora sí, prueba todos los dominios y deberán cargar tus sitios web:
Haz lo mismo desde la máquina anfitrión, tendrás que modificar el archivo hosts de tu máquina
anfitrión y añadir las mismas líneas, si es windows, mira la teoría para saber la ruta del archivo.
Vamos a probar a personalizar el error 404 en la web del instituto, después, veremos cómo hacerlo
en la web de la tienda, pero en esa ocasión utilizaremos .htaccess.
Actualmente, si pruebas a poner una URL que no existe, obtendrás una página por defecto que
pone Apache para 404:
Vamos a modificar este comportamiento, lo primero de todo, crea tú propia página de error 404 y
añádela a la carpeta /instituto/public_html, llámala [Link].
Prueba a acceder directamente a tu HTML para ver que funciona:
Ahora, vamos a modificar el comportamiento, edita el .conf de sites-available correspondiente a
esta web y añade:
Guarda los cambios, reinicia apache y prueba a acceder a cualquier ruta que te inventes y que no
exista:
5. HTACCESS
Antes de empezar a tocar nada, vamos a habilitar el htaccess en apache, para ello modifica el
fichero [Link]
Esta opción bloquea los .htaccess que hayan en el directorio especificado y sus directorios hijos,
por lo tanto, si queremos que funcionen los .htaccess que creemos, debemos habilitarlo:
Habilita el módulo para las redirecciones:
Y reinicia apache.
Importante: cuando realices cambios en ficheros .htaccess NO es necesario reiniciar apache.
5.1 Impedir listar directorios
Prueba lo siguiente:
Por defecto, si accedes a cualquier dirección de tu servidor web que no tenga un [Link], va a
cargar el listado de los elementos. Esto es un fallo de seguridad, por lo tanto, vamos a bloquearlo.
Primero vamos a hacerlo en la web del instituto, por lo tanto, en /var/www/html/instituto, crea
un archivo .htaccess con el siguiente contenido:
Comprueba que ahora ya no te permitirá acceder, pero a la web de la tienda si:
Este comportamiento no lo queremos, por lo tanto, dos opciones, o bloqueas cada web de forma
individual, o bloqueas desde la raíz. Vamos a hacer la segunda opción, mueve el fichero .htaccess a
/var/www/html. De esta forma, ya no podrás acceder a nada:
5.2 Redirecciones - DirectoryIndex
Vamos a probar varias redirecciones.
Vamos a cambiar el [Link] por [Link]
Al hacerlo, si intentas acceder, te saldrá acceso prohibido, el motivo el el siguiente:
● Como hemos quitado el [Link], apache al no encontrar el fichero por defecto a cargar,
intenta listar el contenido del directorio de esa dirección, pero como hemos bloqueado esa
posibilidad, nos aparecer el error.
Para solucionarlo, vamos a crear el archivo .htaccess en public_html y añade lo siguiente:
Si vuelves a probar, ya funcionará de nuevo, hemos cambiado el comportamiento de apache para
que busque un [Link] antes que un [Link]:
5.3 Redirecciones - Errores
Vamos a probar a modificar la página de error 404, ya lo habíamos hecho, pero ahora vamos a
hacerlo en la web de la tienda y en esta ocasión haciendo uso de .htaccess.
Para ello, crea la página [Link] en el directorio public_html de la tienda y prueba primero
que funcione:
Ahora, crea un archivo .htaccess en public_html de la web de la tienda con el siguiente contenido:
Y prueba a acceder a cualquier dirección que no exista:
Como puedes ver, has hecho el mismo cambio que en el instituto, pero en este caso no has
necesitado privilegios de administrador, ni reiniciar apache y sin necesidad de acceder a la
configuración de Apache.
5.4 Redirigir al dominio principal
Vamos ahora a realizar una prueba muy interesante, consistirá en redirigir TODO el tráfico al
dominio principal. En nuestros ejemplos tenemos varios dominios, pero nuestro dominio principal
es el .com, vamos a hacer que siempre que se intente acceder a www, .es o .org, redirija a .com.
Esta práctica es muy importante para el tema del SEO de la web ya que afecta tener varios
dominios.
Modifica el archivo .htaccess del instituto que previamente hemos creado y añade lo siguiente:
Prueba a acceder a cualquiera de los dominios que hemos creado, www, .es o .org y verás que
siempre te va a redirigir al .com
5.5 Redirigir a una web de mantenimiento
¿Qué pasaría si un día tenéis que subir un cambio muy importante o habéis encontrado un bug
de seguridad y necesitáis solucionarlo con urgencia? utilizar una web de mantenimiento, es decir,
una web alternativa donde se redirige a los usuarios momentáneamente hasta que la web esté
funcionando correctamente.
Para ello, vamos primer a crear la web de mantenimiento, ésta será un nuevo VirtualHost llamado
[Link], por lo tanto, haz lo necesario para que funcione y se muestre correctamente:
Una vez tengas lo anterior, modifica el .htaccess del instituto y añade los siguientes cambios:
Primero, hemos comentado las líneas para que no se apliquen, ya que no queremos realizar esas
acciones, lo que ahora queremos es redirigir SIEMPRE a la web de mantenimiento.
Pruébalo y verás que siempre que intentes entrar a la web del instituto, te redirigirá a la web de
mantenimiento (incluso si accedes con los alias).
Si quieres volver al paso anterior, comenta la regla de redirección de mantenimiento y habilita las
otras y volverás al estado anterior.
6. HTTPS
Vamos a hacer segura la comunicación de la web del instituto, para ello vamos a crear un
certificado SSL/TLS.
1º Creamos la llave
(El destino es indiferente ya que posteriormente moveremos los archivos que se generen)
2º Generar el CSR
3º Generar el certificado definitivo
4º Ubicar los archivos
● El .crt lo movemos a /etc/apache2/tls/certs
● El .csr y .key a /etc/apache2/tls/private
(Crea los directorios si no existen)
5º Habilitamos el módulo de SSL por si no estuviera activado
Y reiniciamos apache.
6º Activamos el SSL en el Virtual Host de la web del instituto
7º Probamos que funcione
8º Redirección A HTTPS
Una práctica que se suele realizar es la redirección a HTTPS, es decir, si la web permite conexión
por HTTP, podemos hacer que todas las peticiones vayan redirigidas a HTTPS, ya que si pruebas a
entrar por HTTP funciona:
Para hacer ese cambio, tenemos que modificar el .htaccess y lo dejamos de esta forma:
Comentamos las líneas que redirigen todas las peticiones al dominio principal porque lo que
hemos hecho con las nuevas reglas es hacer todo el trabajo de una vez, es decir:
● Hemos añadido 2 condiciones, una que se aplicará cuando la petición venga de cualquier
dominio pero venga en HTTP, si esto pasa, redirigimos al dominio principal en HTTPS.
● Y si viene alguna petición con HTTPS pero no viene del dominio principal, también la
redirigimos al dominio principal.
IMPORTANTE: el significado de la R significa redirección, el código 301 o 302 significa lo siguiente:
● 301 se utiliza cuando la redirección es definitiva, por ejemplo, en nuestro ejemplo anterior
deberíamos de haber puesto 301, pero si lo hacemos hay problemas con la caché y como
estamos haciendo pruebas lo dejamos así, pero en producción deberíamos poner 301 ya
que lo normal es que si pasamos a HTTPS sea definitivo.
● 302 se utiliza cuando la redirección es temporal, en este caso en la regla para el caso de la
web de mantenimiento, sí es correcto utilizar 302 ya que es una redirección temporal.
7. CORS
Vamos a simular un error de este tipo. Reutilizaremos las webs del instituto y tienda. Haremos que
desde la web tienda haga una petición HTTP a un recurso de la web del instituto, como el cross
origin está rechazado por defecto, no funcionará.
Primero crea el archivo [Link] en public_html del instituto:
Segundo, añade la página [Link] en public_html de la tienda:
Como vemos desde la tienda estamos haciendo una petición al instituto.
Ejecuta en el navegador esta última página, pero antes de hacerlo, abre el inspector de elementos
y ponte en la pestaña consola, ya que el error lo vamos a ver en la consola de javascript:
Como vemos nos está dando el error de CORS.
Para solucionarlo, tenemos que hacer que el instituto acepte este tipo de peticiones ya que por
defecto las está rechazando. Por lo tanto, modifica el .htaccess del instituto y deberá quedar así:
● Hemos quitado la L de la primera redirección ya que queremos que se pueda realizar
también la segunda RewriteRule que hemos puesto.
● La segunda RewriteRule se utilizará únicamente en peticiones de tipo OPTIONS.
● El resto de Headers son para permitir referencias cruzadas desde cualquier origen y
cualquier petición HTTP de la lista que hemos puesto, si viniera otra petición distinta, daría
error.
IMPORTANTE: antes de probarlo hay que habilitar el módulo “headers”:
Prueba de nuevo y verás como el error ha desaparecido y se han obtenido correctamente los datos
solicitados:
Es importante recalcar que normalmente trabajaréis con frameworks, estos frameworks ya vienen
preparados, es decir, suelen tener un módulo para el CORS y simplemente con habilitarlo sería
suficiente, no tendríamos que hacer nosotros el código manualmente, pero es importante que
sepáis de dónde viene todo esto, además de que os podéis encontrar ocasiones en las que sí
tengáis que hacerlo vosotros.
8. AUTENTICACIÓN HTTP
Vamos a probar la autenticación HTTP, para ello, vamos a crear una nueva Web (y por lo tanto un
nuevo VH) llamada [Link]. Accede para ver que funciona correctamente:
Vamos a proteger la web, primero, instalamos (si no lo tenemos ya) la librería apache2-utils:
Y creamos uno o dos usuarios para la autenticación por HTTP:
Como el fichero .htpasswd no
existe, el primer usuario lo creo
con la opción -c (también
podemos crear nosotros el
fichero vacío manualmente)
Compruebo que efectivamente se haya creado el fichero y aparezca mi usuario:
Y añado la configuración en el VH para proteger el directorio (se podrían proteger directorios
secundarios de una web, pero en este caso voy a proteger la web completa):
Reinicio apache:
Pruebo a entrar de nuevo y veo que efectivamente me pide la autenticación:
9. BIBLIOGRAFÍA
[1][Link]
aring&ouid=a116147572324137680319&rtpof=true&sd=true
10. AUTORES (EN ORDEN ALFABÉTICO)
A continuación ofrecemos en orden alfabético el listado de autores que han hecho aportaciones a
este documento.
● Miguel Mira Flor