BTW: Contact info is in my profile if anyone wants the inside scoop. The project just isn't fully ready for public launch yet, but we're well into the cooking.
60 karma · joined July 29, 2011
Social: @dxld@pleroma.debian.social | pleroma.debian.social/dxld
Websites: dxld.at (boring), ipv6.monostack.org (interesting).
Debian: qa.debian.org/developer.php?login=dxld
Patches I sent: lists.sr.ht/~dxld/outbox
sr.ht: git.sr.ht/~dxld
Github (historical): github.com/DanielG
BTW: Contact info is in my profile if anyone wants the inside scoop. The project just isn't fully ready for public launch yet, but we're well into the cooking.
https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transit...
Trivial to setup, guides you through configuring SPF, DKIM, DMARC, MTA-STS, DANE and DNSSEC. Handles certificates by itself through ACME, comes out-of-the-box with IP/domain reputation based and bayesian spam filtering.
While I've come to appreciate how much tweaking you can do with something like exim I'm starting to see the advantage of not having to spend time doing any of that :)
Mox also has some really cool (and AFAICT) novel features stemming from the fact that it's so tightly integrated. Have a look at the "Rejects" mailbox, or the nuanced way it rejects spam at SMTP time to prevent the dilemma between causing backscatter or potentially dropping mails (like gmail likes to do). I've also never heard of REQUIRETLS before seeing it exposed right there in Mox's built-in webmail.
You make my own point sir. They're not going to care about copyright either. So may as well make this proper FLOSS.
I mean he says it right before the proprietary apologism, the problem is pointing people in the direction of the project by name only for them to find malware ridden clones. Well. The problem here isn't the software being cloned, the problem is the same name being used by the attackers.
> [...] we grant you a [...] license to access and use the code solely for the purposes of review, compilation and non-commercial distribution.
> We may suspend, terminate or vary the terms of this license and any access to the code at any time, without notice, for any reason or no reason, in respect of any licensee, group of licensees or all licensees including as may be applicable any sub-licensees.
Bummer.
dynamic-host=cafe.dxld.at,::cafe,lan0
Firewalls tend to support DNS, use it :)I know for a fact nftables and pfSense allow this, worst case you need a cronjob to periodically reload your ruleset to refresh the DNS data as it's evaluated at ruleset load time (for nftables). Incidentally another TODO project of mine is a daemon to allow running scripts when RA information (such as the prefix) changes, this would come in handy here too.
For anyone interested in making IPv6 bettter come talk to me in #ipv6:ungleich.ch (Matrix).
--Daniel
In ifupdown I usually just add something like the following
pre-up ip token set ::cafe dev $IFACE
This way when you get a new GUA there's no need to "renumber" your network manually as everything will just happen automatically. When your router includes a new prefix in the router advertisement all hosts on the LAN generate new addresses for this prefix.Couple of gotchas. 1) The ip-token call has to happen before the interface is marked up (as in ip link set dev $IFACE up, not link presence) so if you want to change it you have to take it down first. 2) If your ISP's router doesn't cleanly announce the old prefix to be deprecated (due to a reboot say) it may remain in use by hosts until it's lifetime expires. See RFC4192 for how renumbering is supposed to work.
FYI: I'm working on a small daemon that will monitor RA and deprecated the prefix to handle broken ISP routers.
--Daniel
In particular I've learned from that doc that there's special handling for putting a vlan device on top of a bridge (br0.123) even if the bridge is vlan unaware.
DSA might also be relevant if you're working with hardware that supports it: https://docs.kernel.org/networking/dsa/dsa.html
I have to do more involved full EDID reconstruction surgery tho since I need to add DTD entries rather than just change existing ones. So I'm looking at [edid-generator] together with [cvt12]. The latter can calculate xrandr modelines for VESA standard timings that all seem to work with my TV. cvt12 adds the option to calculate NTSC (1/1.001) timings over regular cvt which is already in Debian.
[cvt12]: https://github.com/kevinlekiller/cvt_modeline_calculator_12
[edid-generator]: https://github.com/akatrevorjay/edid-generator (thanks Kodi wiki)
Stops it from beeping at you when your allotted product lifetime is up though.
There isn't anything out of the box that I could find, but there was some discussion/prototyping around adding an API for exporting all the necessary key material and metadata to the mbedtls API. With that it would have been "relatively" "easy" to do the TLS bits :)
See https://github.com/Mbed-TLS/mbedtls/issues/3141 and linked ML posts.
check_tls () {
# Check two weeks in the future to give us time to fix certs
faketime +14days \
openssl s_client -showcerts -verify_return_error "$@" \
</dev/null || exit 1
}
The -verify_return_error option makes s_client return an exit code on cert validation failure. Then just loop over the hosts/ports you want to check, wrap the whole script in cronic/chronic to ignore output when it doesn't fail and bam no need for a service to do this. Just have to be able to interpert s_client output ;)An example with dual stack IPv4/v6 https/smtp/imap support:
for af in -4 -6; do
for connect in \
www.example.org:443 \
\
mail.example.org:465 \
mail.example.org:993 \
;
do
check_tls $af -connect $connect
done
check_tls $af -starttls smtp -connect mail.example.org:25
check_tls $af -starttls smtp -connect mail.example.org:587
check_tls $af -starttls imap -connect mail.example.org:143
done
Note that s_client doesn't check if the hostname passed is correct for the certificate it receives by default. To turn this on use the -verify_hostname option (https://www.openssl.org/docs/man3.0/man1/openssl-verificatio...) The monthly prices will change for the following servers you use:
Server name new price old price Starting on
SB42 #xxxxxx 43.20 Euro 40.31 Euro 2022-03-15
Doesn't seem so bad to me.Then I guess I'd have the backend send the user a link with an auth token after joining, that way at least no pasting needs to happen.
[1]: Patched slightly to make it work, https://github.com/restic/restic/pull/2398 (hope this will get merged eventually)
How one goes about not accumulating backups forever is a problem with this setup. My basic plan is manually switching to another bucket and verifying the newly backed-up data before deleting the old bucket.
You can also enable a time-based deprecation of hidden files on B2 then you don't have to actively do anything, but in theory if the malware bides its time it could still delete/overwrite everything without you noticing.
If you want to self-host the restic/rest-server also has a --append-only flag that would have a similar effect, but if you use that you'll have to make sure the malware can't hop onto your backup machine via ssh.
Specifically I'm referring to:
- RFC4864 | Local Network Protection for IPv6,
- RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and
- RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference.
In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world.
[RFC4864]: https://tools.ietf.org/html/rfc4864
[RFC6092]: https://tools.ietf.org/html/rfc6092
[RFC7084]: https://tools.ietf.org/html/rfc7084
Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do.
Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem.
Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall.
I've always wondered if you could burn SGABIOS (https://code.google.com/archive/p/sgabios/) to a PCI(e) card ROM to get this working on real hardware instead of just in QEMU.
Apparently someone did try this, so it might just work: https://www.flashrom.org/User:GNUtoo/Howto_flash_sgabios_on_...
Maybe I should dig up some old flashrom supported NIC card or something.