Enero 12

High Performance DoS Analyzer: FastNetMon

Install

For Debian 6, 7, 8 and CentOS 6, 7 and Ubuntu 14.04 and Fedora and Gentoo you should use the automatic installer:

wget https://raw.githubusercontent.com/pavel-odintsov/fastnetmon/master/src/fastnetmon_install.pl -Ofastnetmon_install.pl
sudo perl fastnetmon_install.pl

Please keep in mind! We track some information about your machine (os type and distro version). If you do not want to share this information, please add flag

--do-not-track-me

To intstall script call. But in this case we can’t improve FastNetMon for your distribution.

It’s REQUIRED to add all of your networks in CIDR notation (11.22.33.0/24) to the file /etc/networks_list in the form of one prefix per line. If you are running this software on an OpenVZ node, you may not need to specify networks explicitly, as we can read them from /proc/vz/veip.

You can whitelist prefixes by adding them to /etc/networks_whitelist (CIDR notation too).

Start main process:

/opt/fastnetmon/fastnetmon

Start the client process in another console:

/opt/fastnetmon/fastnetmon_client

To enable fastnetmon to start on server startup, please add the following line to /etc/rc.local:

/opt/fastnetmon/fastnetmon --daemonize

If something goes wrong, please check logs:

tail -f /var/log/fastnetmon.log

When an incoming or outgoing attack occurs, the program calls a bash script twice (if it exists):

/usr/local/bin/notify_about_attack.sh

The first time when threshold exceed (at this step we know IP, direction and power of attack). Second when we collect 100 packets for detailed audit of what happened.

A sample script is provided and can be installed as follows:

wget https://raw.githubusercontent.com/pavel-odintsov/fastnetmon/master/src/notify_about_attack.sh -O/usr/local/bin/notify_about_attack.sh
chmod 755 /usr/local/bin/notify_about_attack.sh

After downloading the file, you need to open it and configure the ’email_notify’ option as required.

You can use an alternative python script from here.

If you want to use unstable development branch, please use this syntax:

wget https://raw.githubusercontent.com/pavel-odintsov/fastnetmon/master/src/fastnetmon_install.pl -Ofastnetmon_install.pl
sudo perl fastnetmon_install.pl --use-git-master

 

High Performance DoS Analyzer fastnetmon High Performance DoS Analyzer High Performance DoS Analyzer

 

Example deployment scheme:

 

High Performance DoS Analyzer network_map High Performance DoS Analyzer High Performance DoS Analyzer High Performance DoS Analyzer High Performance DoS Analyzer High Performance DoS Analyzer

Category: BGP | Los comentarios están deshabilitados en High Performance DoS Analyzer: FastNetMon
Enero 23

Remotely-Triggered Black Hole (RTBH) Routing

Remotely-Triggered Black Hole (RTBH) routing is an interesting application of BGP as a security tool within service provider networks. One common use is mitigation of distributed denial of service (DDoS) attacks, as this article will explore.

Pictured below is a (very) simplified service provider architecture.

RTBH.png

Routers 1 through 4 compose the network core, and router 9 functions as a standalone “management” router for route injection. OSPF is running across the core to exchange internal routes. Each router in this core square also maintains an iBGP adjacency with the other core routers, and with router 9. The server at 172.16.10.100 represents the target of a DDoS attack.

Assume a DDoS attack is launched from the public Internet toward the customer server at 172.16.10.100. The throughput consumed is so excessive that the attack is impacting the entire internal infrastructure and must be blocked at the edge. Due to the distributed nature of the attack, we must block at the edge all inbound traffic destined for the victim. Rather than resorting to laborious and error-prone access lists, we can utilize BGP and RTBH to quickly achieve the desired result.

Step 1: Null route preparation

The first two steps in configuring RTBH should ideally be completed prior to an attack.

RTBH works by injecting a specially-crafted BGP route into the network, forcing routers to drop all traffic with a specific next-hop — effectively creating a “black hole.” We create a static route on all BGP routers for this next-hop address:

R1(config)# <strong>ip route 192.0.2.1 255.255.255.255 Null0</strong>

This route forces any traffic destined for 192.0.2.1/32 to be immediately dropped by the router. This route is added to all edge routers (R1 and R2) in our example lab.

Note that any IP address can be used for this black hole route; we use an IP from the reserved Test-Net range (see RFC 3330) here out of convenience, as this IP should never appear on a routed network.

Step 2: Route-map preparation

As with the first step, this configuration should also be completed prior to an attack.

A route-map is created to redistribute certain tagged static routes into BGP with a modified next-hop value:

R9(config)# <strong>route-map RTBH</strong>
R9(config-route-map)# <strong>match tag 666</strong>
R9(config-route-map)# <strong>set ip next-hop 192.0.2.1</strong>
R9(config-route-map)# <strong>set origin igp</strong>
R9(config-route-map)# <strong>set community no-export</strong>

This is the key component to RTBH: any route advertised to an edge router with a next-hop of 192.0.2.1 will force recursion to the static Null0 route we implemented in the prior configuration, and any matching traffic will be dropped.

Enable static route redistribution into BGP for the route-map to take effect:

R9(config)# <strong>router bgp 65100</strong>
R9(config-router)# <strong>redistribute static route-map RTBH</strong>

Step 3: Create a victim route on the management router

Once an attack is detected and the decision is made to block traffic, a static route for the victim address is created on the management router (R9):

R9(config)# <strong>ip route 172.16.10.100 255.255.255.255 Null0 tag 666</strong>

Ideally, we would like to simply advertise this route to the edge BGP routers, but a route cannot be advertised as having an invalid next-hop. So, we’ve added a tag value to ensure that our RTBH route-map redistributes the route into BGP with a modified next-hop. Note that the no-export community has been appended here to avoid accidentally exporting the route beyond the local AS.

With our victim route injected, we can verify that the edge routers now drop all traffic bound for that prefix:

R1# <strong>show ip route 172.16.10.100</strong>
Routing entry for 172.16.10.100/32
  Known via "bgp 65100", distance 200, metric 0, type internal
  Last update from 192.0.2.1 00:06:14 ago
  Routing Descriptor Blocks:
  <em>* 192.0.2.1, from 10.0.99.9, 00:06:14 ago</em>
  Route metric is 0, traffic share count is 1
  AS Hops 0

R1# <strong>show ip route 192.0.2.1</strong>
Routing entry for 192.0.2.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  <em>* directly connected, via Null0</em>
  Route metric is 0, traffic share count is 1

Of course, the victim is now unreachable, and we’ve effectively assisted the DDoS in accomplishing its goal. However we have protected our internal infrastructure (and other customers) from the flood of traffic, affording us time to better investigate and more eloquently mitigate the attack. As you might imagine, there are more advanced implementations of this method which can be used, as future articles will cover.

Category: BGP | Los comentarios están deshabilitados en Remotely-Triggered Black Hole (RTBH) Routing