Seguridad de redes y sistemas
"La superficie de ataque más grande es el servidor que dejaste con configuración por defecto."
Qué vas a aprender en este capítulo
La seguridad de aplicaciones es una capa. Pero hay otra capa debajo: el sistema operativo, la red, los puertos abiertos, los servicios corriendo. Este capítulo cubre cómo asegurar la infraestructura: firewalls, IDS/IPS, hardening, VPNs, y el modelo Zero Trust.
4.1 Firewalls
💡 Intuición
Un firewall es como el guardia de seguridad de un edificio: revisa cada paquete que entra/sale y decide si lo deja pasar según reglas predefinidas.
La regla por defecto debe ser DENY (negar todo) y luego permitir explícitamente lo que se necesita. Lo opuesto (permitir todo, denegar excepciones) es lo que causa la mayoría de las brechas.
📐 Fundamento
Tipos de firewalls:
| Tipo | Capa OSI | Decide en base a |
|---|---|---|
| Packet filter | 3-4 | IP, puerto, protocolo |
| Stateful | 3-4 | Lo anterior + estado de la conexión (SYN/ACK/etc.) |
| Application (L7) | 7 | Contenido del paquete (HTTP, DNS) |
| Web Application Firewall (WAF) | 7 | HTTP específico (detecta SQLi, XSS) |
Reglas iptables/nftables (Linux):
# Política por defecto: DROP todo
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT # outbound permitido
# Permitir conexiones ya establecidas
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Permitir loopback
iptables -A INPUT -i lo -j ACCEPT
# Permitir SSH solo desde IP específica (jumphost)
iptables -A INPUT -p tcp --dport 22 -s 200.30.45.10 -j ACCEPT
# Permitir HTTP/HTTPS desde cualquier lado
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Logear (y dropear) todo lo demás
iptables -A INPUT -j LOG --log-prefix "FIREWALL DROP: "
iptables -A INPUT -j DROP
# Persistir reglas
iptables-save > /etc/iptables/rules.v4
ufw (Uncomplicated Firewall) — más simple:
ufw default deny incoming
ufw default allow outgoing
ufw allow from 200.30.45.10 to any port 22
ufw allow 80,443/tcp
ufw enable
ufw status verbose
Cloud security groups (AWS, GCP, Azure):
# AWS Security Group: solo permitir tráfico necesario
SecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Web server
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 22
ToPort: 22
SourceSecurityGroupId: !Ref BastionSG # solo desde el bastión
4.2 IDS, IPS y WAF
📐 Fundamento
IDS (Intrusion Detection System): detecta ataques pero no los bloquea. Solo alerta.
IPS (Intrusion Prevention System): detecta y bloquea automáticamente.
WAF (Web Application Firewall): específico para HTTP/HTTPS, detecta patrones de SQLi, XSS, etc.
Modos de detección:
| Modo | Descripción | Pros | Cons |
|---|---|---|---|
| Signature-based | Patrones conocidos | Pocos falsos positivos | No detecta ataques nuevos (0-day) |
| Anomaly-based | Desvíos del comportamiento normal | Detecta 0-days | Más falsos positivos |
| Hybrid | Combina ambos | Mejor cobertura | Más complejo |
Herramientas comunes:
- Snort, Suricata — IDS/IPS open source.
- OSSEC, Wazuh — Host-based IDS (analiza logs y archivos).
- ModSecurity — WAF open source para Apache/Nginx.
- Cloudflare WAF, AWS WAF — WAFs gestionados en la nube.
Ejemplo de regla ModSecurity (detecta SQLi):
SecRule ARGS "@detectSQLi" \
"id:1001,phase:2,deny,status:403,msg:'SQL Injection detected'"
4.3 Hardening de servidores Linux
💡 Intuición
Un servidor recién instalado es como una casa con muchas ventanas abiertas. Hardening es cerrar las que no se usan, poner cerraduras de calidad, y reforzar las puertas.
Cada servicio que corre, cada puerto abierto, cada cuenta de usuario, cada permiso es una superficie de ataque potencial.
📐 Fundamento
Checklist básico de hardening de Linux:
1. Actualizar el sistema:
apt update && apt upgrade -y
# Configurar updates automáticos de seguridad
apt install unattended-upgrades
dpkg-reconfigure unattended-upgrades
2. SSH seguro:
# /etc/ssh/sshd_config
PermitRootLogin no # nunca login directo como root
PasswordAuthentication no # solo claves SSH, no contraseñas
PubkeyAuthentication yes
Port 2222 # cambiar puerto default
AllowUsers admin osiel # whitelist de usuarios
ClientAliveInterval 300
MaxAuthTries 3
systemctl restart sshd
3. Firewall (ufw o iptables):
ufw default deny incoming
ufw allow from 200.30.45.10 to any port 2222 # SSH desde IP específica
ufw allow 80,443/tcp
ufw enable
4. Fail2ban — bloquea IPs con muchos intentos fallidos:
apt install fail2ban
# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 3
bantime = 3600 # 1 hora
5. Eliminar servicios innecesarios:
systemctl list-unit-files --type=service --state=enabled
# Desactivar lo que no se use
systemctl disable cups bluetooth ...
6. Mínimo privilegio en usuarios:
# No correr aplicaciones como root
useradd -r -s /bin/false appuser
chown -R appuser:appuser /var/app
# El servicio se ejecuta como appuser, no como root
7. Permisos de archivos sensibles:
chmod 600 /etc/shadow
chmod 644 /etc/passwd
chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys
8. Auditoría con auditd:
apt install auditd
# Auditar accesos a archivos sensibles
auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/shadow -p wa -k shadow_changes
ausearch -k passwd_changes
9. AIDE (Advanced Intrusion Detection Environment):
Crea snapshots de archivos del sistema y detecta cambios no autorizados.
apt install aide
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Diariamente:
aide --check
10. Cifrado de disco: LUKS para discos en reposo.
Herramientas de auditoría automática:
- Lynis — audita configuración de Linux.
- OpenSCAP — verifica cumplimiento con estándares (CIS, PCI-DSS).
- CIS Benchmarks — checklists detalladas por OS.
apt install lynis
lynis audit system
# Genera reporte con score y recomendaciones
4.4 VPN y arquitectura Zero Trust
📐 Fundamento
VPN tradicional (perímetro):
El usuario se conecta a una VPN para acceder a la red interna. Una vez dentro, tiene acceso amplio a recursos internos.
Usuario remoto → VPN Gateway → Red interna corporativa
│
[BD, servidores, etc.]
Problema: si las credenciales de VPN son comprometidas, el atacante tiene acceso amplio.
Zero Trust:
"Never trust, always verify." Cada acceso, incluso interno, se autentica y autoriza.
Usuario → Identity Provider → Recurso específico
↓
(decisión por request: ¿quién?, ¿qué dispositivo?,
¿desde dónde?, ¿qué hora?, ¿qué recurso?)
Implementaciones modernas:
- BeyondCorp (Google) — cada empleado se autentica para cada servicio, sin VPN.
- Cloudflare Zero Trust — proxy entre usuario y aplicaciones internas.
- Tailscale (basado en WireGuard) — VPN P2P moderna con identity-aware.
WireGuard — VPN moderna:
Más simple, más rápido, más seguro que OpenVPN/IPsec.
# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = <clave_privada_servidor>
Address = 10.0.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <clave_publica_cliente>
AllowedIPs = 10.0.0.2/32
Segmentación de red:
Dividir la red en zonas con firewalls entre ellas:
[DMZ — servidores web públicos]
│
firewall
│
[Red de aplicaciones (microservicios)]
│
firewall
│
[Red de datos (BDs, secretos)]
Si un atacante compromete un servidor web, no llega automáticamente a la BD — necesita atravesar otro firewall.
Microsegmentación: llevar la segmentación al nivel de cada workload (por servicio en Kubernetes con NetworkPolicies).
# NetworkPolicy: solo permitir tráfico al servicio de pagos desde el de pedidos
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: pagos-policy
spec:
podSelector:
matchLabels:
app: pagos
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: pedidos
ports:
- protocol: TCP
port: 8080
4.5 Ejercicios
✏️ Ejercicio 4.1 — Diseño de red segura
Diseñá la arquitectura de red de La Esquina Cloud con segmentación apropiada:
- App móvil de clientes accede vía internet.
- Tres microservicios: Pedidos, Pagos, Inventario.
- Una base de datos PostgreSQL.
- Servidor de Redis para caché.
Para cada componente: ¿en qué zona va? ¿Qué reglas de firewall entre zonas?
Solución
Zonas:
[Internet]
│
↓
[CDN / WAF (Cloudflare)] ← protege contra DDoS, OWASP Top 10
│
↓
[DMZ pública]
- Load Balancer (HTTPS terminator)
│
↓
[Red de aplicaciones (privada)]
- Microservicio Pedidos (10.0.10.0/24)
- Microservicio Pagos (10.0.10.0/24)
- Microservicio Inventario (10.0.10.0/24)
│
↓
[Red de datos (más privada)]
- PostgreSQL (10.0.20.0/24) — solo accesible desde apps
- Redis (10.0.20.0/24)
Reglas de firewall:
| Origen | Destino | Puerto | Razón |
|---|---|---|---|
| Internet | Cloudflare | 443 | HTTPS público |
| Cloudflare | Load Balancer | 443 | tráfico filtrado |
| Load Balancer | Apps | 8080 | dispatch a microservicios |
| Pedidos | Pagos | 8080 | comunicación inter-servicio |
| Pedidos | Inventario | 8080 | comunicación inter-servicio |
| Apps | PostgreSQL | 5432 | acceso a BD |
| Apps | Redis | 6379 | acceso a caché |
| Cualquier otro | Cualquier | Cualquier | DENY (default) |
Especialmente importante: la BD NO acepta conexiones desde internet ni desde el Load Balancer — solo desde la red de apps.
4.6 Para profundizar
- CIS Benchmarks (cisecurity.org) — checklists de hardening por sistema.
- NSA Cybersecurity Best Practices.
- Cloud security guides (AWS, GCP, Azure).
- Siguiente: Respuesta a incidentes.
Definiciones nuevas: firewall, packet filter, stateful firewall, WAF, IDS, IPS, signature-based detection, anomaly-based detection, hardening, fail2ban, AIDE, Lynis, CIS Benchmarks, VPN, Zero Trust, BeyondCorp, WireGuard, segmentación de red, microsegmentación, NetworkPolicy, DMZ.