Emotet

If you share a WiFi connection with an attacker at a coffee shop, for example, there are certain attacks they can execute to see the unencrypted parts of your Internet communications (e.g., the domain names of the websites you visit) and interfere with your communications to carry out other advanced attacks against you. Typically, security experts recommend the use of a VPN to protect against attackers with whom you share a WiFi connection. Our research reveals that using a VPN opens you up to similar attacks from other VPN users with whom you share your VPN server. In the same way that the WiFi radio signal is a shared resource that makes users vulnerable to attacks, there is a shared resource on VPN servers called a port (each connection through the VPN server is assigned to a port). By carefully crafting packets from within the attacker’s own connection to the VPN server and from a remote Internet location controlled by the attacker, it is possible to carry out attacks on other VPN users who are using the same VPN server in a manner that is very similar to the attacks that could be carried out on shared WiFi. We call this attack primitive a port shadow because the attacker shadows their own information on a victim’s port as a shared resource, and this attack primitive can lead to snooping of unencrypted data, port scans, or connection hijacking.

Ah. So Lemmy with version 0.19.4+ allows users to set a custom thumbnail URL for a post, which can be set to pretty much anything resembling a valid link, especially a link to another image in the local pictrs db and trigger a deletion of both when a minimum age check is passed.

Also this:

Except that the field allows some funny URLs e.g. https://t.t/;';'%22;...[:%3C%3E?]%27;%20yaba%20daba%20doo, if this is an issue too is not confirmed

While this is a great approach for any business hosting mission critical or user facing ressources, it is WAY overkill for a basic selfhosted setup involving family and friends.

For this to make sense, you need to have access to 3 different physical locations with their own ISPs or rent 3 different VPS.

Assuming one would use only 1 data drive + an equal parity drive, now we're talking about 6 drives with the total usable capacity of one. If one decides to use fewer drives and link your nodes to one or two data drives (remotely), I/O and latency becomes an issue and you effectively introduced more points of failure than before.

Not even talking about the massive increase in initial and running costs as well as administrive headaches, this isn't worth it for basically anyone.

This photo may have (unfortunately) won him the race.

Dieses Foto hat ihm vielleicht die Wahl geschenkt.

Aber das ist doch genau mein Standpunkt und widerspricht deinem Punkt, auf den ich geantwortet habe?

Bei deinem ersten Punkt bin ich ganz bei dir.

Allerdings muss ich bei deinem zweiten Punkt widersprechen. Gesetzlich betrachtet sind E-Scooter Kraftfahrzeuge, unterliegen also den gleichen Vorschriften, welche auch auf Autos, Motorräder, etc. angewandt werden. Hier besonders relevant: Beim ersten mal be-/angetrunken mit >= 0,5 Promille werden 528,50 € fällig, man bekommt 2 Punkte und einen Monat Fahrverbot. Wird entsprechend härter, je öfter man erwischt wird oder wenn man >= 1,1 Promille im Blut hat.

Zum Vergleich: Beim Fahrrad gilt erst das Führen des Fahrzeugs ab 1,6 Promille als Straftat, was selbst dann keinen Fahrverbot mit sich zieht, sondern "lediglich" eine MPU. Das gilt analog auch für Pedelecs, also E-Bikes mit Trittunterstützung bis 25 km/h.

Ich persönlich sehe jetzt zwischen einem (E-)Bike und einem Roller keinen relevanten Unterschied, was das Gefahrenpotential bei betrunkenem Führen betrifft. Eher sehe ich Fahrräder noch als gefährlicher an, so muss man zwar treten statt einen Hebel zu betätigen, aber dafür fahren E-Scooter legal maximal 22 km/h (inklusive Toleranz) und bremsen bergab auch selbstständig weitmöglichst runter.

Nun kann man aufgrund dieser Sichtweise in zwei Richtungen gehen: Entweder die sehr harten Grenzen der E-Scooter auch auf Fahrräder anwenden oder andersherum. Ich bin ganz klar für letzteres.

"Oi mate, I wonder if this codebase uses color or colour. Anyway, push to PROD. "

str(float("100.0")) + "%"

This is exactly how it's supposed to work in a functioning democracy.

Where ideally everyone, but at least a critical percentage of citizens is educated enough to recognize the pattern of deceit and false, but easy answers to very complex questions from extremist parties.

Where established parties don't feel the need to pander to the votes of extremist parties by cooperating and adapting points pushed by extremists.

Where the average citizen doesn't feel left out by the system and is tempted to align themselves with extremist parties in order to protest the current reality of said system.

Where the system implements safeguards to not allow the system to be taken hostage by extremists.

Would be nice, eh?

Because this repo is going viral from time to time to developers, I'm open for discussion if you want to promote a product/service in this README file. Just mail me at XXXX

Ew.

I've been tempted by Tailscale a few times before, but I don't want to depend on their proprietary clients and control server. The latter could be solved by selfhosting Headscale, but at this point I figure that going for a basic Wireguard setup is probably easier to maintain.

I'd like to have a look at your rules setup, I'm especially curious if/how you approached the event of the commercial VPN Wireguard tunnel(s) on your exit node(s) going down, which depending on the setup may send requests meant to go through the commercial VPN through your VPS exit node.

Personally, I ended up with two Wireguard containers in the target LAN, a wireguard-server and a **wireguard-client **container.

They both share a docker network with a specific subnet {DOCKER_SUBNET} and wireguard-client has a static IP {WG_CLIENT_IP} in that subnet.

The wireguard-client has a slightly altered standard config to establish a tunnel to an external endpoint, a commercial VPN in this case:

[Interface]
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Address = XXXXXXXXXXXXXXXXXXX

PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = XXXXXXXXXXXXXXXXXXXX

where

PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE

are responsible for properly routing traffic coming in from outside the container and

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

is your standard kill-switch meant to block traffic going out of any network interface except the tunnel interface in the event of the tunnel going down.

The wireguard-server container has these PostUPs and -Downs:

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

default rules that come with the template and allow for routing packets through the server tunnel

PostUp = wg set wg0 fwmark 51820

the traffic out of the tunnel interface get marked

PostUp = ip -4 route add 0.0.0.0/0 via {WG_CLIENT_IP} table 51820

add a rule to routing table 51820 for routing all packets through the wireguard-client container

PostUp = ip -4 rule add not fwmark 51820 table 51820

packets not marked should use routing table 51820

PostUp = ip -4 rule add table main suppress_prefixlength 0

respect manual rules added to main routing table

PostUp = ip route add {LAN_SUBNET} via {DOCKER_SUBNET_GATEWAY_IP} dev eth0

route packages with a destination in {LAN_SUBNET} to the actual {LAN_SUBNET} of the host

PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip route del {LAN_SUBNET} via {DOCKER_SUBNET_GATEWAY_IP} dev eth0

delete those rules after the tunnel goes down

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT

Basically the same kill-switch as in wireguard-client, but with the mark manually substituted since the command it relied on didn't work in my server container for some reason and AFAIK the mark actually doesn't change.

Now do I actually need the kill-switch in wireguard-server? Is the kill-switch in wireguard-client sufficient? I'm not even sure anymore.