Has someone here an 464xlat #CLAT daemon running under debian, more or less in production?
I'm looking for the best solution right now, especially with regard to packaging an automation. I'm not really convinced (yet) about clatd though. #ipv6
Currently, #BoxyBSD has #IPv6 networks in DE, CH, DJ and US (East). Which would you prefer and should one of these location get added?
VAE, AUS, JP, CA, PL, SG, ZA could easily be added.
Unfortunately, nothing near India. Trying to have a look for it.
#IPv6 rocks. Flawless physical migration with only a very minor downtime :-).
Thinking about networks as segregated network segments is just SO MUCH easier, this time around, I went #IPv6only and didn't even bother with setting up IPv4.
If you've ever looked at SSH server logs you know what I'm about to say: Any SSH server connected to the public Internet is getting bombarded by constant attempts to log in. Not just a few of them. A lot of them. Sometimes even dozens per second. And this problem is not going away; it is, in fact, getting worse. And attackers' behavior is changing.
The graph attached to this post shows the number of attempted SSH logins per day to one of @cloudlab s clusters over a four-year period. It peaks at about 3.4 million login attempts per day.
This is part of a study we did on our production system, using logs of more than 640 million login attempts, covering more than 1,500 hosts on our side and observing more than 840 thousand incoming IP addresses.
A paper presenting our analysis and a new, highly effective means to block SSH brute force attacks ("Where The Wild Things Are: Brute-Force SSH Attacks In The Wild And How To Stop Them") will be presented next week at #NSDI24 by @sachindhke . The full paper is at https://www.flux.utah.edu/paper/singh-nsdi24
@SoniEx2@cloudlab@sachindhke An excellent question that I can only speculate on right now, in part because our study only covers IPv4, and in part because I expect the landscape to change, but it's hard to predict exactly how.
In the short term, switching ssh and other services to #IPv6 only will likely reduce the brute force attacks you see by a lot. Our data suggests that attackers are hitting the IPv4 space at random, which is a perfectly good strategy for the relatively dense IPv4 space, but a terrible strategy for the gigantic IPv6 space. If I were an attacker doing brute force, I'd stick to the IPv4 space that's easy and has plenty of targets.
However, let's consider more sophisticated attackers, and/or a future world where we've moved entirely to IPv6. There are lots of things you can do to cut down the scanning space. Most IPv6 space is not even allocated, so you can just skip that. You can focus on specific prefixes used by large ISPs and cloud providers to increase your hit rate. You can use information about the way some devices use MAC addresses to generate part of their public address to target popular NIC and or IoT vendors. You can keep track of live IP addresses based on observed connections (eg. scan everyone who connects to your website.) You can try to enumerate DNS domains to look for targets (most DNS servers try to prevent this, but there are all kinds of attacks on DNS). You can share lists of the live addresses you find. And these are just off the top of my head, I'm sure people have come up with plenty more already, and will find plenty more in the future.
So, will we eventually reach a point where IPv6 scanning is as effective as IPv4 scanning is today? It seems unlikely, but scanning the entire IPv4 space in minutes seemed unlikely not too long ago. So in the long term, I wouldn't bet on security that depends on IPv6 being hard to scan. I would expect that we'll all want to keep up the same strategies of using keys, blocking attackers that we detect, etc.
One thing I would expect is for the patterns to change: right now acquiring a target is easy, so attacks that just try once and move on are common. On IPv6 - both now and in the future - I'd expect that the difficulty of finding targets means that once you find one, you're going to try a lot more usernames and passwords on it.
Le saviez-vous : Si votre instance est en dual stack mais que votre enregistrement DNS ne contient qu'enregistrement AAAA (ipv6), alors vous pouvez envoyer des toots à tout le monde mais ne pouvez recevoir que des toots d'instances en ipv6.
Vous vous en fichez mais je découvre qu'il y a un résolveur #DNS public en Inde (apparemment géré par le registre du .in) et il a une bonne adresse #IPv6 (et elle répond aux ICMP echo).
Comme quoi les adresses IPv6 ne sont pas forcément plus longues et plus dures à mémoriser que les adresses IPv4.
Sharing some technical details about how I'm setting up the hosted email service. It will not be a service of BSD Cafe but tied to my own business. It will run entirely on BSD systems and on bare metal, NOT on "cloud" VPS. It will use FreeBSD jails or OpenBSD or NetBSD VMs (but on bhyve, on a leased server - I do not want user data to be stored on disks managed by others). The services (opensmtpd and rspamd, dovecot, redis, mysql, etc.) will run on separate jails/VMs, so compromising one service will NOT put the others at risk. Emails will be stored on encrypted ZFS datasets - so all emails are encrypted at rest - and only dovecot will have access to the mail datasets. I'm also considering the possibility of encrypting individual emails with the user's login password - but I still have to thoroughly test this. The setup will be fully redundant (double mx for SMTP, a domain for external IMAP access that will be managed through smart DNS - which will distribute the connections on the DNS side and, in case of a server down, will stop resolving its IP, sending all the connections to the other. Obviously, everything will be accessible in both ipv4 and ipv6 and in two different European countries, on two different providers. Synchronization will occur through dovecot's native sync (extremely stable and tested). All technical choices will be clearly explained - the goal of this service is to provide maximum transparency to users on how things will be handled.
Soooo, auch wenn es mir etwas widerstrebt 1&1 (hat gerade mal eine Hand voll Antennen in München) mit Telekom, Vodafone und Telefonica zu vergleichen, so muss ich es doch tun, wenn ich hier keinen Blödsinn verbreiten möchte.
Also alle vier deutschen Mobilfunknetze unterstützen #ipv6 . https://www.thomas--schaefer.de/apn-ipv4-ipv6.html #5G
Just signed my parents up for gigabit #fibre (both upload and download) in Bradford via #Brsk. They support full #IPv6, static #IPv4, and your own router via #DHCP and DHCPv6 PD/SLAAC. The checkout via Stripe was also wonderfully straight forward. Impressed so far.
Damn #ipv6 you just keep coming back up in the #homelab!! Can we make a ipv5.5432 or something that I can wrap my head around this shit easier! It's the adkjlfa;dljfklad:adlkjfal;dkfja:a;lkdjlfkjfjd:123:1233435:3434:22123233 that throws me off. Then here comes them network heads be like.. You dummy the fuck wrong with you that's easy as shit to see.. It's the 3rd semicolon from the back.. you ass hat.. ummm what! 😐
On my search for an ISP which gives me fiber and static #IPv6 PD.
I asked my local/regional ISP for their business offerings, as they do not offer static PD for residential customers.
"Protokoll/SLA-Klassifizierung:
IP-Protokoll über einen shared Port am Access-Netz, eine feste IPv4-Adresse
und ein festes IPv6-Präfix mit einer Länge von /62"
"Protocol/SLA classification:
IP protocol via a shared port on the access network, a fixed IPv4 address and a fixed IPv6 prefix with a length of /62"