-
Peter Müller authored
A while ago, it was discussed whether or not libloc should become an "opinionated database", i. e. including any information on a network's reputation. In general, this idea was dismissed as libloc is neither intended nor suitable for such tasks, and we do not want to make (political?) decisions like these for various reasons. All we do is to provide a useful location database in a neutral way, and leave it up to our users on how to react on certain results. However, there is a problematic area. Take AS55303 as an example: We _know_ this is to be a dirty network, tampering with RIR data and hijacking IP space, and strongly recommend against processing any connection originating from or directed to it. Since it appears to be loaded with proxies used by miscreants for abusive purposes, all we can do at the time of writing is to flag it as "anonymous proxy", but we lack possibility of telling our users something like "this is not a safe area". The very same goes for known bulletproof ISPs, IP hijackers, and so forth. This patch therefore suggests to populate the "is_drop" flag introduced in libloc 0.9.8 (albeit currently unused in production) with the contents of Spamhaus' DROP lists (https://www.spamhaus.org/drop/), to have at least the baddest of the bad covered. The very same lists are, in fact, included in popular IPS rulesets as well - a decent amount of IPFire users is therefore likely to have them already enabled, but in a very costly way. It is not planned to go further, partly because there is no other feed publicly available, which would come with the same intention, volatility, and FP rate. The third version of this patch makes use of an auxiliary function to sanitise ASNs, hence avoiding boilerplate code, and treats any line starting with a semicolon as a comment, which should be sufficient. Further, extracting ASNs from the ASN-DROP feed is done in a more clear way, avoiding code snippets hard to read. Signed-off-by: Peter Müller <peter.mueller@ipfire.org> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
69b3d894