From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: ASN support for iptables Date: Tue, 21 Nov 2017 13:12:58 +0000 Message-ID: <1511269978.4838.588.camel@ipfire.org> In-Reply-To: <20171120200306.51ef49b2.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2429243660155165014==" List-Id: --===============2429243660155165014== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, 2017-11-20 at 20:03 +0100, Peter M=C3=BCller wrote: > Hello Michael, >=20 > > Hi, > >=20 > > On Sun, 2017-11-19 at 15:52 +0100, Peter M=C3=BCller wrote: > > > Hello development list, > > >=20 > > > today, I'd like to discuss whether a new feature in > > > the firewall engine of IPFire makes sense or not. > > >=20 > > > Since Core Update 90, IPFire supports GeoIP based firewall > > > rules, which goes beyond simple IP addresses or CIDR blocks > > > and makes firewalling easier. > > >=20 > > > The idea I had in mind is to add ASN (Autonomous System > > > Number) support for firewall rules, too. > > >=20 > > > An AS (Autonomous System) can be described as an administrative > > > instance on top of IP: For example, several IP blocks belong > > > to an AS, i.e. to the same company, university or whatever. > > > Although these blocks may be used for completely different purposes > > > in completely different countries, they share the same owner. > > >=20 > > > Every AS has a number (ASN) and a description (sometimes > > > abbreviated to ASDescr), while the number is unique. =20 > >=20 > > I think this makes sense and I would welcome that as a new feature in > > IPFire. It > > will in the end have some similar problems like the GeoIP blocker, but th= at > > is > > not too bad. >=20 > Just for curiosity: Which ones are they? Apologies for nothing into depths of that. I just thought of the usual ones l= ike not actually blocking what the user intends to block. Rules changing because prefixes might be moved around, etc. It is just not 100% determinable. But indeed it is better than GeoIP. > I only see the (potential) problem of _another_ incomplete database here (s= ee > below). > Since all necessary data for this AS stuff are more or less public, inaccur= ate > data and extensive manual research are not necessary. >=20 > All we need is to write some scripts that convert the RIPE, ... databases > to a suitable format. Does such a public database of the RIRs exist? I don't know of one. For IPv4 handing out address space has slowed down a lot. And we should not u= se the BGP feed and parse that because then we might miss prefixes that are currently not announced - either deliberately or because of a downtime. I know this: http://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest But it doesn't connect the prefixes to an ASN AFAIK. > Second, in contrast to the GeoIP database, false-positives are extremely ra= re > when dealing with AS information since they have to be technically correct.= As > always, there are some "good" and "bad" ASNs, and a lot "grey" ones, which > stays > the same. We wouldn't really care about that, would we? That is up to the user to decide what they want to block/whitelist. > >=20 > > > There are some scenarios in which AS based firewall rules > > > make sense, since AS information change less seldom than > > > IP ranges: > > >=20 > > > (a) One wants to block malicious traffic, but blocking entire > > > countries is too much since there are some legitimate partners, > > > customers, ... out there. With AS support, it is possible to > > > grant them access by simply permitting their AS. The rest of > > > the country may now safely be blocked. =20 > >=20 > > True. This might work well in some situations, but is probably quite usel= ess > > when fighting against a botnet. >=20 > I am not sure about this. In some cases, blocking access to some bullet pro= of/ > rogue ISPs where many C&C servers are hosted improves the situation. Of > course, > if there is a simple DDoS attack from many different IPs, this will not help > very much. > >=20 > > What would also be good is to open a port forwarding only from a certain = AS. > > Let's call that whitelisting. >=20 > Yes, that is a very good use case. :-) >=20 > And the combination of GeoIP and AS filtering (inbound and outbound) > opens up fare more possibilities... How would we combine this? > > > (b) In some cases, IP ranges change very often, making firewall > > > rules very complex and hard to maintain, or the exact IP address > > > of a machine cannot be determined (dial-up connections). In > > > both cases, the AS (mostly) stays the same and allows firewall > > > rules without permitting access to a whole country. =20 > >=20 > > That will be the biggest challenge here. The database will need to be > > complete > > and needs regular updates. We don't really care if someone is actually > > announcing their prefix, but if they have one assigned, we should > > block/permit > > access. >=20 > I agree with you. >=20 > We could simply ship an updated version with every Core Update (I > had that in mind for the CA list, too, so we don't get too big deltas). If we don't convert this into some nice binary format this will indeed become= a huge database of probably ~10MB?! That would be too much to be included in ev= ery Core Update. > > > (c) Rogue ISPs (networks which are controlled/operated by professional > > > spammers or worse, such as the "Russian Business Network" (RBN), > > > which died in end-2007) sometimes run networks located in "good" > > > countries such as US or NL. Blocking them by GeoIP is not an > > > option because of many false-positives. AS based rules may help > > > here. =20 > >=20 > > The US is practically unblockable on the GeoIP filter, because too much is > > hosted in the US (at least according to the database by businesses that h= ave > > their HQ there). >=20 > Indeed, and there are several ASs over there the internet would be a better > place without. But I guess that applies to most other countries, too. > >=20 > > So this would be a good extension to blocking more granular. > >=20 > > > Since the data behind this can be extracted from BGP feeds, > > > no external databases (such as MaxMind) are required. =20 > >=20 > > If we would use a BGP feed, we will only have the networks in the database > > that > > are currently announced. Wouldn't scraping the WHOIS database be better? >=20 > Good idea. For example, RIPE has one here: > http://ftp.ripe.net/ripe/dbase/split/inet(6)num.gz And where is the link to the ASN? > >=20 > > Why not MaxMind? Not that I am in favour of that, but I am interested why= it > > is > > not an option. >=20 > Well, technically, it is an option. But since there is some trouble with > their GeoIP database, as mentioned somewhere else some time before, I'd > like to move away from them. What trouble? > And since we can build our own database here, I do not see why we should > rely on 3rd party data. > >=20 > > > Unfortunately, my programming skills are too low for implementing > > > this feature. Thereof, if it is decided to do this, I will need > > > some help here. :-) =20 > >=20 > > *raises hand* >=20 > Thank you very much. :-) > >=20 > > > Technically, this is similar to the GeoIP firewall stuff (just > > > another database), so I assume most of the work done there can > > > just be copied. =20 > >=20 > > The GeoIP block uses an iptables extension which parses the database. We > > wouldn't use that here but would either build something with ipset or > > similar. >=20 > Hmmm, not sure how well this performs: If there is only a small AS with > few IP ranges to parse, ipset would be sufficient. >=20 > However, if we have large networks (Level 3, Hurricane Electric, DTAG, ...), > ipset might become slow and cause many iptables rules. And if we update > the database (whomever created it), we need to reload the firewall rules. > Using a database lookup module similar to GeoIP avoids that issues here, as > far as I am concerned. I mean it is an option to build an iptables extension, but I am not sure if t= hat is the best thing. ipset is O(1) for each lookup. So it doesn't matter how large the AS is. iptables rules would be O(n) which is not very nice for larger ASNs, but we should have a look since I do not expect ASNs to announce hundreds of prefixe= s. The average might be way less and I have no idea what to expect as the worst- case performance. That needs investigation. Best, -Michael >=20 > Best regards, > Peter M=C3=BCller > >=20 > > > Any thoughts on this idea? > > >=20 > > > Best regards, > > > Peter M=C3=BCller =20 > >=20 > > -Michael >=20 >=20 --===============2429243660155165014== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxvVUpsb0FDZ2tRZ0hudy8yK1EKQ1FlMFVSQUFveUpDWnhvZURi dFhZdjlFSzduQVpjU0wyK3k4UFFtVjVtOVdSdGt3ektoN0VKUWVVWkd5dDNpUgpocm5wdHpTK2VF QW9FdWxncWNPcHpaVTNBTEdWaEQvMER2eTNBT2Q5WXNtcFNFdHpQZzk5OU1yOUFGWml3clVYCnZk S1puT3JpK2hnbXJyMjdET2VHbEtUT0ZuTFV0S3d2U2x4Njd5U3lCb0JLTURtSGNiZHE4MGlWRTR6 aVRjSEkKRzVFQy81RW4xYnJjdHdPT1VjQ1A1UlE3VHRlV2U3NXFCS2Q3N1hmcTladlNJM2MzUXJF OCtVVlZodjlyVE45cQpqbnZPakFrU2ErMHMrekFQT3o3dDJ3MjZRUndZQ0QyWDJlR2Y3MXZhbElQ Ry9qMDU0OFNUWVpEaUtWMEpEeGwrCndmUlhtMFUwV2ZXOTI1SENmK2M1SnI0c0diL2NNalpOdFlM K0Q0OVZPcmpvYVhhQy82b0pPZlFCeDBOcStDRFYKM3VTaHNTb2xocS9zbGZwVWhlcG5IRlZvdzZh NUVGY05XYzFjQkpzQjZsa1dFVFRhMTNPb2Zqb1BHdXBJeXRkKwpUa3lwemdJWUV1SjRSK0QycVYr NjhBNTllVVBQdXRDa3A4NXJaaGJFcE1kL0JSa25rOFhmc0pTTHcvZ0R2c0NXCmNPUElQczViWWlE aWNiRXdkK3IzVVZ4THhnQTFxUDdJd1c3MzFNMlNDZm5reDNOSEdYUTFmTVBkZnVnUVloYisKNGdy VkRLQUFJRVdQdTBRVE9zSDBaMEh1Smx5ZlB2VkVwWUtqcTZDVlU3eG9XNU9VZXZldEZJRWQ0ZXpM a1RRbAppVXE1cTBDOHoxN0FCT2MvZUlZeVFMRXloTktpUXIvS01kbDF2VUxOZGZweU1aNTluUDg9 Cj01NFdvCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============2429243660155165014==--