Re: automatic rtbh trigger using flow data

[Hugo Slabbert]

On Fri 2018-Aug-31 13:35:29 -0500, Aaron Gould  wrote:


* btw, what can you experts tell me about tcp-based volumetric attacks...
please help me to understand... does tcp have an inherent inability to
ramp-up to massive speeds/loads with it's sliding window and
must-rcv-ack-before sending more segments ??  I ask since I heard this years
ago about tcp and I wonder if this is why


UDP, depending on the application, can be reflected and amplified.  
Generally on the TCP side you can try SYN or ACK floods, but you're not 
going to get an amplified reflection.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



signature.asc
Description: Digital signature

RE: automatic rtbh trigger using flow data

[Aaron Gould]

(I think this is all about volumetric attacks btw...it's my belief that
slow-and-low attacks are continually occurring and are going largely
unnoticed...i'll speak for myself)

Few years ago we began seeing certain ports used as attack vectors, thus we
began our internet boundary policers for these ports... as time went on, we
add to that list of ports.  Some ports as we know, like dns, and I think ntp
from time to time (dang, sorry, lol) are used in amplification, and so, we
can't police legit ports too slowly or real stuff is affected... so that's
what Roland probably meant by "judiciously"

We also have inside this set of qos tools at the internet boundary, an
ever-growing acl that we call "repeat victims"...  we have grown to
understand that, if a customer ip address is attack once, it's likely it
will be attacked again...

There are new attacked ports all the time, so sometimes, an attack gets
through... which is causing me to think about an overall UDP limit on my
internet boundary ports... since most attacks are udp-based*furthermore,
along with that overarching udp limit, I may mark internet-sourced-udp with
a certain marking dscp/exp so that as it travels through my internet
network, it will be the first to get dropped (? Wred ? work well for udp?)
during congestion when an attack gets through

-Aaron

* btw, what can you experts tell me about tcp-based volumetric attacks...
please help me to understand... does tcp have an inherent inability to
ramp-up to massive speeds/loads with it's sliding window and
must-rcv-ack-before sending more segments ??  I ask since I heard this years
ago about tcp and I wonder if this is why 




-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
Sent: Friday, August 31, 2018 12:13 PM
To: NANOG list
Subject: Re: automatic rtbh trigger using flow data


On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote:

> Instead of rtbh I would suggest blocking/rate limiting common ports 
> used in DDoS attacks.

This isn't an 'instead of', it's an 'in addition to'.  And it must be 
done judiciously; many operators doing this have concentrated on common 
port-pairs observed in UDP reflection/amplification attacks.

It's important to understand that any kind of packet of any 
protocol/ports (if such concepts apply on the protocol in question) can 
be used to launch DDoS attacks.

We've many tools in the toolbox, and should use them in a 
situationally-appropriate manner.  And when we're using techniques like 
QoSing down certain ports/protocols, we must err on the side of caution, 
lest we cause larger problems than the attacks themselves.

---
Roland Dobbins 

RE: automatic rtbh trigger using flow data

[Lotia, Pratik M]

>many operators doing this have concentrated on common 
>port-pairs observed in UDP reflection/amplification attacks.

Yes, because that's a great starting point.

> And when we're using techniques like 
>QoSing down certain ports/protocols, we must err on the side of caution,

Arbor report mentions volumetric attacks using DNS, NTP form 75+% of the 
attacks. Then QoSing certain ports and protocols is the best way to start with.

~Pratik Lotia  



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
Sent: Friday, August 31, 2018 11:13 AM
To: NANOG list
Subject: Re: automatic rtbh trigger using flow data


On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote:

> Instead of rtbh I would suggest blocking/rate limiting common ports 
> used in DDoS attacks.

This isn't an 'instead of', it's an 'in addition to'.  And it must be 
done judiciously; many operators doing this have concentrated on common 
port-pairs observed in UDP reflection/amplification attacks.

It's important to understand that any kind of packet of any 
protocol/ports (if such concepts apply on the protocol in question) can 
be used to launch DDoS attacks.

We've many tools in the toolbox, and should use them in a 
situationally-appropriate manner.  And when we're using techniques like 
QoSing down certain ports/protocols, we must err on the side of caution, 
lest we cause larger problems than the attacks themselves.

---
Roland Dobbins 
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 01 Sep, 2018

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  713837
Prefixes after maximum aggregation (per Origin AS):  273774
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  342471
Total ASes present in the Internet Routing Table: 61678
Prefixes per ASN: 11.57
Origin-only ASes present in the Internet Routing Table:   53258
Origin ASes announcing only one prefix:   23227
Transit ASes present in the Internet Routing Table:8420
Transit-only ASes present in the Internet Routing Table:263
Average AS path length visible in the Internet Routing Table:   4.0
Max AS path length visible:  34
Max AS path prepend of ASN ( 30873)  32
Prefixes from unregistered ASNs in the Routing Table:59
Number of instances of unregistered ASNs:59
Number of 32-bit ASNs allocated by the RIRs:  23898
Number of 32-bit ASNs visible in the Routing Table:   19283
Prefixes from 32-bit ASNs in the Routing Table:   80844
Number of bogon 32-bit ASNs visible in the Routing Table:18
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:321
Number of addresses announced to Internet:   2855523908
Equivalent to 170 /8s, 51 /16s and 214 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.0
Total number of prefixes smaller than registry allocations:  238618

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   194522
Total APNIC prefixes after maximum aggregation:   55387
APNIC Deaggregation factor:3.51
Prefixes being announced from the APNIC address blocks:  192645
Unique aggregates announced from the APNIC address blocks:79290
APNIC Region origin ASes present in the Internet Routing Table:9034
APNIC Prefixes per ASN:   21.32
APNIC Region origin ASes announcing only one prefix:   2537
APNIC Region transit ASes present in the Internet Routing Table:   1348
Average APNIC Region AS path length visible:4.0
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4001
Number of APNIC addresses announced to Internet:  767494915
Equivalent to 45 /8s, 191 /16s and 11 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-139577
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:212189
Total ARIN prefixes after maximum aggregation:   100386
ARIN Deaggregation factor: 2.11
Prefixes being announced from the ARIN address blocks:   211909
Unique aggregates announced from the ARIN address blocks:100560
ARIN Region origin ASes present in the Internet Routing Table:18219
ARIN Prefixes per ASN:11.63

RE: automatic rtbh trigger using flow data

[Michel Py]

> Ryan Hamel wrote :
> I also want to make clear to Michel, that colo'ing a router at an ISP is no 
> different than plugging it into your local router, your uplink  will get 
> saturated beyond what it can physically handle with only the ACLs protecting 
> the other side, but if your clients are also receiving traffic on the same 
> uplink as the attack, it's a denial of service to them.

I understand, but there still is a difference : Bandwith inside the colo is 
cheaper than the WAN link; conceptually you could have multiple fat interfaces 
at the colo and hope to filter the unwanted traffic before it hits where it 
generally hurts : on the WAN link. Would save money only if the transit is 
billed separately from the WAN link traffic, and every situation is different.

Michel.

-Original Message-
From: NANOG  On Behalf Of H I Baysal
Sent: Friday, August 31, 2018 2:09 AM
To: Michel Py ; Aaron Gould ; 
mic...@arneill-py.sacramento.ca.us
Cc: Nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data

Most of the solutions mentioned are paid, or fastnetmon is partially paid. And 
the thing you want is paid i believe
Nice tool though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a timeseries 
database (like influxdb and NOT SQL LIKE!!!) you can do whatever you want 
with the (raw) data. And create custom triggers for different calculations.

Flows are on the fly and are coming in constantly, you could have a calculation 
like group by srcip and whatever protocol you want or just srcip, and make a 
calculation for every x seconds or minutes. As i mentioned the flow data is a 
constant stream, so you could have it triggered as fast as you want.

(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)

I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana) And in your case it would be a 
script that does a influxdb command to make the calculations and if the outcome 
shows an IP meeting the thresholds you have set in the calculation, you trigger 
a script that adjusts the route to be announced to your upstream with the 
correct
(rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:
>> Aaron Gould wrote :
>> I'm really surprised that you all are doing this based on source ip, 
>> simply because I thought the distribution of botnet members around the world 
>> we're so extensive that I never really thought it possible to filter based 
>> on sources, if so I'd like to see the list too.
> I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP 
> prefixes is nothing these days. I am not surprised that Joe pushes that to 
> some CPEs.
>
>> Even so, this would not stop the attacks from hitting my front door, 
>> my side of my Internet uplink...when paying for a 30 gigs CIR and 
>> paying double for megabits per second over that, up to the ceiling of 100 
>> gig every bit that hits my front door over 30 gig would cost me extra, 
>> remotely triggering based on my victim IP address inside my network would be 
>> my solution to saving money.
> I agree. If you want to get a real use of source blacklisting, to save 
> bandwidth, you probably went to rent a U in a rack at your upstream(s) to 
> block it there.
> I never did it past 1GE, and I have never measured seriously the bandwidth it 
> would save, would be curious to know.
> I think the two approaches are complementary to each other though.
>
> Michel.
>
>
> On Aug 30, 2018, at 6:43 PM, Michel Py  wrote:
>
>>> Joe Maimon wrote :
>>> I use a bunch of scripts plus a supervisory sqlite3 database process 
>>> all injecting into quagga
>> I have the sqlite part planned, today I'm using a flat file :-( I 
>> know :-(
>>
>>> Also aimed at attacker sources. I feed it with honeypots and live servers, 
>>> hooked into fail2ban and using independent host scripts. Not very 
>>> sophisticated, the remotes use ssh executed commands to add/delete. I also 
>>> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
>>> connectivity.
>> I would like to have your feed. How many attacker prefixes do you currently 
>> have ?
>>
>>> Using flow data, that sounds like an interesting direction to take this 
>>> into, so thank you!
>> The one thing we can share here is the attacker prefixes. The victim 
>> prefixes are unique to each of us but I expect our attacker prefixes to be 
>> very close.
>>
>> Michel.
>>
>> TSI Disclaimer:  This message and any files or text attached to it are 
>> intended only for the recipients named above and contain information that 
>> may be confidential or privileged. If you are not the intended recipient, 
>> you must not forward, copy, use or otherwise disclose this communication 

Re: automatic rtbh trigger using flow data

[Roland Dobbins]

On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote:

Instead of rtbh I would suggest blocking/rate limiting common ports 
used in DDoS attacks.


This isn't an 'instead of', it's an 'in addition to'.  And it must be 
done judiciously; many operators doing this have concentrated on common 
port-pairs observed in UDP reflection/amplification attacks.


It's important to understand that any kind of packet of any 
protocol/ports (if such concepts apply on the protocol in question) can 
be used to launch DDoS attacks.


We've many tools in the toolbox, and should use them in a 
situationally-appropriate manner.  And when we're using techniques like 
QoSing down certain ports/protocols, we must err on the side of caution, 
lest we cause larger problems than the attacks themselves.


---
Roland Dobbins 

RE: automatic rtbh trigger using flow data

[Lotia, Pratik M]

Instead of rtbh I would suggest blocking/rate limiting common ports used in 
DDoS attacks. That will block 90% of the DDoS attacks. We recently open sourced 
a BGP Flowspec based tool for DDoS Mitigation. It applies Flowspec rules per 
victim IP Addr.
https://github.com/racompton/docker-auto-flowspec


~Pratik Lotia 


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of H I Baysal
Sent: Friday, August 31, 2018 3:09 AM
To: Michel Py; Aaron Gould; mic...@arneill-py.sacramento.ca.us
Cc: Nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data

Most of the solutions mentioned are paid, or fastnetmon is partially 
paid. And the thing you want is paid i believe
Nice tool though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a 
timeseries database (like influxdb and NOT SQL LIKE!!!) you can do 
whatever you want with the (raw) data. And create custom triggers for 
different calculations.

Flows are on the fly and are coming in constantly, you could have a 
calculation like group by srcip and whatever protocol you want or just 
srcip,
and make a calculation for every x seconds or minutes. As i mentioned 
the flow data is a constant stream, so you could have it triggered as 
fast as you want.

(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)

I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana)
And in your case it would be a script that does a influxdb command to 
make the calculations and if the outcome shows an IP meeting the 
thresholds you have set in the calculation, you trigger a script that 
adjusts the route to be announced to your upstream with the correct 
(rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:
>> Aaron Gould wrote :
>> I'm really surprised that you all are doing this based on source ip, simply 
>> because I thought the distribution of botnet members around
>> the world we're so extensive that I never really thought it possible to 
>> filter based on sources, if so I'd like to see the list too.
> I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP 
> prefixes is nothing these days. I am not surprised that Joe pushes that to 
> some CPEs.
>
>> Even so, this would not stop the attacks from hitting my front door, my side 
>> of my Internet uplink...when paying for a 30 gigs CIR
>> and paying double for megabits per second over that, up to the ceiling of 
>> 100 gig every bit that hits my front door over 30 gig
>> would cost me extra, remotely triggering based on my victim IP address 
>> inside my network would be my solution to saving money.
> I agree. If you want to get a real use of source blacklisting, to save 
> bandwidth, you probably went to rent a U in a rack at your upstream(s) to 
> block it there.
> I never did it past 1GE, and I have never measured seriously the bandwidth it 
> would save, would be curious to know.
> I think the two approaches are complementary to each other though.
>
> Michel.
>
>
> On Aug 30, 2018, at 6:43 PM, Michel Py  wrote:
>
>>> Joe Maimon wrote :
>>> I use a bunch of scripts plus a supervisory sqlite3 database process all 
>>> injecting into quagga
>> I have the sqlite part planned, today I'm using a flat file :-( I know :-(
>>
>>> Also aimed at attacker sources. I feed it with honeypots and live servers, 
>>> hooked into fail2ban and using independent host scripts. Not very 
>>> sophisticated, the remotes use ssh executed commands to add/delete. I also 
>>> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
>>> connectivity.
>> I would like to have your feed. How many attacker prefixes do you currently 
>> have ?
>>
>>> Using flow data, that sounds like an interesting direction to take this 
>>> into, so thank you!
>> The one thing we can share here is the attacker prefixes. The victim 
>> prefixes are unique to each of us but I expect our attacker prefixes to be 
>> very close.
>>
>> Michel.
>>
>> TSI Disclaimer:  This message and any files or text attached to it are 
>> intended only for the recipients named above and contain information that 
>> may be confidential or privileged. If you are not the intended recipient, 
>> you must not forward, copy, use or otherwise disclose this communication or 
>> the information contained herein. In the event you have received this 
>> message in error, please notify the sender immediately by replying to this 
>> message, and then delete all copies of it from your system. Thank you!...

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not 

Re: automatic rtbh trigger using flow data

[Roland Dobbins]

On 31 Aug 2018, at 22:15, Hugo Slabbert wrote:

I would love an upstream that accepts flowspec routes to get granular 
about drops and to basically push "stateless ACLs" upstream.





---
Roland Dobbins 

Re: automatic rtbh trigger using flow data

[Roland Dobbins]

On 31 Aug 2018, at 16:33, Ryan Hamel wrote:

From experience, sflows are horribly inaccurate for DDoS detection, 
since the volume could disrupt the control plane and render the 
process useless, thus not giving data to the external system to act 
upon it.


On the contrary, flow telemetry in general works quite well for DDoS 
detection/classification/traceback, and is widely utilized for such 
purposes; it has been for many years.


I'm not a big fan of s/Flow comparatively speaking, but it and NetFlow, 
IPFIX, et. al. have proven themselves over the years, assuming that the 
flow export parameters on the exporting devices are configured 
correctly, and the collection/analysis systems are configured optimally.


Flow telemetry is management-plane, not control-plane.  Implementing 
network infrastructure self-protection BCPs such as iACLs is definitely 
recommended in general.



---
Roland Dobbins 

Re: automatic rtbh trigger using flow data

[Hugo Slabbert]

On Fri 2018-Aug-31 06:59:29 +0700, Roland Dobbins  wrote:


On 31 Aug 2018, at 6:47, Aaron Gould wrote:

I'm really surprised that you all are doing this based on source 
ip, simply because I thought the distribution of botnet members 
around the world we're so extensive that I never really thought it 
possible to filter based on sources, i


Using S/RTBH to drop attack sources has been a valid and useful 
mitigation tactic for close to 20 years.  Any kind of modern router 
scales up to large numbers of sources; and note that S/RTBH isn't 
limited to /32s.


It's discussed in this .pdf preso:




I would love an upstream that accepts flowspec routes to get granular about 
drops and to basically push "stateless ACLs" upstream.


_keeps dreaming_

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



signature.asc
Description: Digital signature

Re: automatic rtbh trigger using flow data

[H I Baysal]

I think your experience has to do more with your setup than sflow or 
influxdb...


my sflow data, that i push into influxdb. is 1 on 1 accurate with the 
interface utilization ( even on group by per source ip )

Arista performs fine with sflow Don't know what brand you used.
I'm getting 300 mbit of constant (sflow) data in influxdb


'''
it simply could not keep up, nor could I write any useful queries against it
'''

again, i really think this has to do with the setup or the queries you 
tried to do. (and (i think ) you tried sflow exporter on a server, i 
think the topic was from a appliance as an exporter)


If you still want to give influxdb+ sflow a try, i'm more than willing 
to help you out ;)



On 31-08-18 11:33, Ryan Hamel wrote:

 From experience, sflows are horribly inaccurate for DDoS detection, since the 
volume could disrupt the control plane and render the process useless, thus not 
giving data to the external system to act upon it. You can't get any better 
than mirroring your inbound transit, and sampling the output to a sensor.

I have also spent some time on a spare server running netmap and influxdb, it 
simply could not keep up, nor could I write any useful queries against it. 
Which is why I'm deciding on using pf_ring ft (flow table) and just let it 
calculate all the data to be dumped into a MySQL memory table, and also 
harvesting ntop's NDPI protocol decoding, to enhance the detection rules. My 
ideal setup is to break things down into dedicated programs like flow exporter, 
detection, and response.

I also want to make clear to Michel, that colo'ing a router at an ISP is no 
different than plugging it into your local router, your uplink will get 
saturated beyond what it can physically handle with only the ACLs protecting 
the other side, but if your clients are also receiving traffic on the same 
uplink as the attack, it's a denial of service to them.

-Original Message-
From: NANOG  On Behalf Of H I Baysal
Sent: Friday, August 31, 2018 2:09 AM
To: Michel Py ; Aaron Gould ; 
mic...@arneill-py.sacramento.ca.us
Cc: Nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data

Most of the solutions mentioned are paid, or fastnetmon is partially paid. And 
the thing you want is paid i believe
Nice tool though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a timeseries 
database (like influxdb and NOT SQL LIKE!!!) you can do whatever you want 
with the (raw) data. And create custom triggers for different calculations.

Flows are on the fly and are coming in constantly, you could have a calculation 
like group by srcip and whatever protocol you want or just srcip, and make a 
calculation for every x seconds or minutes. As i mentioned the flow data is a 
constant stream, so you could have it triggered as fast as you want.

(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)

I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana) And in your case it would be a 
script that does a influxdb command to make the calculations and if the outcome 
shows an IP meeting the thresholds you have set in the calculation, you trigger 
a script that adjusts the route to be announced to your upstream with the 
correct
(rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:

Aaron Gould wrote :
I'm really surprised that you all are doing this based on source ip,
simply because I thought the distribution of botnet members around the world 
we're so extensive that I never really thought it possible to filter based on 
sources, if so I'd like to see the list too.

I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes 
is nothing these days. I am not surprised that Joe pushes that to some CPEs.


Even so, this would not stop the attacks from hitting my front door,
my side of my Internet uplink...when paying for a 30 gigs CIR and
paying double for megabits per second over that, up to the ceiling of 100 gig 
every bit that hits my front door over 30 gig would cost me extra, remotely 
triggering based on my victim IP address inside my network would be my solution 
to saving money.

I agree. If you want to get a real use of source blacklisting, to save 
bandwidth, you probably went to rent a U in a rack at your upstream(s) to block 
it there.
I never did it past 1GE, and I have never measured seriously the bandwidth it 
would save, would be curious to know.
I think the two approaches are complementary to each other though.

Michel.


On Aug 30, 2018, at 6:43 PM, Michel Py  wrote:


Joe Maimon wrote :
I use a bunch of scripts plus a supervisory sqlite3 database process
all injecting into quagga

I have the sqlite part planned, today I'm 

RE: automatic rtbh trigger using flow data

[Ryan Hamel]

From experience, sflows are horribly inaccurate for DDoS detection, since the 
volume could disrupt the control plane and render the process useless, thus not 
giving data to the external system to act upon it. You can't get any better 
than mirroring your inbound transit, and sampling the output to a sensor.

I have also spent some time on a spare server running netmap and influxdb, it 
simply could not keep up, nor could I write any useful queries against it. 
Which is why I'm deciding on using pf_ring ft (flow table) and just let it 
calculate all the data to be dumped into a MySQL memory table, and also 
harvesting ntop's NDPI protocol decoding, to enhance the detection rules. My 
ideal setup is to break things down into dedicated programs like flow exporter, 
detection, and response.

I also want to make clear to Michel, that colo'ing a router at an ISP is no 
different than plugging it into your local router, your uplink will get 
saturated beyond what it can physically handle with only the ACLs protecting 
the other side, but if your clients are also receiving traffic on the same 
uplink as the attack, it's a denial of service to them.

-Original Message-
From: NANOG  On Behalf Of H I Baysal
Sent: Friday, August 31, 2018 2:09 AM
To: Michel Py ; Aaron Gould ; 
mic...@arneill-py.sacramento.ca.us
Cc: Nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data

Most of the solutions mentioned are paid, or fastnetmon is partially paid. And 
the thing you want is paid i believe
Nice tool though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a timeseries 
database (like influxdb and NOT SQL LIKE!!!) you can do whatever you want 
with the (raw) data. And create custom triggers for different calculations.

Flows are on the fly and are coming in constantly, you could have a calculation 
like group by srcip and whatever protocol you want or just srcip, and make a 
calculation for every x seconds or minutes. As i mentioned the flow data is a 
constant stream, so you could have it triggered as fast as you want.

(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)

I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana) And in your case it would be a 
script that does a influxdb command to make the calculations and if the outcome 
shows an IP meeting the thresholds you have set in the calculation, you trigger 
a script that adjusts the route to be announced to your upstream with the 
correct
(rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:
>> Aaron Gould wrote :
>> I'm really surprised that you all are doing this based on source ip, 
>> simply because I thought the distribution of botnet members around the world 
>> we're so extensive that I never really thought it possible to filter based 
>> on sources, if so I'd like to see the list too.
> I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP 
> prefixes is nothing these days. I am not surprised that Joe pushes that to 
> some CPEs.
>
>> Even so, this would not stop the attacks from hitting my front door, 
>> my side of my Internet uplink...when paying for a 30 gigs CIR and 
>> paying double for megabits per second over that, up to the ceiling of 100 
>> gig every bit that hits my front door over 30 gig would cost me extra, 
>> remotely triggering based on my victim IP address inside my network would be 
>> my solution to saving money.
> I agree. If you want to get a real use of source blacklisting, to save 
> bandwidth, you probably went to rent a U in a rack at your upstream(s) to 
> block it there.
> I never did it past 1GE, and I have never measured seriously the bandwidth it 
> would save, would be curious to know.
> I think the two approaches are complementary to each other though.
>
> Michel.
>
>
> On Aug 30, 2018, at 6:43 PM, Michel Py  wrote:
>
>>> Joe Maimon wrote :
>>> I use a bunch of scripts plus a supervisory sqlite3 database process 
>>> all injecting into quagga
>> I have the sqlite part planned, today I'm using a flat file :-( I 
>> know :-(
>>
>>> Also aimed at attacker sources. I feed it with honeypots and live servers, 
>>> hooked into fail2ban and using independent host scripts. Not very 
>>> sophisticated, the remotes use ssh executed commands to add/delete. I also 
>>> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
>>> connectivity.
>> I would like to have your feed. How many attacker prefixes do you currently 
>> have ?
>>
>>> Using flow data, that sounds like an interesting direction to take this 
>>> into, so thank you!
>> The one thing we can share here is the attacker prefixes. The victim 
>> prefixes are unique to each of us but I expect 

Re: automatic rtbh trigger using flow data

[H I Baysal]

Most of the solutions mentioned are paid, or fastnetmon is partially 
paid. And the thing you want is paid i believe

Nice tool though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a 
timeseries database (like influxdb and NOT SQL LIKE!!!) you can do 
whatever you want with the (raw) data. And create custom triggers for 
different calculations.


Flows are on the fly and are coming in constantly, you could have a 
calculation like group by srcip and whatever protocol you want or just 
srcip,
and make a calculation for every x seconds or minutes. As i mentioned 
the flow data is a constant stream, so you could have it triggered as 
fast as you want.


(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)


I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana)
And in your case it would be a script that does a influxdb command to 
make the calculations and if the outcome shows an IP meeting the 
thresholds you have set in the calculation, you trigger a script that 
adjusts the route to be announced to your upstream with the correct 
(rtbh) community.

( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:

Aaron Gould wrote :
I'm really surprised that you all are doing this based on source ip, simply 
because I thought the distribution of botnet members around
the world we're so extensive that I never really thought it possible to filter 
based on sources, if so I'd like to see the list too.

I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes 
is nothing these days. I am not surprised that Joe pushes that to some CPEs.


Even so, this would not stop the attacks from hitting my front door, my side of 
my Internet uplink...when paying for a 30 gigs CIR
and paying double for megabits per second over that, up to the ceiling of 100 
gig every bit that hits my front door over 30 gig
would cost me extra, remotely triggering based on my victim IP address inside 
my network would be my solution to saving money.

I agree. If you want to get a real use of source blacklisting, to save 
bandwidth, you probably went to rent a U in a rack at your upstream(s) to block 
it there.
I never did it past 1GE, and I have never measured seriously the bandwidth it 
would save, would be curious to know.
I think the two approaches are complementary to each other though.

Michel.


On Aug 30, 2018, at 6:43 PM, Michel Py  wrote:


Joe Maimon wrote :
I use a bunch of scripts plus a supervisory sqlite3 database process all 
injecting into quagga

I have the sqlite part planned, today I'm using a flat file :-( I know :-(


Also aimed at attacker sources. I feed it with honeypots and live servers, 
hooked into fail2ban and using independent host scripts. Not very 
sophisticated, the remotes use ssh executed commands to add/delete. I also 
setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
connectivity.

I would like to have your feed. How many attacker prefixes do you currently 
have ?


Using flow data, that sounds like an interesting direction to take this into, 
so thank you!

The one thing we can share here is the attacker prefixes. The victim prefixes 
are unique to each of us but I expect our attacker prefixes to be very close.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...