Flowspec rules. Trigger by source

[Makarevich strong]

Hello, community!
I have a question: is it possible to automatically set flowspec rules when an attack is detected, not by destination (the IP being protected), but somehow aggregate the attacking botnet and block outgoing malicious traffic?

Thanks in advance!

[Peter Phaal]

sFlow-RT's build-in BGP FlowSpec implementation can push filters that match on a wide range of fields and implement a variety of actions:

The challenge is in using flow analytics to reliable separate attack traffic from normal traffic originating on your network:

1. How extensive is your sFlow coverage? Are you just monitoring the router, or does coverage extend to the access layer? Monitoring all the way to the access layer is useful since it provides more data to work with and can locate sources of traffic by MAC address, even if IP addresses are spoofed.

2. Are you able to implement reverse path filtering to ensure that no spoofed traffic leaves your network? This will prevent on site hosts being used in DDoS reflection attacks. If reverse path filtering is infeasible then you could use sFlow to detect the spoofed traffic and push flowspec rules based on source address, source protocol, and source port (automatically withdrawing the rule when the traffic stops).

3. Traffic analytics can be helpful in building a profile of users on your network. The first step is to separate address space using sFlow-RT's address group function. Identifying CIDRs allocated to site services vs addresses allocated users via DHCP, for example. The DDoS Protect app  uses address groups to classify internal / external address space - it implements destination address filtering, but the classification scheme could be used for source address filtering. This grouping gives you a CIDR that could be used as a source filter in a FlowSpec rule that efficiently targets all the addresses in the group.

4. Incorporating information about command and control / compromised host address can also be used to build address groups and help identify potential bad actors on your network, for example, Triggered remote packet capture using filtered ERSPAN, builds an address group for compromised hosts.

5. For hostile traffic originating in your network, a flow definition along the lines:

keys:'ipsource,ipdestination', 

value:'frames', 

filter:'tcpflags~....0..1.&group:ipsource:ddos=local&group:ipdestination:ddos=external'

This flow definition identifies local ip addresses generating the largest number of connections per second to external ip addresses. 

The browse-flows app is a good way to experiment with different flow definitions before building scripts to automate detection and mitigation actions. A risk free starting point is to log suspected attacks to gain confidence in the filters before deploying automation. Something along the lines:

var groups = {
  external:["0.0.0.0/0"],
  internal:["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"],
  local:["x.x.x.x/x"] // enter local, routeable prefixes here
};
setGroups('ddos', groups);

setFlow('tcp-connections', {
  keys: 'ipsource,ipdestination',
  value: 'frames',
  filter: 'tcpflags~....0..1.&group:ipsource:ddos=local&group:ipdestination:ddos=external'
});

setThreshold('large-tcp-connection', { metric:'tcp-connections', value: 1000, byFlow:true});

setEventHandler(function(event) {
  logInfo(event.flowKey);
}, ['large-tcp-connection']);

You might also find incorporating the country: / asn: lookups in the flow definitions useful, see Defining Flows.

This is an interesting topic. Does anyone else have comments / suggestions about useful signatures / remediation actions for local bad actors? This would be a useful app to develop for sFlow-RT.