(ATF) Aggregate Threat Feed

aggregate feed sexyness
ATF sexyness

For my first post back into things in awhile (a long while), I thought I would introduce everyone to the sexyness that i’ve called the Aggregate Threat Feed or ATF for short. This feed is derived from threat data at work, namely our network edge IPS (a custom snort implementation, another post on that later) and aggregated firewall data from 250+ servers, mostly being brute force/invasive scan attack addresses.

There really is nothing terribly fancy about this, the data is presented in a drop list format that is updated every 15 minutes with an optional variable to adjust the amount of addresses returned:

http://asonoc.com/api/atf.php?top=50 (defaults at 100)

The entries in the list are sorted on the database side by highest event count first, you can optionally view the source and event count entries in the list but this is considered strictly for review purposes (it wouldn’t be of much other use). Take note that the maximum value for ‘top’ is 300.

http://asonoc.com/api/atf.php?top=300&fmt=list

The review data looks something like follows:

IP | SOURCE | EVENTS
———————-
187.45.224.5 ips 227
92.48.206.91 ips 202
69.13.196.47 fw 176
210.17.251.159 ips 130
83.170.110.194 fw 125

This is pretty basic to understand, the distinction to note however is that event numbers for IPS source data can be 50 events against 1 or 20 servers whereas the event count for fw sourced data typically reflect unique servers. So an address sourced from fw data with 200 events, actually hit 200 servers.

The next release of APF due in the coming months, will feature many changes and among them will be the inclusion of ATF as part of the new feed subscription feature. Further, users will have the option to enable reporting to the rfxn.com server that allows your own block data to be included in the ATF database. As more installations opt-in on this feature it will allow data aggregation to reflect a more global threat landscape that truly represents the users of APF (currently active installations based on those fetching the rfxn.com reserved.networks list daily: 46,921).

Also on the agenda is a simple ATF landing page that presents statistical data and some fancy graphs/charts (probably use google api cause im lazy like that), that will allow users to better visualize threats included in the feed and details on the actual events that caused an address to end up in it (snort events, firewall triggers etc..).

EOF

BOGON Filtering, Update It

One of the features used by APF to prevent address spoofing is that it filters reserved IP address space, also known as BOGON filtering. This is an otherwise very reliable method to keep out random unallocated spoofed addresses from injecting traffic towards your server, assuming, of course, the list is updated regularly.

We decided a few months ago that we would disable by default all remote features in APF, including the auto-updating of the reserved networks file (BOGON filter list). However, this was done with one ill-fated consequence… That if you do not turn on the update feature yourself you may inadvertently start filtering newly allocated address space. This was a change that in hindsight was probably not the best of ideas and as such has now been turned back on by default in the current APF release.

That is then the purpose of this post, every feature even in its best intentions has the capacity when it goes unmanaged to cause more harm than good and that is exactly what the BOGON filtering will do over time if left enabled and it goes unmanaged. The quick fix to this issue is that you enable the reserved network update feature or disable the use of the reserved network filtering in conf.apf altogether; below are details on conducting either task:

1) This change will make APF download and update to the latest reserved network file daily at 4 am (recommended):
edit /etc/apf/conf.apf and set the option DLIST_RESERVED=”1″
restart APF with /etc/init.d/apf restart

OR

2) This change will disable the use of reserved network filtering from APF altogether (not recommended!):
edit /etc/apf/conf.apf and set the option BLK_RESNET=”0″
restart APF with /etc/init.d/apf restart

I hope this assists anyone who is experiencing random connection issues from clients or to better decide if this feature is right for you. The BOGON list APF uses is maintained at http://www.rfxn.com/downloads/reserved.networks , which is updated twice daily with the latest data from ARIN.