[swinog] Re: Contact: geoiplookup.net
Frankly, while I appreciate that MaxMind might behave a little more customer friendly, I'd say the problem here is that people don't understand what GeoIP is: A best guess. You should not send the police to a property because the IP appears in MaxMinds DB. That is true, but in many cases, it's the only alternative that is both cheap and somewhat privacy-friendly. If you want reliable point-of-residence control, you need to ask people about their identity and verify it. That is undesirable to both service providers and end users. Sure, in some cases, people have to reveal their identity anyway (for example when making online purchases), but not in many others. And there is still lots of potential for faking it. > I'm pretty sure RIR's would allow MaxMind to query the original source > of data, either for the IP or for the AS announcing the prefix to bgp. > But RIR's will charge a service fee for that - what is legit from my > perspective. If MaxMind spares this fee and delivers a shitty service > then, the TSP should consider to switch to a more reliable source of > data - it's them who is violating SLAs with their customers. I don't see that too much of a problem, as long as the geolocation providers don't have to shell out big $$$ to every little owner of a /28 for their location data. They're making money off that data, after all. But, it probably wouldn't work without legislation or legal precedent. Blocked access to an online casino would probably not be enough to convince a court, but maybe there are other cases, such as news outlets. Or maybe it would work the other way? Someone with a residence in Switzerland gains access to a casino that is barred from doing business here, because the geolocation data is incorrect? You'd be opening a can of worms there, though... ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
Re: [swinog] SSL Certs question
> 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. 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/ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] G.Fast DSL modems - bridge only
> Since I moved away from VDSL2 area to Fiber to the home place, I can not > really understand these issues anymore. > Why go and abuse copper wires to the absolute limit when its not a > solution long term any way. Its dead technology. Simple: Because those making the decisions who does and doesn't get FTTH are those who will have to pay for a big part of the installation costs. Although, I suppose you could always try to finance the cabling yourself if you have deep pockets... I'm not sure how helpful the BAKOM would be in this, but perhaps you can at least file a complaint against the provider for not providing the advertised bandwidth? It wouldn't help against the decision-maker's refusal to invest into the future, though... ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] OVH datacenter SBG2 in Strasbourg on fire
> Very sad day for our colleagues at OVH AS16276 as they lost their > datacenter SBG-2 in Strasbourg completly („everything is destroyed“) in > a fire and the neighboring SBG1/SBG3/SBG4 at least temporary. A tragic event, it evokes some faint memories on what happened at Fukushima No.1 NPP in 2011. I think this is a good time to remind everyone to review their disaster recovery procedures regularly, and ensure they still work as expected. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Swisscom IPv6 Routing weirdness
> 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. And I can't get a TLS 1.3 handshake to succeed, the load balancers seem to support only TLS 1.1 and 1.2. > Those incorrect checksums: are my systems generating incorrect checksums > or is it the swisscom side? It seems weird that different systems with > different OS at different customers would all start making wrong tcp > checksums. The incorrect checksums are only shown for packets sent by your client, so most likely not something Swisscom can do anything about. I wouldn't bother too much about them though, this can be caused by checksum offloading and is usually corrected after tcpdump has seen the packets. But it can't hurt to try turning such features on/off to see if it makes a difference. The first dump shows the client attempting a TCP handshake (multiple SYN messages), but there is no response from the server. Eventually, the server sends a RST, so it must have gotten some of your SYNs. The second dump shows a successful handshake (SYN, SYN+ACK, ACK) and some data being PuSHed by the client, which is ACKed by the server. Then the server sends a RST. This could indicate incorrect or incomplete packets being sent from your client. A failed TLS 1.3 handshake should look more like SYN, SYN+ACK, ACK, PSH+ACK, PSH+ACK, FIN+ACK. Perhaps something is wrong with your test client? Wrong MTU? OS issue? Did you try a different machine? ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Coop.ch geoblocking?
> 157.161.57.65 => blocked (main NAT ip) > 157.161.57.66 => Ok (a static server ip not used anymore) > 157.161.57.68 => Ok (a static client ip) > 157.161.57.70 => blocked (alternate NAT ip seldom used) > 157.161.5.199 => blocked (Gateway IP, not usually used as src, except > local stuff on the Mtik like DNS) > > Weird! Anyone has insight in what geoIP database coop uses? Or if there > are other criteria they use for blocking? Perhaps they're using some outdated OS where the distributor never bothered to update the geocoding libraries, even when they were obsoleted upstream, such as [1] :) Jokes aside, perhaps they also have some sort of blocking heuristic in place that goes beyond plain country-based blocking. Did you do anything from those IPs that could have gotten you onto some (unrelated) blocking lists? [1] https://rpmfind.net/linux/RPM/centos/7.9.2009/x86_64/Packages/GeoIP-1.5.0-14.el7.x86_64.html ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Cloudflare 'relaying' complaints and take down notices to the hosting ISP instead of handling them.
> I quickly got the reply, that they are not responsible for content > hosted by their customer, therefore they relay complaints to the ISP in > charge of the IP address in question. > > That is a bit weird isn't it? I'm not sure if "getting impatient" will do them any good. A DMCA complaint is worthless if you aren't a US entity or do business in the US. It's indeed a bit weird that Cloudflare doesn't respond to legal requests. But I don't know US law much, so I don't know how cooperative they have to be. They're probably going with the bare minimum, just so they don't get into trouble... ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] WiFi Calling - traffic flow, protocols, ports, probes, ...
Hi, > The address(es) of the ePDG are discovered using DNS: the phone will try > to resolve epdg.epc.mncXXX.mccYYY.pub.3gppnetwork.org, where XXX is your > operator's Mobile Network Code (for instance Swisscom is 001), and YYY > is your Mobile Country Code (228 for Switzerland). > > So I guess a first test can be to look for these addresses and watch for > ipsec traffic. Also looks like a terribly easy way to spoof or screw up automatic discovery. I doubt any vendor uses DNSSec here (or that it will be of any use to protect against abuse). And oh! What about home routers that don't delegate DNS to the provider's DNS infrastructure? Regards, Greg ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] COVID-19 Monitoring Hackathon
Here's another project that is looking for volunteers: https://db.schoolofdata.ch/event/7 In particular, some of you may be able (and willing!) to contribute to the "Daten zur Netzauslastung" topic? -> https://db.schoolofdata.ch/project/67 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Telegram group
> Is there an IOS/Apple app for IRC that acts like an messenger app? (eg > persistant connection)? There is, but it's probably not quite what you were expecting: ZNC Pair that with a regular IRC client and you're good to go. Suggestion: https://apps.apple.com/us/app/palaver-irc/id538073623 And yes, this is exactly what you'd have been doing when you wanted a persistent IRC connection on *any* system: Use an IRC bouncer. Even if that bouncer is just a screen or a tmux session on a shell server. ___ 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]
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 ) It doesn't solve the issue tracking part, however. And in other news: https://www.theregister.co.uk/2019/10/31/notepad_china_spam/ Using code for political protest is taking things one step further... ___ 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]
> 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. > And that is why projects on Github won't leave github easily. Sure, but do they need to? 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. 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. > 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. ;) > (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. ___ 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]
> 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. It is very easy to leave public forks in several places, and there are even ways to automate pulling from one repository to the other. Private Git hosting has its merits, but it makes it more difficult to send patches or improvements. There are ways around that of course (good example: the Linux kernel), but they rely on a lot more effort than is usually necessary for a small open-source project. Of course, it is everybody's own choice to not use public collaboration platforms, but there is also not much harm in doing so. Should one of them shut down, crash & burn, or change their terms of service, there are always other ways to share repositories. This is a very different matter than social networks that rely on proprietary protocols and infrastructure. > I understand your point that it should be easy to contribute, but maybe > it is a more sustainable way to fire up your own git service and have > your code pulled in from your machine, preferable via IPv6? That sound like a tremendous amount of effort in coordination and setup compared to the benefit and will probably put off 99% of all potential contributors... Well, notwithstanding everybody on this mailing list, of course. ;) ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] new project: DHCP Protect
> This is why I wrote DHCP Protect. DHCP Protect works with the userspace API > of Netfilter (iptables/ip6tables) and will treat each DHCP(v4/v6) packet > and decide if it should be forwarded or not. > > Don’t worry, iptables can be configured in a way that if the program is not > working, it will ACCEPT the packets by default. In case anyone is not familiar with userspace filters, here is a good overview of how nftables works: https://www.slideshare.net/azilian/nftables-the-evolution-of-linux-firewall (I found something even better a few years ago, but I lost the link...) > There are no packages available, but don’t be scared, it’s really simple to > install and it will do all the systemd stuff for you! After make install it > will already be running (you can also make uninstall which will delete > everything and remove it from systemd). > > git clone https://git.home.spale.com/dhcp_protect.git Your Gitea instance doesn't seem to like this link when accessed from a web browser. This works better: https://git.home.spale.com/public/dhcp_protect Perhaps you should even put the project on a public collaboration platform to allow for easy pull/merge requests. ;) Anyway, thanks for sharing! ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Geldspielgesetz: Zugangssperren Q
... > A: Die Behörden sind noch nicht so weit. Es gibt keine Liste von zu >sperrenden Domains, welche am 1. Juli >publiziert wird. ... > A: Vorgesehen war der Versand per Email, dies ist aber auf wenig >Akzeptanz bei den Providern gestossen, daher werden die .eml Dateien >der Emails als Work-Around zum Download angeboten. ... > A: Ja, dies ist ein Problem welches nicht gelöst ist. Es ist nicht >vorgesehen, dass die Sperrseite ein gültiges Zertifikat haben soll >und der Problematik dass die Browser dann eine Fehlermeldung >anzeigen sind sich alle bewusst. ... > F: Was passiert mit dem MX Einträgen zu diesen Casinos? Müssen wir >sicherstellen dass Email noch funktioniert? Sprich die Original MX ... > A: An das Thema wurde noch gar nicht gedacht. ... Schön, dass man sich von Anfang an so viel Gedanken über die technische Umsetzung und die Konsequenzen gemacht hat. Auf der anderen Seite wundert mich ein wenig, dass diese Fragen erst jetzt aufkommen. Ich hatte bisher eigentlich angenommen, dass für die Umsetzung des Geldspielgesetzes die gleiche Infrastruktur verwendet werden soll wie für die Gesetzesänderung zu Pornografie von 2006 (Stichwort Kinderpornografie). 13 Jahre sollten doch eigentlich reichen, um ein automatisiertes System zur Verteilung von Sperrlisten aufzubauen, oder? Wer Sarkasmus findet, darf ihn behalten. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] How do website operators get the mobile phone number of visitors?
> And I have sniffed the traffic between my swisscom mobile Samsung > Mobile and my Website, but can't find any of the additional headers > disclosing my phone number. TLS would effectively defeat any attempt at injecting headers into HTTPS traffic - unless the network operator controls a browser-trusted CA and uses it to break TLS for man-in-the-middle traffic manipulation. Also: It doesn't matter if the connection is direct or goes through a proxy. > Is there a trick to make a mobile phone disclose it's phone number > while connected via the mobile network's operator network? I found this, but I'm not sure if it's implemented in any common mobile browser: https://wiki.mozilla.org/WebAPI/MobileIdentity > How can 'website payment' operator like 'obligo' get the phone number > associated with a visitor? Obligo states they got the phone number > to bill 'from the service operator'. I suspect some network operators provide an API for obtaining subscriber information. You should confront your network operator if you're sure you didn't agree to disclosing private information via such a service. See here for an example: https://developer.att.com/technical-library/device-technologies/user-identification Seems like a legacy from the WAP age to me. I'm pretty sure that such an API would not be public, and there would be adequate access protection. It's possible that 'obligo' has an agreement with network operators to access such information. > Would it be possible, that a fraudster injects such headers from a > client to make obligo bill the wrong number? If the service uses a local API like MobileIdentity and the service provider trusts that information, then sure. If it uses strong transport layer security and the information is obtained via a secondary channel (like a provider API), then no. Well, unless the attacker hijacks the provider API, of course... ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Google DNS on Salt Mobile
>> 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). > > They seem to use a mix of Google Public DNS and own resolvers. You are right; the list of servers is somewhat randomised and contains more than two entries. Since my local resolver library only supports two DNS servers at once, I simply wasn't seeing Salt's own DNS server for a while. Still, I don't think it's very nice to push Google DNS to clients. signature.asc Description: OpenPGP digital signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Google DNS on Salt Mobile
Hi, 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). Is there a particular reason for that? 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... Thanks for any info. Greg signature.asc Description: OpenPGP digital signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] BGP Battleships
>> https://blog.benjojo.co.uk/post/bgp-battleships > > How about at work? ;-) > > Mind if I share this with other tech mailing lists? Just don't break the internet, please! ;) Might be a good tool to teach folks about BGP though, so go ahead. I'm not the author anyway, just stumbled upon it on a tech news site. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] BGP Battleships
Some good ol' fun with BGP: https://blog.benjojo.co.uk/post/bgp-battleships Please (don't?) try this at home! ___ 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
Hey, - Different format? Different locations? Different agenda? May I suggest a bit more diversity? Zurich is nice, but there are probably many SwiNOGgers who can't just take a "quick" trip to ZH on a regular working day. How about Bern, Lausanne, Basel, St. Gallen, or somewhere else once in a while? All the best, Greg ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition
> 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. BUT: If you find such a person, you can strongly urge them to read this RFC. ;) ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Swiss ISPs and IPv6 --- 2016 edition
> 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. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] NDG Referendum
A little reminder to everyone who has not cast their vote yet: On September 25, the Swiss citizens will decide whether to accept or refuse the new NDG/LRens/LAIn/LSI/ISA (Nachrichtendienstgesetz/Loi fédérale sur le renseignement/Legge federale sulle attività informative/Lescha federala davart il servetsch d'infurmaziun/Intelligence Service Act): https://www.admin.ch/gov/en/start/documentation/votes/20160925/intelligence-service-act.html Please don't forget to vote! ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Rack mounting Switch/Routers in Cold and Hot Isle DC
> How to you solve this issue? The easiest solution, if there is no fancy (i.e. software controlled) way to reverse fan flow: Just open the switch, unscrew the fans, turn them around and remount them. Our network engineer did that countless times, and it always works. No need to spend heaps of $$$ on hardware with the "correct" flow direction. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Scott Bradner über die Fehler von IPv6
Very interesting interview, also discusses possible reasons why IPv6 is not picking up fast enough: http://heise.de/-3276808 (German only, unfortunately) ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] 20 Minuten Online gehackt?
> GovCERT hat heute Vormittag die IOCs öffentlich gemacht: > http://www.govcert.admin.ch/blog/21/20min.ch-malvertising-incident Adobe Flash... Again. Why is that crap not banned in government/corporate IT infrastructure? If anyone still needs it for certain applications, at least reduce exposure by limiting access to certain domains or (better) pressure your vendors to finally replace it with something less dangerous. Seriously. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Zukunft von Abuse Desks
>> Ich bin nicht bereit, täglich mehrere hundert Complaints via Webform >> mit Captcha einzureichen. Ich wüsste auch nicht, wie ich dies technisch >> machen sollte. > > Amazon Mechanical Turk oder sonst irgendwie an eine Clickworker-Plattform > outsourcen? > ;-) Oder ein Script basteln das das Captcha löst und automatisiert das Abuse-Formular ausfüllt... ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] hotmail issues since 18/1 ?
> It is truly weird. Using the same sender and same path, one email > to "some.u...@hotmail.com" is accepted, another > to "postmas...@hotmail.com" is rejected. They are probably ramping up rejection rates slowly, as suggested here: https://dmarc.org/overview/ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Layer2 ovcer Layer3 Tunnel
I am looking for a way to do a layer 2 connection via a routed network. Arista is using VXLAN for that, but unfortunately my Aristas are not supported. The goal is to back up my direct fiber connection by this virtual fiber. Unfortunately I can't get a second physical fiber here. Any software recommendation? You could use any kind of VPN protocol with layer 2 support, I guess. GRE, OpenVPN, L2TP, ... ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
