Gestión de servidores web

Qué es un servidor web y cómo funciona (HTTP vs HTTPS)

Cuando sirvo una web, en realidad estoy ejecutando un software que atiende peticiones HTTP y responde con HTML, imágenes, CSS o lo que toque. Este modelo cliente-servidor vive en los puertos 80 (HTTP) y 443 (HTTPS). El navegador manda métodos como GET o POST, y el servidor contesta con códigos de estado (200, 404, etc.). Desde HTTP/1.1, el header Host le dice al servidor qué dominio se solicita, clave para alojar varios sitios en una sola máquina. Con HTTPS, la misma conversación va cifrada con TLS/SSL para proteger credenciales y datos.

Mi regla de oro: todo lo que implique credenciales o datos sensibles, por HTTPS. Es la manera práctica de evitar escuchas y manipulación de tráfico.

Checklist previo: requisitos, puertos y entorno de pruebas

Antes de tocar nada, paso por este checklist:

• Sistema objetivo: Windows Server con IIS o Linux con Apache/Nginx. Ambos hacen lo mismo (servir HTTP/HTTPS), aunque la administración cambia (IIS con GUI; Apache/Nginx generalmente por archivos de configuración).
• Puertos abiertos en el firewall: 80/443 como base.
• Prueba rápida en IIS: tras instalar el rol, navego a http://localhost y confirmo la página de bienvenida; sé que el servicio responde.
• Estructura de contenidos: en IIS, el Sitio web predeterminado apunta a C:\inetpub\wwwroot; si pongo ahí un index.html, se sirve. Luego creo sitios adicionales con su propia carpeta.
• Módulos que voy a necesitar (compresión, URL Rewrite, autenticación, CGI/FastCGI si uso PHP). Puedo añadirlos después desde Agregar roles/características.

Si esta verificación pasa, ya tengo el entorno listo para publicar y escalar.

IIS en Windows Server: instalación y primer sitio

Agregar el rol y validar wwwroot

En Administrador del Servidor → Agregar roles y características, marco Servidor Web (IIS) y, si quiero, selecciono servicios concretos (ASP.NET, CGI, autenticaciones, compresión, etc.). Tras instalar, abro un navegador y valido la página de bienvenida; ya puedo publicar en C:\inetpub\wwwroot.

Publicar contenido y tipos básicos

Para publicar, simplemente apunto el sitio a una carpeta física y dejo mis archivos. En el predeterminado, wwwroot sirve para la primera prueba. Más tarde, cada sitio tendrá su propia ruta (p.ej. D:\Webs\MiSitio).

Múltiples sitios con bindings (host, IP, puerto)

Cuando necesito alojar varios dominios en el mismo servidor, uso bindings:

• Por nombre de host (Host Header): lo normal hoy. Un único 80/443 e IIS enruta por el dominio que llega en Host. Ideal para “muchos sitios, una IP”.
• Por IP: cada sitio con su IP propia (menos común salvo requisitos concretos). SNI hizo innecesario multiplicar IPs en la mayoría de escenarios HTTPS.
• Por puerto: útil para entornos internos (ej. :8080), pero poco amigable para usuarios.

Ejemplo típico que configuro: dos sitios www.empresa1.com y www.empresa2.com en el mismo puerto 80, diferenciados por Host name; el DNS de cada dominio apunta a la IP del servidor.

Habilitar HTTPS: certificado, SNI y redirección 80→443

El flujo que sigo:

1. Obtengo/creo un certificado TLS (Let’s Encrypt para público o CA interna en corporativo).
2. Instalo el certificado en el almacén de Windows.
3. En Bindings, agrego https:443 con el certificado correcto y activo SNI si hay varios sitios HTTPS en la misma IP.
4. Fuerzo HTTPS (regla o requisito SSL) para que todo viaje cifrado.

Si uso un certificado autofirmado en producción, el navegador mostrará advertencias; para público, necesito una CA confiable.

Autenticación y autorización con NTFS

Según el contexto:

• Anónimo (IUSR) para la parte pública.
• Básica (siempre sobre HTTPS) cuando quiero algo universal y rápido.
• Digest (envía hash, no texto claro), menos común hoy.
• Integrada de Windows (NTLM/Kerberos) en intranets con Active Directory.

La autorización se decide con permisos NTFS: si el usuario autenticado no tiene lectura en la carpeta, obtendrá acceso denegado. Ajusto permisos para IUSR (anónimo) o para los grupos de dominio que correspondan.

Módulos clave: compresión, caché y URL Rewrite

Para rendimiento y control, activo:

• Compresión (estático/dinámico) para ahorrar ancho de banda,
• Caché en memoria para acelerar respuestas,
• URL Rewrite para reglas de redirección y URLs limpias,
• más lo que pida mi app (.NET, CGI/FastCGI, etc.).
  Todo esto se añade/ajusta vía roles/características si no quedó en la instalación inicial.

Si voy a servir PHP, instalo el runtime y configuro FastCGI; pruebo con un phpinfo() para validar.

Logs y diagnóstico (Failed Request Tracing)

Siempre dejo logs y activo el tracing de solicitudes fallidas cuando algo se resiste; me da visibilidad de errores y cuellos de botella.

---

Alternativas en Linux: Apache y Nginx

En Apache, habilito módulos con a2enmod (por ejemplo, rewrite, ssl, headers, php) y gestiono sitios en sites-available / sites-enabled. Los VirtualHost definen IP/puerto y ServerName y, al igual que en IIS, el enrutado se basa en el header Host.

Para HTTPS en Apache, activo mod_ssl y configuro certificados; en Nginx, uso listen 443 ssl con ssl_certificate y ssl_certificate_key. La idea es la misma: negociar TLS y servir HTTP dentro del canal seguro.

Aunque la experiencia de administración difiere (GUI vs edición de archivos), en esencia los tres—IIS, Apache, Nginx—atienden 80/443, soportan múltiples sitios y módulos, y ofrecen autenticación y lenguajes del lado servidor.

Buenas prácticas de seguridad y rendimiento

Mi receta mínima:

• Menos es más: desactivo módulos y funciones que no uso (p.ej., Directory Browsing, métodos HTTP poco comunes).
• Filtrado de solicitudes: bloqueo extensiones y patrones peligrosos, limito tamaños de subida.
• Principio de mínimos privilegios: el servicio y los Application Pools con derechos limitados; nunca como admin.
• Actualizaciones al día de IIS/Apache/Nginx.
• Firewall: solo puertos necesarios (80/443) y, si procede, restrinjo paneles a IPs de confianza.
• Logs y monitorización constante para detectar errores e intentos de intrusión.
• Compresión + caché para mejorar latencia y consumo.

---

Errores comunes y cómo solucionarlos

• 403 – Prohibido: casi siempre permisos NTFS. Reviso si IUSR o el usuario autenticado tienen lectura en la carpeta del sitio.
• 404 – No encontrado: ruta física mal configurada o binding/host que no coincide con el dominio solicitado. Confirmo carpeta y Host name.
• 500 – Error del servidor: módulo/lenguaje no instalado o mal enlazado (p.ej., PHP sin FastCGI). Activo el módulo correcto y pruebo con phpinfo().
• Advertencias SSL: certificado autofirmado o no confiable. En producción, uso certificados de CA reconocida; en intranet, CA corporativa.

FAQs rápidas sobre gestión de servidores web

¿Puedo alojar varios dominios en una sola máquina?
Sí; usa host headers/ServerName y un único 80/443. Con SNI también compartes 443 con varios certificados.

¿Qué autenticación elijo?
Para público: anónimo; para acceso simple: básica sobre HTTPS; en intranet AD: Integrada de Windows. Ajusta NTFS para autorizar.

¿Qué módulos son imprescindibles al empezar?
Compresión, caché, URL Rewrite y el runtime de tu stack (ASP.NET/CGI/FastCGI). Se agregan desde características del servidor.

¿Cómo verifico que PHP está operativo en IIS?
Configuro FastCGI y pruebo con un phpinfo() servido por IIS.

Conclusión

La gestión de servidores web se gana con método: entiende HTTP/HTTPS, domina bindings y certificados, controla autenticación+NTFS, y activa solo los módulos que aportan. Con buenas prácticas (mínimos privilegios, filtrado, parches, firewall y logging) te llevas un entorno fiable y ágil, listo para crecer.