Cómo evitar que un reporte de abuso se pierda en la bandeja de entrada

La casilla de abuse

En la región de LACNIC la casilla de abuse tiene una sección propia en el manual de políticas. La sección 12 del Manual de Políticas “Registro y Validación de abuse-c y abuse-mailbox”, establece:

• Requiere intervención por parte del destinatario.
• No debe exigir el uso de un formulario para reportar un abuso.
• Debe garantizar que los reportes de abuso, logs, cabeceras, ejemplos, etc., relativos al caso de abuso, sean recibidos.

Dicho de otro modo: la casilla existe, es obligatoria y alguien se comprometió por escrito a leerla. El problema, entonces, es otro.

Por qué un humano no da abasto

¿Cuál es el problema entonces? Que no hay un idioma común. Abusix, la empresa detrás de XARF, cuenta que necesitó desarrollar más de 500 parsers distintos para poder procesar los reportes que reciben sus clientes: cada fuente inventa su propio formato.

Un reporte en texto libre suele fallar en lo básico:

• la fecha sin indicar la zona horaria,
• IP de origen sin puerto, no especificar el protocolo, 
• evidencia sin el timestamp que la ata al evento.

XARF: el formato pensado para este caso

XARF (eXtended Abuse Reporting Format) es un formato de reporte de abuso basado en JSON, mantenido por la comunidad en xarf.org. La versión vigente es la v4, que organiza 32 tipos de incidentes en 7 categorías, desde spam y phishing hasta ataques de red y vulnerabilidades, cada uno con su esquema propio.

Lo mínimo que exige la v4 son siete campos: versión del esquema, identificador único, timestamp del incidente, quién reporta, el origen del abuso y la dupla categoría más tipo. Ojo con el origen: apunta a la IP o el dominio infractor, no a la víctima. La evidencia figura como recomendada, aunque en los hechos es lo que vuelve accionable el reporte. Hay un detalle especialmente útil para los CSIRT: la v4 distingue entre reporter (quien detectó el abuso) y sender (quien envía el reporte), justamente para el caso de un CERT nacional que reporta en nombre de sus miembros.

Para enviarlo por correo, XARF se apoya en ARF (RFC 5965): un mensaje multipart/report de tres partes, una legible por humanos, una legible por máquinas y una con la evidencia. Así, el analista lee el texto y el sistema parsea el JSON. Nadie tiene que elegir.

Ejemplo de reporte sobre ataque DDoS:

From: Example ISP NOC <noc@example-isp.com>
To: abuse@upstream-provider.net
Subject: [XARF] ddos desde 192.0.2.100
Message-ID: <7d1e4f28-9b03-4a6c-8e51-c2f7a04b91d6@example-isp.com>
Date: Mon, 15 Jan 2024 10:00:32 +0000
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="----=_Part_XARF_9f31a"

------=_Part_XARF_9f31a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Automated abuse report.

  Type:        DDoS (UDP flood)
  Source:      192.0.2.100:53
  Destination: 203.0.113.50:53
  First seen:  2024-01-15T09:52:00Z
  Confidence:  0.95

See the attached XARF report for full details and evidence.

------=_Part_XARF_9f31a
Content-Type: message/feedback-report
Content-Disposition: inline

Feedback-Type: xarf
User-Agent: ExampleISP-AbuseReporter/2.0
Version: 1

------=_Part_XARF_9f31a
Content-Type: application/json; name="report.json"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.json"

ewogICJ4YXJmX3ZlcnNpb24iOiAiNC4yLjAiLAogICJyZXBvcnRfaWQiOiAiNTUw
ZTg0MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAwIiwKICAidGltZXN0YW1w
IjogIjIwMjQtMDEtMTVUMTA6MDA6MDBaIiwKICAicmVwb3J0ZXIiOiB7CiAgICAi
[... resto del JSON en base64 ...]

------=_Part_XARF_9f31a--

El JSON adjunto:

{
  "xarf_version": "4.2.0",
  "report_id": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2024-01-15T10:00:00Z",
  "reporter": {
    "org": "Example Security Team",
    "contact": "abuse@example.com",
    "domain": "example.com",
    "type": "automated"
  },
  "sender": {
    "org": "Example ISP",
    "contact": "noc@example-isp.com",
    "domain": "example-isp.com"
  },
  "source_identifier": "192.0.2.100",
  "source_port": 53,
  "category": "connection",
  "type": "ddos",
  "first_seen": "2024-01-15T09:52:00Z",
  "protocol": "udp",
  "destination_ip": "203.0.113.50",
  "destination_port": 53,
  "attack_vector": "udp_flood",
  "evidence_source": "honeypot",
  "description": "DDoS attack detected from this IP address",
  "evidence": [
    {
      "content_type": "application/octet-stream",
      "description": "Packet capture showing attack traffic",
      "payload": "1MOyoQIABAAAAAAAAAAAAP8AAAABAAAA...",
      "hash": "sha256:a3f7b8c9d2e1f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9"
    }
  ],
  "confidence": 0.95,
  "tags": ["ddos", "udp-flood", "dns-amplification"]
}

Otros formatos, y cuándo usar cada uno

IODEF (RFC 7970) es el estándar del IETF para intercambio de incidentes. En formato XML, detallado que XARF.

STIX y MISP resultan herramientas ideales para el intercambio de inteligencia entre pares (como indicadores, campañas o TTPs), sin embargo, no fueron creadas con el fin de notificar a un operador que uno de sus clientes está realizando escaneos o aloja phishing.

Texto plano sigue siendo válido si respeta lo mínimo: recurso afectado, timestamp en UTC, tipo de abuso, evidencia y un contacto que responda. Un buen texto plano le gana a un JSON mal armado.

Qué podemos empezar a hacer

Si reportas: usa un formato estructurado, incluye siempre zona horaria, y consulta el abuse-c en el WHOIS/RDAP antes de enviarlo

Si recibes: valida tu contacto cuando LACNIC te lo pida, responde los reportes que recibas.

Referencias

• Manual de Políticas de LACNIC, sección 12. Registro y Validación de “abuse-c” y “abuse-mailbox”: https://innova.lacnic.net/innovaportal/file/543/1/manual-politicas-sp-2-21.pdf
• Especificación XARF v4: https://xarf.org/docs/specification/
• RFC 6650: An Extensible Format for Email Feedback Reports (ARF): https://www.rfc-editor.org/info/rfc6650/
• RFC 7970: The Incident Object Description Exchange Format (IODEF): https://www.rfc-editor.org/rfc/rfc7970.html