Beiträge von ckd

    Exakt das ist das Thema. CPU rödelt auf den Routern bei 99% Auslastung weil über den Tunnel Backups laufen.
    Daher geht es schon primär um mehr CPU-Leistung. Und um Router, die vielleicht tatsächlich mit mehr als einem Core umgehen können und die S2S-Verschlüsselung nicht nur auf einem Core abarbeiten… Meint: auch mit einer 192 Core-CPU kann man da erstaunlich schlechte Ergebnisse erzielen.

    Das weiß ich ja und da bin ich ja mit 50 MBit down längst, da gehen mit Kompression auch mal 7-8 MB/s drüber. Da ist aber Ende der Fahnenstange - nicht nur für das VDSL sondern vor allem auch für die CPU des Routers. Mir geht es da eher um Faktor 20 bis 200. Natürlich i.d.R. verteilt aber im Maximum auch auf einer Verbindung bis 1 GBit/s oder 10 Gbit/s.

    Protectli ist schonmal ein Ansatz, da sieht man auch etliche Modelle mit real 1GBit+-Durchsatz, bei knapp über 4 GBit ist mit IPSec (5 GBit mit Wireguard) aber definitiv auch mit dem größten Gerät Schluss.

    Die Sophos Appliances koennen das, dank eines dedizierten Chips der die FastPath-Beschleunigung macht. Selbst die kleinsten Appliances sind dort mit 6 GBit/s angegeben bei IPsec Passthrough. Die spannende Frage, was ist dir das wert -- denn unter 4k im Jahr kommste da nicht weg und die Hardware Appliances wurden absichtlich inkompatibel gemacht mit der (kostenlosen) Softwareversion. ^^

    https://www.sophos.com/de-de/products/next-gen-firewall/xgs-smb-branch-office-firewalls

    Verschlüsselung muss keine Bremse sein. Realistisch ist "wirespeed", wenn man die Hardware geeignet auswählt. Die Verschlüsselung wird allerdings oft im Software-Pfad von der CPU erledigt, und die ist immer noch meist nur gerade schnell genug zum Pakete schubsen, nicht um die Daten irgendwie zu verarbeiten. Viele nicht mehr ganz frische CPUs scheitern ohne Hardware-Offloading sogar schon am reinen Durchleiten der Pakete, wenn es in Richtung Gigabit geht.

    FastPath‑Beschleunigung für IPsec VPN haben mittlerweile viele Hardwarehersteller fuer Firewalls, um genau diesen Effekt abzumildern.

    Das ist beispielweise auch der Grund, warum du bei aktivem IPsec VPN auf den Smartphones dem Akku beim Fallen zuschauen kannst -- viele Firmen haben das bis heute nicht auf dem Schirm, wenn die Chefs mal wieder mit ihren Apple Geraeten rumposen. :)

    Aber gibt es da auch etwas, was real (annähernd) 1 GBit/s über einen IPSec-S2S-Tunnel schiebt?

    Der Flaschenhals ist die Verschluesselung von IPsec, weniger die Hardware. Der realistische Durchsatz liegt bei etwa -- oder besser gesagt, "nur" 75 MBit.

    Vergleich doch mal die Hardware gaengiger Firewallprodukte, dort wird der IPsec Passthrough fast immer mit angegeben, i. d. R. zwischen 50 und 100 MBit, je nach Verschluesselungsalgorithmus und sonstigen Sicherheitsfeatures. Ist wie bei einem Proxy auch, wenn IPS/IDS, Virenscanner usw. dazwischengeschaltet werden.

    Luefterlose Hardware gibt es en masse, selbst Cisco bietet mit der CBS 250 Reihe luefterlose managed Switches fuer das Buero an. Anbieter wie Protectli bieten dann die Hardware fuer den Proxmox Hypervisor / Hardware Firewall / Linux Server, ebenfalls passiv gekuehlt. Ein kleiner Luefter direkt ueber der passiv gekuehlten Hardware in einem kleinen Netzwerkschrank bewirkt dann wahre Wunder. In meinem Buero ist es schon seit Jahren fluesterleise, keine aktiven Komponenten mehr.

    @sudoNoSleep  DiamantThomy und fvbor

    Ich hab nichts gegen Wordpress. Ich lass jeden mit dem arbeiten womit er oder sie happy ist. Und ich lass jeden seine Meinung sagen und würde mich nie darüber aufregen, schon garnicht stellvertretend. Ich hab auch überhaupt nichts dagegen dass ein WordPress Benutzer zu Ostern froh ist. Kann ich irgenjemandem ein bisschen Beruhigungstee verkaufen - vielleicht auf einer schönen Elementor Seite mit PayPal und ... wie hiess das Plugin noch - woocommerce? und hört auf den Troll zu füttern - habt ihr keine killfile?

    Also ich gehe zum Angeln (Bashen von fehlerhafter Software) immer ins Heise Forum, weil dort die Fische besser beissen. *SCNR* :)

    09.jpg

    Falls es jemanden interessiert, hier die Kommunikationsbeziehungen FQDN fuer Let's Encrypt (Firewall ausgehend).

    Wer ueber DNS TXT Eintraege seine Zertifikate verifizert, benoetigt keine eingehenden Firewall Regeln fuer Let's Encrypt, lediglich der FQDN eures Anbieters z. B. Cloudflare (api.cloudflare.com) muesst ihr noch in euer ausgehendes Firewall Regelwerk einpflegen. Der Rest erledigt dann euer Certbot.

    • acme-staging-v02.api.letsencrypt.org
    • acme-staging.api.letsencrypt.org
    • acme-v01.api.letsencrypt.org
    • acme-v02.api.letsencrypt.org
    • c.lencr.org
    • e5.o.lencr.org
    • e6.o.lencr.org
    • e7.o.lencr.org
    • e8.o.lencr.org
    • e9.o.lencr.org
    • i.lencr.org
    • letsencrypt.org
    • outbound1.letsencrypt.org
    • outbound2.letsencrypt.org
    • r10.o.lencr.org
    • r11.o.lencr.org
    • r12.o.lencr.org
    • r13.o.lencr.org
    • r14.o.lencr.org
    • ye1.o.lencr.org
    • ye2.o.lencr.org
    • ye3.o.lencr.org
    • yr1.o.lencr.org
    • yr2.o.lencr.org
    • yr3.o.lencr.org

    Und mit diesem Script koennt ihr euch dann noch (automatisiert) alle moeglichen Zertifikatsformate generieren:

    FDE (Full Disk Encryption) erhoeht den Aufwand fuer alle potentiellen Angreifer erheblich, nicht nur fuer Netcup. Wir haben in der Vergangenheit ja schon diverse Exploits gesehen, mit denen die Grenzen zwischen verschiedenen VMs und zwischen VM und Host ueberwunden worden sind. Absolute Sicherheit vor Angreifern mit grossen Resourcen kann niemand garantieren, aber wenn ich die Huerden erhoehe, lohnt sich der Angriff auf mich hoffentlich nicht mehr.

    Falls es jemanden interessiert: Ich benutze FDE ueberall, wo es irgendwie geht. Aber ich lasse Trim auf die LUKS-Container zu. Der theoretische Informationsabfluss dadurch ist so minimal, dass die positiven Aspekte des Trim ueberwiegen. (Keywords "luks,discard" in /etc/crypttab)

    So lange die Maschine laeuft, macht es keinen grossen Unterschied, ob verschluesselt oder nicht. In dem Moment, wo ein Angreifer aus einer VM ausbricht und den Hypervisor kompromittiert, hast du verloren. Generell macht man sich das Leben einfacher, in dem man nichts, was den Schutzbedarf "Normal" uebersteigt, extern betreibt. So lange das Backupkonzept steht und auch funktioniert, ist der Verlust solcher Systeme in Folge einer Kompromittierung zu vernachlaessigen. Sicherheitsluecke schliessen, Backup zurueckspielen und die Auswirkungen der Kompromittierung bewerten und Massnahmen ergreifen, bevor man wieder online geht. Full Disk Encryption wuerde ich nur bei Serversystemen mit Schutzbedarf "Hoch" in Erwaegung ziehen und auf jeden Fall ausschliesslich On-Premise betreiben.

    Bei temporaerem Austausch der eigenen personenbezogenen Daten ueber Nextcloud, Owncloud, Opencloud oder was auch immer, wuerde ich zuerst alles mit PGP verschluesseln, bevor es dort reinwandert.

    D.h. ich hätte für meine WireGuard Verbindung 4 (?) Regeln, 2 Incoming, 2 Outgoing?

    Korrekt. Und zwar einmal mit deiner WAN IP-Adresses deines Servers als Quelle und einmal als Ziel, also insgesamt 8 Regeln.

    Ich hatte selbst, lange mit der Netcup Firewall gekaempft und mich gefragt, warum die so komisch tickt. Bei \I\O\N\O\S oder \O\V\H war das irgendwie einfacher, weil die Firewall die Kommunikationsbeziehungen selbst uebernommen hatte, wenn man die Richtung korrekt vorgegeben hatte. Die Firewall von Netcup verwirft jedoch saemtlichen, nicht explizit freigegeben UDP-Traffic, weil true stateless. Du musst also auch die Antwort des Ziels auf deinen UDP-Traffic mit einkalkulieren, sonst erhaelt dein Client keine Antwort vom WireGuard Server. :)

    Im Gegensatz zu TCP, musst du bei UDP die Regeln immer in beide Richtungen anlegen und das jeweils fuer Ziel- und Quellport. Hier ein Screenshot als Beispiel fuer DNS. Es sind acht Regeln insgesamt, vier Regeln mit der WAN IP-Adresse des Servers als Quelle und vier Regeln mit der WAN IP-Adresse des Servers als Ziel. Die beiden DNS-Server sind von DNS4EU mit dem DNS-Port UDP 53. Nun brauchst du nur noch das Regelwerk als Schablone fuer deine UDP-Regeln zu uebernehmen.

    image.png

    Gleiches Prinzip bei NTP (UDP 123) ohne konkrete Ziel IP-Adresse des NTP-Servers:

    image.png

    Das ist meine Default Policy:

    image.png

    Bei TCP ist das erheblich einfacher, hier am Beispiel fuer SMTP:

    image.png

    Wenn ihr ein Groupware mit E-Mail + Kalender + Kontakte + Notizen ganz offiziell ueber EAS/EWS sucht, dann soltet ihr euch mal Grommunio anschauen. Die Community Version ist kostenlos bis 5 User und das ganze ist auch noch Opensource. Funktioniert dann ganz offiziell ueber Outlook oder Android/iOS ohne Add-Ons oder zusaetzliche Apps, sondern ganz offiziell ueber die Exchange Schnittstelle.

    Ich hatte viele Jahre den kostenlosen DDNS von Cloudflare genutzt (bis ich meine statische IP-Adresse bekommen hatte). Quasi alles aus einer Hand... Reverse Proxy... DNS... Zero Trust... DMARC... DDNS... DNSsec... WAF...

    https://www.cloudflare.com/learning/dns/glossary/dynamic-dns

    Die Anbindung an Cloudflare geschah dann ueber den DDclient auf meiner Linux Kiste mit Shorewall + Squid, spaeter dann mit Sophos Firewall SG / Sophos Firewall XG.

    Man sollte uebrigens keine GUI auf der WAN-Schnittstelle exposen... immer ein IPsec dazwischenschalten!

    Die Idee mit der statischen IP kam mir, als die externen Kosten fuer Webhosting 2015 durch die Decke gingen (> 150 EUR pro Monat) und man seine Infrastruktur dennoch State-of-the-art (SOTA) deployen wollte -- quasi wie im Job auch und damit der Business Anschluss unterm Strich einfach guenstiger war. Im Vergleich zu DE waren die Stromkosten hier ueber viele Jahre gigantisch niedrig und zwar im einstelligen Centbereich. Mittlerweile zahlen wir ja auch unsere 23 Cent... scheiss EU-Regulierung. :/

    Lohnt sich im Hobby-Bereich meiner Meinung nach einfach nicht, da der Aufwand für Reputation und Absicherung am Ende in keinem Verhältnis zum Nutzen steht. Korrigiert mich gern, falls ich damit danebenliege. :)

    Na ja, das Thema Mail ist die letzten Jahre schon erheblich einfacher geworden, es ist keine Raketenrechnik und mit der richtigen Anleitung mittlerweile sogar ein Heimspiel, selbst fuer Hobbyisten. Das ISPmail Tutorial von Christoph Haas ist einfach genial und kann ich nur jedem empfehlen, der gute Grundkenntnisse auf der Shell hat.