swinog

swinog@lists.swinog.ch

4 participants
2830 discussions

Buried alive in switzerland (long and painfull swiss intel hiccup)

by Catseye Chandra

Hello swinogers, Here's an update with my swiss intel affair in the field of telecoms. The feds are using IME/TrustZone for "étouffe, écrase d'affaire". I've had a supposed economical warfare act using the latest wifi hole in the linux kernel of mid october, an infiltration using IME on macOS deleting some files and modifying my OCaml compiler, all to prevent information leak about it. BE FRIGHTENED THE ROTTEN COPS ARE REALLY REALLY STRONG IN THIS COUNTRY BWAHAHAHHAAHHH! (do like me, go tell them to fuck off and you'll get a job change for FREE :) It's in french on my website - Google translate is your friend -- Version html disponible sur: http://www.strauss-engineering.ch/posts/sevices.html A noter que je n'ai, matériellement parlant, plus rien. Je vis désormais dans un établissement psycho-social médicalisé, à l'assurance invalidité, poussé par la force des choses, de loin pas par maladie mentale. Mon réseau de relation amicale ne compte plus qu'un à deux amis. 48 ans, pas de femme, pas de gosses, ce contre mon gré aussi. La plus grande partie de mon réseau de relation, essentiellement passé donc, est "réseauté" de manière sécuritaire. Le contact avec mes amis informaticiens m'est factuellement interdit. Le monde des avocats aussi, réseauté activement sur mes traces électroniques (emails, appels téléphoniques). 160 avocats contacté par email, 40 par lettres papier, 6 de visu ou par téléphone, réponses toujours négatives. Etouffe complète, à 100%, en tout cas tentative. Je n'ai jamais détenu le moindre secret, sauf les mots de passe de mon informatique. Aussi je coûte mensuellement plus de 7000.- par mois à la communauté, sans compter, sans connaître le budget de l'étouffe de cette affaire dans laquel je n'ai rien à voir. Probable jeux d'information fallacieux de la part d'enrôlés dans les télécoms il y a de cela plus de 20 ans en arrière. Je demande 3.5mio CHF net d'impôts comme réparation, probablement que l'enveloppe globale concernant l'étouffe de cette affaire est bien plus élevé. Constament des tentatives de petits roquets, petits rats de hiérarchie sécuritaire de me mettre dans une colère noir, afin que j'invective par email, aussi autour de moi voire que j'en arrive aux mains. 3 ans de lavage de cerveau, 3 ans de dépression abyssale, 14 ans de planche à savon, 20 ans à revenir à une forme normale. Pour rien, strictement rien, je n'ai jamais mis les pieds dans un central téléphonique (génération internet). Aussi google semble avoir été contacté afin de retourner très peu de résultat provenant de mon site web. Ne vous gênez pas de communiquer à ce sujet autour de vous. Salutations.

3 days, 5 hours

Fwd: [NLNOG] Voorkom AS-set namespace collisions. AS-A2B vs AS51088:AS-A2B // AS-SET Squatting

by Arnold Nipper

[ h/t Erik Bais ... helemaal bedankt, Erik! ] Erik hat eine einfache Anleitung, um AS-SET Squatting zu umgehen bzw. auf hierarchische AS-SET zu wechseln * Erstelle einen neuen AS-Set-Namen .. der mit der eigenen AS-Nummer beginnt .... ASNUMBER:<alter AS-Set-Name> * Kopiere alle Informationen darin, die auch im aktuellen (Short) AS-Set enthalten sind * Speichern und überprüfe es in der RIPE DB * Im alten AS-Set .. trägst du eine Referenz ein .. und lässt den Rest leer .. Du bekommst also nur eine Zeile mit Mitgliedern: ASNUMBER:<alter AS-Set-Name> * benachrichtige alle Peers und ändere auch den Eintrag in PeerinDB etc. Viele Grüße Arnold P.S.: Siehe auch https://www.ripe.net/ripe/mail/archives/routing-wg/2022-November/004649.html ff -------- Weitergeleitete Nachricht -------- Betreff: [NLNOG] Voorkom AS-set namespace collisions. AS-A2B vs AS51088:AS-A2B Datum: Fri, 18 Nov 2022 13:02:28 +0000 Von: Erik Bais <erik(a)bais.name> An: nlnog(a)nlnog.net <nlnog(a)nlnog.net> Ollah, Er loopt momenteel bij de RIPE Database Working group ( DB-WG ) een discussie <https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html> waarbij de AS-Set name misbruikt kan worden, omdat de normale short notatie zoals ( AS-A2B ) bij het aanmaken van een ‘nieuwe’ short as name, geen authorisatie vereist in referentie naar een origineel of naar een eigenaar van een netwerk. Nu is er een optie om je AS nummer als authorisatie te gebruiken .. en dan moet je dus je AS set naam aanpassen .. in <ASnummer>:<AS-set naam> Dit is al misbruikt in de afgelopen weken.. waarbij een of andere leukerd in de RIPE Database een AS-Set aangemaakt had met een naam AS-<grote cloud provider> .. Aangezien hun normaal hun AS-Set bij een andere database bijhielden, hadden ze hierdoor opeens een AS-Set name collission .. met als resultaat .. dat alle partijen die bijvoorbeeld bgpq4 gebruiken om de prefixfilters te maken, een lege prefixfilter als resultaat set kregen .. omdat ze tegen de lege AS set in de RIPE db aanliepen ..en daarna exit. Het is dus sterk aan te raden om de ‘long’ AS-Set notatie te gaan gebruiken voor je eigen (en je klanten) hun bereikbaarheid. Wat je nu binnen een paar minuten kan doen is: Creëer een nieuwe AS-Set naam .. die begint met je eigen AS nummer …. ASNUMMER:<oude AS set naam> Kopieer daar alle informatie in, die ook in je huidige (Short) AS-Set staat.. Bewaar en check die dan even in de RIPE DB. ( A2B voorbeeld : https://apps.db.ripe.net/db-web-ui/query?searchtext=as51088:as-a2b <https://apps.db.ripe.net/db-web-ui/query?searchtext=as51088:as-a2b> ) In de oude AS-Set .. zet je 1 verwijzing in .. en de rest laat je leeg .. Dus je krijgt dan alleen een regel met .. members: ASNUMMER:<oude AS set naam> ( Voorbeeld van AS-A2B - https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true… <https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true…> ) En bij peeringdb : zet je de nieuwe AS set naam (ASNUMMER:<oude AS set naam>) .. en wil je het helemaal fancy doen .. dan doe je RIPE:: ASNUMMER:<oude AS set naam> Als je RIPE:: ervoor zet, dan is dat een referentie naar in welke RIR DB je AS-Set te vinden is .. ( voorbeeld in PeeringDB : https://www.peeringdb.com/net/3237 <https://www.peeringdb.com/net/3237> ) Daarna is het handig om ook je AS object even een update te geven .. En loop even overal na, dat je je nieuwe AS-Set in je export regels hebt staan.. zoals : * remarks: Transits * remarks: ============================================================ * import: from AS2914 action pref=100; accept ANY AND NOT {0.0.0.0/0} * export: to AS2914 announce AS51088:AS-A2B * import: from AS3257 action pref=100; accept ANY AND NOT {0.0.0.0/0} * export: to AS3257 announce AS51088:AS-A2B Mocht je dat bij peers / klanten of internet exchanges ook hebben staan.. rinse & repeat .. you know the drill. ( Voorbeeld AS51088 - https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true… <https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true…> ). Het is een pleister tegen een mogelijk issue .. maar wel handig om dit correct te fixen .. waar je later veel plezier van kan hebben .. dus doe er je voordeel mee. Die fix die er besproken wordt in de RIPE DB WG, zorgt er voor dat er geen nieuwe AS-Sets met een short notatie aangemaakt kunnen worden. Maar verhelpen is beter dan genezen. Alvast prettig weekend, Groetjes, Erik Bais -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

5 days, 19 hours

Netbox or similar DCIM consulting/services

by Olaf

Hi, I am looking for someone that offers/provides consulting/services around Netbox or similar DCIM software for Staging/PoC for engineering before we would handover towards operations at my current employer. Gladly off-list via olaf.baumert(a)wz.axpo.com Sorry for the noise everyone not interested. Kind regards, Olaf

6 days, 3 hours

SWINOG Beers - Zurich, 1st December 2022

by Massimiliano Stucchi

Hi everyone, following the event from last week in Geneva, we are now organising swinog beers in Zurich for the 1st of December. We will be meeting at Paddy Reilly's (https://goo.gl/maps/M4Qqvka1FaE1yX1A7) at 17:30 on Thursday, December 1st. Everyone is welcome and there's no need to pre-register, although if you send me an email to let me know of your intentions, it will help in understanding how big of a group we will be. The formula is simple: just show up and enjoy meeting other networkers. Everyone pays for his/her own drinks and food. For any question, please feel free to get in touch with me. I hope to see many of you at the event! Ciao! -- Massimiliano Stucchi MS16801-RIPE Twitter: @stucchimax Telegram: https://t.me/stucchimax

1 week, 6 days

SWINOG Beers - Geneva 10th November

by Massimiliano Stucchi

Hi everyone, together with Will (PorCus), and after some discussions in Belgrade at RIPE85 last week, we have decided to organise some "Swinog Beers" in Geneva on the 10th of November. We will be meeting at Mulligan's (https://goo.gl/maps/VYm7T8P9uQ2dCTqs8) at around 17:30 on Thursday. Everyone is welcome and there's no need to pre-register, although if you send me an email to let me know of your intentions, it will help in understanding how big of a group we will be. The formula is simple: just show up and enjoy meeting other networkers. Everyone pays for his/her own drinks and food. For any question, please feel free to get in touch with me. I hope to see many of you next week! Ciao! PS: We will have a similar event in Zurich in a few weeks -- Massimiliano Stucchi MS16801-RIPE Twitter: @stucchimax Telegram: https://t.me/stucchimax

3 weeks, 3 days

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 ______________________________________________________

4 weeks

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 month, 1 week

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 month, 1 week

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 month, 1 week

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 month, 1 week

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog