Rate this post

In matters of network security, two components functionally stand out:

  • IDS – Intrusion Detection System, an intrusion detection system, a component that detects the very fact of a malicious network intrusion. It can be a dedicated DPI (Deep Packet Inspection) system that allows traffic to pass through itself, a NetFlow statistics analyzer or this function can be built into an application, well, or implemented as a log analyzer (fail2ban).
  • IPS stands for Intrusion Prevention System, an intrusion prevention system, a component that blocks an attacker's network access to an attacked application. This system can be implemented as a function built into the application, a configurable packet filter on the host, as a firewall on the perimeter of the protected network segment, or as a regular network router with BGP. Let's talk about this option today.

All routers have the ability to set packet filters – sets of rules according to which passing traffic is filtered. This rule sets usually has to be entered into the router configuration in the form of an access control list (ACL) and then applied on interfaces, which is not very fast in fact and not very easy to automate. We need to distribute these lists throughout the network. It should also be borne in mind that ACL sizes are usually limited by the capabilities of the router.

These problems have been known for a long time, and in fact, in life, a slightly different approach is used in order to promptly prevent intrusions – blackholing (I wonder if this term can be used on English-language resources now?). For the entire provider network, one “damned” address is selected from the number of non-routable networks, for example, from the network or even – Further, on each router in the network, the route to this host is wrapped in Null, and then the routes to the addresses of the attackers are announced to the network with nexthop just and, of course, with community no-export. Routes are distributed throughout the entire network using BGP – and you’re done, traffic ON addresses of attackers will be destroyed on the very first router.

And here you have every right to exclaim “Well, what’s the point? I need to block traffic FROM the attacker!”. But there will be good. Even if you do not use the unicast reverse path forwarding check option, which will also “nullify” the traffic from the attacker, the “breaker” will not be able to receive responses from the victims, which will not allow complex types of attacks to be carried out. He will cease to be a “lomatel”, but at best he will be a DOS-er.

If you have routers with BGP address family flow support, then everything is conceptually simplified – this address family is just intended to distribute ACLs over the network. And in these ACLs, you can deny traffic FROM the attacker’s address and everything will work in the most correct way. But alas, not everyone can do this.

Thus, to provide IPS, you just need to ensure that the villains’ addresses are transmitted in the form of ACLs (or routes) over the network. This is done easily and naturally if you have a solution like Arbor Peakflow SP deployed on your network, and then you don’t have to read further.

But if not, if you want to provide such an IPS based on information from the logs of network devices, nginx, sshd, snort, suricata, etc., then I think ban2bgp can help here.

This appendix continues the BGP to Rust admin trivia topic (BGPExplorer).

ban2bgp allows you to temporarily ban addresses specified via http rest api in the form of announcements via BGP flow acl and / or blackhole routes. In the counter there is an example of setting for fail2ban – after an attempt to hack your server or attempts to log on to network devices, a villain can be disconnected for an hour not only from one device, but also from your entire network.

For installation, it’s easier to take the sources from the github, it is assumed that you already have git and rust.

$ git clone https://github.com/wladwm/ban2bgp
$ cd ban2bgp
$ cargo build

Let’s configure BGP route-reflector (we assume that RR has the address, our AS 65535, the machine with ban2bgp has the address

conf t
ip route Null0
router bgp 65535
neighbor remote-as 65535
neighbor update-source Loopback0
neighbor transport connection-mode passive
address-family ipv4
neighbor activate
neighbor route-reflector-client

Let’s create an ini with ban2bgp settings:

$ cat > ban2bgp.ini <

And let's run

$ cargo run

Now let's try to ban for an hour:

curl ""

Checking for RR:

#show route
Routing entry for
Known via "bgp 65535", distance 200, metric 0, type internal
Routing Descriptor Blocks, from

After the ban time expires, the route will be automatically recalled.

To issue ban2bgp commands from other hosts, its http rest api, of course, needs to be proxied or run not on

Ban2bgp.ini parameters:

  • httplisten - address and port to start http rest api, by default
  • listen is an optional address with a listening port for incoming BGP connections. The default is Of course, if the port is <1024, then you need to be root.
  • nexthop - ipv4 nexthop for blocking routes. On all routers, you need to statically wrap it in Null.
  • nexthop6 - ipv6 nexthop for blocking routes. On all routers, you need to statically wrap it in Null.
  • communities - a space-separated community list for routes.
  • peers - comma separated list of BGP peers, peer format <ip> AS <n>.
  • duration - the default ban duration in seconds.
  • skiplist - comma separated list of networks that cannot be banned, error protection.

List of endpoints http rest api:

  • /api/add?net= add a ban, net - ipv4 / ipv6 route to add, dur - ban time in seconds
  • /api/remove?net= remove ban
  • / api / json block operation, in POST you need to send JSON with a list of operations, for example: {"add": {"duration": 86400, "nets": [""]}, "remove": ["11.1 .1.1 "," "]}
  • / api / ping Check availability, "pong" responds
  • / api / dumprib Returns a list of blocked addresses