Exploring the roots and future of Internet Relay Chat

Guía de IRCop: /oper, /kill, /kline, snomasks y responsabilidades

Mi primer /oper fue en 2001, en una red italiana de 200 usuarios. Me dieron la contraseña, hice /oper marco password123, y de repente tenía poder sobre la red entera. Podía ver IPs, desconectar usuarios, banear rangos enteros. Tenía 19 años y, como era de esperar, hice exactamente lo que no debería haber hecho: /kill al primer usuario que me molestó.

Esa experiencia me enseñó la lección más valiosa de mi carrera como operador: tener el poder de hacer algo no significa que debas hacerlo. Un IRCop que abusa de sus privilegios destruye la confianza de la comunidad más rápido que cualquier ataque DDoS.

Este artículo es lo que me habría gustado leer antes de hacer mi primer /oper.

¿Qué es un IRCop?

Un IRC Operator (IRCop) es un usuario con privilegios administrativos a nivel de servidor o de red. No confundas con un Channel Operator (op de canal) — que tiene @ en un canal. Un IRCop tiene privilegios sobre el servidor IRC mismo.

Los IRCops pueden:

  • Ver información oculta de usuarios (IPs reales, metadata de conexión)
  • Desconectar usuarios (/kill)
  • Banear usuarios temporal o permanentemente (/kline, /gline, /zline)
  • Ver notificaciones del servidor (snomasks)
  • Rehashear la configuración del servidor (/rehash)
  • Gestionar links entre servidores (/connect, /squit)
  • Aplicar filtros anti-spam (/spamfilter)

Lo que un IRCop NO debería hacer (pero muchos hacen):

  • Intervenir en conflictos de canales — los canales son responsabilidad de sus operadores.
  • Usar /kill como herramienta de moderación habitual — para eso están los bans.
  • Espiar conversaciones privadas — aunque técnicamente puede.
  • Darse operador en canales ajenos sin razón justificada.

Autenticación: /oper y métodos

El comando básico es simple:

# Autenticarse como operador:
/oper nombre_oper contraseña

# Si todo va bien, recibes un mensaje del servidor:
# -!- You are now an IRC operator
# Y se aplican los modos de usuario correspondientes

# Verificar que estás operado:
/mode tu_nick
# Busca el modo +o en la respuesta

Configuración en UnrealIRCd

# unrealircd.conf
oper marco {
    mask *@*.irc6.net;           # Solo desde hosts que coincidan
    password "$argon2id$..."     # Hash de la contraseña
    operclass netadmin;          # Nivel de privilegios
    class opers;                 # Clase de conexión
    swhois "es un Network Administrator";
    vhost "staff.irc6.net";      # Virtual host al hacer /oper
    
    # Autenticación por certificado (más seguro que password):
    # require-modes "z";         # Requiere TLS
    # fingerprint "AA:BB:CC:...";
};

# Hash de contraseña — generar con:
# /home/ircd/unrealircd/bin/unrealircd mkpasswd argon2id
# Introduce la contraseña y te da el hash

Configuración en InspIRCd

# inspircd.conf











Consejo: Nunca uses autenticación solo por contraseña. Combina siempre con restricción de host (mask) y/o fingerprint de certificado TLS. Un /oper con password pero sin restricción de IP significa que cualquiera que obtenga tu contraseña puede operarse desde cualquier parte del mundo. Con fingerprint de certificado, necesitarían tu certificado privado además de la contraseña.

Comandos de operador

/kill — Desconectar un usuario

# Desconectar un usuario con razón:
/kill nick :Violación de las reglas de la red

# El usuario ve:
# Killed (marco (Violación de las reglas de la red))
# Y es desconectado del servidor

# IMPORTANTE: /kill es una desconexión, NO un ban.
# El usuario puede reconectar inmediatamente.
# Si necesitas impedir la reconexión, usa /kline o /gline.

/kline — Ban a nivel de servidor

# Ban temporal (1 hora) por host:
/kline 1h *@evil-host.com :Abuso detectado

# Ban temporal (7 días) por IP:
/kline 7d *@203.0.113.0/24 :Rango de botnet

# Ban permanente:
/kline *@*.spam-isp.net :ISP no cooperativo

# Eliminar un kline:
/unkline *@evil-host.com

# Listar klines activas:
/stats k

/gline — Ban a nivel de red

# G-line se propaga a TODOS los servidores de la red:
/gline *@botnet-source.net 24h :Botnet activa

# La diferencia con kline:
# kline  = solo este servidor
# gline  = toda la red (todos los servidores)
# zline  = por IP (sin resolver hostname) — más difícil de evadir
# qline  = prohíbe un nick o patrón de nick
# shun   = silencia al usuario sin desconectarlo (UnrealIRCd)

# Ejemplo de shun:
/shun *@sospechoso.host 2h :Estamos investigando tu actividad

/rehash — Recargar configuración

# Recargar la configuración sin reiniciar el IRCd:
/rehash

# El servidor relee unrealircd.conf (o inspircd.conf)
# y aplica los cambios. Las conexiones existentes NO se interrumpen.

# Rehash remoto (en otro servidor de la red):
/rehash servidor.remoto.net

Snomasks: los ojos del operador

Las server notice masks (snomasks) son filtros que determinan qué notificaciones del servidor ves. Son el equivalente a suscribirte a canales de log específicos. Cada snomask es una letra que habilita un tipo de notificación.

# Activar snomasks:
/mode tu_nick +s +cFkejvGnNqS

# Snomasks comunes en UnrealIRCd:
# c = conexiones locales (CONNECT)
# f = flood detectado
# F = conexiones remotas
# k = kills
# e = eyes (operadores haciendo /oper)
# j = junk (problemas de link)
# v = virus/trojan detected
# G = glines activas/expiradas
# n = cambios de nick locales
# N = cambios de nick remotos
# q = rechazos de conexión
# S = spamfilter matches

# Ver qué snomasks tienes activas:
/mode tu_nick
# Busca +s seguido de las letras

# Snomasks en InspIRCd:
# a = ANNOUNCE (oper announcements)
# c = CONNECT (local connections)
# C = REMOTE CONNECT
# d = DEBUG
# k = KILL (local kills)
# K = REMOTE KILL
# l = LINK (server links)
# o = OPER (oper up/down)
# q = QUIT (local quits)
# x = XLINE (ban adds/removes)

Mi setup de snomasks es +cFfkeSG. Conexiones, flood, kills, operadores, spamfilter y glines. Los cambios de nick (n/N) generan demasiado ruido en redes con más de unos pocos cientos de usuarios — los tengo desactivados y confío en los logs para cuando necesito rastrear un nick específico.

Advertencia: Los snomasks de conexión (c/F) muestran las IPs reales de los usuarios que conectan. Si tienes tu ventana de IRC compartida en pantalla (streaming, presentación, etc.), desactiva estos snomasks temporalmente. He visto operadores filtrar IPs de usuarios en directo sin darse cuenta.

Niveles de operador y privilegios

La mayoría de IRCds permiten definir diferentes niveles de operador con distintos privilegios. En UnrealIRCd se llaman "operclass" y en InspIRCd son "types" y "classes".

# Jerarquía típica (de menos a más privilegios):

# 1. Local Operator (locop)
#    - /kill usuarios locales
#    - /kline (solo servidor local)
#    - Snomasks básicos
#    - NO glines, NO rehash, NO links

# 2. Global Operator (globop)
#    - Todo lo de locop +
#    - /kill usuarios de cualquier servidor
#    - /gline (ban en toda la red)
#    - Snomasks completos
#    - /map, /trace

# 3. Network Administrator (netadmin)
#    - Todo lo de globop +
#    - /rehash
#    - /connect, /squit (gestión de links)
#    - /spamfilter
#    - /sajoin, /samode (override de canales)

# 4. Server Administrator (serveradmin)
#    - Todo lo de netadmin +
#    - /die, /restart
#    - Configuración completa del servidor

# UnrealIRCd - operclass predefinidas:
operclass locop {
    permissions {
        kill;
        kline;
        snomask { local; };
    }
};

operclass globop {
    parent locop;
    permissions {
        kill { remote; };
        gline;
        snomask { global; };
    }
};

operclass netadmin {
    parent globop;
    permissions {
        rehash;
        server { link; delink; };
        spamfilter;
        sajoin;
        samode;
    }
};

Responsabilidades reales

Ser IRCop no es solo tener comandos. Es una responsabilidad con la comunidad. Después de más de 20 años como operador, estas son las reglas no escritas que sigo:

1. No intervengas en canales ajenos

Si el fundador de #canal-random tiene un conflicto con sus operadores, no es tu problema como IRCop. Tu jurisdicción es la red, no los canales individuales. La excepción: actividad ilegal, phishing, distribución de malware.

2. Documenta todo

Cada /kill, /kline y /gline debería tener una razón clara y documentada. "Porque me caes mal" no es una razón. "Flood en #canal detectado, 50 mensajes/segundo desde este host" sí lo es. Los logs están ahí para cuando alguien cuestione tus acciones.

3. Usa la fuerza mínima necesaria

Si un usuario spamea en un canal, un /kill es suficiente como primera advertencia. Si reincide, /kline temporal. /gline permanente es el último recurso. No uses un cañón para matar un mosquito.

4. Comunica a los otros operadores

Antes de hacer un /gline que afecte a toda la red, avisa al equipo. Usa el canal de operadores o el MemoServ. He visto glines puestas por un operador y quitadas por otro que no entendía por qué estaban — la comunicación evita estos conflictos.

5. Nunca leas mensajes privados

Técnicamente, con acceso al servidor puedes ver todo el tráfico. Éticamente, nunca deberías leer conversaciones privadas de usuarios. La confianza de tu comunidad depende de esto. Si necesitas investigar un abuso, usa los logs del servidor (que registran metadatos, no contenido) y pide evidencia al denunciante.

Errores de novato que he cometido

Para que no los repitas:

  • /kill reactivo — Alguien me insultó en un canal, le hice /kill. El usuario se quejó públicamente, otros usuarios le dieron la razón, y mi reputación como operador quedó tocada durante meses. Lección: si es personal, no actúes como IRCop.
  • Gline demasiado amplia — Quería banear un rango /24 de un ISP problemático. Me equivoqué en la máscara y baneé un /16 entero. 50 usuarios legítimos desconectados. Lección: verifica dos veces la máscara antes de ejecutar.
  • Operar sin TLS — En mis primeros años, hacía /oper en una conexión sin cifrar. La contraseña viajaba en texto plano. Si alguien estaba sniffando la red entre mi casa y el servidor, tenía mis credenciales de operador. Lección: NUNCA hagas /oper sin TLS.
  • No tener backup de la config — Hice un /rehash después de editar la config directamente en producción. Había un error de sintaxis. El IRCd no pudo cargar la configuración y se quedó con la anterior, pero los servicios que dependían de la nueva config fallaron. Lección: valida la config antes de rehashear, y siempre ten una copia de la config anterior.
# Validar la configuración ANTES de rehashear:

# UnrealIRCd:
/home/ircd/unrealircd/bin/unrealircd configtest
# Si no hay errores: "Configuration test passed"

# InspIRCd:
/home/ircd/inspircd/bin/inspircd --testconf
# Si no hay errores: "Configuration is valid"

# SOLO DESPUÉS de que el test pase:
/rehash

Preguntas frecuentes

¿Cuántos IRCops necesita una red?

Depende del tamaño y la actividad. Para una red de 200-500 usuarios, 3-5 operadores activos en diferentes zonas horarias es razonable. Lo que quieres es que haya al menos un operador disponible en cualquier momento del día. Un operador por zona horaria principal (América, Europa, Asia) es el mínimo para redes con usuarios internacionales. Más operadores no siempre es mejor — más operadores significa más opiniones sobre cómo gestionar situaciones, lo cual genera conflictos internos.

¿Qué hago si un IRCop abusa de sus privilegios?

Si tienes acceso a la configuración del servidor, revoca su bloque oper, rehashea, y discute la situación con el equipo. Si no tienes acceso directo, contacta a quien lo tenga. En redes con buena gobernanza, debería haber un proceso definido para revocar privilegios. Si la red no tiene gobernanza clara y el operador abusivo controla el servidor... esa es una de las razones por las que las redes IRC mueren. La gobernanza importa desde el día uno.

¿Es posible ser IRCop sin acceso root al servidor?

Sí, y es lo habitual. El administrador del servidor configura tu bloque oper en la configuración del IRCd. Tú solo necesitas conectar a la red y hacer /oper. No necesitas SSH ni root en el servidor. Tus privilegios como IRCop están definidos en la configuración — puedes tener /kill y /kline sin tener /rehash o /die. El principio de mínimo privilegio se aplica aquí: solo da los permisos que cada operador necesita para su función.