swinog

swinog@lists.swinog.ch

2 participants
2940 discussions

### SwiNOG #38 - Agenda ###
by Simon Ryf 08 Jun '23

08 Jun '23

Dear SwiNOG community, we could finally compile the agenda for the upcoming SwiNOG #38 – June Wednesday 21st Have a look at https://www.swinog.ch/meetings/swinog38/ There is still time to https://register.swinog.ch/ if you have not done it already. We have a super packed agenda. On the other hand, I’m very happy with all the exciting speeches which have made it to the final list. A few last things to wrap up and then we’re ready to welcome you again in ~ 2 weeks. Looking forward to seeing many of you. SwiNOG Core Team

1 0

Re: swinog Digest, Vol 219, Issue 11
by f_sfetea＠yahoo.com 20 May '23

20 May '23

Hmm, instead of securing their networks and pushing for better security standards they'll cut access to one fish. Is that an ideal strategy? Some other bigger meaner fish will still use those vulnerabilities. I was wondering if the GSMA is or should regularly perform security audits. https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement… Or perhaps award publicly visible badges of honor to those mobile networks that are not vulnerable to similar attacks. I mean how many companies do we know? that publicly stated: Hello our mobile users btw. we fixed those vulnerabilities in our network! You should now be better protected. I never got any such information from any of my providers. Did you? Beste Grüsse, Regards si s-auzim de bine Florin Sfetea On Friday, May 19, 2023, 12:00:21 PM GMT+2, <swinog-request(a)lists.swinog.ch> wrote: Send swinog mailing list submissions to swinog(a)lists.swinog.ch To subscribe or unsubscribe via email, send a message with subject or body 'help' to swinog-request(a)lists.swinog.ch You can reach the person managing the list at swinog-owner(a)lists.swinog.ch When replying, please edit your Subject line so it is more specific than "Re: Contents of swinog digest..." Today's Topics: 1. Re: Sicherheit von SS7 - mit Schweiz-Bezug (Ralph Krämer) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 May 2023 22:33:17 +0200 (CEST) From: Ralph Krämer <ralph.kraemer(a)vable.ch> Subject: [swinog] Re: Sicherheit von SS7 - mit Schweiz-Bezug To: swinog <swinog(a)lists.swinog.ch> Message-ID: <172298345.199.1684441997706.JavaMail.zimbra(a)vable.ch> Content-Type: text/plain; charset=utf-8 nice : https://www.spiegel.de/netzwelt/netzpolitik/andreas-fink-mobilfunkverband-g… about time ;-) ----- Am 15. Mai 2023 um 13:31 schrieb Florin Sfetea via swinog swinog(a)lists.swinog.ch: > Hello all, > > I was reading this old(2018) ENISA Report [ > https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7… > | > https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7… > ] > Might help in some way but reading it had reminded me of ARP spoofing/poisoning > attacks which even today are still used and work in a lot of networks that I > have been. :) > > One year later I had open a case with Salt where I requested a public statement > that they had fixed/mediated the issues discovered up to that time(March 2019) > or at least that a remediation plan was in place. > > Someone from Support answered that " The introduction of 5G will only take place > if data security is guaranteed for our customers and we can assume that the > security issue will not lead to a delay in the introduction of 5G. " > > I was not satisfied ::)) with the answer and requested an escalation > > They eventually closed my case in July 2019 with: > > " Dear Sir, > > > Salt follows industry best practices in terms of security for its entire mobile > infrastructures and improves constantly the protection of its mobile > infrastructures and customers. The case you mention is known and has been > addressed accordingly. > " > No public statement nor such other mentions of which fix was exactly addressed. > > I don't have anything with any mobile provider. At that time it was just happen > to be Salt. I move from time to time to different other ones. > > I think we should have here in Switzerland more or less a same similar to ENISA > organization that should supervise and perform regular audits on mobile > providers. Melani/NCSC would that fit your bill? > > I never really had time to further test if any of those vulnerabilities or newer > where actually fixed. Someone should definitely do it. Free for fame or payed > from a government branch is to > [ https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement… > | https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement… > ] > > > Regards, > Florin > > _______________________________________________ > swinog mailing list -- swinog(a)lists.swinog.ch > To unsubscribe send an email to swinog-leave(a)lists.swinog.ch ------------------------------ Subject: Digest Footer _______________________________________________ swinog mailing list -- swinog(a)lists.swinog.ch To unsubscribe send an email to swinog-leave(a)lists.swinog.ch ------------------------------ End of swinog Digest, Vol 219, Issue 11 ***************************************

2 1

Re: Sicherheit von SS7 - mit Schweiz-Bezug
by Florin Sfetea 18 May '23

18 May '23

Hello all, I was reading this old(2018) ENISA Report https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7… Might help in some way but reading it had reminded me of ARP spoofing/poisoning attacks which even today are still used and work in a lot of networks that I have been. :) One year later I had open a case with Salt where I requested a public statement that they had fixed/mediated the issues discovered up to that time(March 2019) or at least that aremediation plan was in place. Someone from Support answered that "The introduction of 5G will only take place if data security is guaranteed for our customers and we can assume that the security issue will not lead to a delay in the introduction of 5G." I was not satisfied ::)) with the answer and requested an escalation They eventually closed my case in July 2019 with: "Dear Sir, Salt follows industry best practices in terms of security for its entire mobile infrastructures and improves constantly the protection of its mobile infrastructures and customers. The case you mention is known and has been addressed accordingly. " No public statement nor such other mentions of which fix was exactly addressed. I don't have anything with any mobile provider. At that time it was just happen to be Salt. I move from time to time to different other ones. I think we should have here in Switzerland more or less a same similar to ENISA organization that should supervise and perform regular audits on mobile providers. Melani/NCSC would that fit your bill? I never really had time to further test if any of those vulnerabilities or newer where actually fixed. Someone should definitely do it. Free for fame or payed from a government branch is to https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement… Regards, Florin

2 1

Mailproblems with / on (isis)servercorner.net
by Mueller Urs SBB CFF FFS 16 May '23

16 May '23

Hello One of my clients got a problem to receive mails from one customer. He sends mails from its system through isis.servercorner.net and the mailserver refuses to accept the mail with a «no such mailbox» answer. But the mailserver should not look for the mailbox but forward to M365. We suspect a wrong mx in the dns of servercorner.net. When we look into the mx of the customer, it looks like: dig mx 4plusarchitektinnen.ch +short 0 4plusarchitektinnen-ch.mail.protection.outlook.com. dig 4plusarchitektinnen-ch.mail.protection.outlook.com +short 104.47.22.10 104.47.22.74 The customer was on a hosting somewhere inside servercorner.net and we suspect there are leftovers. Anybody here from servercorner.net? How to contact? Regards, Urs

1 0

Front de libération des IXPs
by Angry Peer 14 May '23

14 May '23

Just have been made aware of https://www.de-cix.ch/ I would like to join! Have a nice Sunday afternoon, A.P.

1 0

IANA AS Numbers Registry Update
by Selina Harrington 11 May '23

11 May '23

Hi, The IANA AS Numbers registry has been updated to reflect the allocation of the following blocks to APNIC: 151866-152889 Assigned by APNIC 2023-05-10 152890-153913 Assigned by APNIC 2023-05-10 You can find the registry at: https://www.iana.org/assignments/as-numbers/ The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en Best Regards, Selina Harrington IANA Operations Manager

1 0

bluewin.ch and DMARC
by Juerg Reimann 05 May '23

05 May '23

Is there any particular reason why bluewin.ch does not support DMARC in the year 2023? Thanks, Juerg

1 0

Re: DNSSEC auto-disabled by SWITCH on some .ch domains?
by swinog＠klingonsec.ch 03 May '23

03 May '23

G'day Franco, To the partners at least, in October 2022 informing them that anything containing digest-type 1 and/or key algorithm 5 oder 7 are no longer supported and will be deleted. This was done last week and digest-type 2 and key algorithm should be used. Since end of January 2023 you could not use them anymore. cheers Marcus Monday, May 1, 2023, 12:55:56 AM, you wrote: >> Hey SWINOGgers, >> I noticed that DNSSEC was somehow auto-disabled at registry level for some .ch domains I am responsible for. >> For these domains, no DS records are published anymore in the .ch zone, dnsviz shows a broken chain of trust. >> However, registrar data still shows that DNSSEC is enabled, but the registry (SWITCH) says it is not... >> Is this a known problem? >> Seems not all DNSSEC protected .ch domains are affected, which leads me to the suspicion that it might have >> to do with the algorithm being used. >> Did SWITCH turn off older algorithms, e.g. algo 7 (RSASHA1-NSEC3-SHA1)? Did I miss an announcement? >> Random example, e.g. gkb.ch (notably a bank...) >>> dig +short @dns1.inventx.ch gkb.ch dnskey >>> 256 3 7 AwEAAdYydDZyd5M3UGS5b4Yv6qlIO5eOSwskJ/DQjiRO0as59ZG6hMDJ VseqslJMTwghdiCrd/sicWvDOszK6Cuqye0+ZEm9tfG6gxgWWmzpSmXQ KDHRG1iV8UF0KSOciFAPp4qRe083KPXu2ChXkTUSAa/iRCcZdFJK2M6l c7Gjjj55 >>> 257 3 7 AwEAAbQv5Whc+cna1IbtESB+Pwx+8eP5jfbjhuqiFuU/18qUckR9NxT7 KUCT8GDlRTsGYmuKxcMITvH510CgGOA/6TORaB4iIXRnACmfiiku25/B NHmNJd58ymZ/ED17smVJ4ou77/rhxW+/0Q1iVIAOcY8EblWq3EabepYz E6CY9Vh/RTh2mvSl80h8nZyFotsEwN0LIlc/Pi0qGmy7iTOBqtVsbFVm gssn/2c7IMCA8N2aaP1it8Qi+3DDGDh3N8HSEIVk+nrgQtsqQaLOFPGQ Q0ezahQO6oVGKG4XAHw+2XaZQ3UT0sTcFj3ZVKCcGE4Ddoa3J/gqLQh7 aA44cVIQx+s= >>> >>> dig +short @a.nic.ch gkb.ch ds >>> >>> -> no DS record >> Working example with algorithm 13 (ECDSA Curve P-256 with SHA-256): >>> dig +short @ns2.switch.ch switch.ch dnskey >>> 257 3 13 keJOWxnKOCymNa0sPpwp/ioeyvgrXjY9hu8KxWdaxlMFukxquKVLdt2J 5KxGOpmIZZbOXRALfG78FnDsE/k8EQ== >>> 256 3 13 YOf+TLHGeDBL0q6DSpE4vE2ub8RUvniew7xYkZJHocU6je7Ww/MfUeHf B1LEDpFNFloYHFBvWD92gu5MT2ZJ1A== >>> 256 3 13 twHlL7CfhxPadzuRi3wRxEDs+3i/oe9W3heRKiP8CALwpexBZYCjMJ2w Z403h9dJ/iA7CzCTSmvePLGdJ4cIzQ== >>> >>> dig +short @a.nic.ch switch.ch ds >>> 32265 13 2 8A865736961D246F99D6111BCA060E69908380FD5545D799F21E4652 DA60A17C >> Could anybody shed some light on this? >> Thx & Gruass, Franco >> _______________________________________________ >> swinog mailing list -- swinog(a)lists.swinog.ch >> To unsubscribe send an email to swinog-leave(a)lists.swinog.ch -- --------------------------------------------------- Klingon Embassy Runners http://klingon-embassy-runner.im ********************************************* Klingon Embassy: http://www.klingon-embassy.co.za --------------------------------------------------- -----------------------------------------------------

4 10

DNSSEC auto-disabled by SWITCH on some .ch domains?
by Franco Hug 01 May '23

01 May '23

Hey SWINOGgers, I noticed that DNSSEC was somehow auto-disabled at registry level for some .ch domains I am responsible for. For these domains, no DS records are published anymore in the .ch zone, dnsviz shows a broken chain of trust. However, registrar data still shows that DNSSEC is enabled, but the registry (SWITCH) says it is not... Is this a known problem? Seems not all DNSSEC protected .ch domains are affected, which leads me to the suspicion that it might have to do with the algorithm being used. Did SWITCH turn off older algorithms, e.g. algo 7 (RSASHA1-NSEC3-SHA1)? Did I miss an announcement? Random example, e.g. gkb.ch (notably a bank...) > dig +short @dns1.inventx.ch gkb.ch dnskey > 256 3 7 AwEAAdYydDZyd5M3UGS5b4Yv6qlIO5eOSwskJ/DQjiRO0as59ZG6hMDJ VseqslJMTwghdiCrd/sicWvDOszK6Cuqye0+ZEm9tfG6gxgWWmzpSmXQ KDHRG1iV8UF0KSOciFAPp4qRe083KPXu2ChXkTUSAa/iRCcZdFJK2M6l c7Gjjj55 > 257 3 7 AwEAAbQv5Whc+cna1IbtESB+Pwx+8eP5jfbjhuqiFuU/18qUckR9NxT7 KUCT8GDlRTsGYmuKxcMITvH510CgGOA/6TORaB4iIXRnACmfiiku25/B NHmNJd58ymZ/ED17smVJ4ou77/rhxW+/0Q1iVIAOcY8EblWq3EabepYz E6CY9Vh/RTh2mvSl80h8nZyFotsEwN0LIlc/Pi0qGmy7iTOBqtVsbFVm gssn/2c7IMCA8N2aaP1it8Qi+3DDGDh3N8HSEIVk+nrgQtsqQaLOFPGQ Q0ezahQO6oVGKG4XAHw+2XaZQ3UT0sTcFj3ZVKCcGE4Ddoa3J/gqLQh7 aA44cVIQx+s= > > dig +short @a.nic.ch gkb.ch ds > > -> no DS record Working example with algorithm 13 (ECDSA Curve P-256 with SHA-256): > dig +short @ns2.switch.ch switch.ch dnskey > 257 3 13 keJOWxnKOCymNa0sPpwp/ioeyvgrXjY9hu8KxWdaxlMFukxquKVLdt2J 5KxGOpmIZZbOXRALfG78FnDsE/k8EQ== > 256 3 13 YOf+TLHGeDBL0q6DSpE4vE2ub8RUvniew7xYkZJHocU6je7Ww/MfUeHf B1LEDpFNFloYHFBvWD92gu5MT2ZJ1A== > 256 3 13 twHlL7CfhxPadzuRi3wRxEDs+3i/oe9W3heRKiP8CALwpexBZYCjMJ2w Z403h9dJ/iA7CzCTSmvePLGdJ4cIzQ== > > dig +short @a.nic.ch switch.ch ds > 32265 13 2 8A865736961D246F99D6111BCA060E69908380FD5545D799F21E4652 DA60A17C Could anybody shed some light on this? Thx & Gruass, Franco

3 2

DNSSEC auto-disabled by SWITCH on some .ch domains?
by Franco Hug 01 May '23

01 May '23

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
294
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog