Arch Linux después del install: hardening, AUR seguro y servicios esenciales para sysadmins 2026

Arch Linux es la distro donde aprendí Linux en serio porque te obliga a entender cada decisión. Después de instalar Arch 12 veces en distintas máquinas, tengo una lista reproducible de pasos post-instalación que dejan el sistema listo para producción: AUR seguro con aurutils, hardening del kernel con parámetros sysctl, firewall con nftables, snapshotting con snapper + btrfs, y los servicios esenciales que siempre faltan (chrony, fail2ban, logwatch). Esta guía documenta esa lista con los scripts exactos, las decisiones detrás de cada paso, y los gotchas que solo aparecen después de la segunda semana de uso.

Si quieres correr Arch en serio y no morir en el intento, esta guía es para ti.

---

Por qué endurecer Arch después del install

Arch Linux se entrega con una promesa: tú decides qué corre en tu sistema. Esa libertad tiene un precio. A diferencia de Ubuntu Server, Fedora Server o incluso Debian en su perfil por defecto, Arch no configura firewall, no activa unattended-upgrades, no genera un usuario con sudo limitado y no instala fail2ban. Te entrega un sistema limpio con pacman, systemd y poco más. Cualquier cosa que se conecte a internet antes de las primeras configuraciones queda expuesta a escaneos automatizados que, según Shodan, completan el reconocimiento de un puerto SSH abierto en menos de 90 segundos.

El endurecimiento post-instalación no es paranoia: es el conjunto de pasos que lleva tu Arch recién instalado al nivel que esperarías de un servidor Ubuntu LTS o de un RHEL 9 endurecido según CIS Benchmark. En 2026, con Archinstall 4.5 reduciendo la barrera de entrada y miles de nuevos usuarios llegando a la distribución cada mes, estos pasos son la línea que separa una instalación hobby de un sistema que aguanta producción o servidor homelab expuesto.

Esta guía asume que ya tienes Arch funcionando (consulta la guía de instalación si acabas de llegar). Cubre mirrors, package manager, AUR, firewall, SSH, snapshots automáticas y los tres servicios de mantenimiento que olvidan el 80% de los sysadmins.

Actualizar y configurar mirrorlist con reflector

El primer paso de cualquier post-instalación es pacman -Syu. La ISO de octubre 2026 trae paquetes congelados a fecha de release; los repositorios oficiales ya tienen parches de seguridad que no quieres perderte. Si la actualización falla con error 404 sobre un mirror, el problema es que tu mirrorlist apunta a espejos desactualizados. Ahí entra reflector.

# Instalar reflector y la lista de países soportada
sudo pacman -S reflector reflector-simple
# Backup de la mirrorlist original
sudo cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak
# Generar mirrorlist con los 20 mirrors más rápidos ordenados por velocidad
sudo reflector --latest 20 --sort rate --save /etc/pacman.d/mirrorlist 
  --protocol https --country Canada,Mexico,Colombia,Argentina,Chile,United States,Brazil,Spain
# Verificar el resultado
head -20 /etc/pacman.d/mirrorlist
# Reforzar la base de datos
sudo pacman -Syyu

El parámetro --country acepta códigos ISO de dos letras separados por coma. Si tu servidor está físicamente en Montreal pero sirves contenido para Chile, conviene priorizar espejos chilenos para reducir latencia de descarga; al revés, prioriza Canadá para que la primera fase de pacman -Syu llegue rápido. Una vez tengas el archivo limpio, automatiza la actualización mensual con un timer systemd:

# Habilitar el timer que corre reflector-refresh.service cada semana
sudo systemctl enable --now reflector.timer
# Verificar el estado
systemctl list-timers reflector.timer
systemctl status reflector.service

Si prefieres no instalar reflector y quieres control manual, edita /etc/pacman.d/mirrorlist directamente. Pero reflector te garantiza que cada semana tu sistema está consultando los mirrors HTTPS más rápidos y que ningún mirror caído te deja a medias una actualización.

AUR helpers: yay vs paru e instalación segura

El AUR (Arch User Repository) es el repositorio comunitario de Arch: casi 100.000 paquetes mantenidos por usuarios, con sus scripts de build (PKGBUILDs) en lugar de binarios precompilados. Es la razón por la que Arch tiene soporte de paquetes mucho mayor que cualquier otra distro, pero también es el principal vector de ataque para quien no lee lo que instala. Un PKGBUILD puede contener cualquier cosa que se le ocurra al mantenedor.

Característica	yay	paru
Lenguaje	Go (rápido, dependencias ligeras)	Rust (más moderno, mejor manejo de errores)
Mantenedor principal	Jguer (activo desde 2018)	maximbaz (ex-mantenedor de yay, fork comunitario)
Soporte AUR	Sí, completo	Sí, completo, con deferred builds
Multi-fuente (ABS + AUR)	Sí	Sí, con opción --sudo
Configuración declarativa	Limitada	Sí (sigue mismo formato que pacman.conf)
Detección interactiva de prompts	Básica	Mejorada, sin necesidad de -i

Para instalación minimalista, instala solo uno. Mezclar yay y paru genera colisiones en ~/.cache/ y directorios de build redundantes. Recomendación 2026: yay por compatibilidad masiva (la mayoría de tutoriales lo asume); paru si quieres una herramienta más reciente con deferred builds (no bloquea el prompt mientras compila).

# Bootstrap de yay: clonar el repo, compilar e instalar
sudo pacman -S --needed base-devel git
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
# Salir del directorio después de instalar
cd ~
# Primera prueba: instalar un paquete popular del AUR (Visual Studio Code)
yay -S visual-studio-code-bin
# Revisar qué va a hacer antes de instalar (modo dry-run)
yay -S --sudoloop visual-studio-code-bin --dry-run

Reglas duras de uso del AUR (lectura obligatoria antes de instalar nada):

1. Lee el PKGBUILD completo antes de confirmar la instalación. yay -S paquete te muestra el diff después de pulsar D. Si ves un curl ... | bash ciego, un wget desde un dominio que no es el upstream, o un install -m 755 some-binary /usr/bin/ sin checksum, aborta.
2. Verifica la suma de verificación (sha256sums) del código fuente: si el mantenedor no la incluye o la marca SKIP, ese paquete es candidato a no instalar.
3. Revisa los comentarios en la página del AUR antes de instalar paquetes populares con pocos votos: ahí reportan paquetes maliciosos o abandonados.
4. Nunca uses yay -Sy paquete. El flag -y sincroniza la base de datos local antes de instalar; con AUR esto puede generar versiones inconsistentes. Usa siempre yay -S paquete simple, o -Syu para actualización global.

pacman.conf: endurecimiento del gestor de paquetes

El archivo /etc/pacman.conf controla el comportamiento global del gestor de paquetes. Por defecto viene funcional pero laxo. Cuatro ajustes lo cambian a un nivel de seguridad razonable sin perder usabilidad.

# Backup del original
sudo cp /etc/pacman.conf /etc/pacman.conf.bak
# Editar con tu editor favorito
sudo vim /etc/pacman.conf

Dentro del archivo, busca la sección [options] y aplica estos cambios (preserva el resto):

[options]
# Colorear salida y un Easter egg visual (no afecta seguridad, pero sí UX)
Color
ILoveCandy
# Nivel de verificación de firmas: Required DatabaseOptional
# - Required: todos los paquetes deben estar firmados (incluidos los del repo)
# - DatabaseOptional: la base de datos puede no estar firmada (default)
# Para servidor expuesto, usar Required.
SigLevel = Required DatabaseOptional
# Paquetes que NUNCA se actualizan (protegen contra actualizaciones que rompen boot)
HoldPkg = pacman glibc
# No extraer ciertos archivos de paquetes .pkg.tar.* (reduce superficie de ataque)
NoExtract = usr/share/doc/* usr/share/man/* usr/share/locale/* usr/share/info/*
# Ejecutar descargas como usuario nobody (no root): limita el impacto de un mirror comprometido
DownloadUser = nobody
# Caché: mantener solo 3 versiones instaladas (libera /var/cache/pacman/pkg/)
CleanMethod = KeepInstalled

Aplicar sin reinstalar nada: sudo pacman -Syu respetará los nuevos ajustes en la siguiente operación. Verifica que ningún paquete crítico haya sido retenido por HoldPkg: pacman -Qdt lista huérfanos, pacman -Qk verifica integridad de archivos.

Firewall base: nftables o ufw según perfil

Arch no trae firewall activo. Cualquier puerto que abras queda expuesto. Para servidor headless expuesto a internet, nftables es la opción correcta: es nativo del kernel desde 5.x, consume 0% CPU en estado idle y reemplaza al antiguo iptables con sintaxis más clara. Para escritorio o portátil que sale ocasionalmente a la red, ufw (Un Front Simple) ofrece comandos de alto nivel y es suficiente.

# Opción A: servidor headless con nftables
sudo pacman -S nftables
sudo systemctl enable --now nftables.service
# Reglas base: solo permitir SSH (puerto 22) hacia adentro, bloquea todo lo demás
sudo tee /etc/nftables.conf > /dev/null <<'EOF'
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    # Permitir tráfico en loopback
    iif lo accept
    # Permitir conexiones establecidas
    ct state established,related accept
    # Permitir ICMP (ping)
    ip protocol icmp accept
    ip6 nexthdr ipv6-icmp accept
    # Permitir SSH
    tcp dport 22 accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}
EOF
sudo systemctl restart nftables.service
sudo nft list ruleset

Para entorno de escritorio, donde la prioridad es que las apps funcionen sin fricción, ufw tiene una sintaxis más cercana al inglés natural:

# Opción B: escritorio o portátil con ufw
sudo pacman -S ufw
sudo systemctl enable --now ufw.service
# Política por defecto: bloquear todo lo entrante, permitir todo lo saliente
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Permitir SSH
sudo ufw allow 22/tcp comment 'SSH'
# Habilitar
sudo ufw enable
sudo ufw status verbose

Después de activar cualquier firewall, valida desde otra máquina con nmap -Pn -p 22,80,443 tu-ip: solo el 22 debe estar abierto. Si abres un puerto web (80/443) recuerda añadir la regla antes de habilitar.

Hardening de SSH antes de exponer el puerto

Si dejas el servidor SSH con la configuración por defecto de Arch (PermitRootLogin yes, PasswordAuthentication yes), los bots de fuerza bruta lo encuentran en minutos. La configuración endurecida estándar para Arch Linux 2026 (compatible con OpenSSH 9.x incluido en los repos) cubre cinco controles críticos.

# Backup del archivo original
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# Aplicar configuración endurecida
sudo tee /etc/ssh/sshd_config > /dev/null <<'EOF'
# Puerto no estándar (opcional pero reduce 90% del ruido automatizado)
Port 2222
# Solo autenticación por clave pública
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM yes
# Bloquear login root directo
PermitRootLogin no
# Reducir superficie de ataque
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PrintMotd no
# Limitar intentos de autenticación
MaxAuthTries 3
LoginGraceTime 30
MaxStartups 3:50:10
ClientAliveInterval 300
ClientAliveCountMax 2
EOF
# Validar la configuración antes de reiniciar
sudo sshd -t
# Si la validación pasa, reiniciar el servicio
sudo systemctl restart sshd.service

Si tu puerto SSH está detrás de un NAT (firewall de hogar, máquina virtual, homelab), cambia el puerto del router también. Si lo expones a internet directo, considera fail2ban como segunda capa: registra intentos fallidos y bloquea IPs agresivas durante 1 hora tras 3 intentos. La guía completa de configuración y pila 2FA está en Seguridad SSH en 2026: TOTP, FIDO2 y la pila 2FA.

Snapper y btrfs-assistant: snapshots automáticas

Si instalaste Arch con btrfs como sistema de archivos raíz (recomendado en el método manual de la guía anterior), tienes acceso a snapshots instantáneas del sistema antes y después de cada operación de pacman. Con snapper + grub-btrfs + btrfs-assistant puedes revertir el sistema a un estado anterior en segundos sin boot desde USB.

# Instalar las herramientas necesarias
sudo pacman -S snapper snap-pac grub-btrfs btrfs-assistant
# Crear la configuración snapper para el subvolumen raíz
sudo snapper -c root create-config /
# Habilitar el timer que toma snapshot pre/post pacman
sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer
# Listar snapshots existentes
sudo snapper -c root list
# Integrar las snapshots al menú GRUB (necesita reboot la primera vez)
sudo grub-mkconfig -o /boot/grub/grub.cfg
# Si tu bootloader es systemd-boot (UEFI puro), el paquete grub-btrfs
# no aplica; usa systemd-btrfs en su lugar:
# sudo pacman -S systemd-btrfs

El paquete snap-pac crea automáticamente snapshots pacman-pre y pacman-post en cada operación de pacman: si una actualización rompe el sistema, basta con elegir el snapshot anterior en GRUB (o desde el menú de btrfs-assistant) y arrancar desde ahí. Para entornos de servidor sin GUI, los comandos snapper undochange y snapper status permiten revertir cambios sin reiniciar.

Servicios de mantenimiento que olvidas

Tres timers que ningún instalador automático activa pero que marcan la diferencia entre un servidor estable y uno que muere en seis meses.

Servicio	Frecuencia	Función
fstrim.timer	Semanal	Envía comandos TRIM al SSD para mantener rendimiento y liberar bloques marcados como libres
paccache.timer	Semanal	Limpia la caché de paquetes en /var/cache/pacman/pkg/ conservando solo las últimas 3 versiones
logrotate.timer	Diario	Rotación, compresión y purga de logs según la configuración en /etc/logrotate.d/

# Habilitar los tres timers
sudo systemctl enable --now fstrim.timer
sudo systemctl enable --now paccache.timer
sudo systemctl enable --now logrotate.timer
# Verificar que están corriendo
systemctl list-timers | grep -E 'fstrim|paccache|logrotate'
# Comprobar la siguiente ejecución de fstrim (importante en SSD)
systemctl status fstrim.timer

Si tu sistema está en HDD mecánico (raro en 2026 pero posible en servidores legacy), fstrim.timer no aplica: las unidades rotacionales no usan TRIM. Para servidores con almacenamiento mixto, asegúrate de que fstrim corre solo sobre los puntos de montaje de SSD; el script /usr/lib/systemd/system/fstrim.service ya excluye por defecto dispositivos rotacionales.

Problemas conocidos en hardening de Arch (octubre 2026)

El endurecimiento no es perfecto. Estos son los tres tropiezos más reportados en foros y Reddit durante el último mes, con solución verificada.

1. yay falla al compilar con “cannot find rust toolchain”. El error aparece porque yay requiere rustc para compilarse a sí mismo en el bootstrap, y algunos perfiles minimalistas no incluyen el toolchain. Fix:

sudo pacman -S rust base-devel
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
cd ~

2. Reflector genera mirrorlist vacía después del filtro. Si tu combinación de --country no incluye ningún mirror accesible, reflector escribe un archivo vacío y pacman falla con “no usable mirrors configured”. Fix:

# Probar sin filtro de país primero
sudo reflector --latest 50 --sort rate --save /etc/pacman.d/mirrorlist
# Verificar que el archivo tiene contenido
grep -c '^Server' /etc/pacman.d/mirrorlist
# Solo después aplicar filtro específico

3. SSH deja de aceptar claves después de activar PubkeyAuthentication yes. Si copiaste la clave pública al servidor pero sigues recibiendo “Permission denied (publickey)”, verifica permisos en el servidor:

# En el servidor, como tu usuario:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
# Verificar que el servicio SSH ve las claves
sudo sshd -T | grep -i authorizedkeysfile

El error silencioso más común: el directorio ~/.ssh pertenece a root después de una copia con sudo cp. Usa chown -R tu-usuario:tu-usuario ~/.ssh para corregir.

¿Vale la pena para un sysadmin?

Sí, con matices. Arch post-instalación es la distribución más rápida para tener un sistema exacto: ningún paquete sobrante, ninguna capa intermedia, ningún servicio heredado. La curva de mantenimiento es mayor que la de Ubuntu LTS (no hay LTS, hay rolling release) pero el control que ganas es proporcional. Para servidores de producción en equipos con poca experiencia, Fedora Server o Rocky Linux ofrecen un compromiso razonable; Arch brilla cuando el sysadmin quiere entender exactamente qué corre y por qué.

El endurecimiento que cubre esta guía lleva entre 25 y 40 minutos después de la instalación base. Una vez configurado, los timers automáticos (reflector, snapper, fstrim, paccache, logrotate) corren solos y solo vuelves a tocar la configuración cuando agregas un servicio nuevo. La auditoría periódica (Lynis, OpenSCAP) completa el ciclo: ejecutarla cada 3 meses detecta drift y regresiones antes de que se vuelvan incidentes.

Conclusión

Un Arch Linux recién instalado es como una casa con cerradura estándar: habitable, pero vulnerable si alguien prueba la puerta. Los pasos de este artículo (mirrorlist optimizado, AUR seguro, pacman.conf endurecido, firewall activo, SSH con clave pública, snapshots automáticas y timers de mantenimiento) convierten esa casa en una con alarma, cámaras y sistema de respaldo. La instalación dura 30 minutos más que el método por defecto, pero el sistema resultante es lo suficientemente sólido para correr como servidor homelab o de producción pequeña.

El siguiente paso natural es auditar lo construido con Lynis, integrar las copias de seguridad con Restic, Borg o Kopia y configurar la pila 2FA en SSH para resistir phishing de credenciales.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux