[swinog] Re: Any users of SCION here?

[Jeroen Massar via swinog]

> On 28 Mar 2024, at 12:08, Rainer Duffner via swinog  
> wrote:
> 
> Hi,
> 
> and specifically the hardware the company behind it (anapaya) sells.

Before looking at technologies, one should always first define what one's 
current situation is, what one's problems with that are and then what the state 
of the art is for those problems to be resolved. When one has that overview, 
one can actually say if something is adequate for solving the problem at hand.

Some companies seem to think SCION solves something:
 
https://www.swisscom.ch/en/business/enterprise/themen/security/resilienz-cyberattacken-scion.html
 https://www.six-group.com/de/products-services/banking-services/ssfn.html

A choice quote from that:
"The network made available by the SCION provider cannot be blocked by DDoS 
attacks from the global internet"

Which makes sense, as it is not the Internet ;)


As DDoS seems to be the primary problem, do you have those issues?

Any private network link, something disconnected from the Internet would 
already address most of those concerns...

Greets,
 Jeroen

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swiss Domain Security Report Q3 2022

[Jeroen Massar via swinog]

Noting you do part of this already.

But. note this nasty effect:

---
From: Jonas Meier via swinog 
Reply-To: Jonas Meier 
---

Now add that to people having "automatically add recipient to addressbook"  and 
when one wants to send an email to Jonas... it autocompletes to the public list 
;)

Mailman3 does not do the @via trick yet unfortunately; hence why folks use 
custom remailers quite often :)

Greets,
 Jeroen


> On 8 Jun 2023, at 12:06, Jeroen Massar  wrote:
> 
> 
> 
>> On 8 Jun 2023, at 11:47, Jonas Meier via swinog  
>> wrote:
>> 
>> Hi Franco, Dear List
>> 
>> Thank you for your feedback.
>> 
>> 1) I configured mailman3 [1] dmarc_mitigate_action to "munge_from" (to 
>> replace the from header) and dmarc_mitigate_unconditionally to true. My 
>> thought was that this would mean that there can no longer be a dmarc policy 
>> which sets dkim to strict. This way, an invalid dkim signature would no 
>> longer be such a big problem. But I was probably wrong. I don't want to set 
>> up the mails to be re-signed overnight, maybe there is an option to remove 
>> the signature. If anyone has experience with mailman3 and dkim, please write 
>> to me directly.
> 
> The only real solution is effectively to do SRS aka "From Rewriting" to be 
> able to decently send emails through a mailinglist and have them not land up 
> in spam/junk...
> 
> The list has to remove the Original "From" and replace it with eg 
> jeroen+massar.ch@via.lists.swinog 
> .ch
> Then you sign that From with your DKIM key.
> 
> To make the receiver happy that there is the 'old' DKIM header you then need 
> to do ARC signingt: http://arc-spec.org/
> That way, a receiver knows "oh the rewrote something and they are taking 
> responsibility for this mail"
> 
> 
> 
> For Mailman there is some info here: https://wiki.list.org/DEV/DMARC
> 
> Thus the option you need to do is:
> 
> "Munge the From: header"
> some other details: 
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html
> 
> For ARC: 
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/arc_sign.html
> 
> Greets,
> Jeroen
> 
> 

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swiss Domain Security Report Q3 2022

[Jeroen Massar via swinog]

> On 8 Jun 2023, at 11:47, Jonas Meier via swinog  
> wrote:
> 
> Hi Franco, Dear List
> 
> Thank you for your feedback.
> 
> 1) I configured mailman3 [1] dmarc_mitigate_action to "munge_from" (to 
> replace the from header) and dmarc_mitigate_unconditionally to true. My 
> thought was that this would mean that there can no longer be a dmarc policy 
> which sets dkim to strict. This way, an invalid dkim signature would no 
> longer be such a big problem. But I was probably wrong. I don't want to set 
> up the mails to be re-signed overnight, maybe there is an option to remove 
> the signature. If anyone has experience with mailman3 and dkim, please write 
> to me directly.

The only real solution is effectively to do SRS aka "From Rewriting" to be able 
to decently send emails through a mailinglist and have them not land up in 
spam/junk...

The list has to remove the Original "From" and replace it with eg 
jeroen+massar.ch@via.lists.swinog .ch
Then you sign that From with your DKIM key.

To make the receiver happy that there is the 'old' DKIM header you then need to 
do ARC signingt: http://arc-spec.org/
That way, a receiver knows "oh the rewrote something and they are taking 
responsibility for this mail"



For Mailman there is some info here: https://wiki.list.org/DEV/DMARC

Thus the option you need to do is:

"Munge the From: header"
some other details: 
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

For ARC: 
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/arc_sign.html

Greets,
 Jeroen


___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: DNSSEC auto-disabled by SWITCH on some .ch domains?

[Jeroen Massar via swinog]

Alg 7 is ancient and deprecated...

When one has DNS issues, especially DNSSEC related, run dnsviz:

https://dnsviz.net/d/gkb.ch/ZDeung/dnssec/

as that will show you what is off:

```
• gkb.ch zone: The server(s) were not responsive to queries over UDP. 
(2001:67c:2350:11::bad:babe)
• gkb.ch/A: No response was received from the server over UDP (tried 12 
times). (2001:67c:2350:11::bad:babe, UDP_-_NOEDNS_)
• gkb.ch/NS: No response was received from the server over UDP (tried 12 
times). (2001:67c:2350:11::bad:babe, UDP_-_NOEDNS_)
```

```
• RRSIG gkb.ch/A alg 7, id 42122: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/A alg 7, id 52259: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/DNSKEY alg 7, id 18681: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/DNSKEY alg 7, id 18681: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/DNSKEY alg 7, id 18681: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/DNSKEY alg 7, id 42122: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/DNSKEY alg 7, id 52259: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/MX alg 7, id 42122: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/MX alg 7, id 52259: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/NS alg 7, id 42122: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/NS alg 7, id 52259: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/NSEC3PARAM alg 7, id 42122: DNSSEC specification recommends 
not signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/NSEC3PARAM alg 7, id 52259: DNSSEC specification recommends 
not signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/SOA alg 7, id 42122: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/SOA alg 7, id 52259: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/TXT alg 7, id 42122: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
• RRSIG gkb.ch/TXT alg 7, id 52259: DNSSEC specification recommends not 
signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1).
```

Greets,
 Jeroen

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Datacenter switches

[Jeroen Massar via swinog]

> On 27 Apr 2023, at 04:04, Matthias Hertzog via swinog 
>  wrote:
> 
> Dear colleagues
> 
> As some of you already figured, i‘m about to dive into the ISP scene again. 
> „What a surprise“ ;-)
> 
> I‘m currently evaluating datacenter switches. Current need is at least 12 
> 10gig SFP ports and some 10gig copper ports.
> 
> What brands and models are you guys using these days? I‘ve used cisco and 
> Foundry/Brocade in the past, but i‘m open for recommendations.


Arista.


You pay, install them, they work. But there might be lead times...



You can also do cheaper depending on what you really need:
 https://ipng.ch/s/articles/2022/12/05/oem-switch-1.html
 https://ipng.ch/s/articles/2022/12/09/oem-switch-2.html
or
 https://ipng.ch/s/articles/2021/08/07/fs-switch.html


Pim can prolly help you get those ;)

Greets,
 Jeroen

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: How to destroy data effectively?

[Jeroen Massar via swinog]

> On 7 Dec 2022, at 13:04, Hendrik Jäger via swinog  
> wrote:
> 
> Hi
> 
>> And this is a problem if you rely on something you can not verify 
>> immediately. For example if I use a big hammer I immedialtey  see the 
>> results. But a degaußed Disk does not looked destroyed - you can not verify 
>> it with your eyes.
> 
> You see the physical result but does that really reliably mean that the data 
> is not recoverable?
> I’m just thinking of the work some germans are doing to reconstruct 
> shreddered stasi files: they also seemed completely destroyed, at least 
> enough that the stasi considered it enough, yet they are being reconstructed.
> I’d imagine that a hammer would not be enough to be _certain_ that 
> reconstruction is _impossible_ (not just more or less convinced that no one 
> will put in the effort to attempt it). Are you sure it is enough? When is it 
> enough? I imagine bent platters are hard but not quite impossible to 
> reconstruct and the effort required would probably not be worth the results 
> in most cases. But that always depends on the significance of the data on the 
> disks …
> I wouldn’t feel _certain_ with neither hammer nor degausser because I’m not a 
> recovery expert. Melting the platters down with just heat or thermite or 
> something would probably convince me. Shredding them to 1x1mm tiny pieces 
> would leave me reasonably certain enough for most scenarios, as well.
> 
> Any data recovery experts on this list who can shed more light?

As I noted: Full Disk Encryption.

Throw away the encryption keys (forget them) and you are done.

It solves the "disks get stolen" and the "we need to destroy the disk" part, 
noting that when a disk fails you cannot write to it anymore.

Any physical destruction is then just for show.

Greets,
 Jeroen

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: How to destroy data effectively?

[Jeroen Massar via swinog]

The real answer, net to using it for target practice, shredding and melting 
down is much easier: Full Disk Encryption.

Just lose the encryption keys and the data is useless. If you then also do one 
of the above for fun, just added bonus.

FDE helps for the "my disks got stolen" case, but also for the "disk broke" 
case, and just letting a random remote hands person remove them: one does not 
have to trust that they are destroyed properly, as nobody, but hopefully the 
sysadmins, have the FDE keys.

Of course, FDE does not help when the disk is online and one can SSH or 
otherwise execute code on it, but that is a different problem.

Regards,
 Jeroen

PS: Food for thought: what is worse, Financial Services or Advertising?
[and at least you are not scamming people with ponzi schemes, right...? :) ]

> On 2 Dec 2022, at 15:51, Martin Ebnoether via swinog  
> wrote:
> 
> Hi all.
> 
> As some of you know, I work at a money laund... financial
> company. Some time ago, the question arose, how to effectively
> destroy data safely and securely in an easy way?
> 
> How does your company deal with hard disks (or any media) that
> needs to be decommissioned? Do you just dd a few times over it?
> Or rather let a professional company shred your media to little
> bits?
> 
> CU, Venty
> 
> -- 
> 10 PRINT "BASIC programmers don't die."
> 20 PRINT "They just GOSUB without RETURN."
> 30 END
> READY.
> ___
> swinog mailing list -- swinog@lists.swinog.ch
> To unsubscribe send an email to swinog-le...@lists.swinog.ch

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch