[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 
> <mailto: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

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

[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:as5.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, 
h...@moz.com)"
"Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; 
h...@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/"
"axios/0.27.2"
"clark-crawler2/Nutch-1.19-SNAPSHOT"
"colly - https://github.com/gocolly/colly/v2;
"curl/"
"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/; 
ab...@serpstatbot.com)"
"x28-job-bot; +http://x28.ch/bot.html;



> On 17 Oct 2022, at 11:39, Fredy Kuenzler  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@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

Re: [swinog] CDN: Access Denied Reference #18.cad1f557.1634833505.1903b12e

[Jeroen Massar]

Hi,

Did you check if the customer's network is maybe infected with some botnet or 
spambot that triggers honeypots?

Clearly, if the IP changes and the customer gets blocked again, it is something 
being caused by the source IP...

Netflow... Netflow all the things ;)

Greets,
 Jeroen

--

> On 20211026, at 09:19, Benoit Panizzon  wrote:
> 
> Dear Colleagues
> 
> We have a customer whose IP keep getting blocked by various CDN
> operators.
> 
> If we change his IP, this solved the issue for a couple of days, then
> he is blocked again. Actual IP: 87.102.212.133
> 
> At the moment, this IP is being blocked by the CDN used by:
> 
> klm.com
> nespresso.com
> easyjet.com
> 
> I opened a case with Amazon, as this is the ones that host the
> easyjet.com CDN but they replied that he is blocked 'upstream' by their
> customer easyjet.
> 
> Our customer called the Easyjet Helpdesk, but they have no clue what
> generates this error and sent him to is ISP :-/
> 
> We don't get any kind of complaints regarding the IP of this customer. 
> 
> https://multirbl.valli.org/lookup/87.102.212.133.html
> 
> Two entries on blacklist I am not familiar with. One of them about an
> email misconfiguration?
> 
> All the customer is seing on the webpage is:
> 
> === snipp ===
> Access Denied
> 
> You don't have permission to access "http://www.easyjet.com/; on this server.
> 
> Reference #18.57d61202.1634833697.32bab06
> === snapp ===
> 
> Any hints on how to solve or what blocking provider is used (all pages
> show a very similar message with similar ID) are appreciated.
> 
> PS: Yes, google is finding reports of this exact issue. None I found
> provided any useful hint on what causes the issue.
> 
> 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 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Survey : which console/terminal servers are you using for Out-of-band mgmt ?

[Jeroen Massar]

Of course OOB, depending on location and requirements various options:

- IPMI built-in to many hosts (SuperMicro >X10 have Redfish and thus HTML5 KVM)
  then you can always fix that host and continue from there if serial connected 
etc.
- PCEngines APU (https://pcengines.ch/apu2.htm )
  connected over serial and/or ethernet for a nice management entry
   (APU6 with SPF https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html 
 is coming!)
- Michael Stapelberg's FreeTServ: https://freetserv.github.io 

  for serial lines
- "the other host in the same rack" with ethernet + serial cross-connected

Do note that OOB is only fully OOB if you can mess up prod completely and still 
reach your OOB devices, that means if a switch is involved in your IPMI setup, 
it should not be the main switch, but a separate one (so that one can kill the 
main one, and use the OOB to fix it again). That also means that you need 
separate connectivity (borrow an IP from a friendly ISP in the same rack) or 
use 4G/5G if available in the DC.

If using 4G, remember that one can do a wireguard mesh OOB to a non-own VM 
somewhere for OOB too. Ensure that you have ACLs and static IPs to connect from 
them too. Tor is also a fine option for low-bandwidth access in more hostile 
networks, then people need to know the onion fingerprint to get to your SSH.


In DCs you will also find opengear or airconsoles btw.

As noted, depends on requirements, budget and many more things.

Greets,
 Jeroen

> On 20210729, at 15:29, Félix Curinga  wrote:
> 
> Hi all,
> 
> I am starting a small project with a student of the Technical School in 
> Lausanne ETML-ES (for his diplom work), it will end up as a mobile kit for 
> remote staging.
> I would like to collect some experience from you folks, will be kept 100% 
> anonymous.
> If you agree, can you drop me an email directly and answer these questions:
> 
> - do you have Out-of-Band console management for your network equipment ?
> - if no : how do you manage your network equipment ?
> - if yes: which product (brand/model) ?
> - if yes: which interfaces on the equipment side ? (RJ45, USB, etc..)
> 
> Thanks in advance.
> For the people providing answers: I will send you the survey result without 
> company or people's names.
> 
> Best regards
> --félix
> 
> -- 
> Félix Curinga
> +41 79 446 38 11
> 
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Geldspielgesetz: 404 COMLOT renamed to GESPA? (or did they get hacked!?)

[Jeroen Massar]

A small update: seems that somebody reconfigured it between 2021-06-21 
21:52 and 2021-06-21 22:52 and after that change it is now redirecting 
requests, so that the file is retrievable. (the breaking change was done 
around midnight 2021-06-03 btw), before there where 141 entries, with 
the swap 128 entries stayed, 13 have been removed, and 22 new ones 
addded, thus currently 150 entries, good list of casinos for gamblers 
too visit. Just like the old DMOZ days and other "Internet Directories" :)



$ wget -v https://blacklist.comlot.ch/blacklist.comlot.ch.pub
--2021-07-07 10:17:46--  https://blacklist.comlot.ch/blacklist.comlot.ch.pub
Resolving blacklist.comlot.ch (blacklist.comlot.ch)... 194.187.88.5
Connecting to blacklist.comlot.ch 
(blacklist.comlot.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://blocklist.gespa.ch/blocklist.gespa.ch.pub [following]
--2021-07-07 10:17:47--  https://blocklist.gespa.ch/blocklist.gespa.ch.pub
Resolving blocklist.gespa.ch (blocklist.gespa.ch)... 194.187.88.5
Connecting to blocklist.gespa.ch 
(blocklist.gespa.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response... 200 OK
Length: 2874 (2.8K) [application/octet-stream]
Saving to: ‘blacklist.comlot.ch.pub’

blacklist.comlot.ch.pub  100%[===>]   2.81K 
 --.-KB/sin 0s


2021-07-07 10:17:47 (32.7 MB/s) - ‘blacklist.comlot.ch.pub’ saved 
[2874/2874]



Still of course, no official word about this change...

Guess that fixing things is easier than communicating :)

Greets,
 Jeroen

--


On 2021-06-03 08:47, Jeroen Massar wrote:

Hi Folks,

Is there an official announcement that I missed?

Seems that blocklist.gespa.ch is the new place, and that all of 
comlot.ch now points to gespa.ch, but filenames have been renamed too.

(see previous brokeness email in the mailarchive for old details).

Considering neither is under admin.ch, cannot really say it is an 
official website either.


Anybody got an official update about this, or did they just break the 
system again? Cannot find any duckduckgoogle references either.


Why did Swiss Voters vote for this broken system if it is not working 
anyway? (it is not, because otherwise it is a perfect list to find your 
casinos that are 'illegal' or something)


All those poor* casino users that now have access to a bunch of 
unlicensed casinos... what a sad day again.



Greets,
   Jeroen

* = as the house always wins


-

$ wget -v https://blacklist.comlot.ch/blacklist.comlot.ch.pub
--2021-06-03 08:21:02--  
https://blacklist.comlot.ch/blacklist.comlot.ch.pub

Resolving blacklist.comlot.ch (blacklist.comlot.ch)... 194.187.88.5
Connecting to blacklist.comlot.ch 
(blacklist.comlot.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://blocklist.gespa.ch//blacklist.comlot.ch.pub [following]
--2021-06-03 08:21:03--  
https://blocklist.gespa.ch//blacklist.comlot.ch.pub

Resolving blocklist.gespa.ch (blocklist.gespa.ch)... 194.187.88.5
Connecting to blocklist.gespa.ch 
(blocklist.gespa.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response... 404 Not Found
2021-06-03 08:21:05 ERROR 404: Not Found.

-


It seems the "official specification" (comlot.ch redirects is gone):

https://www.gespa.ch/download/pictures/9a/e78461lvxuzcv82c505b1kpckd58pf/spezifikationen_fda_v1.pdf 



still have blocklist.comlot.ch in it.

Except for the URL itself, Google also finds nothing about this:
https://www.google.com/search?hl=en=%22blacklist.gespa.ch%22

$ dig +short comlot.ch
194.187.88.3
$ dig +short comlot.ch 

$ dig +short comlot.ch mx
10 mx.cmsbox.com.
$ dig +short comlot.ch ns
ns3.netstyle.ch.
ns1.netstyle.ch.
ns2.netstyle.ch.

$ dig +short gespa.ch a
194.187.88.3
$ dig +short gespa.ch 
2a00:c38:2:9f62::2:3
dig +short comlot.ch mx
10 mx.cmsbox.com.
$ dig +short gespa.ch ns
ns3.netstyle.ch.
ns2.netstyle.ch.
ns1.netstyle.ch.

I also gotta love the generic wildcard Let's Encrypt cert, though 
comlot.ch did that too


https://crt.sh/?q=gespa.ch
https://crt.sh/?q=comlot.ch

Looks like a rather generic hoster. Maybe the whole domain got hacked?





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Cloudflare DMCA Takedown requests - but content not present under mentioned IP

[Jeroen Massar]

They could simply take it down by:

 - Contacting their own customer (for which they are proxying)
 - Stop providing proxy services to any entity and often for 'free'...

Fun that they contact you, while they are exposing it to the Internet ;)


Greets,
 Jeroen

> On 20210706, at 13:20, Benoit Panizzon  wrote:
> 
> Am Tue, 6 Jul 2021 12:01:58 +0200
> schrieb Markus Wild :
> 
>> I find this a bit odd, that they'd send you take-down requests for their own 
>> IP addresses
> 
> No, that was me resolving the domain. :-)
> 
> They of course mention the IP in our ranges, which I don't want to
> expose here as I can not find any way to verify the DMCA claims.
> 
> 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 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Coop.ch geoblocking?

[Jeroen Massar]

On 2021-06-23 10:48, Franco wrote:


On 22.06.21 08:58, Jeroen Massar wrote:

I suggest using a mailhost that has proper spam filtering, considering it is 
trivial to identify
that the sending host is not properly configured, why bother accepting mail 
from it?


That's not enough. In first place, the SWINOG contributors should be protected 
from being crawled.
-> SWINOG homework


Won't fix a thing. Also as a public list, it is public.

As noted anybody can subscribe or archive the list.

As an example:
https://www.mail-archive.com/swinog@lists.swinog.ch/msg07408.html

Apparently 3 years old:
https://swinog.swinog.narkive.com

etc etc etc..

And a spammer can just simply also subscribe, next to the avenue of a 
hacked computer of one of the members who does not clean out their mailbox.


Greets,
 Jeroen

PS: I simply use my mail address everywhere publicly, as spam will come 
anyway from whatever source when the address is public somewhere, one 
just need to filter and classify properly: good old Spamassassin with a 
few RBLs, bit of mimedefang and you are pretty good already (5 per day 
in my case), any other (mostly paid) resources will bring spam amount 
close to 0 while being able to actually use your mail address.


Spam is the way of live and unfortunately there is always going to be 
some source where it will be coming from, as long as the spammers gain 
something from their spams... (that something I am still wondering 
about, but clearly they must gain something even if the procentiles are 
super low).


Oh, and yes, to avoid From: spamming, do have proper DKIM/SPF/DMARC 
checks, they 'solve' the spamming issue quite a bit, with only few 
mailinglists being problematic while forwarding.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Coop.ch geoblocking?

[Jeroen Massar]

36.35.59.161] (port=45371 helo=in3days.org) by
>  cloudserver2.webbossuk.com with esmtpsa (TLS1.2) tls
>  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (Exim 4.93) (envelope-from
>  ) id 1lvNEU-00069P-CD for s.d...@protonmail.ch; Mon,
>  21 Jun 2021 17:57:10 +0100
> Received: from cloudserver2.webbossuk.com (cloudserver2.webbossuk.com
>  [95.172.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
>  (256/256 bits)) (No client certificate requested) by
>  mailin025.protonmail.ch (Postfix) with ESMTPS id 4G7yKH3NF6z9vNPW for
>  ; Mon, 21 Jun 2021 18:11:47 + (UTC)
> Mime-Version: 1.0
> Date: Mon, 21 Jun 2021 17:57:11 +0200
> Authentication-Results: mailin025.protonmail.ch; dkim=pass (2048-bit key)
>  header.d=in3days.org header.i=@in3days.org header.b="pK1dKfuL"
> Authentication-Results: mailin025.protonmail.ch; spf=none
>  smtp.mailfrom=in3d...@in3days.org
> Authentication-Results: mailin025.protonmail.ch; dmarc=none (p=none
>  dis=none) header.from=in3days.org
> Authentication-Results: mailin025.protonmail.ch; dkim=pass (Good 2048 bit
>  rsa-sha256 signature) header.d=in3days.org header.a=rsa-sha256
> 
> 
> 
> On 21.06.21 23:42, Jeroen Massar wrote:
>> Full headers would be rather useful to determine the real origin of that 
>> message...
>> 
>> Greets,
>>  Jeroen
>> 
>> 
>>> On 20210621, at 21:35, Serge Droz  wrote:
>>> 
>>> Hi all
>>> 
>>> It seems there is a SWINOG member who should clean his computer.
>>> 
>>> Happy hunting
>>> Serge
>>> 
>>> 
>>> 
>>>  Forwarded Message 
>>> Subject:Re: [swinog] Coop.ch geoblocking?
>>> Date:   Mon, 21 Jun 2021 17:57:11 +0200
>>> From:   Roger 
>>> Reply-To:   Roger 
>>> To: Serge Droz 
>>> 
>>> 
>>> 
>>> Good day!
>>> 
>>> We mail document to you again. You can discover it at the link lower:
>>> 
>>> 
>>> annanigrodermatologia.it/mac-lesch/s_droz-80.zip
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Hoi Roger > > ich denke nur das diese unterdrückung von unerwünschten
>>>> meinungen falsch > ist . > Das sehe ich auch so. Aber das macht Coop
>>>> ja nicht. > und im sinne coop finde ich es erstens nutzlos und
>>>> zweitens bedenklich > wenn man security probleme mit regionalesn
>>>> beschänkungen zu vermindern > versucht statt sie zu beseitigen > Keine
>>>> Ahnung warum das Coop macht, ist aber ihr Recht, ist ja Ihre Webseite.
>>>> Gruss Serge > .. so long ;) > > Roger > > > On 28.02.2021 19:37, Serge
>>>> Droz wrote: >> I think you misunderstand what free speech is. Free
>>>> speach means, you >> cannot be punished for what you say, nothing
>>>> more. It does not guarantee >> you an audience, or a platform. >> An,
>>>> although a bit US centric, explanation is here: >>
>>>> https://www.aclu.org/other/what-censorship >> >> If blocking is a good
>>>> idea for security reasons is en entirely different >> questions, and
>>>> has nothing what so ever to do with free speech or >> censorship. >>
>>>>>> Best >> Serge >> >> >> >> -- >> Serge Droz >> Security Lead >>
>>>> Proton Technologies AG >> -- Serge Droz Security Lead Proton
>>>> Technologies AG
>>> 
>>> 
>>> 
>>> ___
>>> swinog mailing list
>>> swinog@lists.swinog.ch
>>> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>> 
> 
> --
> Dr. Serge Droz
> Senior Security Engineer
> 



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Coop.ch geoblocking?

[Jeroen Massar]

Full headers would be rather useful to determine the real origin of that 
message...

Greets,
 Jeroen


> On 20210621, at 21:35, Serge Droz  wrote:
> 
> Hi all
> 
> It seems there is a SWINOG member who should clean his computer.
> 
> Happy hunting
> Serge
> 
> 
> 
>  Forwarded Message 
> Subject:  Re: [swinog] Coop.ch geoblocking?
> Date: Mon, 21 Jun 2021 17:57:11 +0200
> From: Roger 
> Reply-To: Roger 
> To:   Serge Droz 
> 
> 
> 
> Good day!
> 
> We mail document to you again. You can discover it at the link lower:
> 
> 
> annanigrodermatologia.it/mac-lesch/s_droz-80.zip
> 
> 
> 
> 
> 
>> Hoi Roger > > ich denke nur das diese unterdrückung von unerwünschten
>> meinungen falsch > ist . > Das sehe ich auch so. Aber das macht Coop
>> ja nicht. > und im sinne coop finde ich es erstens nutzlos und
>> zweitens bedenklich > wenn man security probleme mit regionalesn
>> beschänkungen zu vermindern > versucht statt sie zu beseitigen > Keine
>> Ahnung warum das Coop macht, ist aber ihr Recht, ist ja Ihre Webseite.
>> Gruss Serge > .. so long ;) > > Roger > > > On 28.02.2021 19:37, Serge
>> Droz wrote: >> I think you misunderstand what free speech is. Free
>> speach means, you >> cannot be punished for what you say, nothing
>> more. It does not guarantee >> you an audience, or a platform. >> An,
>> although a bit US centric, explanation is here: >>
>> https://www.aclu.org/other/what-censorship >> >> If blocking is a good
>> idea for security reasons is en entirely different >> questions, and
>> has nothing what so ever to do with free speech or >> censorship. >>
 Best >> Serge >> >> >> >> -- >> Serge Droz >> Security Lead >>
>> Proton Technologies AG >> -- Serge Droz Security Lead Proton
>> Technologies AG
> 
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Geldspielgesetz: 404 COMLOT renamed to GESPA? (or did they get hacked!?)

[Jeroen Massar]

Hi Folks,

Is there an official announcement that I missed?

Seems that blocklist.gespa.ch is the new place, and that all of 
comlot.ch now points to gespa.ch, but filenames have been renamed too.

(see previous brokeness email in the mailarchive for old details).

Considering neither is under admin.ch, cannot really say it is an 
official website either.


Anybody got an official update about this, or did they just break the 
system again? Cannot find any duckduckgoogle references either.


Why did Swiss Voters vote for this broken system if it is not working 
anyway? (it is not, because otherwise it is a perfect list to find your 
casinos that are 'illegal' or something)


All those poor* casino users that now have access to a bunch of 
unlicensed casinos... what a sad day again.



Greets,
  Jeroen

* = as the house always wins


-

$ wget -v https://blacklist.comlot.ch/blacklist.comlot.ch.pub
--2021-06-03 08:21:02--  https://blacklist.comlot.ch/blacklist.comlot.ch.pub
Resolving blacklist.comlot.ch (blacklist.comlot.ch)... 194.187.88.5
Connecting to blacklist.comlot.ch 
(blacklist.comlot.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://blocklist.gespa.ch//blacklist.comlot.ch.pub [following]
--2021-06-03 08:21:03--  https://blocklist.gespa.ch//blacklist.comlot.ch.pub
Resolving blocklist.gespa.ch (blocklist.gespa.ch)... 194.187.88.5
Connecting to blocklist.gespa.ch 
(blocklist.gespa.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response... 404 Not Found
2021-06-03 08:21:05 ERROR 404: Not Found.

-


It seems the "official specification" (comlot.ch redirects is gone):

https://www.gespa.ch/download/pictures/9a/e78461lvxuzcv82c505b1kpckd58pf/spezifikationen_fda_v1.pdf

still have blocklist.comlot.ch in it.

Except for the URL itself, Google also finds nothing about this:
https://www.google.com/search?hl=en=%22blacklist.gespa.ch%22

$ dig +short comlot.ch
194.187.88.3
$ dig +short comlot.ch 

$ dig +short comlot.ch mx
10 mx.cmsbox.com.
$ dig +short comlot.ch ns
ns3.netstyle.ch.
ns1.netstyle.ch.
ns2.netstyle.ch.

$ dig +short gespa.ch a
194.187.88.3
$ dig +short gespa.ch 
2a00:c38:2:9f62::2:3
dig +short comlot.ch mx
10 mx.cmsbox.com.
$ dig +short gespa.ch ns
ns3.netstyle.ch.
ns2.netstyle.ch.
ns1.netstyle.ch.

I also gotta love the generic wildcard Let's Encrypt cert, though 
comlot.ch did that too


https://crt.sh/?q=gespa.ch
https://crt.sh/?q=comlot.ch

Looks like a rather generic hoster. Maybe the whole domain got hacked?



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SSL Certs question

[Jeroen Massar]

On 2021-05-20 08:51, Gregor Riepl wrote:

the mailserver I use, does not support ACME setup. I can only do old
style SSL certificate requests.
for the webserver its not an issue though.


Why does the mail server need to support ACME?

Simply do periodic DNS verification and trigger a restart/reload of the
internet-facing mail server components when the certificate was renewed.

And if replacing the cert in your mail service requires manual action,
you could disable SSL and put a TCP load balancer that does SSL
offloading in front of it.


For SMTPS (TLS tcp/465) yes, but most inbound mail goes over plain 25 
and then does the EHLO/STARTTLS dance, thus one does then need a load 
balancer that understand that AND that then also passes the right IP 
address to the backend if the real mail server does anything with an IP 
address. Transparent TCP/STARTTLS interception is fun ;)


Also, outbound mail goes over TLS / STARTTLS and one can even indicate 
that with MTA-STS. (https://www.hardenize.com/blog/mta-sts has a good 
intro on MTA-STS).


And that means outbound mail needs to properly do SSL too.

Upgrading to a mail system from >2015 is thus a much better idea ;)


With the maximum validity period of certificates supported by browsers
getting shorter and shorter, you'll eventually have to deal with fully
automated certificate renewal anyway.

Even some "traditional" cert providers have understood this and provide
ACME or ACME-like renewal functionality:
https://docs.digicert.com/certificate-tools/Certificate-lifecycle-automation-index/acme-user-guide/


Indeed, they are wising up that otherwise their business model croacks.

Which is evidenent with 70%+ market share for Let's Encrypt.

I still find it funny that Digicert allows "Org Validated" (OV) certs to 
be issued there. That is one of the few business cases that is left (e.g 
for bare IP SSL certificates)


Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SSL Certs question

[Jeroen Massar]

On 2021-05-13 13:05, Andreas Fink wrote:



Jeroen Massar wrote on 13.05.21 10:46:

On 2021-05-13 11:29, Andreas Fink wrote:

Hello all,

I need to get some SSL certificates for some african country operations
and i can unfortunately not use letsencrypt for this.


Any reason? What are your requirements?


the mailserver I use, does not support ACME setup. I can only do old
style SSL certificate requests.
for the webserver its not an issue though.


You could get the certs from LE/ZeroSSL every 90 days and replace them 
by hand does not scale, but works ;)


But there are thousands of CAs, just check the list.



Would ZeroSSL (https://zerossl.com) who also do ACME work?


No. ACME is the issue. And ZeroSSL is hosted in the US on cloudflare
with a cloudflare SSL certificate. So by definition not DSGVO conform as
NSA could theoretially infiltrate cloudflare to infliltrate all my certs
etc. etc. It might be far fetched but since snowden, we know that many
things we considered far far far fetched are not anymore.


You have the private key and that does not leave the box unless you do 
that, thus unless there is some crypto that is broken, they can't do 
much with that. If they have broken crypto some way, then it applies to 
everything and we are generally screwed. I am not aware of such a thing 
at this point in time.


All certs are logged in Certificate Transparency (see for instance 
https://ct.cloudflare.com/) thus the source should not matter.


The US unfortunately is where most corporations are based; 
companies in the rest of the world fall under bilateral exchange laws.


Thus if one is afraid of the US, it is game over, one will have to 
disconnect from this Internet thing as their influence 
(code/hardware/legal/people) is everywhere.


For me at least that is not a threat, your model might include it it seems.

You more have to be afraid of the Googles of the world, considering they 
control the browser trust store:

 https://thehackernews.com/2017/07/chrome-certificate-authority.html
as a quick random example...


(yes people, Let's Encrypt is not the only game... if you do ACME for
your systems, also setup zero ssl and issue certs from both places at
the same time, just in case LE ever has an issue, though that will be
resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)

Cloudflare's juristiction is definitively a red flag for me.


As above, I'll give a little link:
 https://www.coe.int/en/web/criminal-law-coop/bilateral-cooperation

US law is enforced everywhere, we (.ch) fortunately/hopefully have 
judges that protect from overreach though.




I was trying to
get a certificate from Swissign for this but for some reason they refuse
issuing certificates to domains for Guinea and Guinea Bissau


Do you need org validated or something that the country matters?

no. I simply need the domain be in that country.
The holder of the domain can be myself in switzerland or one of the
entities in Africa which is not on the blacklist (which is actually what
I tried). Swisssign put the certificate under embargo because the domain
ending contained .gw and .com.gn. Thats all.
And I don't want to buy a domain for every mailserver separately, thats
why I want a multidomain certificate. As it has to be renewed every
years its painfully enough already.


Sounds like upgrading software or fronting it with a proxy is the way to 
go, as then you can do like the rest of the world (well 72%): LE



An alternative option would be to use DANE/TSLA, then you can provide a 
self-signed certificate. Watch out with setting up MTA-STS in that case 
though.


At that point though, you already have new software that should be able 
to handle ACME certificates (read: being able to reconfigure the SSL 
cert in a scripted manner).


Greets,
 Jeroen

PS: Don't hesitate to provide details of the setup off-list and we can 
see what we can do if you want to go the LE route.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SSL Certs question

[Jeroen Massar]

On 2021-05-13 11:29, Andreas Fink wrote:

Hello all,

I need to get some SSL certificates for some african country operations
and i can unfortunately not use letsencrypt for this.


Any reason? What are your requirements?


Would ZeroSSL (https://zerossl.com) who also do ACME work?

(yes people, Let's Encrypt is not the only game... if you do ACME for 
your systems, also setup zero ssl and issue certs from both places at 
the same time, just in case LE ever has an issue, though that will be 
resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)



I was trying to
get a certificate from Swissign for this but for some reason they refuse
issuing certificates to domains for Guinea and Guinea Bissau


Do you need org validated or something that the country matters?

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] FYI: COMLOT Geldspielgesetz Key expired => updated

[Jeroen Massar]

As an update (not that anybody really cares :) )

The key has been updated and also verifies again.

Fun detail is that they updated all the signatures too, which is partially good 
as at least one can verify them; one cannot know for sure when they updated it 
(well, except for folks like me who pull the directory and git and keep a watch 
on it that way).

Greets,
 Jeroen

--


> On 20210331, at 16:53, Jeroen Massar  wrote:
> 
> As it is 1 april tomorrow, some things expired yesterday:
> 
>Not After : Mar 30 13:28:58 2021 GMT
> 
> That thing is the COMLOT key to verify those Geldspielgesetz keys for 
> their fun list of worldwide casinos:
>  https://blacklist.comlot.ch/comlot_blacklist.txt
> 
> see full cert details below.
> 
> You can get the key with or attached:
> 
> $ wget -vS https://blacklist.comlot.ch/blacklist.comlot.ch.pub
> --2021-03-31 16:50:00--  https://blacklist.comlot.ch/blacklist.comlot.ch.pub
> Resolving blacklist.comlot.ch (blacklist.comlot.ch)... 194.187.88.5
> Connecting to blacklist.comlot.ch (blacklist.comlot.ch)|194.187.88.5|:443... 
> connected.
> HTTP request sent, awaiting response...
>  HTTP/1.1 200 OK
>  Server: nginx/1.14.2
>  Date: Wed, 31 Mar 2021 14:50:01 GMT
>  Content-Type: application/octet-stream
>  Content-Length: 2927
>  Connection: keep-alive
>  Last-Modified: Wednesday, 31-Mar-2021 14:50:01 GMT
>  Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, 
> max-age=0
>  Strict-Transport-Security: max-age=15768000
>  Accept-Ranges: bytes
> Length: 2927 (2.9K) [application/octet-stream]
> Saving to: ‘blacklist.comlot.ch.pub’
> 
> blacklist.comlot.ch.pub 
> 100%[==>] 2.86K  
> --.-KB/sin 0s
> 
> 2021-03-31 16:50:01 (558 MB/s) - ‘blacklist.comlot.ch.pub’ saved [2927/2927]
> 
> Funny that nginx claims the file changed... the moment I downloaded it, bit 
> strange for a static file.
> 
> 
> Anybody has contacts at COMLOT. As technically speaking, we should not be 
> updating the list anymore into RPZ now; the process I have is thus stuck at 
> the list from yesterday (not that it matters, with such a nice list, a 
> bit of VPN and/or simply choosing any non-provider DNS server and voila... 
> bypassed the law you, know, Their Law!
> 
> https://www.youtube.com/watch?v=zKNoU2P0dQc
> 
> Enjoy!
> 
> Greet,
> Jeroen
> 
> --
> 
> 
> openssl x509 -in blacklist.comlot.ch.pub -text
> Certificate:
>Data:
>Version: 3 (0x2)
>Serial Number:
>61:5d:a4:eb:83:eb:a0:a3:be:97:59:c9:56:9b:28:e9
>Signature Algorithm: sha256WithRSAEncryption
>Issuer: C = CH, O = SwissSign AG, CN = SwissSign CH Person Platinum CA 
> 2017 - G22, organizationIdentifier = NTRCH-CHE-109.357.012
>Validity
>Not Before: Mar 30 13:28:58 2020 GMT
>Not After : Mar 30 13:28:58 2021 GMT
>Subject: C = CH, L = Bern, ST = BE, organizationIdentifier = 
> NTRCH-CHE-196.380.112, O = Lotterie- und Wettkommission Comlot, CN = 
> Lotterie- und Wettkommission Comlot
>Subject Public Key Info:
>Public Key Algorithm: rsaEncryption
>RSA Public-Key: (2048 bit)
>Modulus:
>00:8d:2c:7f:48:c2:07:30:b9:fa:29:26:1d:29:83:
>82:41:ef:73:2e:8e:dc:de:28:a4:6b:0b:93:0d:19:
>b6:ee:d2:c5:63:95:3f:d0:ed:a7:f3:80:70:e3:07:
>48:6e:f3:e7:5a:d1:fd:80:d5:2e:4e:6d:3d:e1:db:
>8e:44:2f:4f:a7:21:58:1d:c9:59:40:9b:97:85:4c:
>b6:5a:f6:cc:1a:71:a1:ef:59:59:65:f2:6c:be:25:
>74:15:37:29:40:b1:6c:6d:3b:43:82:85:ee:5b:e8:
>01:86:92:32:a5:f8:a9:ba:8b:85:6e:14:6e:ca:cc:
>33:35:ff:7e:b7:fb:1c:c6:dc:c3:c4:f8:31:7b:73:
>c8:91:86:59:07:4b:75:1f:10:68:50:61:93:19:5b:
>ac:3d:43:c4:49:0a:ea:17:1b:ea:0e:f5:c1:7f:d5:
>db:c0:58:c5:61:19:dd:05:b7:b5:35:27:85:ea:ec:
>70:6e:c5:a6:d5:c1:ca:5b:85:3e:42:08:14:f0:01:
>aa:b5:47:93:ed:ed:eb:20:35:db:d8:d8:58:da:6b:
>dc:3d:14:ee:e1:91:c8:85:12:d5:59:9c:fc:4f:04:
>0e:f5:a4:d5:c0:ab:ec:57:6b:c1:d9:8f:1d:6b:dc:
>bf:5a:0e:58:a0:4c:01:0f:13:31:c0:0b:dd:ac:aa:
>2b:6f
>Exponent: 65537 (0x10001)
>X509v3 extensions:
>X509v3 Key Usage: critical
>Digital Signature
>X509v3 Basic Constraints:
>CA:FALSE
>X509v3 Subject Key Identifier:
>1B:2B:

[swinog] G.Fast DSL modems - bridge only

[Jeroen Massar]

Hi Folks,

So there is the list:
https://www.swisscom.ch/dam/swisscom/en/ws/documents/E_BBCS-Documents/e_bbcs_supporting-documentprovedequipment.pdf

Anybody got a recommendation out of that for a bridge-only G.Fast modem?

Apparently FRITZ!Box 7582 does not do Bridge mode, but Zyxel XMG3927 does.

Cisco C1113-8P ISR is a bit much for my purposes (and at 800+ bit much too)

Anybody has any positive/negative experiences and/or other recommendations?

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] FYI: COMLOT Geldspielgesetz Key expired

[Jeroen Massar]

As it is 1 april tomorrow, some things expired yesterday:

Not After : Mar 30 13:28:58 2021 GMT

That thing is the COMLOT key to verify those Geldspielgesetz keys 
for their fun list of worldwide casinos:

  https://blacklist.comlot.ch/comlot_blacklist.txt

see full cert details below.

You can get the key with or attached:

$ wget -vS https://blacklist.comlot.ch/blacklist.comlot.ch.pub
--2021-03-31 16:50:00--  https://blacklist.comlot.ch/blacklist.comlot.ch.pub
Resolving blacklist.comlot.ch (blacklist.comlot.ch)... 194.187.88.5
Connecting to blacklist.comlot.ch 
(blacklist.comlot.ch)|194.187.88.5|:443... connected.

HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx/1.14.2
  Date: Wed, 31 Mar 2021 14:50:01 GMT
  Content-Type: application/octet-stream
  Content-Length: 2927
  Connection: keep-alive
  Last-Modified: Wednesday, 31-Mar-2021 14:50:01 GMT
  Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, 
max-age=0

  Strict-Transport-Security: max-age=15768000
  Accept-Ranges: bytes
Length: 2927 (2.9K) [application/octet-stream]
Saving to: ‘blacklist.comlot.ch.pub’

blacklist.comlot.ch.pub 
100%[==>] 
2.86K  --.-KB/sin 0s


2021-03-31 16:50:01 (558 MB/s) - ‘blacklist.comlot.ch.pub’ saved [2927/2927]

Funny that nginx claims the file changed... the moment I downloaded it, 
bit strange for a static file.



Anybody has contacts at COMLOT. As technically speaking, we should not 
be updating the list anymore into RPZ now; the process I have is thus 
stuck at the list from yesterday (not that it matters, with such a 
nice list, a bit of VPN and/or simply choosing any non-provider DNS 
server and voila... bypassed the law you, know, Their Law!


https://www.youtube.com/watch?v=zKNoU2P0dQc

Enjoy!

Greet,
 Jeroen

--


 openssl x509 -in blacklist.comlot.ch.pub -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:5d:a4:eb:83:eb:a0:a3:be:97:59:c9:56:9b:28:e9
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = CH, O = SwissSign AG, CN = SwissSign CH Person 
Platinum CA 2017 - G22, organizationIdentifier = NTRCH-CHE-109.357.012

Validity
Not Before: Mar 30 13:28:58 2020 GMT
Not After : Mar 30 13:28:58 2021 GMT
Subject: C = CH, L = Bern, ST = BE, organizationIdentifier = 
NTRCH-CHE-196.380.112, O = Lotterie- und Wettkommission Comlot, CN = 
Lotterie- und Wettkommission Comlot

Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:8d:2c:7f:48:c2:07:30:b9:fa:29:26:1d:29:83:
82:41:ef:73:2e:8e:dc:de:28:a4:6b:0b:93:0d:19:
b6:ee:d2:c5:63:95:3f:d0:ed:a7:f3:80:70:e3:07:
48:6e:f3:e7:5a:d1:fd:80:d5:2e:4e:6d:3d:e1:db:
8e:44:2f:4f:a7:21:58:1d:c9:59:40:9b:97:85:4c:
b6:5a:f6:cc:1a:71:a1:ef:59:59:65:f2:6c:be:25:
74:15:37:29:40:b1:6c:6d:3b:43:82:85:ee:5b:e8:
01:86:92:32:a5:f8:a9:ba:8b:85:6e:14:6e:ca:cc:
33:35:ff:7e:b7:fb:1c:c6:dc:c3:c4:f8:31:7b:73:
c8:91:86:59:07:4b:75:1f:10:68:50:61:93:19:5b:
ac:3d:43:c4:49:0a:ea:17:1b:ea:0e:f5:c1:7f:d5:
db:c0:58:c5:61:19:dd:05:b7:b5:35:27:85:ea:ec:
70:6e:c5:a6:d5:c1:ca:5b:85:3e:42:08:14:f0:01:
aa:b5:47:93:ed:ed:eb:20:35:db:d8:d8:58:da:6b:
dc:3d:14:ee:e1:91:c8:85:12:d5:59:9c:fc:4f:04:
0e:f5:a4:d5:c0:ab:ec:57:6b:c1:d9:8f:1d:6b:dc:
bf:5a:0e:58:a0:4c:01:0f:13:31:c0:0b:dd:ac:aa:
2b:6f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
1B:2B:A0:91:2C:6F:2B:92:49:EC:96:04:BD:1C:8D:36:35:45:4D:76
X509v3 Authority Key Identifier:

keyid:1E:C8:04:6D:FB:72:62:51:60:A2:73:24:6F:BE:F2:5F:4D:34:92:FC

X509v3 CRL Distribution Points:

Full Name:

URI:http://crl.swisssign.net/1EC8046DFB72625160A273246FBEF25F4D3492FC

Full Name:

URI:ldap://directory.swisssign.com/CN=1EC8046DFB72625160A273246FBEF25F4D3492FC%2CO=SwissSign%20AG%2CC=CH?certificateRevocationList?base?objectClass=cRLDistributionPoint

X509v3 Certificate Policies:
Policy: 2.16.756.1.89.1.1.1.1.10
  CPS: 
https://repository.swisssign.com/SwissSign-Platinum-CP-CPS.pdf

  User Notice:
Explicit Text: regulated certificate
Policy: 0.4.0.194112.1.3

Authority Information Access:
CA Issuers - 

Re: [swinog] DENOG Leadership Meetup #1 -- Save the DATE: Mittwoch 24. März 2021, 18:30 Uhr

[Jeroen Massar]

On 2021-03-16 21:04, Stefan Funke wrote:

Good afternoon SWINOG!

Since SWINOG is also a German-speaking network operator group, I wanted to take 
the chance to invite you to the first DENOG Leadership Meetup.


ehh.. as the resident foreigner, I would like to point out that:

 - You wrote your message in English
 - Switzerland has four official languages: !!!Swiss!!! German, French, 
Italian & Romansch

 - Two unofficial ones: German, English ;)

and while. most of the stuff goes on in German here (because nobody 
wants to hear my German, or French... or soon Italian) we have a 
rather large group of French speaking folks on here.



That said, sounds like a cool meeting, keep it coming, even if it is 
only in German!


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Bluewin SMTP server reachable from outside bluewin/swisscom?

[Jeroen Massar]

Follow-up: do not test with new tools.

So, as a few folks pointed me off-list rightly to it.. but my brain did not 
click to this old issue... it is all because of the short key.

I think it was discussed on swinog before, but I'll add it again, as I found 
the ticket where I reminded myself about it but that was from July 2019...

Due to the logjam attack OpenSSL (especially on Debian) disabled DH keys <= 
1024 bytes.
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
https://lists.debian.org/debian-lts-announce/2015/06/msg00013.html

8<
Additionally OpenSSL will now reject handshakes using DH parameters
shorter than 768 bits as a countermeasure against the Logjam attack
(CVE-2015-4000).
-->8

(Yes, it is 2021 today, that is from 2015)


Thus if you want to test if that server works, disabling DH avoids it:

openssl s_client -cipher 'DEFAULT:!DH' -connect smtpauths.bluewin.ch:587 
-starttls smtp


So reminder, if you properly run new tools, you might have to work around 
servers that are still in planning of upgrading.

And in the end the origin of the issue was a DNS issue caused by a route 
reflection issue causing a variety of routes not to be available and yes, then 
things do not work as excepted... it is always DNS, except when it is IP :)


PS: This seems unrelated to the IPv6 issue with the F5, even though it appears 
both systems run behind an F5.

Greets,
 Jeroen


--

Sidenote, without directly doing the starttls, your connection will be dropped 
too:

$ openssl s_client -cipher 'DEFAULT:!DH' -connect smtpauths.bluewin.ch:587
CONNECTED(0003)
140142292489536:error:1408F10B:SSL routines:ssl3_get_record:wrong version 
number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 298 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

With starttls it will work. timing is key too...

$ openssl s_client -cipher 'DEFAULT:!DH' -connect smtpauths.bluewin.ch:587 
-starttls smtp
CONNECTED(0003)
depth=2 C = CH, O = SwissSign AG, CN = SwissSign Gold CA - G2
verify return:1
depth=1 C = CH, O = SwissSign AG, CN = SwissSign Server Gold CA 2014 - G22
verify return:1
depth=0 C = CH, ST = Bern, L = Worblaufen, O = Swisscom (Schweiz) AG, OU = IT, 
CN = smtpauths.bluewin.ch
verify return:1
---
Certificate chain
 0 s:C = CH, ST = Bern, L = Worblaufen, O = Swisscom (Schweiz) AG, OU = IT, CN 
= smtpauths.bluewin.ch
   i:C = CH, O = SwissSign AG, CN = SwissSign Server Gold CA 2014 - G22
 1 s:C = CH, O = SwissSign AG, CN = SwissSign Server Gold CA 2014 - G22
   i:C = CH, O = SwissSign AG, CN = SwissSign Gold CA - G2
---
Server certificate
-BEGIN CERTIFICATE-
MIIH2jCCBsKgAwIBAgIUGEfAQSLKDtSxeCCekVh0nFmkCOEwDQYJKoZIhvcNAQEL
BQAwUjELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEsMCoGA1UE
AxMjU3dpc3NTaWduIFNlcnZlciBHb2xkIENBIDIwMTQgLSBHMjIwHhcNMTkwODA4
MDg0NDAxWhcNMjEwODA4MDg0NDAxWjB9MQswCQYDVQQGEwJDSDENMAsGA1UECBME
QmVybjETMBEGA1UEBxMKV29yYmxhdWZlbjEeMBwGA1UEChMVU3dpc3Njb20gKFNj
aHdlaXopIEFHMQswCQYDVQQLEwJJVDEdMBsGA1UEAxMUc210cGF1dGhzLmJsdWV3
aW4uY2gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJuFh6Yc/73bmW
Lyedte6kZQ56Q5XGsaKFtZmXWZXqYFmlPrlZ/vKYpTT712DCwOklcpd7/CrjPFwN
OhVL1aAsfr5UwfrBfFtE0pRsiUl/o3I/6NyfU1FobEVO8xnBhDKaOQOJlwZwndyR
GQLz6I1wsddJeh/puh4KvIl3vHq0ge8igZFTG2MuXIsayPUOWpdrbLuvebiaDfMw
FuJCtgkiSfhi9wRDLVkmXJF+q9+n/6FdJcr8+SgF+oiz2koXhSt/dVjrfrz+rL9/
5dZz9h8JT6X/sLG56SyVpOV4Mmzgq72afizutwtGHobygMqYyusW5GfwZJPqX+cb
BhiBmvNFAgMBAAGjggR7MIIEdzA4BgNVHREEMTAvghRzbXRwYXV0aHMuYmx1ZXdp
bi5jaIIXc210cGF1dGhzLmxiLmJsdWV3aW4uY2gwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQURQnYL5/oRqKp
p2+CnXirj1TyDCMwHwYDVR0jBBgwFoAU5/Hn/S5TrRHlgRpXpHOPEn2YyK4wgf8G
A1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0U3RjFF
N0ZEMkU1M0FEMTFFNTgxMUE1N0E0NzM4RjEyN0Q5OEM4QUUwgaiggaWggaKGgZ9s
ZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RTdGMUU3RkQyRTUzQUQx
MUU1ODExQTU3QTQ3MzhGMTI3RDk4QzhBRSUyQ089U3dpc3NTaWduJTJDQz1DSD9j
ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz
dHJpYnV0aW9uUG9pbnQwcwYDVR0gBGwwajBUBglghXQBWQECAQswRzBFBggrBgEF
BQcCARY5aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1NpZ24t
R29sZC1DUC1DUFMucGRmMAgGBgQAj3oBBzAIBgZngQwBAgIwgdUGCCsGAQUFBwEB
BIHIMIHFMGQGCCsGAQUFBzAChlhodHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmlu
L2F1dGhvcml0eS9kb3dubG9hZC9FN0YxRTdGRDJFNTNBRDExRTU4MTFBNTdBNDcz
OEYxMjdEOThDOEFFMF0GCCsGAQUFBzABhlFodHRwOi8vZ29sZC1zZXJ2ZXItZzIu
b2NzcC5zd2lzc3NpZ24ubmV0L0U3RjFFN0ZEMkU1M0FEMTFFNTgxMUE1N0E0NzM4
RjEyN0Q5OEM4QUUwggF7BgorBgEEAdZ5AgQCBIIBawSCAWcBZQB1AESUZS6w7s6v
xEAH2Kj+KMDa5oK+2MsxtT/TM5a1toGoAAABbHBmPNYAAAQDAEYwRAIgCvjTT2sR
PgoaHtOiCqmh1oERGFsdlSEy01a/da2WgxQCIAXM1dSNyXhiWTLGGKlg7fYjsVEx
Ed/WM6NYSh0AJPK+AHYAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMA

Re: [swinog] Bluewin SMTP server reachable from outside bluewin/swisscom?

[Jeroen Massar]

On 2021-03-11 11:46, Jeroen Massar wrote:
So apparently there is a DNS entry for smtp.bluewin.ch, but that is not 
the one to use as it was apparently EOLd in 2006 or so. Thanks for 
offlist info that it is and this link[1] that describes:


smtpauths.bluewin.ch:465 so TLS only (which is good!)

But, see below, connect with openssl and it drops from Init7, Quickline 
but works from BIT.nl...


Anybody similar sightings?


PCAP attached. Connection succeeds, but TLS alert and drop

Maybe passing through the same "load balancer" as:
http://lists.swinog.ch/public/swinog/2021-March/007457.html

Greets,
 Jeroen


swisscom.pcap
Description: Binary data

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Bluewin SMTP server reachable from outside bluewin/swisscom?

[Jeroen Massar]

 = Worblaufen, O = Swisscom (Schweiz) AG, OU 
= IT, CN = smtpauths.bluewin.ch

verify return:1
depth=0 C = CH, ST = Bern, L = Worblaufen, O = Swisscom (Schweiz) AG, OU 
= IT, CN = smtpauths.bluewin.ch

verify return:1
write W BLOCK
---
Certificate chain
 0 s:/C=CH/ST=Bern/L=Worblaufen/O=Swisscom (Schweiz) 
AG/OU=IT/CN=smtpauths.bluewin.ch

   i:/C=CH/O=SwissSign AG/CN=SwissSign Server Gold CA 2014 - G22
 1 s:/C=CH/O=SwissSign AG/CN=SwissSign Server Gold CA 2014 - G22
   i:/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
---
Server certificate
-BEGIN CERTIFICATE-
MIIH2jCCBsKgAwIBAgIUGEfAQSLKDtSxeCCekVh0nFmkCOEwDQYJKoZIhvcNAQEL
BQAwUjELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEsMCoGA1UE
AxMjU3dpc3NTaWduIFNlcnZlciBHb2xkIENBIDIwMTQgLSBHMjIwHhcNMTkwODA4
MDg0NDAxWhcNMjEwODA4MDg0NDAxWjB9MQswCQYDVQQGEwJDSDENMAsGA1UECBME
QmVybjETMBEGA1UEBxMKV29yYmxhdWZlbjEeMBwGA1UEChMVU3dpc3Njb20gKFNj
aHdlaXopIEFHMQswCQYDVQQLEwJJVDEdMBsGA1UEAxMUc210cGF1dGhzLmJsdWV3
aW4uY2gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJuFh6Yc/73bmW
Lyedte6kZQ56Q5XGsaKFtZmXWZXqYFmlPrlZ/vKYpTT712DCwOklcpd7/CrjPFwN
OhVL1aAsfr5UwfrBfFtE0pRsiUl/o3I/6NyfU1FobEVO8xnBhDKaOQOJlwZwndyR
GQLz6I1wsddJeh/puh4KvIl3vHq0ge8igZFTG2MuXIsayPUOWpdrbLuvebiaDfMw
FuJCtgkiSfhi9wRDLVkmXJF+q9+n/6FdJcr8+SgF+oiz2koXhSt/dVjrfrz+rL9/
5dZz9h8JT6X/sLG56SyVpOV4Mmzgq72afizutwtGHobygMqYyusW5GfwZJPqX+cb
BhiBmvNFAgMBAAGjggR7MIIEdzA4BgNVHREEMTAvghRzbXRwYXV0aHMuYmx1ZXdp
bi5jaIIXc210cGF1dGhzLmxiLmJsdWV3aW4uY2gwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQURQnYL5/oRqKp
p2+CnXirj1TyDCMwHwYDVR0jBBgwFoAU5/Hn/S5TrRHlgRpXpHOPEn2YyK4wgf8G
A1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0U3RjFF
N0ZEMkU1M0FEMTFFNTgxMUE1N0E0NzM4RjEyN0Q5OEM4QUUwgaiggaWggaKGgZ9s
ZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RTdGMUU3RkQyRTUzQUQx
MUU1ODExQTU3QTQ3MzhGMTI3RDk4QzhBRSUyQ089U3dpc3NTaWduJTJDQz1DSD9j
ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz
dHJpYnV0aW9uUG9pbnQwcwYDVR0gBGwwajBUBglghXQBWQECAQswRzBFBggrBgEF
BQcCARY5aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1NpZ24t
R29sZC1DUC1DUFMucGRmMAgGBgQAj3oBBzAIBgZngQwBAgIwgdUGCCsGAQUFBwEB
BIHIMIHFMGQGCCsGAQUFBzAChlhodHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmlu
L2F1dGhvcml0eS9kb3dubG9hZC9FN0YxRTdGRDJFNTNBRDExRTU4MTFBNTdBNDcz
OEYxMjdEOThDOEFFMF0GCCsGAQUFBzABhlFodHRwOi8vZ29sZC1zZXJ2ZXItZzIu
b2NzcC5zd2lzc3NpZ24ubmV0L0U3RjFFN0ZEMkU1M0FEMTFFNTgxMUE1N0E0NzM4
RjEyN0Q5OEM4QUUwggF7BgorBgEEAdZ5AgQCBIIBawSCAWcBZQB1AESUZS6w7s6v
xEAH2Kj+KMDa5oK+2MsxtT/TM5a1toGoAAABbHBmPNYAAAQDAEYwRAIgCvjTT2sR
PgoaHtOiCqmh1oERGFsdlSEy01a/da2WgxQCIAXM1dSNyXhiWTLGGKlg7fYjsVEx
Ed/WM6NYSh0AJPK+AHYAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMA
AAFscGY9CQAABAMARzBFAiBgWjl7D2nTcHPMOY8UVM0qvV9vG1Oqrf8J1zBrJuvw
kwIhAOtIKQQSbapV8Aw8q3+E5iLYYSMQdPXHUhDHueBebXygAHQA7ku9t3XOYLrh
Qmkfq+GeZqMPfl+wctiDAMR7iXqo/csAAAFscGY7sgAABAMARTBDAh9koSaw1fr6
ZrNJsVN2+v2+2QQ9VkMU4KJSQEfedRUbAiBY6V8yU93utvDWtrGnSck9X6aV9M7q
WhrZz7q9dQr5QzANBgkqhkiG9w0BAQsFAAOCAQEAdYPLeU/e7ugYfozqShEja1IT
LOrJ+FGQ6NNIYoRtilYX79tr+vpieN+P3q0W7M5Y9XEOpLWjuFWe/Ea67j2N4ixa
ZrTFNpw3gHHHJmYnARvKqZpKtC32MAj+NPWDLxy1e8+zcMw0YweZHc6506LPgioo
X6d5IXWcStolqJBWnbYs1KQdgH8sbWLyhHJ9kCedX39vwQE/N+cBvharzwccjedv
crxeTX/NNjicD6YqobSiehIv+xI8QUWHr8lzPQmFFFBWl01mNJFM3aPs5bZCI+bM
bc1zPKsXNIeDuRJAqBtVCMoOUu6sRjobwEwL5QGWfuQjaHe7zXLSXk1HV6Zztg==
-END CERTIFICATE-
subject=/C=CH/ST=Bern/L=Worblaufen/O=Swisscom (Schweiz) 
AG/OU=IT/CN=smtpauths.bluewin.ch

issuer=/C=CH/O=SwissSign AG/CN=SwissSign Server Gold CA 2014 - G22
---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 4433 bytes and written 477 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: DHE-RSA-AES256-GCM-SHA384
Session-ID: 
E2D86472371DD856CAA1D45E9D6580DF60CA0A5E0660161F0C3396EB6EF5D0EF

Session-ID-ctx:
Master-Key: 
9B916B6F692D256A1DF13961D1997A4E296B139E2038C78FA6EB9C85775373B3085169984688961BAB7A14F883BD75BA

Start Time: 1615459460
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---
220 smtpauths.lb.bluewin.ch vimdzmsp-sfwd05.bluewin.ch Swisscom AG ESMTP 
server ready



On 2021-03-11 09:25, Jeroen Massar wrote:

Hi,

(Possibly in relation to 
http://lists.swinog.ch/public/swinog/2021-March/007457.html, but in this case 
not even a TCP ACK...)

It seems smtp.bluewin.ch (25 and 465 tested) is unreachable from all places I 
checked (Init7, Quickline, BIT.nl).

Is that service normally open for Bluewin customers to connect to 
smtp.bluewin.ch?

As apparently Swisscom is sending out mails to providers that their customers 
are complaining that their customers on non-swisscom/bluewin cannot use their 
SMTP service.


But telnet does not even answer (no TCP ACK at all, no ICMP, nada nothing), 
thus looks like it is firewalled away.

Greets,
  Jeroen

[swinog] Bluewin SMTP server reachable from outside bluewin/swisscom?

[Jeroen Massar]

Hi,

(Possibly in relation to 
http://lists.swinog.ch/public/swinog/2021-March/007457.html, but in this case 
not even a TCP ACK...)

It seems smtp.bluewin.ch (25 and 465 tested) is unreachable from all places I 
checked (Init7, Quickline, BIT.nl).

Is that service normally open for Bluewin customers to connect to 
smtp.bluewin.ch?

As apparently Swisscom is sending out mails to providers that their customers 
are complaining that their customers on non-swisscom/bluewin cannot use their 
SMTP service.


But telnet does not even answer (no TCP ACK at all, no ICMP, nada nothing), 
thus looks like it is firewalled away.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom IPv6 Routing weirdness

[Jeroen Massar]

I have your answer :)

$ telnet -6 www.swisscom.ch 80
Trying 2a02:a90:c400:5001::2...
telnet: Unable to connect to remote host: Connection refused

same for 443. It takes a while for it to respond with a RST... which is a 
really cool one:

   52 54 00 b2 ca 34 cc 4e 24 45 ef 00 86 dd 60 00   RT...4.N$E`.
0010   00 00 00 3d 06 2f 2a 02 0a 90 c4 00 40 01 00 00   ...=./*.@...
0020   00 00 00 00 00 02 20 01 16 20 20 b0 00 00 00 00   .. ..  .
0030   00 00 00 00 00 55 01 bb ee 1c 00 00 00 00 c4 a0   .U..
0040   ea f9 50 14 00 00 ff 13 00 00 42 49 47 2d 49 50   ..P...BIG-IP
0050   3a 20 5b 30 78 32 62 33 38 30 62 35 3a 32 37 31   : [0x2b380b5:271
0060   5d 20 68 61 6e 64 73 68 61 6b 65 20 74 69 6d 65   ] handshake time
0070   6f 75 74  out


I guess that tells it all :)

The fun thing is, that is just a telnet (should have used netcat to ignore 
telnet attributes).

Greets,
 Jeroen

--

> On 20210309, at 10:49, Jean-Pierre Schwickerath  wrote:
> 
> Hi Gregor
> 
> Thank you for your insights.
> 
> On 02.03.21 20:51, Gregor Riepl wrote:
>> I tried different ISPs to which I have access and I can't establish a
>> IPv6 connection to port TCP/443 to neither 2a02:a90:c400:4001::2 nor
>> 2a02:a90:c400:5001::2 which seems the two loadbalancers responsible for
>> www.swisscom.ch except from a Swisscom Business DSL connection.
>> 
>> Init7 -> fail
>> Strange, from AS13030 (Fiber7 residential), both IPs work fine.
> I just tried it again from a customer with a Fiber7 access and I still
> can't open www.swisscom.ch neither in a browser edge / firefox on a
> windows machine, nor from wget on a linux server.
> 
> 
>> Perhaps something is wrong with your test client? Wrong MTU? OS issue?
>> Did you try a different machine?
> 
> I tried from various windows and linux machines from our office (via
> netrics), from customers (fiber7) and from our datacenter (nts) and it's
> all the same - I use different routers, different OS versions.
> 
> My datacenter ISP (nts) suspects that it's a reverse path issue and
> advised me to use atlas probes to confirm.
> 
> I made two mesurement but the results show more successes that failure:
> 
> https://atlas.ripe.net/measurements/29275604/#probes
> 
> https://atlas.ripe.net/measurements/29275617/#probes
> 
> 
> So maybe it's really only me and I have to live with the fact that I
> can't login to the swisscom website when v6 connectivity is enabled.
> 
> Strange thing is that I even found a swisscom sme fiber customer where
> the connection to https://www.swisscom.ch times out and one on a ip-plus
> fiber access. Maybe that's my best bet to open a ticket with their support.
> 
> It would be so much easier to debug if their webserver would answer to
> pings on v6.
> 
> I'll keep the list updated if I have any relevant news.
> 
> 
> Best Regards and thanks again to all of you who spend some time on this
> issue already
> 
> Jean-Pierre
> 
> -- 
> HILOTEC Engineering + Consulting AG - Langnau im Emmental
> IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
> VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
> Tel: +41 34 408 01 00 - https://www.hilotec.com/
> 
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom IPv6 Routing weirdness

[Jeroen Massar]

> On 20210225, at 16:52, Jean-Pierre Schwickerath  wrote:
> 
> Hi Jeroen
>> that "sinkhole" is just a misconfigured/internet-ignorant "load
>> balancer": those things do not care about ICMP...
>> 
>> you are thus reaching the dest, it is just misconfigured: the Internet
>> is just HTTP for many, they do not care about this TCP, ICMP or IP
>> thing... be happy there is some kind of IPv6...
>> 
> I wouldn't have noticed the issue if the loadbalancer / webserver had
> actually returned a webpage on port TCP/443. But it doesn't. So I tried
> from a different network to see if the issue is reproducible and that
> when I noticed the path taken by the traceroute packets.
> 

Check with a tcpdump, don't forget to include ICMP.

Could also be an MTU issue or something on your side killing it.

Of course the behavior of the "load balancer" says quite a few things... sbb.ch 
is like that too...

>> 
>> Btw, when complaining about something, it is wise to include IP
>> addresses, especially for the source...
>> 
> The first hop of the traceroute is actually a good indicator for the
> source.

192.168.205.240 ?

DNS is ambiguous and reverses do not always match forwards. Including the 
actual IPs can thus be very useful...

That is, if you actually want it resolved.

You might want contact swisscom directly (good luck with that) or at least your 
ISPs that provide the connectivity, they might have better chance at contacting 
them.
(taking transit over swissix is a fun one; but yea it is not that swisscom 
likes to peer, what else would a monopoly do)

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom IPv6 Routing weirdness

[Jeroen Massar]

On 2021-02-25 15:45, Jean-Pierre Schwickerath wrote:

Dear Swisscom Routing-Experts

Are you not peeing at swissIX anymore?

Your webserver www.swisscom.ch (2a02:a90:c400:4001::2) gives me a hard
time to be reached. Either it wants it traffic to be routed from Berne
via NL, UK, US and ends in a sinkhole or it uses what looks like using
private peering from tineo/netrics/finecom to the same sinkhole:


that "sinkhole" is just a misconfigured/internet-ignorant "load 
balancer": those things do not care about ICMP...


you are thus reaching the dest, it is just misconfigured: the Internet 
is just HTTP for many, they do not care about this TCP, ICMP or IP 
thing... be happy there is some kind of IPv6...



Btw, when complaining about something, it is wise to include IP 
addresses, especially for the source...


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 2020-10-27 13:15, Gert Doering wrote:

Hi,

On Tue, Oct 27, 2020 at 01:00:59PM +0100, Jeroen Massar wrote:

Making sure one only egress mail that one is supposed to send
(SPF/DKIM/DMARC/ARC) is the only way to do that and would mean being a
good citizen on the Internet,


Much easier said than done...


Of course it is easily said, this is a mailinglist, not a big slide deck 
or a huge howto how to run a mailserver. Needs quite some experience that ;)



For many folks on this list, SPF came, then DKIM, then DMARC, then ARC 
and their installations started supporting them one by a time, thus 
evolution is easy.


Starting from 0, not so much.

But, SwiNOG is here to help. If people have setup questions, we can 
answer them here, another good citizen on the internet is a win for 
everybody.



which is why lists like UCEProtect exist:
if you configure your stuff correctly, you won't end up on them.


You totally miss the "you have a contract with the customer to run their
mail for them, so of course you accept the mail, and then they mess up
their SPF records in DNS" part.

And then your whole mail server is blocked.


Yes, what UCEProtect does in 'one fail and you are out' is a bit over 
aggressive. That is completely out of your control. Rejecting the mail 
would be good enough indeed, as the collateral damage is too much. 
(Would be fun if they listed Google + MS MXs though, will quickly stop 
people using those kind of lists... and considering the amount of spam 
originating through google, though with valid SPF/DKIM etc... should 
happen at one point :) -- maybe it a threshold "X mails out Y bad, then 
block", and a low volume sender then gets blocked quicker than a high 
volume spammer...



One variant: as the domain needs also DKIM + SPF, and if the customer is 
not as tech savvy: always take over domain hosting...


And/or monitoring DKIM/SPF records that they are valid for your setup 
and warning the customer that you stop relaying their messages as their 
setup is wrong.


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 2020-10-27 09:04, Gert Doering wrote:

Hi,

On Tue, Oct 27, 2020 at 08:40:39AM +0100, Jeroen Massar wrote:

Mail server admin can do a SPF check (or have a list of allowed source
email domains) before outbound and reject forwarding these emails.


I read this and I wonder "which of the MTAs out there can do that" -
that is, check SPF (and others) for outgoing mails.


Not many, as normally you do not accept mail at ingress (smtp/maildrop) 
that you cannot send. I've built custom SMTP engines for people that did 
this though (and if the domain was not acceptable either reject that or 
wrap it in a @via. / SRS-style)




For a ready-off-the-shel-prioject I am sure that Halon 
(https://halon.io/) can do this though, but for most you would have to 
custom code a SPF-check-on-exit. (as SPF mostly is applied to inbound).



For everybody else one simply configures a list of domains that one is 
authoritive for and just use that when mail is dropped in over SMTP or 
maildrop. Hopefully along with valid DKIM + SPF records outbound and 
signing etc when it actually goes out of the box.




"Blaiming all on the MTA operator" isn't totally reasonable either - you
might have a totally valid configuration, and then someone whose mail you
legitimately sent before (either forward rules that had no conflicting
SPF yet, or your server was listed, or...) changes *their* SPF stuff,
making *your* MTA noncompliant.

Is this an error?  Yes, surely.

Is the MTA operator to blaim for it?  Possibly sometimes, but certainly
not "always, and solely".


I don't think blaming somebody is a useful avenue.

As mentioned, marketing can be an annoying thing. For instance I noticed 
that one of our domains maxed out the SPF inclusion limit... because 
people just kept on piling on SPF includes, never actually understanding 
what it is for and what the limitations are. All that marketing spam 
(and all legit mail) ended up in SPF:permerr land, thus nicely rejected ;)



The reason for my mail was to elaborate what one could do against 
becoming listed in restrictive lists like UCEProtect.


Making sure one only egress mail that one is supposed to send 
(SPF/DKIM/DMARC/ARC) is the only way to do that and would mean being a 
good citizen on the Internet, which is why lists like UCEProtect exist: 
if you configure your stuff correctly, you won't end up on them.



That said, I personally avoid strict lists like that, but everybody can 
pick their own lists, your domain, your selection on what to accept for 
whatever you want.


Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 2020-10-27 08:01, Silvan M. Gebhardt wrote:

I assume this swiss provider has never allowed any customer to leave.

Every customer who changes DNS providers becuase their marketing decides on a 
new website and not telling anyone and then their marketing department 
hijacking the DNS, and forgetting that they run some mailing via some 
application hosted with you and not caring about spf records becuase the 
webdesigner doesn't know it, will get you on the blacklist.


Mail server admin can do a SPF check (or have a list of allowed source 
email domains) before outbound and reject forwarding these emails.


Of course the marketing/sales department will just "make it work" and 
"that is your problem"


Still, technically, something one can stop from wrongly forwarding 
messages that the host is not supposed to be sending.



Given that one really need properly configured SPF/DKIM/DMARC to have 
your mail not arrive in Spam folder on the big providers it does not 
make sense to send mail that one cannot send anyway.


Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 2020-10-27 00:01, Mueller Urs SBB CFF FFS wrote:

Thank you guys


well, technically, they (UCEProtect) are correct.

If an IP sends a mail with the From: header indicating a domain for 
which an SPF record exists, and the sending IP is not supposed to send 
it, then it is a misconfiguration and that IP should not be trying to 
send such a mail at all.


If it is trying to send that, it indicates it allows forwarding of mails 
From: domains that it should not be transmitting for. It should not be 
doing that.



As such, listing it after one such event might be a bit quick, but 
technically indeed, that server is misconfigured and allowing relaying 
of messages it should not be.



Now of course, such an event can happen easily, e.g. when somebody 
configures a forwarding rule and no rewriting happens. And in the day 
and age of SPF/DKIM/DMARC/ARC, it again tells you, that such an event 
should not happen as the rewrite should have taken place.



Thus in the end UCEprotect is correct: fix the host on the IP that is 
sending those mails, as it is sending mails it should not.


Now, when that situation is fixed, then UCEprotect should IMHO be able 
to remove the block entry though.



Greets,
 Jeroen

--



My colleague just wrote me:

"I got the following reply from the swiss provider that obviously works 
closely with UCEprotect that I'd also call a rogue list as of now. This 
is the reply after sending them all of your arguments which I thank you 
for. They do obviosuly not only not understand the basic problem but 
also seem to be more keen on posting bla bla and accusations rather than 
arguments that make sense. Here is their text:


SPF wurde etabliert, um Phishingmails und sonstige Formen von Betrug zu 
unterbinden. Wenn der Eigentümer einer Domain solch einen SPF Record 
setzt, dann gibt er damit automatisch zu verstehen, daß IPs, die nicht 
erfasst sind, nicht zum Versand von Mails unter seiner Domain berechtigt 
sind. Ein Server, der Mails versendet, die er ganz offensichtlich nicht 
versenden darf, beweist, daß er ein gravierendes Sicherheitproblem hat. 
Euer Diskussionspartner sollte von daher bei Einlieferungen von Kunden 
schlicht und ergreifend auf SPF prüfen, und Mail, die er laut SPF nicht 
versenden DARF, von vorne herein nicht annehmen... Dann werden seine 
Server auch nicht bei uns geblacklistet. Wenn er technisch dazu nicht in 
der Lage sein sollte, kann das nicht unser Problem sein, UCEPROTECT 
Server beherrschen das jedenfalls. Statt Ihre und unsere Zeit zu 
stehlen, um unsinnige Diskussionen über unsere Policies zu führen, hätte 
er auch seinen Kunden kontaktieren, und diesen zur Abänderung oder 
Löschung seines SPF Records auffordern können...


Was er aber macht ist ein typisches Lamerverhalten. Statt die Ursache 
des Problems zu beheben, versuchen solche Leute das Symptom abzumildern, 
und ihr eigenes Versagen anderen in die Schuhe zu schieben. Ja und das 
Gejammer und Geschwurbel über uns in irgendwelchen Foren und auch auf 
Webseiten geht uns gepflegt dort vorbei, wo die Sonne nicht scheint...


Wir betreiben die UCEPROTECT Listen für unsere weltweit zahlreichen 
zufriedenen Anwender... Wenn diese unzufrieden mit den Listen wären, 
würde die Listen niemand nutzen, und somit hätten die Gelisteten keinen 
Grund zu jammern. Mit ihrem Gejammer überführen sich Gelistete aber 
selbst als Lügner daß dieser Hoster Euch damit wochenlang belästigt, 
statt das Problem direkt auf seinem System abzustellen, oder mit seinem 
Kunden zu sprechen, zeigt jedenfalls, wes Geistes Kind er ist... Ich 
denke, damit ist alles gesagt..."


My (Urs) opinion, rather rough words, I personally would like to know 
the name of that provider, but it’s not me to blame him.


Regards, Urs

*Von:*swinog-boun...@lists.swinog.ch  
*Im Auftrag von *Matthias Leisi

*Gesendet:* Donnerstag, 8. Oktober 2020 22:35
*An:* Markus Wild 
*Cc:* swinog@lists.swinog.ch
*Betreff:* Re: [swinog] Handling of UCE / RBL while minor misconfigurations

I think Markus misses the main point of the OP. The question of the OP 
is not whether SPF is a good or bad idea in general.


The question is whether its reasonable to add a blacklisting entry for 
the server IP if you receive a single mail with a non-matching SPF 
record (ie, server with IP a.b.c.d not covered by the SPF for foo.com 
).


My take on this is that this blacklisting behaviour is entirely 
unreasonable.


And I agree that it’s questionable why anyone should use a list with 
such unreasonable listing practices (apart from their extortion 
practices). Unfortunately the burden is first shifted not onto the 
admins responsible for such stupid decisions, but on the sending party 
who must wade through massive layers of ignorance and denial.


— Matthias



Am 08.10.2020 um 09:14 schrieb Markus Wild mailto:swinog-l...@dudes.ch>>:

Hello Urs,

My take on your problem is the following:
- SPF is bad and breaks mail delivery, don't use it. 

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 20201008, at 17:49, Maxim Samo  wrote:
> 
> Last time I looked ubs.com does use DKIM, SPF, and DMARC.

Easy to look:

There is SPF:

$  dig +short ubs.com txt|grep v=spf
"v=spf1 include:spf-a.ubs.com include:spf-hosted.ubs.com  
include:spf.protection.outlook.com -all"


There is definitely DKIM (grabbed from random message):

8<---
Dkim-Signature: ⁨v=1; a=rsa-sha256; c=relaxed/relaxed; d=ubs.com; h=date 
:date:content-transfer-encoding:content-type:content-type 
:mime-version:subject:subject:message-id:from:from:received 
:received:received:received:received:received; s=srsa2048; t= 1601855040; 
bh=
Return-Path: ⁨⁩
--->8

And finally DMARC:

$ dig +short _dmarc.ubs.com txt
"v=DMARC1; p=reject; sp=reject; 
rua=mailto:dmarc-reports-57574806756964364...@open.ch,mailto:dmarc-repo...@ubs.com;
 ruf=mailto:dmarc-forens...@ubs.com; rf=iodef; pct=100; ri=86400"

Seems the fine folks at open.ch have a hand in it ;)

If they did not then they would not be able to deliver their mail.
And fortunately marketing folks win it over security folks (who can't get other 
things fixed), thus it get implemented.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 20201008, at 15:53, Markus Wild  wrote:
> 
> Hey Jeroen,
> 
>> SPF is only a part of a solution to the battle of spam.
> 
> SPF isn't suited to combat SPAM at all (including the whole other DKIM etc 
> enchilada), since it's quite trivial for
> spammers to define these records correctly in throwaway domains.

Notice the word "part" above, there are many ways to combat spam, and most are 
not 100% effective.

Even the closed gardens of the big tech corporations with their millions is not 
even, heck they are a large source of spam...

> Thus, no reasonable spam filter can honour (in a
> positive way) the presence of an SPF record, they can only punish the 
> connection if there is an SPF record and the
> connection is in violation of that record. The really only benefit you could 
> get from SPF is some kind of antispoofing
> protection, but at least in my experience, that is hardly ever a real problem 
> to begin with


It completely stops 'simple attacks' though: hijack/bot a box and spew crap 
from a random domain and that solves a lot of phishing attempts also with the 
real domain (does not solve anything like registering a lookalike domain etc 
though, or just uninformed users).

That is actually most of the nonsense happening in the world and takes care of 
every host that is not properly configured. And that is the goal of SPF, and 
also DKIM and also DMARC.


True spammers (read: advertising) are professional organisations and indeed can 
setup that infrastructure completely without issue.

Thus nothing really works against that as they have more resources and legal 
constructions to avoid any persecution.

See also the other messages on the list about Rocket Mail and of course this 
cool GDPR / DSVGO thing.


>> It helps a lot to combat broken setups.
>> 
>> If a setup is broken, they are not worthy of receiving mail in the first 
>> place.
>> 
>> Thus, if you hate on SPF, I can only conclude you have shot yourself in the 
>> foot a lot with it.
> 
> No, I hate SPF because it breaks basic SMTP relaying, or in more enduser 
> speak: redirected mails.

Rewrite the mail (e.g SRS-style), DKIM sign it, setup proper SPF and voila, it 
all works fine.
Systems I take care of literally send millions of mails that way without issue.
(See also http://lists.swinog.ch/public/swinog/2020-August/007358.html)

SMTP Relaying would involve MXs that authorize eachother to accept mail.

You are simply forwarding/redirecting, and the source is not the anymore where 
it originally came from nor did they give you permission to do so. As such, 
rewrite the From as you are not that the original sender.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Jeroen Massar]

On 20201008, at 09:14, Markus Wild  wrote:
> My take on your problem is the following:
> - SPF is bad and breaks mail delivery, don't use it. But, if someone defines 
> SPF records, and they thus declare they
>  want to shoot themselves into their feet, by all means, I encourage to block 
> mails failing SPF, because that's what
>  domain owners who define SPF records ask for.

As one of the original people involved in SPF and having been doing this 
anti-spam dance for some time


SPF is only a part of a solution to the battle of spam.

It helps a lot to combat broken setups.

If a setup is broken, they are not worthy of receiving mail in the first place.


Thus, if you hate on SPF, I can only conclude you have shot yourself in the 
foot a lot with it.

As you note though, your server, your problem on how one it is configured.


If you need help in resolving your problems, don't hesitate to ask me directly 
or here on list so that others can also benefit.

Greets,
 Jeroen

(Running the full stack of SPF/DKIM/DMARC,MTA-STS, etc etc and not having mail 
delivery issues... ;)



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Announcement of 'china government' routes 125.208.4[567].0/24 forbidden?

[Jeroen Massar]

On 2020-08-27 17:16, Benoit Panizzon wrote:

Hi List

A customer complained, he cannot reach the website of chinese embassy in
Switzerland.

CH.CHINA-EMBASSY.ORG

The DNS Servers are hosted under 125.208.4[567].0/24 and none of our
peers do announce those routes to us.

The all, according to the looking glasses, seem to get those routes
announced from AS24406 CNNIC but do not redistribute them.


https://stat.ripe.net/125.208.46.1#tabId=at-a-glance

"125.208.46.0/24 is visible by 99% of 322 IPv4 RIS full peers."

Seems many get it.

Greets,
 Jeroen

Pudding:

Telia has a route amongst others:


traceroute to 125.208.46.1 (125.208.46.1), 30 hops max, 60 byte packets
 1  r2win7.core.init7.net (213.144.131.49)  0.399 ms  0.300 ms  0.298 ms
 2  r1win6.core.init7.net (77.109.140.194)  0.345 ms  0.303 ms  8.952 ms
 3  r1zrh6.core.init7.net (82.197.168.101)  3.714 ms  7.947 ms  3.632 ms
 4  r1glb1.core.init7.net (82.197.168.223)  0.696 ms  0.662 ms  0.774 ms
 5  r1zrh2.core.init7.net (77.109.128.237)  0.949 ms  0.917 ms  0.872 ms
 6  zch-b2-link.telia.net (62.115.148.48)  6.748 ms  6.817 ms  7.364 ms
 7  prs-bb4-link.telia.net (62.115.135.128)  154.649 ms  153.825 ms 
153.758 ms
 8  ldn-bb3-link.telia.net (62.115.123.68)  157.327 ms 
ldn-bb3-link.telia.net (62.115.134.93)  156.875 ms 
ldn-bb3-link.telia.net (62.115.123.68)  156.408 ms

 9  * * *
10  * chi-b23-link.telia.net (62.115.137.59)  113.334 ms *
11  sea-b2-link.telia.net (62.115.117.48)  155.829 ms  155.826 ms 
155.446 ms
12  chinamobile-ic-342124-sea-b2.c.telia.net (62.115.171.221)  155.576 
ms *  157.235 ms

13  223.120.6.53 (223.120.6.53)  169.313 ms * *
14  223.120.12.34 (223.120.12.34)  354.228 ms 
chinamobile-ic-342124-sea-b2.c.telia.net (62.115.171.221)  166.138 ms 
223.120.12.34 (223.120.12.34)  354.171 ms

15  221.183.55.110 (221.183.55.110)  366.540 ms  366.853 ms *
16  * *^C



$ dig +trace CH.CHINA-EMBASSY.ORG

; <<>> DiG 9.16.3 <<>> +trace CH.CHINA-EMBASSY.ORG
;; global options: +cmd
.   204425  IN  NS  h.root-servers.net.
.   204425  IN  NS  m.root-servers.net.
.   204425  IN  NS  k.root-servers.net.
.   204425  IN  NS  g.root-servers.net.
.   204425  IN  NS  b.root-servers.net.
.   204425  IN  NS  i.root-servers.net.
.   204425  IN  NS  d.root-servers.net.
.   204425  IN  NS  l.root-servers.net.
.   204425  IN  NS  a.root-servers.net.
.   204425  IN  NS  f.root-servers.net.
.   204425  IN  NS  c.root-servers.net.
.   204425  IN  NS  j.root-servers.net.
.   204425  IN  NS  e.root-servers.net.
.			289637	IN	RRSIG	NS 8 0 518400 2020090617 2020082416 46594 . 
t6M8J6ex2mlP8Tn+WIlrNB7SAYPv+6+uWn6Ppeu1+IyRhHDYMfdBjG9n 
QoNUHv6tfhhAPoR4G1zbzRsH3JPciZMwiBJpHcp0Uz9wVQgJBl9PDQ1c 
fu8iA/7lXo8kCpB0/cgBjvfHfGXF+Gwsvrvve/A8zhxKbiRtgoDNRDe1 
/3vkZzLJUODOqlXiIfm2qudMz/y01+siFYM/pgLk5zJbn/4BnAe/9kUc 
MbqGi7wD5SdlloJ0UYtu5q0LTVu5EQ6JC7s/qgxGAvEiBCRqlo1CKIP/ 
/bzs4+Krxu01pvGmlsnmOqOCff13EvKPaQt1yuzCO7VzYDXchOfazHnX n/mGJg==

;; Received 1125 bytes from 8.8.8.8#53(8.8.8.8) in 1 ms

org.172800  IN  NS  b0.org.afilias-nst.org.
org.172800  IN  NS  a0.org.afilias-nst.info.
org.172800  IN  NS  b2.org.afilias-nst.org.
org.172800  IN  NS  a2.org.afilias-nst.info.
org.172800  IN  NS  d0.org.afilias-nst.org.
org.172800  IN  NS  c0.org.afilias-nst.info.
org.86400   IN  DS  17883 7 1 
38C5CF93B369C7557E0515FAAA57060F1BFB12C1
org.			86400	IN	DS	17883 7 2 
D889CAD790F01979E860D6627B58F85AB554E0E491FE06515F35548D 1EB4E6EE
org.			86400	IN	RRSIG	DS 8 1 86400 2020090905 2020082704 46594 . 
DUBoJT8syNiDGXHXEivBinzu4dFrqKrNSL2Ppwx05Ze+ktzNjSMaBEdm 
qsWfpBJhgeafBORxwVaq2/4HtZUztd1syWETyBzz6/DjuMCej+vsj5W0 
3dX2IfLQCbgL+15N3OsWsIdA87OADUUKFAP6Y18vhvAwMLxC8BuszBcF 
8xEYSGGkEKV+rJTHsp1/aNBl0ovKuViB4Ja1cn8u3VQelhfM1IT6SvlB 
RH3AjpRGUhmuR4kkjKdHADX273nt7TIboLYaM8OPSC8fqjQRkOY5hvk/ 
h9UNfO0w6ms9MbURoKL7WFhk0glzLtAPcxjHPdkX1qM2U4OCv30kU17T eH2Xuw==

;; Received 853 bytes from 2001:500:200::b#53(b.root-servers.net) in 139 ms

china-embassy.org.  86400   IN  NS  ns.fmprc.gov.cn.
china-embassy.org.  86400   IN  NS  ns3.fmprc.gov.cn.
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB 
H9P94CHNCUOADBOKM57JBRIMA2O6J0IQ NS SOA RRSIG DNSKEY NSEC3PARAM
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN RRSIG NSEC3 7 2 86400 
20200917154745 20200827144745 21869 org. 
hVuKf+InL1VJg6zZWYfHiE/KWQTurhYGL1ZAm01XldC7qCkh0HvUPXJf 
YOfsh9ce6SW+SARSOcKDWY87geZn3iqfQ60aBYtVuz/paw+ShjTlO4pq 

Re: [swinog] DMARC Reports from Swiss Internetproviders

[Jeroen Massar]

Andres wrote:
> Does anybody know, if Swiss Internetproviders do send DMARC Reports
> in theyr Email Service?

sunrise.net & libertyglobal.com (read: UPC/Cablecom) are reporting at least.

There are also a variety of other Swiss companies sending out reports.
(switch, unibas, unil, swiss-re)


AS15600 currently does not send out reports, but if people really would
want them, could look into enabling it.


On 2020-08-04 12:20, Benoit Panizzon wrote:
[..]
> I have not yet found easy tools to evaluate the reports. (any tips
> welcome).

For AS15600 we peek at the results gathered with:

https://github.com/domainaware/parsedmarc

Though it is a primarily to just peek, not to monitor, there are other
tools for that.

Be prepared to learn that:
 - Google receives most email (quelle surprise).
 - Google also sends mail for your domains
   (likely forwarding as the DKIM headers are intact)
 - there are a few persistent spamming hosts spamming towards Google,
   that never get cleaned up or blacklisted
   (but SPF/DKIM/DMARC causes the mail to not be accepted)
   Looking at boracaybeachhouses.com / 209.59.154.15
 - Spammers generate sometimes more mail than you, that nicely
   all get rejected (SPF/DKIM/DMARC)
 - Some obscure domain on your mailplatform is used as a source
   for spam, but SPF/DKIM/DMARC drops that :)
 - 70% DMARC Passage, 65% DKIM Alignment, 46% SPF Alignment


It is thus quite educational, as it shows that the SPF/DKIM/DMARC combo
is actually effective and avoids quite some backscatter when verified
during the SMTP-DATA phase.

Of course, there are side-effects, forwarding is horribly broken. But...



For the encrypted remailer that is trident.li, used in a variety of
places (one recently part of a flamewar on the RIPE lists ;), I've
solved that with a 'via' address:

When an incoming mail has a DKIM-Signature header, trident rewrites
From: to:

 From: "Jeroen Massar [jer...@massar.ch]" 

This so that it is clear what the From is; noting that many MUAs store
emails automatically in the addressbook; thus using e.g.
l...@example.net in the From will just cause problems (see also Jira
notifications).

then it adds it's own DKIM + ARC(Authenticated-Results/ARC-AR)
signatures, which validate happily.

When a user hits 'reply-all' then both From + To: are considered and
goes to the right recipients.
When the user hits 'reply list' it goes correctly to the list (as that
To: address is still valid and the List-Reply header is there.
When the user hits 'reply' it goes to the From which is the @via address
at example.net, which can rewrite it back to the normal user and forward
the message along.

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SwiNOG #27 & COVID-19 | Please fill in survey

[Jeroen Massar]

On 2020-07-06 12:13, Steven Glogger wrote:

Hi community

We’re currently in discussion if we will proceed with our SwiNOG #27 
plans or if not…

We would like to get your opinion.
Please help us and provide an honest answer to our really short 
questinaire (will take 30sec to fill in):

http://swinog.ch/covid/



People be aware:

If you select "no" on the first page ("Would you like to have a..."), 
then you do not get to chose the multi selector which has more useful 
options:


- Remote: Join only if there is an remote / online session
- On-Site: Join personally on site I would not join online nor remote - 
- I'll just watch the presentations and videos late…

- I am ok for on-site if COVID infection rates drop by this tim…
- Join Onsite, no live stream (otherwise less ppl attend,) if i…


I think most people would have selected on of those options if they 
could: 70% said 'no' now and did not get to be represented in the second 
chart which skews the results quite a bit.


Also, keep that in mind when looking at the chart: 33 responses no, 
while 10 of those could fill in the second chart, 23 did not get to see it.



I am good with remote session (though I tend to then just watch the ones 
I am directly interested in to allow for questions/feedback, and watch 
the rest at a later point).


Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] How / where to address weird 'akamai' cloud issues?

[Jeroen Massar]

See offlist reply for a direct contact.

Noting that here: if people have a problem, do make your problem known
on SwiNOG so that we can help each other in resolving problems ;)

Sometimes the right person at a company can make things move along.

Greets,
 Jeroen

--

On 2020-06-18 15:26, Adrien Baranger wrote:
> Hi Swinog users, 
> 
> We (netplus.ch SA) are experiencing same Akamai issues with big websites like 
> Apple.com and Playstation Network. 
> We opened a ticket to their NOC (check peeringDB for contacts) and are 
> waiting for their feedback. 
> 
> Best regards, 
> 
> --
> 
> Adrien Baranger
> Telecom team 
> 
> tel : +41 27 565 75 62
> fax : +41 27 565 75 12
> email : adrien.baran...@netplus.pro
> 
> netplus.ch SA
> Techno-pôle 3
> 3960 Sierre
> 
> 
> 
> -Message d'origine-
> De : swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] 
> De la part de Benoît Panizzon
> Envoyé : jeudi, 18 juin 2020 15:04
> À : swinog@lists.swinog.ch
> Objet : [swinog] How / where to address weird 'akamai' cloud issues?
> 
> Hi List
> 
> I'm confronted with two strange akamai cloud platform issues.
> 
> Yangming.com:
> When accessed from certain ip addresses, the akamai 'webserver' returns
> a cryptic error number in about 6 of 5 attempts (ssl is established,
> cert valid and everything, the error is then shown as website content
> instead of the website). Yangming.com tells it's not 'their' problem
> and we as ISP operating the affected ip addresses have to fix this.
> 
> Brack.ch:
> When customers try to subscribe to their newsletter, the website
> answers 'Bestätigungsemail gesendet'. But at least two specific email
> address are never getting that email (not even a trace in the logs when
> I try to subscribe them an watch the logs at the same time) as if it
> were blocked @ the sender. Brack Techs never encountered such an issue
> and don't know where to start looking as everything is in the akamai
> cloud.
> 
> Has anyone a contact @ akamai able to debug such issues?
> 


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Fwd: AW: FDV Technische Vorschriften Netzqualität

[Jeroen Massar]

On 2020-06-12 20:16, Fredy Künzler wrote:

Dear all,

Please see below my communication with BAKOM (OFCOM) regarding the
official speed test measurement system which is proposed in the FDV
(Fernmeldedienstverordnung).


So I guess that all these providers will apply nice "QoS" to the well 
known speedtest prefix, while still applying negative "QoS" for the 
competition, or by not doing proper peering etc etc etc...


What is the point of doing this, when it will never match reality?


Also, it seems that there are monopoly providers who are present at IXs 
and won't peer then with other ISPs, thus not very useful all that, 
as the speedtest will be amazing, but the actual packets to the other 
ISP will fly over timbooktoo...



Thus maybe, next to speedtests to standardized sinkholes, doing 
speedtests between ISPs is a good idea; of course, with changing IPs.


That is: if you participate in this speedtest setup, you host a bunch of 
nodes in your network, which automatically do speedtests & traceroutes 
all the time.


Something akin to RIPE's RIS system, or NLNOG Ring or heck Sam Knows, 
but then a non-corrupt version of that ;)


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Init7 wins peering case against Swisscom and ComCom

[Jeroen Massar]

Fredy,

Congratulations with such an amazing win!

This might just provide the possibility of smaller ISPs to actually have an 
honest competition to the big established market monopolies.
The future will tell what this will change.


That this took 7 years though, could have been a killer for a small company. 
Fortunately they granted the preliminary solution earlier, otherwise it would 
likely have been impossible to compete in anyway and you would have been pushed 
out of the market.


Thanks for fighting the good fight! Very much appreciated.

Regards,
 Jeroen

--


On 2020-04-29 10:12, Fredy Künzler wrote:
> Bundesverwaltungsgericht BVGER (Tribunal administrativ federal) decides
> as the court of last resort in the IP interconnection (peering) case pro
> Init7 and pro open and discrimination free internet.
> 
> The cartel of Deutsche Telecom and Swisscom until January 2016 has been
> sanctioned. ComCom needs to decide about a price for cost oriented peering.
> 
> Details in our press release (German only).
> 
> https://drive.google.com/open?id=13nMQkj1abja-3cPBiQWiZaybsFIUkWa5
> 
> We are very happy that this case is now over. It took seven years, it
> all started 2012 when Swisscom tried to make us pay for peering.
> 
> Besides, as ComCom is going to decide about IP peering, we believe the
> court order will have an impact the peering landscape beyond Switzerland.
> 



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Weird Bluewin Error: 'Unable to verify MX-Record for domain'

[Jeroen Massar]

On 2020-03-31 10:13, Andreas Fink wrote:
> your reverse DNS is not matching for 157.161.57.26 as it returns 
> aleka.scout.ch.
> 
> list.scout.ch. is not the same as aleka.scout.ch
> You could do instead
> 
> 
> list.scout.ch  MX 50 aleka.scout.ch
> 
> or 
> 
> list.scout.ch  CNAME aleka.scout.ch.

Please, please, please, for your own sanity: NEVER EVER point an MX to a CNAME.


Sendmail, which some people still use (oh heck my inbound MX's are sendmail), 
will mess up the domain that way and nicely replace it.

Thus a mail to: someth...@lists.scout.ch would be replaced by sendmail with 
someth...@aleka.scout.ch, which likely will not end up in the same place, and 
will cause other expected.



Also RFC refs why not to do it:

https://tools.ietf.org/html/rfc1912#section-2.4
8<
Don't use CNAMEs in combination with RRs which point to other names like MX, 
CNAME, PTR and NS.
...
->8


http://tools.ietf.org/html/rfc2181#section-10.3

8<
10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value 
of a MX resource record must not be an alias. Not only is the specification 
clear on this point, but using an alias in either of these positions neither 
works as well as might be hoped, nor well fulfills the ambition that may have 
led to this approach. This domain name must have as its value one or more 
address records. Currently those will be A records, however in the future other 
record types giving addressing information may be acceptable. It can also have 
other RRs, but never a CNAME RR.
->8

and there are others that detail this problematic setup.



In general actually: avoid CNAMEs where possible; just pre-process your records.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Quickline contact

[Jeroen Massar]

On 2020-01-28 17:24, Marco Kälin wrote:

Hi list,

Someone from Quickline mx ord dns team here?

You send VPBX Fax2Mail Messages from faxser...@business.quickline.ch.
Can you please check your spf record on business.quickline.ch?

root@localhost:~# dig @8.8.8.8 business.quickline.ch txt +short
"v=spf1 -all"​


That record indicates it domain should not be sending mail, which likely 
is intended.



business.quickline.ch is a bit of an odd domain though, as most of the 
'enterprise' stuff has been bumped to Tineo.



Please send the full headers and other details if any to 
jeroen.mas...@qlgroup.ch and I'll have a peek at it and/or pass it to 
the right folks who should be handling it.


Greets,
 Jeroen

PS: since end of December most Quickline domains (especially the domains 
hosted on the mailplatform) have proper SPF/DKIM/DMARC records, thus 
spoofed or forwarded mails will nicely have to be dropped.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] FYI: admin.ch broken DNSSEC thus DNS down!

[Jeroen Massar]

On 2020-01-11 16:15, Jeroen Massar wrote:

As mentioned on Swinog IRC (yes we are alive there, join us! :):

admin.ch is unreachable due to broken DNSSEC.


And apparently fixed:

https://twitter.com/BIT_OFIT/status/1216035755350511619?s=20

8<-
Das @BIT_OFIT geht davon aus, dass die Webseiten der Bundesverwaltung 
wieder von überall her verfügbar sind. Bei der teilweisen 
Nicht-Erreichbarkeit der Seiten scheint es sich um ein 
Konfigurationsproblem gehandelt zu haben. Die Details werden nun analysiert.

->8

Light on details, but maybe somebody is able to invite them to give a 
talk once at a next SwiNOG meeting so we can hear more of the details 
and engage with them in how the Swiss ISP community can help out / 
cooperate more?


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] FYI: admin.ch broken DNSSEC thus DNS down!

[Jeroen Massar]

As mentioned on Swinog IRC (yes we are alive there, join us! :):

admin.ch is unreachable due to broken DNSSEC.

See:
 https://dnsviz.net/d/admin.ch/dnssec/

8<
ch to admin.ch: No valid RRSIGs made by a key corresponding to a DS RR 
were found covering the DNSKEY RRset, resulting in no secure entry point 
(SEP) into the zone. (162.23.37.16, 162.23.37.160, 212.103.72.85, 
2a00:c38:2:28:0::d467:4855, UDP_-_EDNS0_4096_D_K)


ch to admin.ch: The DS RRset for the zone included algorithm 8 
(RSASHA256), but no DS RR matched a DNSKEY with algorithm 8 that signs 
the zone's DNSKEY RRset. (162.23.37.16, 162.23.37.160, 212.103.72.85, 
2a00:c38:2:28:0::d467:4855, UDP_-_EDNS0_4096_D_K)

-->8

(I got a screencap of the page for later, just in case it get 
fixed/changed in the meantime; swinog only allows 40KiB attachments 
which would ruin the res too much for it to be useful :)




Thus for all ISPs on this list: tell your customers that it is an 
admin.ch issue, not something you can solve (unless you disable dnssec 
validation for admin.ch, which is an option, but kinda against dnssec).

(Fortunately it is not tax time or something like that)


For folks working at admin.ch: I offer myself pro bono to help out 
resolving the issue, don't hesitate to reach out (email or contact 
details on my homepage).


We can then replicate a stable environment as described in:

https://jeroen.massar.ch/presentations/vid/SwiNOG35-Managing_sleep_with_a_resilient_infrastructure/

or otherwise likely improve the situation to avoid such outages.

Good luck folks at admin.ch in resolving this..

Greets,
  Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] ##### SwiNOG#36 - Travel Info #####

[Jeroen Massar]

On 2019-11-12 21:51, Simon Ryf wrote:

Dear SwiNOG Community,

Please find general information about the SwiNOG #36 meeting below.

https://www.swinog.ch/meetings/swinog36/

Date: 14.10.2018 - Registration 08h15 - 09h15


Back to the future!

I can only assume 14.11.2019 aka 'tomorrow' (thursday).

Greets,
 Jeroen
  (eating fresh homemade spanish croquetas de jamon serrano[1], thus 
won't be bothering anybody there ;)


[1] 
https://spanishsabores.com/2011/10/12/croquetas-de-jamon-serrano-recipe-ham-croquettes/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Decentralisation vs. centralisation [was: new project: DHCP Protect]

[Jeroen Massar]

On 2019-10-31 08:47, Gregor Riepl wrote:
> Addendum, a possible solution for better collaboration between privately
> hosted Git platforms could be something like this:
> https://github.com/forgefed/forgefed
> (also based on https://github.com/go-gitea/gitea/issues/184 )
 
You might want to look again what the bottom of Pascal's server shows as a 
version ;)

> It doesn't solve the issue tracking part, however.

One can allow people to open accounts on private instances.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Decentralisation vs. centralisation [was: new project: DHCP Protect]

[Jeroen Massar]

On 2019-10-31 08:27, Gregor Riepl wrote:

Git repo is only part of that solution.

The primary reason for difficulty switching to another 'git host' (gitlab,
github, https://git.sr.ht/, or self hosted) is issue tracking...


That is true, but it's also not something that is essential or needs to live
on Github. I've seen projects that direct users to Launchpad for issue
tracking, but accept PRs on Github, for example.

In the worst case, you will lose issue discussions, but you will never lose
the code.


Launchpad is just another centralization, you just moved your problem there.

And really, a single interface for code insight and review is really handy.




And that is why projects on Github won't leave github easily.


Sure, but do they need to?


They need to be in a place where people can contribute and where code 
does not go missing.




I thought it was simply ridiculous when projects left for gitlab.com after
Microsoft acquired Github. Admittedly, Gitlab is better software, but I don't
think this played a big part.


Is it really 'better'? Also politically they are under fire...

Everything has pro/cons there, and they are all centralized platforms.

Check the Subject line ;)


If the project maintainers really cared about not being hosted by one of the
biggest data empires on the planet, they should have moved away from
proprietary services altogether. But that would have reduced visibility and
ease of use for contributors.


You mentioned launchpad (more an Ubuntu thing), Debian has self-hosted 
Gitlab, and many projects have their own instances of repo.


Pick what you want to maintain and works for you but remember those 
backups / private copies...




Of course, this could partially be solved with better commit messages, but who
has time for that eh ;)


Well, you should consider writing these anyway. Just like good code comments.
Think about much easier it will be to understand your own code after 2 years. ;)


I do so... others will not.


   (who mirrors his projects on github, but has a private original of the repo
self hosted; issue tracking thus is public and private...).


I think this is the best of both worlds.


It is a balance, not every programmer is willing to afford that amount 
of effort...



Many programmers are not sysadmins, or network folks and some claim 
to be 'devops', but that is just using a git-style tool to track 
changes, they are not programmers and sysadmins at the same time either.


([1] Defining programmer as somebody who can crank out a fully working 
system, not a few scripts or modification, as the distinction there).


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Decentralisation vs. centralisation [was: new project: DHCP Protect]

[Jeroen Massar]

On 2019-10-30 22:09, Gregor Riepl wrote:

Gregor, if I understand you correctly, you are implicitly saying "please
put your stuff on one of the big sites like github/gitlab/bitbucket".

I personally think that this is the wrong direction to move, as it
makes the Internet more dependent on a few entities. That makes it less
robust, as we have seen in the censorship case at github related to nationality.


IMHO, this does not apply to Git repositories.


Git repo is only part of that solution.

The primary reason for difficulty switching to another 'git host' 
(gitlab, github, https://git.sr.ht/, or self hosted) is issue tracking...


As those issues are not stored/tracked in the .git repo you can clone, 
and thus 'taking out' or 'moving' that data is near impossible.


And that is why projects on Github won't leave github easily.


Yes, some of the platforms have 'import' scripts to tackle this, but it 
is not a universal given that one can export/import these issues.


And issues can contain a lot of data about a project (discussion about a 
bug, why it was solved, why not etc).


Of course, this could partially be solved with better commit messages, 
but who has time for that eh ;)


Greets,
 Jeroen
  (who mirrors his projects on github, but has a private original of 
the repo self hosted; issue tracking thus is public and private...).



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem

[Jeroen Massar]

So instead of waiting for all that and never fixing a known issue:

They could just take a little Linux box with nginx (which is F5 now ... 
funnily), assign the IPv6 address to that and proxy with that. Voila. Solved.

No need to have a load balancer for that as I doubt that sbb.ch gets more than 
a few 100mbit in IPv6 traffic. And as it is broken today, it is not like they 
are losing redundancy.

> The F5 box has a bug, something with the checksum goes wrong and the F5 
> discards the ICMP packet.

As noted in previous comments that is standard ICMPv6 PtB handling.

See https://blog.cloudflare.com/path-mtu-discovery-in-practice/ and many other 
similar explanations.

Greets,
 Jeroen

--


On 2019-03-12 12:03, Silvia Hagen wrote:
> Hi guys
> 
> Here's some info from SBB (I was working with them and just spoke with them 
> today). 
> 
> . They are aware of the problem.
> . The problem only happens when someone uses smaller packet sizes (often when 
> using some tunnelling techniques).  
> . Currently the webserver is in an IPv4 zone, the Internet router is a Cisco 
> box which does 64 Translation. The packets go through an F5 LB to reach the 
> webserver.
> . When the packets go out and the Cisco box asks for fragmention, it sends 
> the ICMP packet to the webserver. The F5 box has a bug, something with the 
> checksum goes wrong and the F5 discards the ICMP packet.
> . They have had a neverending incident with F5 and F5 does not seem to be 
> able to fix that. SBB has given up on this incident.
> 
> The plan:
> . SBB is currently enabling IPv6 on the routing layer, plan to be 
> accomplished by summer 2019. 
> . Next step on the plan is to enable v6 out to the datacenter, with priority 
> on the webserver zone. So with that the problems should go away.
> 
> SBB was attending the last swinog event in Switzerland. They will also come 
> again and they offered to have a talk if desired. I can connect to the right 
> person if you are interested.
> 
> Thanks, Silvia
>  
> 
> -Ursprüngliche Nachricht-
> Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] 
> Im Auftrag von Nico Schottelius
> Gesendet: Dienstag, 12. März 2019 10:33
> An: swinog@lists.swinog.ch
> Betreff: [swinog] SBB.ch / IPv6 MTU / fragmentation problem
> 
> 
> Good morning,
> 
> is anyone from sbb.ch reading here?
> 
> https://sbb.ch does not load on IPv6 for us.
> It seems that packets > 1420 bytes are dropped inside the SBB network,
> 
> Local PMTU / fragmentation seems to work, my local outgoing MTU is 1420. MTR 
> below.
> 
> Best,
> 
> Nico
> 
> 
> [10:23] line:~% mtr -w -c1 -s 1500 sbb.ch
> Start: 2019-03-12T10:24:17+0100
> HOST: lineLoss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 2a0a:e5c1:111:111::420.0% 1   11.2  11.2  11.2  11.2   0.0
>   2.|-- ??? 100.0 10.0   0.0   0.0   0.0   0.0
>   3.|-- 2a0a:e5c0:2:12::70.0% 1   69.8  69.8  69.8  69.8   0.0
>   4.|-- 2a0a:e5c0:1:1::9 0.0% 1   74.3  74.3  74.3  74.3   0.0
>   5.|-- 2001:1620:20e6::10.0% 1   69.4  69.4  69.4  69.4   0.0
>   6.|-- r1zrh2.core.init7.net0.0% 1   69.1  69.1  69.1  69.1   0.0
>   7.|-- r1olt2.core.init7.net0.0% 1   58.0  58.0  58.0  58.0   0.0
>   8.|-- r1brn1.core.init7.net0.0% 1   62.8  62.8  62.8  62.8   0.0
>   9.|-- r2brn1.core.init7.net0.0% 1   65.4  65.4  65.4  65.4   0.0
>  10.|-- r1epe1.core.init7.net0.0% 1   75.2  75.2  75.2  75.2   0.0
>  11.|-- r1qls1.core.init7.net0.0% 1   78.4  78.4  78.4  78.4   0.0
>  12.|-- r1gva3.core.init7.net0.0% 1   81.0  81.0  81.0  81.0   0.0
>  13.|-- gw-sunrise.init7.net 0.0% 1   64.4  64.4  64.4  64.4   0.0
>  14.|-- 2001:1700:1:7:120::2 0.0% 1   84.4  84.4  84.4  84.4   0.0
>  15.|-- 2001:1700:4d00:2::2  0.0% 1   81.3  81.3  81.3  81.3   0.0
>  16.|-- 2a00:4bc0::ff00::1d  0.0% 1   67.0  67.0  67.0  67.0   0.0
>  17.|-- ??? 100.0 10.0   0.0   0.0   0.0   0.0
> [10:24] line:~% mtr -w -c1 -s 1400 sbb.ch
> Start: 2019-03-12T10:24:35+0100
> HOST: line   Loss%   Snt   Last   Avg  Best  Wrst 
> StDev
>   1.|-- 2a0a:e5c1:111:111::42   0.0% 13.2   3.2   3.2   3.2   
> 0.0
>   2.|-- 2a0a:e5c1:100::10.0% 1   69.0  69.0  69.0  69.0   
> 0.0
>   3.|-- 2a0a:e5c0:2:12::7   0.0% 1   74.7  74.7  74.7  74.7   
> 0.0
>   4.|-- 2a0a:e5c0:1:1::90.0% 1   69.9  69.9  69.9  69.9   
> 0.0
>   5.|-- 2001:1620:20e6::1   0.0% 1   60.5  60.5  60.5  60.5   
> 0.0
>   6.|-- r1zrh2.core.init7.net   0.0% 1   75.3  75.3  75.3  75.3   
> 0.0
>   7.|-- r1olt2.core.init7.net   0.0% 1   70.7  70.7  70.7  70.7   
> 0.0
>   8.|-- r1brn1.core.init7.net   0.0% 1   69.1  69.1  69.1  69.1   
> 0.0
>   9.|-- r2brn1.core.init7.net   0.0% 1   54.6  54.6  54.6  54.6   

Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem

[Jeroen Massar]

On 2019-03-12 11:17, Alarig Le Lay wrote:
> Hi,
> 
> I’m not from sbb, but it seems to work from here:

try a tracepath6, you likely have a 1500 MTUand yeah then it "works", not when 
PtB gets involved though.

ICMPv6 (and other packets, 40% on one hop), are obviously being dropped...

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem

[Jeroen Massar]

On 2019-03-12 10:32, Nico Schottelius wrote:
> 
> Good morning,
> 
> is anyone from sbb.ch reading here?
> 
> https://sbb.ch does not load on IPv6 for us.
> It seems that packets > 1420 bytes are dropped inside the SBB network,
> 
> Local PMTU / fragmentation seems to work, my local outgoing
> MTU is 1420. MTR below.

Has been that way for years already.

Long live load balancers & firewalls and people who run them and do not know 
what they are or how they work.

Don't worry. Google had the same problem for a while and it took them a month 
or two to realize what the problem was and so did Cloudflare, at least the 
latter wrote it up so that other people can start getting the problem:

https://blog.cloudflare.com/increasing-ipv6-mtu/

Thus, folks, please read and start fixing your setups... ICMPv6 is required in 
IPv6 and when you do any kind of load balancing, do honor PTBs...

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] mail.protection.outlook.com - dns issues?

[Jeroen Massar]

On 2019-01-11 13:26, Tobias Goeller wrote:

Hi All,

Anyone else having problems with customers using mail.protection.outlook.com or 
spf.protection.outlook.com in their SPF Records?

Just asking (both records seem to be not resolvable at the moment...)


$ dig +short spf.protection.outlook.com txt
"v=spf1 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 
ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 
ip4:213.199.180.128/26 ip4:52.100.0.0/14 
include:spfa.protection.outlook.com -all"


Looks fine to me...


As for the other, you are supposed to use:

"The MX record for a domain that's enrolled in Exchange Online uses the 
syntax .mail.protection.outlook.com."


See:
https://support.office.com/en-us/article/fix-email-delivery-issues-for-error-code-550-5-4-1-in-office-365-7dcf7a8b-e00e-49f8-bf8d-74aba79c5a6a

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] *** Save the Date - SwiNOG#35 08.05.2019 ***

[Jeroen Massar]

As per twitter https://twitter.com/i/web/status/1057297710305435648
"See you on May 8th 2019 for #SwINOG35!"

That is teh answ3r! May the 8th be with us!

Greets,
 Jeroen


On 2018-11-04 22:01, Jeroen Massar wrote:



On 2018-11-04 21:48, Simon Ryf wrote:

Dear SwiNOG’ers

Save the Date ! Put it in your Calendar - NOW :)

*Wednesday May 5^th 2019*is SwiNOG #35


May the 5th be with us, as that is a Sunday, not a Wednesday!? :)

Which is the real date we need to put in our calendars?

Greets,
  Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] *** Save the Date - SwiNOG#35 08.05.2019 ***

[Jeroen Massar]

On 2018-11-04 21:48, Simon Ryf wrote:

Dear SwiNOG’ers

Save the Date ! Put it in your Calendar - NOW :)

*Wednesday May 5^th 2019*is SwiNOG #35


May the 5th be with us, as that is a Sunday, not a Wednesday!? :)

Which is the real date we need to put in our calendars?

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] QNAME minimization (Was: Quad9 "does not collect", but .... it does....)

[Jeroen Massar]

On 2018-11-01 21:53, Rainer Duffner wrote:

Am 01.11.2018 um 21:26 schrieb Jeroen Massar :
TLDR:


On a related note:

Does anyone run a resolver with QNAME-minimization enabled?

Any problems, common or specific to certain domains?


At least everybody running unbound is (as it is the default) and unbound 
is very often deployed in high-speed recursor situations.


Do note that unbound has a not-default-on strict mode. That means in 
non-strict mode (default) it will retry when failures happen. (As such, 
a MITM/bad-authoritive could introduce a failure to learn more)


The config option reads and explains reasonably well:
--
   qname-minimisation-strict: 
  QNAME  minimisation  in strict mode. Do not fall-back to 
sending
  full QNAME to potentially broken nameservers. A lot  of  
domains
  will  not be resolvable when this option in enabled. Only 
use if
  you know what you are doing.  This option only has  effect 
 when

  qname-minimisation is enabled. Default is off.


Exact details are in the archives of the unbound mailing list...

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Quad9 -- mostly constructive comments (Was: Google DNS on Salt Mobile)

[Jeroen Massar]

On 2018-11-01 09:18, Bill Woodcock wrote:
[..]

No, that’s false.  Please read RFCs 7816 and 7871.  Quad9 implements
the former and not the latter


And because of the latter instead of going to the local ISP netflix 
cache one might go to the country-level cache or because it does not 
know better to the continental cache. GeoDNS goes rather bad when the 
source address is odd.
Next to the problem of load-balancing or traffic engineering that the 
sending party is trying to fix by doing those tricks in the first place.



Hence, supporting ENDS-Client-Subnet (stripping at minimum to BGP or /24 
or /48 subnet) would be a good thing.
If it is not considered a good thing, a little note on the site why not 
would go a long way.




Again, if, after acquainting yourself with Quad9’s practices and the
relevant RFCs, you see any way in which Quad9 could provide better
privacy or security protections to users, they would VERY MUCH LIKE
YOUR CONSTRUCTIVE INPUT, as that’s the entire point.  It’s an open and
transparent community project, to serve the community.



- Please put on the quad9 website a _versioned_ "policy" and "privacy" 
page, thus that one can also see the previous editions. That would be 
good transparency.
- align https://quad9.net/about/ with them, as "policy" does not mention 
"no other secondary revenue streams for personally-identifiable data" 
which is a 'good' sentence, but needs repeating there too.
- Create a minimal version of those; 99% of the people do not bother 
reading them at all, let alone when too long.


- Provide a /technical/ details page:
 - what software is used (e.g "we run bind4 custom patched by vix 
himself") and when possible point to Open Source to recognize their 
efforts (one does run multiple different resolver types to avoid any 
bugs I hope ;)

 - what actual RFCs/techniques are (not) used
   - why for instance RFC7871 is chosen not be to be supported
   - that DNSSEC is supported and that validation is active

 - list of providers of 'malicious domains' and who randomly 
samples/verifies that list (otherwise: who censors it)
   "Quad9 checks the site against a list of domains combined from 19 
different threat intelligence partners."
   does one hit in a list block the domain, or do N lists (RPZ?) need to 
blacklist it?
   (RPZ does not have spamassassin-like scoring, asked for that option 
once though, but it is hard to do ;)


Technical details (even though not verifiable as one does not have 
access to the infra) would be a great thing.




Some other not-so-constructive comments (I snipped around those sections 
of the mail):


- Remove refs to "not-for-profit" as that just means that all the money 
goes into the business instead of paying taxes...
- "The three primary founding collaborators for the project have goals 
that are similar.", I can only assume that Big Blue is not a founding 
collaborator then... but the logos tell differently.



in order to minimize the leakage of
data from end-user to authoritative server.  Moreover, that’s only an
issue with zones for which PCH is not authoritative.  For all those
for which PCH is authoritative, no queries pass “through” to anywhere
else.


(I can only assume that you mean "9.9.9.9 recursor sits on the same 
net/vlan/switch as the PCH auth, thus it never leaks ;)


Integrity is a bigger issue and there are many examples where it is 
actively

being violated - this is at least partially addressed by DNSSEC.


Which is why Quad9 was the first global anycast resolver to implement
DNSSEC validation, and why PCH is the only DNSSEC operator besides
ICANN to implement FIPS 140-2 Level 4 security.


"global anycast resolver". That is a DNS recursor that is 'open for the 
world' right? :)




Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Quad9 "does not collect", but .... it does.... (Was: Google DNS on Salt Mobile)

[Jeroen Massar]

TLDR:
 - https://quad9.net/policy/ and https://quad9.net/privacy/ are the 
multiple pages of legalese

- it is a long text, not actually mentioning any actual technology
- nobody using 9.9.9.9 will read it as they are using an IP, not a 
website with text
- it can change whenever, there are no versions, there is no history 
of what changed (archive.org possibly)
- for a variety of reasons IP (and thus PII) might be gathered 
anyway
- IP prefixes are summarized, but unknown till which size (IPv6 
/48?)
- Undefined what happens with packets towards 9.9.9.9 (is somebody 
doing PDNS, or otherwise grabbing bits?)
- Nothing mentioned about RFC7871 (EDNS Client Subnet) which is 
required for helping CDNs/Geo-DNS...

more inline ;)


Oh and for the record: Woody, you are not the "problem" here, the 
companies around Quad9 though, they have a commercial interest in the 
data... somebody has to pay for it, and that can mostly only be solved 
with the personal data collection nothing is for free in the end and 
bills (and woody's :) have to be paid.



On 2018-11-01 06:24, Bill Woodcock wrote:

On Oct 29, 2018, at 11:38 PM, Jeroen Massar  wrote:

[snip]

How can something be "GDPR compliant" when no consent is given at all?


By not collecting any PII.


That is indeed a great start, what one does not have, one cannot abuse.


Have you layered HTTP on top of DNS to provide a 20-pager of legalise 
that nobody can be bothered to read as it will change at a moment's 
notice?


No.

Stating "it doesn’t collect source IP addresses" means "but we collect 
everything else”.


That’s an obviously false statement, and doesn’t usefully contribute
to the conversation.



Strange as https://quad9.net/privacy/ reads:

"We share anonymized data on specific domains (such as domain, 
timestamp, geolocation, number of hits, first seen, last seen) with our 
threat intelligence partners."


That says "Domains" and possibly labels.
It also says "geolocation" which is derived from an IP, which can be 
wildly wrong but also extremely specific...



It is not specified at all what is actually really collected. It would 
be great to have a list, or a log example or heck the tool (as it is 
likely open source...) of what is actually logged/collected/"shared with 
partners".




But more importantly, for us 'geeky people' who run our own domains, 
that domain identifies an individual and thus a domain in effect points 
to PII. while 'gmail' is general, 'massar.ch' is not so general any 
more...




Next to that labels can include IP addresses (e.g. 1.2.3.4.in-addr.arpa, 
but also the forward 4-3-2-1.dsl.isp.example) Noting that these are 
looked up by every SMTP server on the planet.


Are you saying you are dropping these labels? As otherwise, you are 
collecting PII.



https://quad9.net/policy/ reads:

"This policy may be amended by Quad9, and the new version of the policy 
shall become effective upon its posting "


so, as it is not versioned, and previous versions are not available, 
that 'policy' can be changed any time.


Today it might look okay, tomorrow, it will not, and then 9.9.9.9 is 
hardcoded like 8.8.8.8 and nobody gave consent on the change in policy.



Lets look a bit deeper:
"When you use Quad9 DNS Services, the information we gather aides us to 
personalize, improve and operate our infrastructure. "


Personalize? So, as in, P(ersonaliz)eII , how does one "personalize" 
when you claim to not collect Personal Information?


"Our normal course of data management does not have any IP address 
information or other PII logged to disk or transmitted out of the 
location in which the query was received."


What is the "not-normal course"? When is that applied? What happens 
then?



Did you note the 20 pages of legalese I mentioned, indeed, there is 
about that amount on those pages. Would be cool to have a bullet list of 
what is collected...


"We may aggregate certain counters to larger network block levels for 
statistical collection purposes"


So, you keep addresses, but at "block" level. For IPv6, is that on /64, 
/56 or /48? And for IPv4 /31? ... would be great to specify otherwise 
that is a meaningless statement.


"observed behaviors which we deem malicious or anomalous"

Is "trying to resolve a malware URL" considered "malicious"? would be 
great to specify this.
(I guess what I know what is written, but hey, it is a policy, thus 
legalese and thus, needs to be specific).



"We do keep some generalized location information (at the 
city/metropolitan area level) so that we can conduct debugging and 
analyze abuse phenomena."


Are you saying that certain "cities" have more abuse than others!? :)

Look, just state that for debugging, IP addresses will be seen, nobody 
minds t

Re: [swinog] Announcing mirror.init7.net

[Jeroen Massar]

On 2018-10-30 10:19, Fredy Kuenzler wrote:

As SWITCH has announced the sunset of http://mirror.switch.ch/ a while
ago we are happy to announce a successor mirror.init7.net.

https://mirror.init7.net


Awesome Freddy, thanks!


And of course, also a big thanks to SWITCH for hosting the original for 
years!


Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Google DNS on Salt Mobile

[Jeroen Massar]

On 2018-10-30 00:25, Bill Woodcock wrote:

On Oct 29, 2018, at 1:16 AM, Gregor Riepl  wrote:
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with 
Google DNS

servers (8.8.8.8 8.8.4.4).
I'd rather not send all my DNS requests to Google.
Perhaps it's time to switch to private resolvers everywhere, if not 
even ISPs

are providing that service any more…


For what it’s worth, there’s a Quad9 server cluster in Zurich, and
unlike Google, Quad9 is GDPR-compliant.  As someone will certainly
point out, it’s also subject to US law, but is a public-benefit
not-for-profit corporation, and US law doesn’t compel an organization
to turn over data which isn’t collected in the first place.  And Quad9
is GDPR-compliant because it doesn’t collect source IP addresses in
the first place.


How can something be "GDPR compliant" when no consent is given at all? 
(or have you layered HTTP on top of DNS to provide a 20-pager of 
legalise that nobody can be bothered to read as it will change at a 
moment's notice?).


Stating "it doesn’t collect source IP addresses" means "but we collect 
everything else". Likely doing Passive DNS style things at minimum.



IP addresses, especially sources, sometimes also appear in the label, 
simply because some weird CDNs/ISPs will encode the source IP for 
'geo-dns' or 'loadbalancing' reasons in the label. Are you stripping 
those?


And then there are RBLs, and reverse-IPs in general. Do you filter 
those? or do you track those IP Addresses anyway, as that exposes the 
other side of the connection



There are many reasons why so many of the public DNS resolvers popped 
up: one of them is the amount of data that can be extracted from it.


Even if it is just the weird domains people look at (and then crawl 
those, as they where not known yet), or statistics like "in that ASN 
people look at Netflix, but less at Youtube".



Please stop centralizing this Internet thing

Greets,
 Jeroen



And yes, we recommend anyone who has the capacity to do so run their
own resolver rather than using _any_ external resolver.  Something
like 95% of Quad9’s users are behind their own caching resolvers.

-Bill



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] are you also seeing more ssh attacks ?

[Jeroen Massar]

On 2018-07-02 12:25, Manuel Schweizer wrote:
> Hey Tobi
> 
> Not seeing what you are seeing, but I can really recommend Fail2Ban if you 
> are not using it already.
[..]
> Failed attempts will now be logged and source IPs will be banned after 
> several failed attempts.

Which is quite useless with the distributed scanners that exist have
existed for the last few years.

A single IP will only hit you a few times... typically below the
threshold of standard fail2ban or other alarm bells.
The distributed scanner will keep on trying by using another IP from
their vast botnet...


The big question: Why is that SSH port open to the world ? :)

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] are you also seeing more ssh attacks ?

[Jeroen Massar]

On 2018-07-02 11:25, Tobias Oetiker wrote:
> Good Morning
> 
> are you running an ssh daemon on non standard ports to avoid some of the
> drive-by-scanning ? we have been doing that for quite some time now with
> great reduction of scanning noise ...

I suggest running SSH always behind white-list only firewalls.

That, and otherwise use a VPN to get in to a fixed-IP so that one is in
the whitelist.

Providing an 'open over IPv6 only', or "SSH via Tor" is also a
reasonable technique there.


If you have to run a jumpbox style host: For SSH, it is also heavily
suggested to disable any form of password-auth, that way, only public
key authentication is accepted and guess what the scanner scripts do not
support as they do not have a key which thus makes guessing impossible...

for OpenSSH:
UsePAM no
PasswordAuthentication no
ChallengeResponseAuthentication no

Do have working pubkeys on the box first :)


> since yesterday this has changed
> ... we are getting a lot of connection attempts  ... 
> 
> are you seeing this too ? is someone actively looking for ssh across the
> whole port range or is this 'personal' ?

There are more and more "Internet scanning" services, especially since
people realized the amount of data that Shodan shows, every company is
having their own scanning boxes.

Next to that of course, there are thousands of kiddies running the
default scripts just trying random username/passwords.

Whitelisting is the best trick in the toolchest.

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] GDPR / DSGVO and 'whois' domain data

[Jeroen Massar]

On 2018-07-02 09:45, Benoit Panizzon wrote:
[..]

> Also, such domains usually quite quickly get a bad reputation as hiding
> the whois data is something the 'bad guys' do. Also it becomes a bit
> more difficult, to verify if a domain is legit or not to decide upon
> well crafted phishing emails. Or to contact the owner in case of
> security incidents.

Bad guys just provide false data (and the privacy hiding things)

Hence, whois is mostly useless, even though that false data might be
able to correlate multiple domains (which is a feature that is lost now)


As RIPE is clearly demonstrating though, throwaway addresses and emails
are totally okay to have in RIPE whois



Currently "good guys" will publish one of these:
 https:///.well-known/security.txt

e.g.:
 https://www.google.com/.well-known/security.txt
 https://unfix.org/.well-known/security.txt
etc.

as per the _draft_:
 https://tools.ietf.org/html/draft-foudil-securitytxt-03
 https://github.com/securitytxt/security-txt
and (as usual)not everybody is happy with it:
 https://news.ycombinator.com/item?id=15416198

Many folks also publish it directly as /security.txt; I have a default
location in nginx to cover them and put it everywhere (with try_files
one can try to per-vhost edition and then fall back to a generic one).


.oO(Yes, the Internet is HTTPS now, everything else is futile...
new Internet users on the block do not know what whois is, let
alone what it was useful for; problem reports are automated
nowadays, few still actually read/act upon abuse@ or security@
addresses...)

[..]
> So I asked Gandi for how the GDPR exactly forces them to hide their
> customer's whois data. I haven't got a reply to this yet.

Nothing forces them to do so, they are just covering their behinds.

By blocking it they do not have to deal too much with GDPR, thus it is
the path of least difficulty (read: money).

[..]
> If I get the whois data for some well known domains like:
> 
> microsoft.com
> google.com
> swiss.com
> credit-suisse.com
> 
> NONE has 'privacy protect' activated.

None of those are private individuals.

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] PTR records with CNAME ?

[Jeroen Massar]

On 2018-05-31 17:55, Ralph Krämer wrote:
> Per,
> 
> I just want to throw in the following:
> 
> In case you want to subdelegate a part of a PTR zone, this seems to be the 
> recommended way to do it:
> 
> https://simpledns.com/kb/77/how-to-sub-delegate-a-reverse-zone
> 
> jeroen, any comment on this?

As per previous reply on this thread, the IETF way to do it is detailed in:
   https://www.ietf.org/rfc/rfc2317.txt

Anything that needs clarification there?

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] PTR records with CNAME ?

[Jeroen Massar]

On 2018-05-30 17:35, Per Jessen wrote:
> Jeroen Massar wrote:
> 
>> On 2018-05-30 16:44, Per Jessen wrote:
>>> According to RFC1034 and 2181, a PTR record using a CNAME is not
>>> permitted.  I believe this to still be correct, postfix certainly
>>> doesn't work with a CNAME when it does a reverse lookup.
>>
>> Postfix certainly does as:
>>
>> $ dig +short 50.131.144.213.in-addr.arpa. ptr
>> 50.63-28.131.144.213.in-addr.arpa.
>> citadel.ch.unfix.org.
>>
>> would otherwise not work and that trick of CNAME'ing in-addr.arpa
>> space is used a lot by ISPs to delegate space (as per the above
>> example where init7 forwards them to my nameservers).
>>
>> There is also a nice RFC on that:
>>  https://www.ietf.org/rfc/rfc2317.txt
> 
> Okay, thanks for clarifying that - I was wondering.  I don't why my
> postfixes come up with host name 'unknown'.

Where does postfix say 'unknown'? In the prepended "Received: from ..."
header? in logs?

Can be many reasons why it does not trust the originally provided data,
especially as HELO/EHLO can be spoofed. Also depends on the resolver etc
etc, many factors ;)

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] PTR records with CNAME ?

[Jeroen Massar]

On 2018-05-30 16:44, Per Jessen wrote:
> According to RFC1034 and 2181, a PTR record using a CNAME is not
> permitted.  I believe this to still be correct, postfix certainly
> doesn't work with a CNAME when it does a reverse lookup.  

Postfix certainly does as:

$ dig +short 50.131.144.213.in-addr.arpa. ptr
50.63-28.131.144.213.in-addr.arpa.
citadel.ch.unfix.org.

would otherwise not work and that trick of CNAME'ing in-addr.arpa
space is used a lot by ISPs to delegate space (as per the above example
where init7 forwards them to my nameservers).

There is also a nice RFC on that:

 https://www.ietf.org/rfc/rfc2317.txt

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Mail to CNAME a thing?

[Jeroen Massar]

On 2018-02-19 12:57, Markus Wild wrote:
> Hi there,
> 
> I've just come across a weird mail reception problem of some mails from 
> Microsoft. Our servers insist that
> a specified MAIL FROM address can be resolved correctly, and this usually 
> boils down to the following checks 
> on the domain-part of the email-address specified:
> - is there an MX? Does the target resolve using an A record (not a CNAME), 
> and does it resolve to a publically
>   reachable address (not RFC1918 or localhost etc)
> - if there is no MX, is there an A record that fulfils the same criteria as 
> the MX target above?

If you are anti-spam, don't bother checking this (dom.com A); anybody
who wants to receive mail will have an MX, if not, let them join the
2000s...

Also, instead of bothering with the MX Lookup, verify and enforce SPF,
DKIM and DMARC instead, they are meant for checking against the envelope
From, MXs are not. Non-existence of a MX on a domain does not mean it
does not get used for sending mail; thus you might have a small false
positive rate there... (which you might chose to accept, you are the
receiving end, hope you have an informative rejecting message ;) )

Spammers will make sure that MX, SPF, DKIM and DMARC are all configured
btw; they only really 'resolve' spoofing issues.

[..]
> - if none of these are true, the address is considered to be invalid and mail 
> is rejected

I assume you also allow '<>' for DSNs?



If you do the above, you might want to check for "MX .", this indicates
a domain that will never send mail as per RFC7505:

https://tools.ietf.org/html/rfc7505

I set that for every domain that I don't actually use for mail and quite
a few marketing hosters are pretty good at it too.

But again: MX is for _receiving_, not _sending_ (From) thus checking it
is a bit wrong, but at your prerogative.

Last note: do _not_ use 'host' for debugging DNS related issues, always
use the very useful 'dig' tool, or if you want use 'drill' instead.
('host' hides various error situations and does not properly show what
you are actually querying...)

Greets,
 Jeroen





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swinog-be?

[Jeroen Massar]

On 2017-07-06 09:26, Viktor Steinmann wrote:
> Guys... is there any news on this topic?

Over the years the ML is slowly pacing down, likely having to do with
merging companies and people getting more busy with their private lives.

But if you like beer... http://www.beerontuesday.ch/ ;)

Different place(s), different beers, minimally different people as they
are more 'security' oriented, but same goals: better networking, good
talk and... well beer and other drinks ;)

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Research project and survey: Network filtering and IP spoofing

[Jeroen Massar]

On 2017-03-01 23:49, Jeroen Massar wrote:
> On 2017-03-01 17:02, Franziska Lichtblau wrote:

[..]

Related paper:

http://www.caida.org/publications/papers/2017/using_loops_observed_traceroute/

Using Loops Observed in Traceroute to Infer the Ability to Spoof

8<---
Despite source IP address spoofing being a known vulnerability for at
least 25 years, and despite many efforts to shed light on the problem,
spoofing remains a popular attack method for redirection, amplification,
and anonymity. To defeat these attacks requires operators to ensure
their networks filter packets with spoofed source IP addresses, known as
source address validation (SAV), best deployed at the edge of the
network where traffic originates. In this paper, we present a new method
using routing loops appearing in traceroute data to infer inadequate SAV
at the transit provider edge, where a provider does not filter traffic
that should not have come from the customer. Our method does not require
a vantage point within the customer network. We present and validate an
algorithm that identifies at Internet scale which loops imply a lack of
ingress filtering by providers. We found 703 provider ASes that do not
implement ingress filtering on at least one of their links for 1,780
customer ASes. Most of these observations are unique compared to the
existing methods of the Spoofer and Open Resolver projects. By
increasing the visibility of the networks that allow spoofing, we aim to
strengthen the incentives for the adoption of SAV.
-->8

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Research project and survey: Network filtering and IP spoofing

[Jeroen Massar]

On 2017-03-01 17:02, Franziska Lichtblau wrote:
> On Wed, Mar 01, 2017 at 12:50:49PM +0100, Jeroen Massar wrote:
>> On 2017-03-01 11:59, Franziska Lichtblau wrote:
>> [..]
>>>> Oh, and indeed, Switzerland is a bad place for BCP38, most networks
>>>> allow spoofing on both IPv4 and IPv6.
>>>
>>> Which is "kinda good" for me cause only answers from people who are 
>>> implementing
>>> all of that won't help us much understanding whats going on ;) 
>>
>> That is not "kinda good" as it means that spoofing can happen easily and
>> those kind of attacks are much harder to trace than ones that do proper
>> full TCP (or heck UDP).
> 
> You got me wrong there. I didn't mean to say it's good that the possibility 
> for spoofing is out there. What I meant to convey was, that if I only speak
> to operators or regions where a ''perfect'' level of filtering is applied I 
> will not get meaningful insights about why it is not done everywhere and 
> how we can improve on that. 
> That's one of the biggest challenges - to actually talk to the people who are
> not doing as we all would want them to. 

The only place where a 'perfect level of filtering' is in place is Finland.

And that is because FICORA (their ~BAKOM) has made BCP38 mandatory in 2014:

https://www.viestintavirasto.fi/attachments/cert/tietoturvakatsaukset/Cyber_review_Q1_2014_EN.pdf

And they have good successes with it. Google for the many reports about
this by the great people from FICORA.

The rest of the world, you will not find a lot of BCP38 to the joy of
many many people who provide 'security services' (be that
booters/testers/etc or the ones selling protection against ddos)

>> But with this whole Mirai thing and hundreds of thousands of hosts being
>> compromised of end-sites or Wordpress/Joomla/etc on servers with proper
>> upstream connectivity, it really does not matter, as spoofing is not
>> even really needed to properly DDoS any network, unless we are talking
>> about distributed or properly anycasted networks.
> 
> That is completely true. But that's a completely different problem (which I 
> used
> to work on very superficially). One that I'd actually like to see fixed, but 
> I'm
> not sure what a research perspective (which is the one I can offer) can help
> there. I'm totally open to suggestions. 

Research unfortunately won't solve BCP38 deployment either.

Regulatory enforcement like in Finland seems to be the only way.

Like IPv6, as long as there is no real business interest -- read: money
can be made from it nothing will happen. (the eyeball networks getting
ddossed of the net by bots on their own network for instance would make
a business interest, again *not a hint* ;) )

>> Eyeball networks though are both the source of many problems and when
>> miscreants figure out they can take down an eyeball network (which
>> cannot be protected with tricks like anycast and throwing more resources
>> at it, as pipe full == pipe full... *not a hint* ;) ) and ransom those
>> networks, lots of fun will happen.
> 
> There are things you can not not think once you've thought about them once ;) 
> I agree - there's lots of potential fun out there 
> 
>> The fun part is then also that those networks will just not work, they
>> will also get overloaded call centers which is amazing from a money
>> perspective thus it will do a lot of damage.
>>
>> But maybe then those eyeball networks finally will start taking action
>> in cleaning up their userbase, thus IMHO, it can't happen early enough
>> as then we finally will have a proper Internet where that nonsense gets
>> taken care of instead of just ignored...
> 
> The problem is always, that people need incentives - there's a good amount
> of people that you can get with the global idea of a well working community...

That does not make a business incentive aka earning money though.

> but sadly not all of them. That's one of the reasons why we ask what are the
> incentives of people who try to keep their network clean and now we can
> lower the bars for those who are not yet there. 

Make a business case and then convince the management of ISPs about the
risk of the Mirai hosts (and many others) in their network.

Because of Mirai existing though, BCP38 would not do anything to stop
that, thus you'll have to find a better example botnet that actually
spoofs. As long as Mirai and friends exist, spoofing is not needed and
thus BCP38 only solves a little bit of a puzzle unfortunately.


As I note above: Regulatory requirement are likely the only way.

Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Research project and survey: Network filtering and IP spoofing

[Jeroen Massar]

On 2017-03-01 11:59, Franziska Lichtblau wrote:
[..]
>> Oh, and indeed, Switzerland is a bad place for BCP38, most networks
>> allow spoofing on both IPv4 and IPv6.
> 
> Which is "kinda good" for me cause only answers from people who are 
> implementing
> all of that won't help us much understanding whats going on ;) 

That is not "kinda good" as it means that spoofing can happen easily and
those kind of attacks are much harder to trace than ones that do proper
full TCP (or heck UDP).

But with this whole Mirai thing and hundreds of thousands of hosts being
compromised of end-sites or Wordpress/Joomla/etc on servers with proper
upstream connectivity, it really does not matter, as spoofing is not
even really needed to properly DDoS any network, unless we are talking
about distributed or properly anycasted networks.

Eyeball networks though are both the source of many problems and when
miscreants figure out they can take down an eyeball network (which
cannot be protected with tricks like anycast and throwing more resources
at it, as pipe full == pipe full... *not a hint* ;) ) and ransom those
networks, lots of fun will happen.

The fun part is then also that those networks will just not work, they
will also get overloaded call centers which is amazing from a money
perspective thus it will do a lot of damage.

But maybe then those eyeball networks finally will start taking action
in cleaning up their userbase, thus IMHO, it can't happen early enough
as then we finally will have a proper Internet where that nonsense gets
taken care of instead of just ignored...

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Research project and survey: Network filtering and IP spoofing

[Jeroen Massar]

On 2017-03-01 09:58, Franziska Lichtblau wrote:
> Hi,
> 
> we are a team of researchers from TU Berlin [1] working on a measurement 
> project
> to assess the ramifications of traffic with spoofed source IP addresses in 
> the 
> Internet.
> 
> To better understand the operational challenges that you as network operators
> face when deploying (or not deploying) source IP address filtering techniques,
> we'd like to invite you to participate in our survey.
> 
> If you could spare 5 minutes of your time, we'd be delighted if you could fill
> out our survey form and tell us about your current practices regarding network
> filtering.
> 
> To participate, please visit:
> [2] http://filteringsurvey.inet.tu-berlin.de/

You are missing the option for:

 "hardware does not support it at line rate"

Which is the most important excuse by the larger networks to not enable
BCP38/SAVE[1]/MANRS[2].

Most smaller shops, where the traffic conditions fit inside the hardware
budget, just do not care enough unfortunately...

Oh, and indeed, Switzerland is a bad place for BCP38, most networks
allow spoofing on both IPv4 and IPv6.

Greets,
 Jeroen

[1] http://www.redbarn.org/internet/save
[2] http://www.routingmanifesto.org/manrs/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Zurich SwiNOG Beering 2017, dates, agenda, suggestions

[Jeroen Massar]

On 2016-12-20 16:49, Viktor Steinmann wrote:
> On 20.12.2016 15:37, Gregor Riepl wrote:
>> How about Bern, Lausanne, Basel, St. Gallen, or somewhere else once in
>> a while?
> 
> The original idea of the beer event was, to meet with a smaller group of
> geeks more often than during the "official" SwiNOG meetings, locally. We
> started our "chapter" in Zurich, because that's where I worked at the
> time (I'm the founder of this event, together with Steven Glogger).
> 
> There have been some Beer Events in Geneva as well iirc and maybe even
> in Berne? Please continue that if the need is there!

There is also: http://www.beerontuesday.ch/

Slightly different audience (defcon switzerland / bsides zurich /
"infosec" etc) but related to keeping the Internet save and useable :)

Runs on Tuesdays in a variety of places. Effectively: 1st tuesday =
bern, 2nd = zurich, 3rd = Geneva, 4th = Lucerne, 5th = Lausanne.

Website has all the details; I am just pimping that event, contact the
folks from Defcon Switzerland for more exact details etc...

Have a good new year folks!

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Is hinting the authorities or CERT team about a customer willingly distributing malware legal?

[Jeroen Massar]

[ Dear awesome folks from MELANI: Please present on this subject "being
a good netizen" / "What to report to MELANI" at next SWINOG :) ]

On 2016-12-16 08:44, Benoit Panizzon wrote:
[..]
> But what can the hoster/registrar do next? Can he contact his
> government's CERT team or the authorities and hand them over the
> customer data, ip addresses used to upload the site etc. to try to get
> hold of the gang behind that fraud as quickly as possible? Or would that
> break the privacy laws and they have to wait to get a subpoena, which
> could take several weeks and give the gang enough time to clear all
> traces?

Awesome question, better to ask beforehand than after ;)

Below all with IMHO and IANAL or working for MELANI etc.


Reporting to CERT/authorities (read for Switzerland _calling_ MELANI)
that you have in you network such an instance is a the required thing to
do if one is a a good netizen (and we all are on SwiNOG :) ).

Inform them that you have noticed suspicious XYZ and that you want them
to look at it.

They'll likely ask for a variety of things, at which point authorities
are asking you to release data about your network:
 - IP address(es)
 - hostnames / domaines
 - date stamps (UTC, NTP synced)
 - Netflow/IPFIX/sFlow logs

*Flow is a standard 'accounting' procedure, thus having it, is there to
account but also to provide logging. Of course make sure there is a
little blurb in whatever EULA that you can change every day.

At one point they'll ask for customer details, at which point, if they
claim they are allowed to do so, you could.


Thus: informing of the event is great; I assume that directly sharing
the IP/hostname is a standard detail nowadays (all the abuse trackers
and other mitigation things do so) might even be considered 'legal'

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] blackhole-1.iana.org : no servers could be reached

[Jeroen Massar]

On 2016-10-27 20:13, Christian Fahrni wrote:
> Hi Julien
> 
> Yes, we are experiencing the same issues recently with ptr-requests
> forwarded to the iana blackhole nameservers.
> 
> # dig -x 10.0.0.100 @blackhole-1.iana.org

Traceroute? :)

Those nodes are anycasted. See previous answer or google AS112.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] blackhole-1.iana.org : no servers could be reached

[Jeroen Massar]

On 2016-10-27 16:13, m...@mbuf.net wrote:
> Hi,
> are there some people experiencing issues on some AS when using
> iana blackhole nameservers for localnets?

That is a AS112 project (https://www.as112.net/) which is heavily anycasted.

You really want to do a traceroute for that destination.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] DDOS >1Tbps - Swiss-wide (regional) BGP propagation?!

[Jeroen Massar]

On 2016-10-02 05:27, Rabbi Rob Thomas wrote:
> Dear team,
> 
>> Since we see >1Tbps DDOS attacs in the wild, I suppose
>> out-of-the-box DDOS mitigation suppliers have lost this race. There
>> is no operator in Switzerland which can handle 1Tbps DDOS attacks.
> 
>> When we saw DDOS against digitec.ch and others earlier this year, I
>> was a bit surprised that none of the so called "experts" proposed
>> regional BGP propagation as a remedy.
> 
> May I offer up UTRS as a model or perhaps part of your solution?
> 
> 

Good one.

Lets see if the SwiNOG #30 PC gives a slot for this discussion, then
we'll include it in the slidedeck and conversation.

Unless somebody from TC is hopping over, I'll use the details on:
 https://www.cymru.com/jtk/misc/utrs.html
as input. Pointing out that TC is of course the one who runs UTRS :)

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] DDOS >1Tbps - Swiss-wide (regional) BGP propagation?!

[Jeroen Massar]

On 2016-10-01 20:24, Patrick Albrecht wrote:
> Hi
> 
> I'm a employee of a good known E-Commerce site here in switzerland and I
> would like to share some thoughts from my side if that's okay for all. I
> hope I understood well enough what you plan. Otherwise just ignore what
> I just wrote :)
>> Given that e-commerce such as digitec.ch is assumingly making 99.9% of
>> the revenue within Switzerland, their prefix doesn't need to reachable
>> from all over the world.
>
> That's correct, the /customer/ doesn't need to the reach the website
> from outsite switzerland normaly. But there're many 3rd-Party Provider
> for Newsletter, Monitoring etc. and distributors that need to be able to
> resolve digitec.ch outside of switzerland for example.

"resolve" implies DNS.

Peering is about BGP.

> (because there server are not located in switzerland) Mostly it's dispensable 
> if they
> can't reach the website or a ftp server for some minutes, but if they
> can't access the page for days the E-Commerce Site will have issue with
> orders, product availability, newsletter shipping etc. Also some
> 3rd-Party Scripts may use a dns lookup and would fail then.

You need to see that 'limited announce of prefix' would only happen in
the case of a DDoS, this, so that local sites / direct peers can reach
it, but it is 'dead' over transit, thus cutting off most DDoS traffic
that comes from strange countries (not .ch).

As for those external companies, if you are worried about them failing:
peer directly with them, setup a VPN or: move your stuff more local
where you have control.

Also, do realize that providing Swiss customer data to a foreign entity
might break various privacy regulations do ask your legal team and
of course inform your customers.

> There's also
> a possibilty that the employee reach the internet via a proxy outside
> of switzerland (due to a enterprise policy) so they wouldn't be able
> to access there site and couldn't work at all.

That is a weird "Enterprise policy". Doing business that way opens you
up to all kind of fun international laws concerning your business.

Also note that you can of course always announce to trusted peers that
are not in Switzerland...

The major point is "trusted peers". Ones that will clean up their
attacking hosts the moment you notify them.

> Of course if the site isn't available at all it's not a good experience
> for the customer and they may order there article on a other onlineshop,
> but if the website is online and doesn't work properly that's also not a
> optimal solution either.

Better test it out today what happens when your site gets DDoSsed to
bits, as the script kiddies have access to the same botnet know that
Krebs got sent after him... (see other mail).

> Addiontally to the fact that more and more E-Commerce Websites use
> DDoS-Protection services like akamai or cloudflare, only about half
> hosting there website on server in switzerland.

You might want to reconsider your hosting location ;)

Also, if you are paying those kind of companies: prepare to dig deep in
your pockets for DDoS protection... we are going to have a fun X-mas
this year...

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Krebs: Source Code for IoT Botnet ‘Mirai’ Released

[Jeroen Massar]

https://krebsonsecurity.com/2016/10/source-code-for-iot-botnet-mirai-released/

And now the script kiddies have their hands on it...

Enjoy that Internet...

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] DDOS >1Tbps - Swiss-wide (regional) BGP propagation?!

[Jeroen Massar]

On 2016-10-01 16:51, Fredy Kuenzler wrote:
[..]
> To achieve this I think we need a collaborative community effort setting
> up a common procedure and define a BGP communitiy with the effect "do
> not announce beyond Switzerland".

Great initiative! If you need extra hands, don't hesitate to yell...

Did you btw see:
 http://www.trustednetworksinitiative.nl/
 https://www.nl-ix.net/solutions/security-solutions/trusted-routing
 https://ams-ix.net/technical/trusted-networks-initiative

We should have a Swiss equivalent:
 - trusted and direct contacts
 - require BCP38 where possible
 - proper statistics/monitoring
 - proper & standardized "You are DDoS'ing" notifications
   providing Flow info as "proof".
 - proper & standardized "We put customer in walled garden"

The problem with the latter: VoIP... thus the walled garden needs to not
block that due to "emergency services". Thus a throttle and a call to
the customer might be needed to inform them...


As for the BGP thing... I thought folks had a deal like that per default
for all their prefixes :)

It is after all the reason why quite a few IRC servers live(d) in PI
/24:
 - always the prefix to local peers
 - when 'normal' also announce to transit providers

When DDoS comes:
 - stop announcing to transits
 - check monitoring/stats tools which local peers are sending crap
   traffic and kick them hard

Now, the more important part is actually that:
 - You have good relationship with your transit
 - You have amazing relationship with your local peers:
   so that you can call them and notify them of the problem
 - Have proper instrumentation

Of course, when you have that, you might also want to peek at:
 - RPF / BCP38 kinda stuff and 'force' or 'require' that from your peers
   thus avoiding any spoofed traffic from them.

Not that BCP38 actually solves anything for these DDoS's as there are
just thousands of botted devices involved...

Proper flows everywhere, proper notification and shutdowns at the source
are the only way to go there.

And that will involve people calling helpdesks because:
 - their botted host is sending too much traffic
   making "The Internet Slow" and them complaining
 - they are disconnected, as you caught them participating.

Which might not fly with management in many places as helpdesk == money.

Hence, maybe to cover that at least, having a admin.ch rule, BAKOM
maybe, that allows an ISP to "restrict access", eg wall-garden an
endpoint that is causing DDOS attack would be a good thing.

Though, does not have to go that high actually, having a general
consensus between ISPs that this is the case and putting it in the
end-user agreement could be good enough to cover their ass a bit.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

On 2016-09-20 19:40, Gregor Riepl wrote:
>> That does not make IPv6 broken though, that makes people who think they
>> have to filter the wrong things broken.
>>
>> Misconfigurations is not something a protocol can solve.
> 
> There's an RFC for that: https://www.ietf.org/rfc/rfc4890.txt
> Great document, even serves as a good primer for folks who are new to IPv6.

Unfortunately the people who misconfigure do not read RFCs, if they did,
they would not filter.

They do not read this list either, let alone other resources that they
should be reading. Hence... not something one can solve.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

On 2016-09-20 15:58, Jim Romaguera wrote:
> 
> On 20.09.2016 15:40, Jeroen Massar wrote:
>>
>>>> Anybody has a proper excuse? :)
> 
> No I don't have an excuse but interested in the communities (& your)
> opinion re your challenge...
> 
> o DHCPv6 re Android re enterprise, BYOD, PWLAN, etc environments
> 
> Is a problem or was a problem / no problem at all?

One person at Google decided that they do not want to properly want to
support IPv6 even though people have been asking for it...

https://code.google.com/p/android/issues/detail?id=32621
http://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues/
etc etc


And even if they finally change their mind:
 https://developer.android.com/about/dashboards/index.html
you will never get the correct version on the devices

I am still waiting for the new 7.x to pop up on that chart ;)
I mean, it is only out for a month now...

Hey look, IOS 10.x is at 25% already:
  https://david-smith.org/iosversionstats/
while that was released, what, a week ago? :)

Hence, just buy a different device, Android is hopeless...

Greets,
 Jeroen

 well CyanogenMod might be useful, but they do not have DHCPv6
either afaik...



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

On 2016-09-20 15:29, Gert Doering wrote:
> Hi,
> 
> On Tue, Sep 20, 2016 at 03:20:56PM +0200, Jeroen Massar wrote:
>> On 2016-09-20 14:56, René Gallati wrote:
>> [..]
>>> I've activate IPv6 in my home network in 2011
>>
>> 2011, thus 5 years after 6bone had shut down and 12 years after RIR
>> space has been available. Welcome to IPv6! ;)
>>
>> /me waves at DE-SPACE-19990812 as well, Gert is on this list likely ;)
> 
> ... which was allocated about two years after we had our first IPv6 router
> running... that box was decommissioned about 10 years *ago*... :-)

You decommissioned the box *10 years ago* and people still do not have
IPv6, hahaha ! :)

>> Anybody has a proper excuse? :)
> 
> "I can make much more money by selling multi-stage NAT boxes and consulting
> services to go with it"!

Which is ABSOLUTELY true, similarly:

"I can make more money by keeping people on IPv4 and then moving them at
the last moment to IPv6 when they are willing to pay for it"

or:

"Lets put all the consumers on DS-Lite and sell the IPv4 addresses to
businesses with a heavy heavy profit"...

Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

On 2016-09-20 13:00, Roger Schmid wrote:
> Just one .. Dropping MTU handling and point to layer7 should handle that
> doesnt let you feel strange ? So how could an app handle packet size
> thru L4 ?

Both IPv4 and IPv6 have this little protocol called ICMP (+ICMPv6) it is
very useful and for IPv6 it is mandatory.

Even Google (who force MSS to magic values) and Cloudflare had issues
with that too:

https://blog.cloudflare.com/path-mtu-discovery-in-practice/

That does not make IPv6 broken though, that makes people who think they
have to filter the wrong things broken.

Misconfigurations is not something a protocol can solve.

> My experience is soma pages ar crawling like a snake .. Some ar not
> loading complete at all,
> for me v6 is still not ready to deploy to the masses as at least the
> mentioned flaw is a show stopper

I can find many many sites in IPv4 that are brokenly configured. That
does not make IPv4 broken.

That you find weird excuses that are already solved for well over 15
years of deployment (even 6bone as shut down 10 years ago)

Maybe, as it is 2016, time to actually start deploying!?

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

On 2016-09-19 23:53, Roger Schmid wrote:
> |Come on folks, it is 2016! IPv6 is
> |*20 years* old...
> But still not matured enough to put on public usage

According to Google 10% of their traffic is IPv6.
Apple requires it for IOS.

How is it not 'mature'?

> beside of some
> design flaw it is in some cases even bad implemented

Need more details.

> Maybe the isp/hoster/transit provider ned some teaching how to do it the
> right way.

Management of companies need to be convinced. Technical folks typically
know that they want it, but are not allowed to play with it...

That is not a technical, but a political issue.

Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

On 2016-09-15 20:04, Gert Doering wrote:
> Hi,
> 
> On Thu, Sep 15, 2016 at 12:11:44PM +0200, Jeroen Massar wrote:
>> Oh and note: Dual-stack IPv4 + IPv6, along with a /56 per user.
> 
> What do you want this IPv4 stuff for?  That's even, like, 40+ years old.

To access those ISPs that didn't bother to move yet ;)

Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Swiss ISPs and IPv6 --- 2016 edition

[Jeroen Massar]

As there is an upcoming SwiNOG lets throw some people under the bus
before they arrive. Or at least allow them time to come up with more
excuses.


Some quotes from Swiss ISPs from the Call Your ISP page:
  https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6

8<

"Currently, as demand for IPv6 is very low, we have no plans to
introduce IPv6 native.

"No plans to support IPv6 for our private and SoHo clients"

"The plan is to move everyone on DSLite."

"Provider info: IPv6 is "planned" and soon should get a priority status.
When that "soon" will be is not yet known."

"They know what IPV6 is, eventually they will provide it"

>8

Come on folks, it is 2016! IPv6 is *20 years* old...

Even Sky.uk was able to get it working[1].

Oh and note: Dual-stack IPv4 + IPv6, along with a /56 per user.

It is not that hard to get right and yeah, you kinda had 20 years
already to 'plan' for this

Greets,
 Jeroen


[1]
https://corporate.sky.com/media-centre/news-page/2016/sky-completes-roll-out-of-ipv6-becoming-the-first-major-uk-internet-provider-to-future-proof-its-service-for-customers


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Jeroen Massar]

On 2016-09-14 18:13, Andreas Fink wrote:
> I could do a presentation on the SCTP networking protocol which combines
> some features of TCP and UDP and offers some unique features neither TCP
> nor UDP have.

Is there any tool that actually uses SCTP ? :)

IPFIX is supposed to use it, but everybody still sends over UDP, rare
support for SCTP (except for purists like me who did implement it and
then also never really used it).

WebRTC is supposed to go partially over SCTP, never seen it actually used.

Apple chose to use Multipath TCP instead...

The article on Wikipedia does not list much more:
https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

Apparently some variant of SSH should support it, but no actual
implementations mentioned there either.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] The Internet 40 years on

[Jeroen Massar]

http://m.sfgate.com/business/article/40-years-on-the-Internet-transmits-every-aspect-9187484.php

For the people who like 'our history' ;)

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] peering request

[Jeroen Massar]

On 2016-08-28 14:11, Julien Sansonnens wrote:
> Just the kind of condescending and stupidly aggressive message that
> makes the charm of this type of list :)

Just a simple reality check, which you should have known about the
moment you where able to fill in the paperwork to get an ASN and a prefix.

Note that that latter paperwork used to contain a guarantee for two
upstreams. The reason for that was so that people realized they also
needed that...

> Probably in 1984, with the guys of 1984, I would not have received
> this kind of "response".

In 1984 they would have asked you how you would be paying for the
physical cable which brought you to them would have been a rather
expensive deal to get that telephone link up 24/7

Moving bits has always have a cost, and those costs have gone down a
lot, but still exist. The ones that give 'free transit' do that so that
they can balance their input/output ratio better which allows them to
negotiate better deals and of course to claim they are global Tier-1s
while they just have a l3-switch in a rack somewhere... great for
playing around, but nothing else.


You might want to ask OVH in France if they are able to provide you with
native IPv6, as they can. They might also be able to give you a BGP
session, but at that point, like the rest of their service they will
nicely ask you to pay for that service.


BGP over tunnels is a bad thing, as the tunnel will break and then that
flap in BGP gets progressed all around the world not even speaking
about MTU issues and fragmentation that you will run into.

Please keep the Internet a 1500 clean place, do your part and get Native
IPv6.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] peering request

[Jeroen Massar]

On 2016-08-27 19:58, Julien Sansonnens wrote:
> Hello,
> 
> Zaledia.com is a small not-for-profit organisation. We
> are a group of some interested technicians, IP networks
> enthusiasts. We like development and open protocols.
> 
> We operate AS207149, and provide IPv6 connectivity to
> our users, with a goal of sharing
> knowledge and development of a free internet, decentralized and
> neutral.
> 
> We don't have the money yet to obtain native IPv6 connectivity from
> some datacenter, so we receive it via a tunnel

Welcome to 2016. The 6bone was shut down 10 years ago.

Go to an IX and get native IPv6

Like you had to pay for the ASN and for the maint fee for the RIR
prefix, you will have to pay even more hard cash for the bits that flow
to/from the Internet in the form of transit.

The Internet is commercial, it is not 1984...

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] bluewin MX is blocking our mails

[Jeroen Massar]

On 2016-05-17 12:03, Markus Meier wrote:
> Hello everybody
> 
> 
> We moved our equipment to a new location and a new IP range. In the
> first few days a lot of outgoing email where blocked from various
> reputation filters. In the meantime we could fix most of the issues.
> Phuh... ;-)
> 
> Since today morning, the bluewin MX blocks our messages again. I already
> requested for a statistic reset at "Cloudmark".
> 
> What's wrong with our "reputation"?

That you do not send enough mail.

Cloudmark apparently works under the premise that when an IP rarely
sends mails and then suddenly sends more mail than the average it was
doing it thus must suddenly be spamming.

Hence, actual mass-volume spammers are great in their eyes, everybody
else they just block.

Little you can do about, except slowly ramp up sending mail through
their filters so that it looks like your normal volume is high...

Indeed, they do not actually care about content.

Note that there are 'feedback' mechanisms in their system and apparently
some domains are able to feedback into their scoring, and if you then
get negative feedback as some person just hits 'it is spam' even though
it was really not a spam message, you end up in the bad score too;
again, that is not a problem if you send massive amounts of mail, it is
a problem (one person hitting the spam button) when you actually send
few mails out...

Otherwise said: your IP is too new, does not have reputation yet, thus
you need to spam more and have nobody hit the 'spam' button in the
meantime; over time reputation builds up and then you can send 1M actual
spams, as long as you send 100M non-spam ones...

Oh, and of course there is a 'paid' option to get your reputation
corrected go figure what a nice business model that is.

> Hostname saturn.uptm.ch (mail.uptm.ch)
> IPv4 185.104.16.21
> IPv6 2a00:f740:100::15:1
> PTR should be correct
> SPF set for all customers domains

Is SPF set correctly? :)

Also, do try to get DKIM deployed. reverse->forward->reverse + SPF+DKIM
together are more or less required to send email to Google... especially
for IPv6 where they have apparently different and even more strict rules
than IPv4 (and nope, nobody, even employees apparently are able to tell
what those rules are or resolve issues when hosts of theirs are marked
as 'spam' according to big "do no evil" Google, see also something with
monopoly investigation by the EU...)

> Thank you for any hint.
> 
> It would also be nice, if someone from bluewin could contact me offlist
> and provide some more information, what made our IP evil again.

Like many other ISPs that simply use cloudmark (which thus reads every
email at those ISPs, wow, the insight that must give into the personal
lives of people not even living in your own country: privacy is
completely destroyed), they won't be able to tell, as the ISP is just a
customer of Cloudmark and has no insight into what Cloudmark does
consider or does not consider 'spam'.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swisscom now peering with Netflix

[Jeroen Massar]

On 2016-03-22 14:39, Fredy Kuenzler wrote:
> In case you missed it: Swisscom now peering with Netflix after big
> shitstorm in social media and general media yesterday and today.
> 
> http://pastebin.com/sgwD3qfh
> 
> I suppose the peering policy of Swisscom is now obsolete, as well as
> their monetizing OTT strategy.
> 
> It's a good day for real netneutrality, not the crippled version of some
> larger Swiss operators.

Real netneutrality would be the moment that also reaches the actual
houses of the endusers...

And there is a long way to go before everybody has an actual choice in
ISPs and as long as the cables and frequencies are owned by a few that
monopolize things, that won't happen...

Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Reject von hotmail.com -- also Swiss providers do this nonsense

[Jeroen Massar]

On 2016-03-22 08:12, Charles Buckley wrote:
> I have also been having trouble with my Swiss provider (hosttech) making
> such insane spam rejections.
[..]

Have you considered choosing with your money?

Just like when you do not get IPv6[1] from your ISP or any other
feature, somebody else will more than happily take your money for you.

And money is the only thing that really talks at companies, do be sure
to mention when you cancel why you are canceling

Greets,
 Jeroen

[1] https://www.sixxs.net/news/2015/#callyourispforipv6-1201



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Zukunft von Abuse Desks

[Jeroen Massar]

On 2016-03-18 08:44, Benoit Panizzon wrote:
[..]
> Wie sieht die Zukunft von ARF / X-ARF Complaints aus? Macht es
> überhaupt noch Sinn, solche zu versenden, oder soll man die betroffenen
> ISP und Hoster einfach sperren, da viele sowieso nicht mehr auf Spam
> Complaints reagieren?

Ich sage dir nur: http://www.misp-project.org/

Es gibt eine menge instanzen davon die daten automagisch austauschen.


Gibt genugend doko davor wie mann es verwenden kann:

 https://www.circl.lu/doc/misp/book.pdf

 
https://www.ncia.nato.int/Documents/Agency%20publications/Malware%20Information%20Sharing%20Platform%20(MISP).pdf

Wir drehen einen instanz beim ops-trust und die leuten die es bauen sind
super.

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Reject von hotmail.com

[Jeroen Massar]

On 2016-03-18 09:47, Franco Hug wrote:
> Hoi zaema,
> 
> Ich beobachte das gleiche Verhalten mit contabo.de, aus dem Netz 
> 178.238.224.0/22, evtl. gar 178.238.224.0/20 ...
> 
>> DE-GIGA-HOSTING-20100728 178.238.224.0 - 178.238.239.255
>> CONTABO  178.238.224.0 - 178.238.227.255
> 
> Da scheint das ganze Netz auf einer Migro$oft Blacklist gelandet zu sein.
> 
>> 550 SC-001 (BAY004-MC3F37) Unfortunately, messages from 178.238.227.40 
>> weren't sent. Please contact your
>> Internet service provider since part of their network is on our block list. 
>> You can also refer your
>> provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
> 
> Bei den einschlaegig bekannten blacklists ist das Netz auf jeden Fall nicht 
> gelistet.
> 
> In der Tat hatte ich selbst innerhalb der letzten 3 Monate 1x ein Spam-Mail 
> aus diesem Netz erhalten.
> Eigentlich nichts Aussergewoehnliches, hin und wieder flutscht halt mal was 
> durch bei diesen grossen
> Providern. Dass deswegen ein ganzes Netz gelistet wird, und somit auch 
> Unschuldige betroffen sind, ist
> aergerlich. Umso mehr, weil nicht wirklich klar ist, was man genau tun muss, 
> um das Problem zu beheben.

Registriere bei postmaster.live.com ... (yep, und auch bei google etc,
die grossen haben kein lust um spam zu empfangen, so schieben sie das
auf der ISPs die gerne mail wollen schicken)

Richtige WHOIS, reverse DNS, SPF + DKIM und naturlich funktionierende
abuse@ und abuse mail auch richtig behandeln.

abuse-c oben ist ab...@contabo.de und wann dort sage 50 /24s hin gehen
und aus der 50, 1 /24 viel spam geschickt werde und abuse@ das nicht
losst, dan werd gleich die andere 50 auch als 'reagiert nicht' markiert,
also.. rufe deine ISP an und frage mal nach ob die abuse behandeln...

Greets,
 Jeroen



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Reject von hotmail.com

[Jeroen Massar]

On 2016-03-18 06:36, Klaus Ethgen wrote:
[..]
> Die IP 5.9.7.51 ist meine Outgoing-Adresse und ist seit Jahren der
> valide Mailserver meiner Domains. Ich kann auch ausschließen, daß über
> die Domain auch nur die geringste Spam oder andere Malware versendet
> wird.

Hetzner steht bei viele ISPs in der schwarze liste, da die nicht immer
richtig abuse behandeln, dann ist es einfacher um kein email zu entfangen.

Was du proberien kann, ist der IP einzutragen im Live Postmaster:
 https://mail.live.com/mail/postmaster.aspx

Aber das funktioniert nur wann du auch im WHOIS steht als kontakt, und
es dauert auch einige zeit vor das das funktioniert beim hotmail.

Vor Jahren wann Ich noch ein kiste hatte beim Hetzner hatte das
gelungen, auch wenn der sperre bereits da war.



Es gibt viele vorteilen ein etwas 'teuere' hoster zu wahlen, mindestens
das die support gut funktioniert und problemen gelost werden, aber auch
das die noch an abuse tun ;)

Und naturlich, Schweizer hosters fallen auch unter .ch regeln, nicht
unter die von fremde lander und personen... und sicher fuer email ist
das wichtig.

Greets,
 Jeroen


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] TCP timestamps

[Jeroen Massar]

On 2016-03-10 17:12, Andre Keller wrote:
> Dear fellow SwiNOGers,
> 
> in the last few months we had several security audits and all of them
> proposed to disable tcp timestamps.

Did they also state why? :)

> (i.e. on Linux
> net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp
> relies on this and there might be implications for PAWS (tcp sequence
> number wrapping).

You might want to read up on:
 http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf

> What do you guys think about this?

It all depends on what you are "protecting" yourself from.

Think about it: if it was a huge security issue, it would be disabled
per default ;)

It is primarily a obfuscation technique that primarily hides if you did
upgrade your kernel recently...

Greets,
 Jeroen




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog