🥇 Redes en Linux (II): SSH, FTP y DNS

La administración de servicios de red es una de las habilidades más demandadas en el mundo de la administración de sistemas Linux. En esta segunda parte sobre administración de redes, profundizamos en los demonios (daemons) que hacen funcionar Internet: desde el acceso remoto seguro con SSH hasta la resolución de nombres con DNS, pasando por la transferencia de archivos y la gestión moderna de servicios con systemd. Si en la primera parte vimos los fundamentos de red (TCP/IP, interfaces, enrutamiento), aquí aprenderás a desplegar y gestionar los servicios que dan vida a un servidor Linux profesional.

Ingeniero de redes trabajando en un rack de servidores Linux — 📸 Ingeniero de redes configurando servidores — Pexels (Licencia libre)

👹 Demonios y servicios en Linux: de inetd a systemd

En el mundo Unix/Linux, un demonio (del inglés daemon) es un proceso que se ejecuta en segundo plano, sin terminal asociado, proporcionando un servicio al sistema o a la red. El nombre proviene de los «demonios de Maxwell» de la física termodinámica, entidades que trabajan incansablemente en segundo plano — exactamente lo que hacen estos procesos.

Los demonios son los responsables de que un servidor Linux pueda atender peticiones SSH, resolver nombres DNS, servir páginas web o transferir archivos. Por convención, sus nombres terminan en d: sshd (SSH), named (DNS), httpd (Apache), vsftpd (FTP).

La evolución histórica: inetd → xinetd → systemd

En los primeros sistemas Unix, cada servicio de red requería un demonio permanentemente cargado en memoria, consumiendo recursos incluso sin recibir peticiones. Para resolver esto, en 1980 se creó inetd, el «super-servidor de Internet»: un único demonio que escuchaba múltiples puertos y lanzaba el servicio correspondiente solo cuando llegaba una conexión.

/etc/inetd.conf — Formato histórico (obsoleto)
# servicio  socket  protocolo  flags  usuario  programa       argumentos
ftp       stream  tcp  nowait  root  /usr/sbin/vsftpd    vsftpd
telnet    stream  tcp  nowait  root  /usr/sbin/in.telnetd in.telnetd
ssh       stream  tcp  nowait  root  /usr/sbin/sshd      sshd -i

xinetd (Extended Internet Services Daemon) mejoró inetd añadiendo control de acceso por IP, limitación de conexiones simultáneas, logging detallado y configuración modular en /etc/xinetd.d/. Durante años fue el estándar en Red Hat y derivados.

Sin embargo, ambos han quedado obsoletos. Desde 2010, systemd ha asumido su función mediante un mecanismo llamado socket activation: systemd crea los sockets de escucha y, cuando llega una conexión, arranca el servicio correspondiente bajo demanda, exactamente como hacía inetd pero con todas las ventajas de la gestión moderna de servicios.

💡 ¿Sabías que...?

El concepto de «super-servidor» (inetd) fue inventado en la Universidad de Berkeley como parte del BSD 4.3 en 1986. Hoy, 40 años después, systemd hace exactamente lo mismo pero integrado en el sistema de inicio moderno.

Característica	inetd	xinetd	systemd
Época	1980-2000	1999-2015	2010-presente
Configuración	/etc/inetd.conf	/etc/xinetd.d/	Unit files .socket + .service
Control de acceso	tcpd wrappers	Integrado (only_from, no_access)	Firewall + cgroups
Logging	syslog básico	Configurable por servicio	journald integrado
Límite de conexiones	No	Sí (instances, per_source)	Sí + protección DoS
Estado	Obsoleto	Obsoleto	Estándar actual

⚙️ Gestión de servicios con systemd

En cualquier distribución moderna (Ubuntu, Debian, Fedora, RHEL, Arch), systemd es el sistema de inicio y gestor de servicios por defecto. Cada servicio se define mediante un unit file — un archivo de texto que describe cómo arrancar, detener y supervisar el demonio.

terminal — Comandos esenciales de systemctl
# Ver estado de un servicio
sudo systemctl status sshd

# Arrancar / detener / reiniciar
sudo systemctl start sshd
sudo systemctl stop sshd
sudo systemctl restart sshd

# Recargar configuración sin cortar conexiones
sudo systemctl reload sshd

# Habilitar / deshabilitar en el arranque
sudo systemctl enable sshd
sudo systemctl disable sshd

# Listar todos los servicios activos
systemctl list-units --type=service --state=running

La potencia de systemd radica en que controla no solo el arranque del servicio, sino también su reinicio automático ante fallos, la limitación de recursos (CPU, memoria), el aislamiento de seguridad (sandboxing) y el registro de logs mediante journald.

terminal — Consultar logs de un servicio
# Ver logs de SSH en tiempo real
sudo journalctl -u sshd -f

# Logs de DNS desde hace 1 hora
sudo journalctl -u named --since "1 hour ago"

# Logs de arranque del sistema
sudo journalctl -b -p err

✅ Consejo profesional

Usa systemctl reload en lugar de restart siempre que el servicio lo soporte. La recarga aplica cambios de configuración sin interrumpir las conexiones activas — fundamental en servidores en producción.

🔐 SSH: acceso remoto seguro con OpenSSH

SSH (Secure Shell) es el protocolo estándar para acceder de forma remota y segura a máquinas Linux. Reemplazó completamente a Telnet y rsh, que transmitían todo — incluyendo contraseñas — en texto plano. OpenSSH es la implementación más utilizada y viene preinstalada en prácticamente todas las distribuciones.

SSH cifra toda la comunicación entre cliente y servidor mediante criptografía asimétrica (para la autenticación) y simétrica (para la sesión). Además de sesiones de terminal, SSH permite túneles cifrados, reenvío de puertos y transferencia segura de archivos.

terminal — Instalación y uso básico de SSH
# Instalar servidor SSH (Ubuntu/Debian)
sudo apt install openssh-server

# Verificar que está activo
sudo systemctl status ssh

# Conectar a un servidor remoto
ssh usuario@192.168.1.100

# Conectar especificando puerto
ssh -p 2222 usuario@servidor.ejemplo.com

# Ejecutar un comando remoto sin sesión interactiva
ssh usuario@servidor "df -h && free -m"

Autenticación por clave pública (la forma correcta)

La autenticación por contraseña es vulnerable a ataques de fuerza bruta. El método recomendado es la autenticación por clave pública: el usuario genera un par de claves (pública + privada), deposita la pública en el servidor, y la privada nunca abandona su máquina.

terminal — Configurar autenticación por clave
# 1. Generar par de claves Ed25519 (más seguro que RSA)
ssh-keygen -t ed25519 -C "mi-servidor-produccion"

# 2. Copiar la clave pública al servidor remoto
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@192.168.1.100

# 3. Verificar que funciona sin pedir contraseña
ssh usuario@192.168.1.100

# 4. Desactivar autenticación por contraseña (en el servidor)
sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload ssh

⚠️ Seguridad crítica

Nunca desactives la autenticación por contraseña hasta verificar que puedes entrar con tu clave pública. De lo contrario, te quedarás bloqueado fuera del servidor sin forma de acceder.

🛡️ Configuración avanzada de SSH

El archivo de configuración del servidor SSH es /etc/ssh/sshd_config. Estas son las directivas más importantes para un servidor seguro en producción:

/etc/ssh/sshd_config — Configuración segura
# Puerto — cambiar del 22 por defecto reduce escaneos automáticos
Port 2222

# Solo protocolo 2 (más seguro)
Protocol 2

# Prohibir login directo como root
PermitRootLogin no

# Desactivar autenticación por contraseña
PasswordAuthentication no

# Solo permitir usuarios específicos
AllowUsers admin deploy

# Limitar intentos de autenticación
MaxAuthTries 3

# Desconectar sesiones inactivas (300 seg = 5 min)
ClientAliveInterval 300
ClientAliveCountMax 2

# Deshabilitar reenvío X11 si no se necesita
X11Forwarding no

# Algoritmos de cifrado recomendados (2025+)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org

Directiva	Valor recomendado	Efecto
Port	2222 (o cualquiera no estándar)	Reduce escaneos automatizados del puerto 22
PermitRootLogin	no	Obliga a usar un usuario normal + sudo
PasswordAuthentication	no	Solo permite autenticación con clave pública
AllowUsers	lista de usuarios	Whitelist de usuarios autorizados
MaxAuthTries	3	Bloquea tras 3 intentos fallidos por conexión
X11Forwarding	no (en servidores)	Elimina superficie de ataque gráfica innecesaria

Túneles SSH: reenvío de puertos

Una de las funcionalidades más potentes de SSH es la capacidad de crear túneles cifrados que redirigen tráfico de red a través de la conexión segura:

terminal — Túneles SSH
# Túnel local: acceder a un servicio remoto como si fuera local
# Ejemplo: acceder a una base de datos MySQL remota en puerto 3306
ssh -L 3306:localhost:3306 usuario@servidor-db

# Túnel remoto: exponer un servicio local al servidor remoto
ssh -R 8080:localhost:80 usuario@servidor-publico

# SOCKS proxy: navegar a través del servidor remoto
ssh -D 1080 usuario@servidor-remoto

📁 Transferencia de archivos: FTP, SFTP y SCP

La transferencia de archivos es una de las funciones más básicas y necesarias en la administración de servidores. Linux ofrece múltiples protocolos, cada uno con sus ventajas y limitaciones.

Switch de red con cables Ethernet conectados para transferencia de datos — 📸 Infraestructura de red: switch Ethernet — Pexels (Licencia libre)

Protocolo	Puerto	Cifrado	Uso recomendado
FTP	21	No (¡peligroso!)	Solo en redes aisladas o con FTPS
FTPS	990	TLS/SSL	Compatibilidad con clientes FTP legacy
SFTP	22	SSH completo	✅ Método preferido para todo
SCP	22	SSH completo	Copias simples entre servidores
rsync+SSH	22	SSH completo	Sincronización y backups incrementales

SFTP y SCP: transferencia segura sobre SSH

Si ya tienes SSH configurado, automáticamente dispones de SFTP y SCP sin instalar nada adicional. Son el método preferido en entornos profesionales:

terminal — Transferencia con SCP y SFTP
# SCP: copiar archivo local al servidor remoto
scp backup.tar.gz usuario@192.168.1.100:/home/usuario/backups/

# SCP: copiar archivo del servidor al equipo local
scp usuario@192.168.1.100:/var/log/syslog ./logs/

# SCP: copiar directorio completo recursivamente
scp -r proyecto/ usuario@servidor:/var/www/html/

# SFTP: sesión interactiva
sftp usuario@192.168.1.100
sftp> ls              # listar remoto
sftp> put config.php  # subir archivo
sftp> get database.sql # descargar archivo
sftp> bye

vsftpd: cuando necesitas un servidor FTP

En algunos casos (compatibilidad con sistemas legacy, repositorios de archivos anónimos), puede ser necesario un servidor FTP. vsftpd (Very Secure FTP Daemon) es la opción más segura:

terminal — Instalar y configurar vsftpd
# Instalar vsftpd
sudo apt install vsftpd

# Editar configuración
sudo nano /etc/vsftpd.conf

/etc/vsftpd.conf — Configuración segura
# Desactivar acceso anónimo
anonymous_enable=NO

# Permitir usuarios locales
local_enable=YES

# Permitir escritura
write_enable=YES

# Enjaular usuarios en su home (chroot)
chroot_local_user=YES
allow_writeable_chroot=YES

# Activar TLS para cifrar las conexiones
ssl_enable=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key
force_local_data_ssl=YES
force_local_logins_ssl=YES

# Modo pasivo (necesario detrás de firewall)
pasv_min_port=30000
pasv_max_port=31000

# Mensaje de bienvenida
ftpd_banner=Bienvenido al servidor FTP de la empresa

💡 rsync: la herramienta profesional

Para backups y sincronización, rsync supera a SCP: transfiere solo las diferencias entre archivos (transferencia incremental), puede reanudar transferencias interrumpidas, y preserva permisos y timestamps. Ejemplo: rsync -avz --progress /datos/ usuario@servidor:/backup/datos/

🌐 DNS: resolución de nombres con BIND9

El DNS (Domain Name System) es el servicio que traduce nombres legibles por humanos (como www.ejemplo.com) en direcciones IP (como 93.184.216.34). Sin DNS, Internet sería prácticamente inutilizable — tendríamos que recordar direcciones IP numéricas para cada sitio web.

En Linux, el software DNS más utilizado es BIND9 (Berkeley Internet Name Domain), que alimenta la mayoría de los servidores DNS del mundo desde hace más de 30 años. Alternativas modernas incluyen Unbound (resolver/caché) y dnsmasq (redes pequeñas).

Conceptos fundamentales de DNS

Concepto	Descripción	Ejemplo
Zona	Porción del espacio de nombres DNS que administra un servidor	ejemplo.com
Registro A	Asocia un nombre a una dirección IPv4	www → 93.184.216.34
Registro AAAA	Asocia un nombre a una dirección IPv6	www → 2606:2800:220:1:...
Registro CNAME	Alias: apunta a otro nombre DNS	blog → www.ejemplo.com
Registro MX	Servidor de correo del dominio	mail.ejemplo.com (prioridad 10)
Registro NS	Servidores de nombres autoritativos para la zona	ns1.ejemplo.com
Registro SOA	Inicio de autoridad: metadatos de la zona	serial, refresh, retry, expire
Registro PTR	Resolución inversa: IP → nombre	34.216.184.93 → www.ejemplo.com

🔧 Configuración práctica de un servidor DNS

Vamos a configurar un servidor DNS autoritativo con BIND9 para el dominio ficticio miempresa.local. Este es un escenario habitual en redes corporativas internas.

terminal — Instalación de BIND9
# Instalar BIND9 y utilidades
sudo apt install bind9 bind9-utils bind9-dnsutils

# Verificar que está activo
sudo systemctl status named

/etc/bind/named.conf.local — Definir zonas
// Zona de resolución directa (nombre → IP)
zone "miempresa.local" {
    type master;
    file "/etc/bind/zones/db.miempresa.local";
};

// Zona de resolución inversa (IP → nombre)
zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.168.1";
};

/etc/bind/zones/db.miempresa.local — Archivo de zona directa
$TTL    604800
@   IN  SOA ns1.miempresa.local. admin.miempresa.local. (
                  2026022601  ; Serial (YYYYMMDDNN)
                  3600        ; Refresh (1 hora)
                  1800        ; Retry (30 min)
                  604800      ; Expire (1 semana)
                  86400 )     ; Negative Cache TTL (1 día)

; Servidores de nombres
@       IN  NS      ns1.miempresa.local.
@       IN  NS      ns2.miempresa.local.

; Registros A (nombre → IPv4)
ns1     IN  A       192.168.1.10
ns2     IN  A       192.168.1.11
www     IN  A       192.168.1.20
mail    IN  A       192.168.1.30
db      IN  A       192.168.1.40
intranet IN CNAME   www.miempresa.local.

; Registro MX (correo)
@       IN  MX  10  mail.miempresa.local.

terminal — Validar y activar la configuración
# Validar la configuración general
sudo named-checkconf

# Validar el archivo de zona
sudo named-checkzone miempresa.local /etc/bind/zones/db.miempresa.local

# Si todo es OK, reiniciar BIND
sudo systemctl restart named

# Probar la resolución
dig @localhost www.miempresa.local
nslookup mail.miempresa.local localhost

⚠️ Importante: el número serial

Cada vez que modifiques un archivo de zona, debes incrementar el serial. El formato recomendado es YYYYMMDDNN (año, mes, día, número de revisión). Los servidores DNS secundarios comprueban este número para decidir si necesitan actualizar su copia de la zona.

🧱 Proteger servicios con firewall (UFW e iptables)

De nada sirve configurar servicios si no los proteges con un firewall. En Linux, el firewall se implementa a nivel de kernel con netfilter, y se gestiona con herramientas como iptables (bajo nivel) o UFW (Uncomplicated Firewall, más accesible).

terminal — Configurar UFW para servicios de red
# Instalar y activar UFW
sudo apt install ufw

# Política por defecto: denegar todo lo entrante, permitir lo saliente
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Permitir SSH (¡ANTES de activar el firewall!)
sudo ufw allow 2222/tcp comment "SSH personalizado"

# Permitir DNS
sudo ufw allow 53 comment "DNS BIND9"

# Permitir FTP (si es necesario)
sudo ufw allow 21/tcp comment "FTP control"
sudo ufw allow 30000:31000/tcp comment "FTP pasivo"

# Permitir HTTP/HTTPS
sudo ufw allow 80/tcp comment "HTTP"
sudo ufw allow 443/tcp comment "HTTPS"

# Activar el firewall
sudo ufw enable

# Ver reglas activas
sudo ufw status verbose

fail2ban: protección contra fuerza bruta

Para proteger SSH contra intentos automatizados de acceso por fuerza bruta, fail2ban monitoriza los logs y bloquea IPs que fallan repetidamente:

terminal — Instalar y configurar fail2ban para SSH
# Instalar fail2ban
sudo apt install fail2ban

# Crear configuración local (nunca editar jail.conf)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Editar la configuración local
sudo nano /etc/fail2ban/jail.local

/etc/fail2ban/jail.local — Protección SSH
[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 3600     # Bloquear 1 hora
findtime = 600      # Ventana de 10 minutos

✅ Recomendación profesional

Combina siempre tres capas de seguridad para SSH: autenticación por clave pública (elimina contraseñas), firewall UFW (limita acceso por IP o puerto) y fail2ban (bloquea atacantes persistentes). Esta combinación hace que un servidor SSH sea prácticamente invulnerable a ataques automatizados.

📊 Monitorización y diagnóstico de servicios de red

Un buen administrador de sistemas no solo configura servicios, sino que los monitoriza constantemente. Linux proporciona herramientas poderosas para verificar el estado de los servicios, diagnosticar problemas y detectar anomalías.

terminal — Herramientas de diagnóstico de red
# Ver puertos en escucha y qué proceso los usa
sudo ss -tlnp
# Alternativa clásica (deprecated pero aún útil)
sudo netstat -tlnp

# Verificar que SSH escucha en el puerto correcto
sudo ss -tlnp | grep sshd

# Probar conectividad a un puerto específico
nc -zv 192.168.1.100 22

# Rastrear la ruta de paquetes a un destino
traceroute 8.8.8.8

# Capturar tráfico de red (para diagnóstico avanzado)
sudo tcpdump -i eth0 port 53 -n

# Consultar registros DNS con dig
dig www.ejemplo.com A
dig ejemplo.com MX
dig ejemplo.com NS +short

# Ver conexiones activas por servicio
sudo ss -tp state established

Herramienta	Función principal	Ejemplo de uso típico
ss / netstat	Ver sockets y conexiones	Verificar qué puertos están abiertos
dig / nslookup	Consultas DNS	Depurar resolución de nombres
tcpdump	Captura de paquetes	Analizar tráfico en tiempo real
nc (netcat)	Probar conectividad a puertos	Verificar que un servicio responde
traceroute	Rastrear ruta de red	Identificar dónde se pierde conectividad
journalctl	Consultar logs de systemd	Ver errores de un servicio específico
systemctl	Gestión de servicios	Verificar estado, reiniciar, habilitar

✏️ Ejercicios prácticos resueltos

📝 Ejercicio 1: Configurar SSH seguro

Instala OpenSSH en un servidor Ubuntu, genera un par de claves Ed25519, configura autenticación por clave pública, desactiva el login por contraseña, cambia el puerto a 2222 y habilita fail2ban. Verifica que todo funciona.

Ver solución del Ejercicio 1

Solución — SSH seguro paso a paso
# 1. Instalar OpenSSH
sudo apt update && sudo apt install openssh-server fail2ban

# 2. Generar claves en la máquina CLIENT
ssh-keygen -t ed25519 -C "ejercicio-ssh"

# 3. Copiar clave al servidor
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@servidor

# 4. Verificar acceso sin contraseña
ssh usuario@servidor

# 5. En el SERVIDOR, editar /etc/ssh/sshd_config:
# Port 2222
# PermitRootLogin no
# PasswordAuthentication no
# AllowUsers usuario

# 6. Abrir el nuevo puerto en UFW
sudo ufw allow 2222/tcp

# 7. Reiniciar SSH
sudo systemctl restart ssh

# 8. Configurar fail2ban para el nuevo puerto
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Editar [sshd]: port = 2222, maxretry = 3
sudo systemctl enable fail2ban && sudo systemctl start fail2ban

# 9. Verificar conexión con nuevo puerto
ssh -p 2222 usuario@servidor

📝 Ejercicio 2: Servidor DNS local con BIND9

Configura un servidor DNS en tu red local para el dominio lab.local con registros A para tres máquinas: web (192.168.1.20), db (192.168.1.30) y mail (192.168.1.40). Incluye un registro MX para el correo y un CNAME intranet → web. Valida la configuración.

Ver solución del Ejercicio 2

Solución — DNS con BIND9
# 1. Instalar BIND9
sudo apt install bind9 bind9-utils

# 2. Crear directorio de zonas
sudo mkdir -p /etc/bind/zones

# 3. Añadir zona en /etc/bind/named.conf.local:
# zone "lab.local" {
#     type master;
#     file "/etc/bind/zones/db.lab.local";
# };

# 4. Crear /etc/bind/zones/db.lab.local:
# $TTL 604800
# @ IN SOA ns1.lab.local. admin.lab.local. (
#     2026022601 3600 1800 604800 86400 )
# @ IN NS ns1.lab.local.
# ns1  IN A  192.168.1.10
# web  IN A  192.168.1.20
# db   IN A  192.168.1.30
# mail IN A  192.168.1.40
# intranet IN CNAME web.lab.local.
# @ IN MX 10 mail.lab.local.

# 5. Validar
sudo named-checkconf
sudo named-checkzone lab.local /etc/bind/zones/db.lab.local

# 6. Reiniciar y probar
sudo systemctl restart named
dig @localhost web.lab.local
dig @localhost lab.local MX

📝 Ejercicio 3: Script de monitorización de servicios

Escribe un script en Bash que compruebe si los servicios SSH, BIND y vsftpd están activos, y envíe una alerta si alguno está caído.

Ver solución del Ejercicio 3

monitor_servicios.sh
#!/bin/bash
# Monitor de servicios de red
# Uso: ./monitor_servicios.sh

SERVICIOS=("ssh" "named" "vsftpd")
ALERTAS=0
LOG="/var/log/monitor_servicios.log"
FECHA=$(date "+%Y-%m-%d %H:%M:%S")

for servicio in "${SERVICIOS[@]}"; do
    if systemctl is-active --quiet "$servicio"; then
        echo "[$FECHA] ✅ $servicio: ACTIVO" >> "$LOG"
    else
        echo "[$FECHA] ❌ $servicio: CAÍDO — intentando reiniciar" >> "$LOG"
        sudo systemctl restart "$servicio"
        if systemctl is-active --quiet "$servicio"; then
            echo "[$FECHA] ♻️ $servicio: reiniciado con éxito" >> "$LOG"
        else
            echo "[$FECHA] 🚨 $servicio: NO SE PUDO REINICIAR" >> "$LOG"
            ((ALERTAS++))
        fi
    fi
done

if [ "$ALERTAS" -gt 0 ]; then
    echo "⚠️ $ALERTAS servicio(s) fallaron. Revisar $LOG"
    # Opcional: enviar correo de alerta
    # mail -s "ALERTA: servicios caídos" admin@miempresa.com < "$LOG"
fi

❓ Preguntas frecuentes sobre Administración de redes en Linux (II): servicios de red, SSH, DNS y transferencia de archivos

Las dudas más comunes respondidas de forma clara y directa.

Un demonio es un proceso que se ejecuta en segundo plano sin intervención del usuario. Los demonios gestionan servicios de red como SSH (sshd), DNS (named), servidores web (httpd/nginx) y bases de datos. En sistemas modernos, systemd se encarga de arrancar, detener y supervisar estos demonios automáticamente.

SSH (Secure Shell) establece una sesión remota cifrada. SCP (Secure Copy) copia archivos entre máquinas a través de SSH, ideal para transferencias simples. SFTP (SSH File Transfer Protocol) es un protocolo interactivo de transferencia de archivos sobre SSH, similar a FTP pero completamente cifrado. Los tres usan el puerto 22 y el mismo sistema de autenticación.

Siempre SFTP cuando sea posible. FTP transmite las credenciales y los datos sin cifrar, lo que supone un riesgo de seguridad grave. SFTP funciona sobre SSH y cifra toda la comunicación. Si necesitas FTP por compatibilidad, usa vsftpd con TLS (FTPS) como mínimo.

El software más utilizado es BIND9 (Berkeley Internet Name Domain). Se instala con apt install bind9, se configuran las zonas en /etc/bind/named.conf.local, y se crean los archivos de zona con registros A, AAAA, MX, CNAME y NS. Tras configurar, se valida con named-checkconf y named-checkzone antes de reiniciar el servicio.

inetd fue el primer super-servidor de Internet en Unix, que escuchaba múltiples puertos y lanzaba servicios bajo demanda. xinetd lo mejoró con control de acceso y logging avanzado. Ambos están obsoletos. systemd los reemplaza con socket activation: systemd escucha el puerto y lanza el servicio solo cuando llega una conexión, combinando eficiencia y seguridad moderna.

SSH es seguro si se configura correctamente: desactiva la autenticación por contraseña y usa solo claves públicas, cambia el puerto por defecto, instala fail2ban para bloquear intentos de fuerza bruta, restringe usuarios con AllowUsers, y mantiene OpenSSH actualizado. Nunca permitas login directo como root.

💬 Foro de discusión

¿Tienes dudas sobre Administración de redes en Linux (II): servicios de red, SSH, DNS y transferencia de archivos? Comparte tu pregunta con la comunidad.

¿Tienes cuenta? o comenta como invitado ↓

Todavía no hay mensajes. ¡Sé el primero en participar!

🚀 ¿Quieres dominar Linux profesionalmente?

Cursos bonificados por FUNDAE para empresas — formación 100% subvencionada

Ver cursos de Linux →

Administración de redes en Linux (II): servicios de red, SSH, DNS y transferencia de archivos

👹 Demonios y servicios en Linux: de inetd a systemd

La evolución histórica: inetd → xinetd → systemd

⚙️ Gestión de servicios con systemd

🔐 SSH: acceso remoto seguro con OpenSSH

Autenticación por clave pública (la forma correcta)

🛡️ Configuración avanzada de SSH

Túneles SSH: reenvío de puertos

📁 Transferencia de archivos: FTP, SFTP y SCP

SFTP y SCP: transferencia segura sobre SSH

vsftpd: cuando necesitas un servidor FTP

🌐 DNS: resolución de nombres con BIND9

Conceptos fundamentales de DNS

🔧 Configuración práctica de un servidor DNS

🧱 Proteger servicios con firewall (UFW e iptables)

fail2ban: protección contra fuerza bruta

📊 Monitorización y diagnóstico de servicios de red

✏️ Ejercicios prácticos resueltos

❓ Preguntas frecuentes sobre Administración de redes en Linux (II): servicios de red, SSH, DNS y transferencia de archivos

💬 Foro de discusión

🔑 Recuperar contraseña

Crear cuenta

¿Cómo valorarías tu experiencia aprendiendo en esta sección?

¡Gracias por tu valoración!

👹 Demonios y servicios en Linux: de inetd a systemd

La evolución histórica: inetd → xinetd → systemd

⚙️ Gestión de servicios con systemd

🔐 SSH: acceso remoto seguro con OpenSSH

Autenticación por clave pública (la forma correcta)

🛡️ Configuración avanzada de SSH

Túneles SSH: reenvío de puertos

📁 Transferencia de archivos: FTP, SFTP y SCP

SFTP y SCP: transferencia segura sobre SSH

vsftpd: cuando necesitas un servidor FTP

🌐 DNS: resolución de nombres con BIND9

Conceptos fundamentales de DNS

🔧 Configuración práctica de un servidor DNS

🧱 Proteger servicios con firewall (UFW e iptables)

fail2ban: protección contra fuerza bruta

📊 Monitorización y diagnóstico de servicios de red

✏️ Ejercicios prácticos resueltos

❓ Preguntas frecuentes sobre Administración de redes en Linux (II): servicios de red, SSH, DNS y transferencia de archivos

💬 Foro de discusión

Iniciar sesión

🔑 Recuperar contraseña

Crear cuenta