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 198.18.0.0/15 network or even 192.0.0.0/24 – 192.0.0.0/32. 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 192.0.0.0 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 10.0.0.1, our AS 65535, the machine with ban2bgp has the address 10.1.1.1):

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

Let’s create an ini with ban2bgp settings:

$ cat > ban2bgp.ini <