MikroTik RouterOS 7: NetFlow export and BGP blackholes

Checked against MikroTik’s pages Traffic Flow, BGP and Route Selection and Filters, and against captures from a RouterOS 7 router. Check against the documentation for your RouterOS version. Lines MikroTik’s pages don’t show verbatim are marked check on your version.

RouterOS exports NetFlow v9 and IPFIX and accepts blackhole routes. It has no sFlow export and no FlowSpec, so on a MikroTik, Heimnull mitigates attacks with blackholes.

The examples use these addresses. Replace them with your own:

Flow export (NetFlow v9)

/ip traffic-flow
set enabled=yes interfaces=ether1 cache-entries=1M packet-sampling=yes sampling-interval=1 sampling-space=99 \
    active-flow-timeout=15s inactive-flow-timeout=5s
/ip traffic-flow ipfix
set dst-mac-address=no src-mac-address=no tcp-ack-num=no tcp-seq-num=no tcp-window-size=no ttl=no \
    ip-header-length=no ip-total-length=no udp-length=no igmp-type=no is-multicast=no ipv6-flow-label=no
/ip traffic-flow target
add dst-address=10.0.0.10 port=2055 src-address=10.0.0.1 version=9 v9-template-refresh=20 v9-template-timeout=1m

• Interfaces. Only the WAN (ether1 here), so each packet is counted once. Both directions through it are exported, for IPv4 and IPv6, each in its own template.
• Sampling. sampling-interval is how many packets are sampled in a row, and sampling-space how many are skipped. 1 and 99 sample 1 in 100, and the record then carries 100 (IE 34), which Heimnull applies. At 1 in 500, a 10 Mbit/s link gives under one record a second, so the Live page has to average over about 30 seconds; at 1 in 100 that window is about 6 seconds. Check the router’s CPU (/system resource monitor) before and after.
• Timeouts. The router exports a flow only when it has been idle for inactive-flow-timeout, or every active-flow-timeout while it lasts. Heimnull counts late records from their arrival, so the lag is the timeout:
  • 5 seconds inactive gives about 6 seconds of delay on Live and about 10 seconds to detect an attack, against about 20 seconds at the 15-second default.
  • Keep the active timeout at 30 seconds or less, or long flows show up in bursts.
• Templates. v9-template-refresh counts packets, not time. On a quiet link that can be minutes apart, and records are dropped until the template arrives after a Heimnull restart. v9-template-timeout=1m bounds that.
• Fields. Heimnull uses addresses, ports, protocol, TCP flags, ToS, ICMP type and code, interfaces, timestamps, the gateway, and the NAT fields, which name the inside host behind your WAN address. The fields turned off above are never used, so records stay smaller. Check on your version that this menu also shapes NetFlow v9 records; on the router we tested, it does.
• Source address. Heimnull identifies the router by the datagrams’ source address, so set src-address.
• version=ipfix also works.

RouterOS counts received TCP packets after the kernel merges them, so a record can claim one packet of nearly 3,000 bytes. Heimnull recounts such records from their bytes, so packet rates stay true. There’s nothing to configure.

BGP session with Heimnull

Heimnull’s BGP speaker connects from Heimnull’s address. Add the session in Heimnull (Configure → BGP) with the MikroTik’s address, the remote AS, “Announce” on, and the IPv4 and IPv6 next hops the router should use for blackholes.

On the MikroTik (iBGP in this example):

/routing/bgp/connection
add name=heimnull remote.address=10.0.0.10 remote.as=64512 as=64512 local.role=ibgp \
    input.filter=heimnull-in output.filter-chain=heimnull-out

• Check on your version: the property names remote.as, as, input.filter and output.filter-chain come from RouterOS v7 examples. MikroTik’s BGP page shows the add name=… remote.address=… local.role=… form, but not every property.
• Send nothing. heimnull-out must reject everything. Heimnull accepts no routes from any session, but anything sent still sits in its BGP speaker’s memory (about 0.8 GiB per million routes).

Blackhole filter

Accept from Heimnull only host routes inside your networks that carry the blackhole community, and make them blackhole routes. Reject everything else.

/routing/filter/rule
add chain=heimnull-in rule="if (dst in 203.0.113.0/24 && dst-len == 32 && bgp-communities includes blackhole) { set blackhole yes; accept; }"
add chain=heimnull-in rule="if (dst in 2001:db8:42::/48 && dst-len == 128 && bgp-communities includes blackhole) { set blackhole yes; accept; }"
add chain=heimnull-in rule="reject"
add chain=heimnull-out rule="reject"

• blackhole above is RFC 7999’s well-known community, 65535:666. It’s the default we recommend: set it on Heimnull’s BGP page as the default community.
• If you use your own community, match it with a community list or a literal. Check the literal form on your version, for example bgp-communities includes 64512:666.
• blackhole is a writable route property in RouterOS v7 filters. Check whether your version wants set blackhole yes or set blackhole true: both forms appear in RouterOS v7 examples.
• Upstream RTBH. To pass the blackhole on to your transit providers, add their blackhole community in your export chain towards them, following each provider’s documentation.

Check it

• In Heimnull, Mitigations → “Mitigate an address” → Preview shows exactly what the MikroTik will receive. Use Dry run first.
• On the MikroTik, /routing/route print where blackhole should list the /32 while the blackhole is active, and nothing after it’s withdrawn. Check the exact print filter on your version.
• In Heimnull, each mitigation’s page shows what the session actually received, and every change is in the audit log.