swinog October 2022

swinog@lists.swinog.ch

22 participants
11 discussions

by Michele Capobianco

Hey all A friend just told me that Cybernet told him there is a Switzerlandwide Internet Problem. Does anybody know something? Cheers Michele -------- Online Consulting AG, Michele Capobianco, System Administrator, Weststrasse 38, CH-9500 Wil Phone +41 (0)71 913 31 31, Fax +41 (0)71 913 31 32 http://www.online.ch, michele.capobianco(a)online.ch<mailto:michele.capobianco@online.ch> --------

4 months, 3 weeks

Is AS203790 reading this list? (up-network.ch)

by Benoît Panizzon

Hi If so, could you please contact me off-list (attempted your abuse desk last week) regarding either a joe-job against your company, or a real incident where our customer involved is hiding his IP in our network behind cloudflare. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 year, 1 month

Server racks abzugeben / server cabinets available

by juergen＠jaritsch.at

Servus die Runde, wir bauen derzeit einen unserer Cages im Interxion ZUR1 um und haben dadurch einen kompletten Kaltgang abzugeben: 16 Stk 47U 800x1000 Minkels Racks Türen an der Rückseite Keine Trennwände (gibt es nach wie vor von Minkels direkt!) Keine Türen an der Front Kaltgang Dach Doppelte Schiebetüre an der Stirnseite Zweite Stirnseite offen Das System ist derzeit noch vollständig aufgebaut und kann auch besichtigt werden. Preis-Vorschläge gerne per Mail - wir stellen uns etwa 7000 CHF für die komplette Anlage vor. Per sofort verfügbar. Fotos: https://cloud.jaritsch.at/index.php/s/TJB3Z5RyEbYqyfN?path=%2F Weitere Details bzw Besichtung bitte direkt per Mail mit mir ausmachen. Danke & viele Grüße Jürgen #### Dear colleagues, we do rebuild one of our cages at Interxion ZUR1. Therefore we do have the below cold corridor containment available: 16 pcs 47U 800x1000 Minkels Racks Doors at the rear no slide-in walls between the cabinets (available from Minkels!) No doors at the front Cold corridor roof Sliding doors at the entrance of the roof No wall at the tail end System is still installed and can be reviewed in the datacenter. Price-discussions by email - we do guess to achieve something like 7000 CHF for the whole thing (16 racks incl cold corridor, etc). Counter offers are welcome! The system is immediately available. Pcitures: https://cloud.jaritsch.at/index.php/s/TJB3Z5RyEbYqyfN?path=%2F More details and discussion: please send me an email. thanks & best regards Jürgen

1 year, 1 month

Detecting, mitigating, and preventing distributed large-scale prefix de-aggregation attacks

by Lars Prehn

Dear SwiNOG, Our apologies to those who received this message via multiple channels. My colleagues and I recently revisited the topic of prefix de-aggregation attacks. We believe that the current IPv6 allocation policies combined with the ever-growing number of interconnection opportunities may facilitate those attacks to the point where they may circumvent traditional prevention mechanisms. Hence, we'd like to raise awareness on how to detect, mitigate, and prevent these kinds of attacks. # Prefix De-aggregation Attacks While allocation policies in IPv4 are very tight, even a new LIR can obtain, e.g., a /29 IPv6 address block from RIPE without justification [1]. This /29 may source more than a million unique IPv6 prefixes when using all CIDR sizes between /29 and /48 (the largest CIDR size that is not filtered). To prevent this many prefixes from flooding the DFZ, many ASes set a maximum prefix limit on their eBGP sessions. When initially introduced, these max-prefix limits prevented prefix de-aggregation attacks. In today's hyper-connected world, prefix limits transform these attacks into session-hunting challenges. To better illustrate this relationship, consider the following example: If an adversary combines two remote-peering offerings of BSO's IXReach [2] and Epsilon's Infinity Platform [3], they can establish ports at more than a hundred peering LANs. If this adversary uses Hurricane Electric as their IPv6 transit provider and establish a BGP session at every in-common peering LAN [4], this will lead to 100+ sessions. With a per-session limit of e.g. 500 prefixes, the adversary could redistribute 50K unique prefixes via this setup alone. If an adversary further increases the number of remote peering providers, adds announcements from BGP-enabled VPS services (e.g., Vultr [5] among many others [6]), and contracts additional IPv6 transit providers, they may globally increase the current IPv6 routing table size manifold. Notably, each of these new routes would have a valid ROV status once the adversary adds a single ROA entry for a /29 with a max CIDR size of /48; hence, they would pass the redistribution requirements for various transit providers. While many current router models support multiple million IPv6 routes, especially older models may crash, drop sessions, or behave in other unintended ways when either their FIB or RIB runs out of memory. When the adversary also withdraws all routes simultaneously, the number of updates generated from BGP's path-hunting may further lead to very high load for extended periods of time. To put this into perspective: Some of you might have noticed increased CPU load alongside other effects when Vultr was de-aggregating 12k IPv6 prefixes on October 5th [7]. Using the different methods described above, an highly-motivated adversary might be able to produce 1-2 orders of magnitude more updates. Please note that we performed various smaller (<600 prefixes) de-aggregation tests as part of our research---see sections 6 and 8 in the document referenced at the end of this notification for detailed explanations. While our experimental setup was very similar to the October 5th incident (we also announced address space obtained from SecureBit via VMs within Vultr), we are in no way related to that incident neither did we share any information about our research or findings with individuals outside our research group prior to the start of our private disclosure phase on October 11th. # Detection, Mitigation, and Prevention Mechanisms. Luckily, prefix de-aggregation attacks are easily detectable (e.g., based on prefix-limit notification thresholds or direct routing table size monitoring) and can be mitigated quickly by filtering either the more specifics of the covering prefix or all prefixes announced by the adversary's ASN(s). Effectively, damage can only be done within the human reaction time---which we hope to shorten with this notification. To protect yourself from prefix de-aggregation attacks, you may establish dynamic yet tight per-session limits on all eBGP sessions. As an adversary could enter unreasonably large values into databases such as PeeringDB, we'd recommend to not solely rely on them but also accept at most 1.5-2x the number of yesterday's prefixes for peers and customers and 1.2x yesterday's routing table size for transit providers (which would currently reflect a headroom of ~32k prefixes with a yearly growth rate of <50k prefixes [8]). We'd also recommend ensuring that the summed prefix limits across all sessions do not drastically exceed the router's maximal FIB size. To protect others, you may: (i) ensure that you only redistribute a certain number of routes per origin; currently, AS 9808 announces the most (~4K) IPv6 prefixes. (ii) ensure that you only redistribute a certain number of more-specific routes for each assigned address block; currently, 2409:8000::/20 is the prefix with the most (~10K) more-specifics. If you want to know more about the research that initiated this notification (including our concluded private disclosure process), you may find a write-up at: https://arxiv.org/pdf/2210.10676.pdf Best regards, Lars [1] https://www.ripe.net/publications/docs/ripe-738#initial_size [2] https://www.ixreach.com/services/remote-peering/ [3] https://epsilontel.com/global-network-footprint/internet-exchanges/ [4] https://he.net/peering.html [5] https://www.vultr.com/features/advanced-networking/ [6] https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6… <https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6…> [7] https://twitter.com/Qrator_Radar/status/1577748939805278209 [8] https://bgp.potaroo.net/v6/as2.0/index.html

1 year, 1 month

Re: MaxMind location determination (was: Contact: geoiplookup.net)

by Jeroen Massar

Hi, If you configure it (remarks and/or geofeeds: attribute in whois), they will come. I see a bit below a thousand IPs fetching my geofeed data over the last few days Quick grep (with some filtering due to versions etc) of UAs; see below; quite some normal web crawlers, but also dedicated it seems. Note that like anything, geofeed is just an indicator, somebody might use or not use it. Many build precise geoloc based of physical orders and/or GPS in mobile phones, thus depending on users logging in to certain websites or ordering things and having GPS enabled for that site... Greets, Jeroen -- "APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html)" "CheckMarkNetwork/1.0 (+http://www.checkmarknetwork.com/spider.html)" "Crawlbot/Nutch-1.19-SNAPSHOT" "Go-http-client/2.0" "IonCrawl (https://www.ionos.de/terms-gtc/faq-crawler-en/)" "Ipregistry/2.0.0 (geofeeds; +https://ipregistry.co)" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; +http://www.komodia.com/newwiki/index.php/URL_server_crawler) KomodiaBot/1.0" "Mozilla/5.0 (compatible; Adsbot/3.1; +https://seostar.co/robot/)" "Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)" "Mozilla/5.0 (compatible; Barkrowler/0.9; +https://babbar.tech/crawler)" "Mozilla/5.0 (compatible; Crawlson/1.0; +https://www.crawlson.com/search?q=site:as57777.net)" "Mozilla/5.0 (compatible; DataForSeoBot/1.0; +https://dataforseo.com/dataforseo-bot)" "Mozilla/5.0 (compatible; Dataprovider.com)" "Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/dotbot, help(a)moz.com)" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help(a)moz.com)" "Mozilla/5.0 (compatible; EntferBot/0.1; +https://entfer.com; +a_new_independent_search_engine;)" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "Mozilla/5.0 (compatible; Linespider/1.1; +https://lin.ee/4dwXkTH)" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)" "Mozilla/5.0 (compatible; MegaIndex.ru/2.0; +http://megaindex.com/crawler)" "Mozilla/5.0 (compatible; SeznamBot/4.0-RC1; +http://napoveda.seznam.cz/seznambot-intro/)" "Mozilla/5.0 (compatible; TorusBot/1.0; +https://torus.company/bot.html)" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" "Mozilla/5.0 (compatible; Yeti/1.1; +http://naver.me/spd)" "Mozilla/5.0 (compatible; ips-agent)" "Python/3.9 aiohttp/3.8.1" "Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)" "Wget/<various>" "axios/0.27.2" "clark-crawler2/Nutch-1.19-SNAPSHOT" "colly - https://github.com/gocolly/colly/v2" "curl/<various>" "db-ip "libwww-perl/6.42" "ltx71 - (http://ltx71.com/)" "netEstate NE Crawler (+http://www.website-datenbank.de/)" "python-requests/2.22.0" "serpstatbot/2.1 (advanced backlink tracking bot; https://serpstatbot.com/; abuse(a)serpstatbot.com)" "x28-job-bot; +http://x28.ch/bot.html" > On 17 Oct 2022, at 11:39, Fredy Kuenzler <kuenzler(a)init7.net> wrote: > > I think that the RFC8805 approach is the way to go for the industry, however I wonder which ISP is already using it in real life today. I couldn‘t find much about it besides the slides of RIPE81. > > We see GeoIP complaints of end customers on a regular basis and it would be nice if RFC8805 could solve the problem. > > https://ripe81.ripe.net/presentations/27-RIPE81_geofeeds_discovery.pdf > 27-RIPE81_geofeeds_discovery > PDF-Dokument · 2.3 MB > > > -- > Fredy Künzler > > Init7 (Switzerland) Ltd. > Technoparkstrasse 5 > CH-8406 Winterthur > https://www.init7.net/ > > <(null).(null)>_______________________________________________ > swinog mailing list -- swinog(a)lists.swinog.ch > To unsubscribe send an email to swinog-leave(a)lists.swinog.ch

1 year, 1 month

Contact: geoiplookup.net

by Benoit Panizzon

Hi Swinogers Does anyone know who operates geoiplookup.net and how to contact them? They repeatedly put parts of our IP ranges into Germany creating vast service disruptions for our affected customers by Swiss service providers that use their API for GeoBlocking. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 year, 1 month

switch started blocking whois queries?

by Benoit Panizzon

Hi Gang From three different IP Addresses I get: Requests of this client are not permitted. Please use https://www.nic.ch/whois/ for queries. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 year, 1 month

DNS help: named 'end of file resolving' a hostname.

by Benoît Panizzon

Hi Team Maybe some of you has already come over that issue and know how to fix. Bind 9.18.4 fails to resolve the A record of: fd19g0409.drive.pro.io Bind 9.11.36 works. Both versions have DNSSEC Validation enabled and connected to a network not restricting EDNS. Bind Logs: named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53 Dr. Google does not spit out any useful answer to this error. Analyzing the traffic with Wireshark, shows the authoritative server for this domain is answering and nothing jumps to my eye which could be wrong with the answer I see in the trace. I guess _.drive.pro.io is a dummy query performed to get OPTIONS. So my usual attempt is to disable all options that might cause issues: $ dig +noedns +nocookie +nodnssec +noednsnegotiation A fd19g0409.drive.pro.io @{BIND-9.18.4-NS} Error persists. Any help appreciated in a pointer to the possible cause. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 year, 1 month

Looking for /22 PA Space

by Matias Meier

Hello colleagues If anyone of you would like to sell a clean /22 IPv4 PA network, please reach out to me off list with your asking price. Thank you and have a nice day and soon, a nice weekend. Greetings Matias

1 year, 1 month

DEC-IX buy SwissIX?

by peerwithme

Today news is DE-CIX buy of SwissIX Why that is not consulted to the members? Why that is plan? Job of Rémy? Port price raise? garantie no price raise? DE-CIX is €€€€€€€€€ for small swiss network! DE-CIX = profit SwissIX = verein how is possible?

1 year, 1 month

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog October 2022