Messages

1

German - Deutsch / Re: Viele Ports <--DNAT--> Viele IPs scripten oder API möglich?

« on: September 09, 2022, 06:29:09 pm »

Ach ja, es sind neue Mappings, weil einige Ihre Server noch etwas weiterverwenden und ich denen die nicht unterm Hintern abschalten möchte. Ich mag es außerdem übersichtlich und es gibt genügend Ports, so dass ich ein Schema etabliert habe, dass es mir bis ins Jahr 2065 erlaubt, auf den ersten Blick aus IP, Port oder Hostname die anderen Werte zu erzeugen...

2

German - Deutsch / Re: Fragen zu Letsencrypt, FQDNs, HA Proxy

« on: September 09, 2022, 06:10:11 pm »

Im Grunde störe ich mich in allererster Linie an der Warnung des selbst erzeugten Zertifikats.
Aber nun wird die Baustelle immer größer, nur weil ich zu bequem bin, um mir das Root-Zertifikat meiner CA auf eine handvoll Geräte zu packen.
Scheint irgendwie kein guter Deal zu sein wenn die Zeit ein kostbares Gut ist   

Gibt es einen Weg, wie man diese Zertifikate in der Kommunikation "anbieten" kann? -- So nach dem Motto: "Mein Service --> meine Regeln!"   --- Dann könnte man auf den Endgeräten selbst entscheiden, ob oder ob nicht man meiner CA vertrauen möchte.

Das ist schonmal sehr gut, dass du dich daran störst, es gibt nichts schlimmeres als sich anzugewöhnen, da Ausnahmen hinzuzufügen. Dann merkt man nämlich nicht, wenn jemand dazwischen sitzt.
Es ist kein Riesenaufwand, das Root-Cert auf Geräte zu packen. Bei Windows geht das sogar per Gruppenrichtlinie, falls du AD hast. Aber auch sonst, du legst es irgendwo zugänglich ab, z.B. in einem Netzlaufwerk, USB-Stick oder auf einem Webserver und man importiert es eben einmal in den Browser oder wo auch immer man es braucht. Dauert keine 2 Minuten.

3

German - Deutsch / Re: Fragen zu Letsencrypt, FQDNs, HA Proxy

« on: September 09, 2022, 05:53:04 pm »

Jag doch alles, auch von innen, durch den Proxy mit Letsencrypt. Das schadet doch nicht.

Ansichtssache. Entweder man ver- und entschlüsselt doppelt so oft, das kostet dann Rechenleistung, vor allem, wenn der Proxy etwas älter ist und kein AES-Support im Prozessor hat. Das wird das bei entsprechendem Traffic im LAN schnell zum Flaschenhals, z.B. für Nextcloud o.Ä., wo ordentlich Daten durchgeschaufelt werden.
Oder man hat alles zwischen Proxy und Host unverschlüsselt, incl. Logindaten usw. Wenn dann mal eine Komponente hochgenommen wird, kommt der Angreifer auch anschließend wirklich überall dran.

4

German - Deutsch / Re: Viele Ports <--DNAT--> Viele IPs scripten oder API möglich?

« on: September 09, 2022, 05:42:17 pm »

Das ist tatsächlich so etwas wie Hosting, nur mit beschränkten Mitteln aber dafür für einen guten Zweck. Dient der Lehre. Studierende bekommen je Semester eine eigene VM (genauer einen Container...) um sich mit Internettechnologien vertraut zu machen. Es sind auch nicht 255 sondern weniger, ich richte aber immer 255 ein, damit ich nicht später nochmal nachlegen muss. Mir ist klar, dass ein /24 Block die Sache vereinfachen würde, aber ist gerade nicht verfügbar und auch eigentlich nicht nötig. HTTP geht mit einer externen IP per Subdomain über einen Proxy auf die entsprechende VM. Die Proxy-Config erzeuge ich auch per Script.
SSH wird per Port zugeordnet. Da können die gleich mal lernen, ssh -p12345 zu benutzen, dann hat man auch nicht so viele Loginversuche von irgendwelchen Kaspern im auth.log wie bei Port 22.
VPN wäre eine Alternative, aber das macht die Sache komplizierter und das möchte ich ungern supporten müssen ("So, jetzt zeige ich euch mal 3 Stunden auf 37 unterschiedlichen Betriebssystemen, welche Besonderheiten es beim Einrichten eines VPN gibt...").
IPv6 wäre evtl. eine Option.
Doppeltes NAT ginge auch: Portrange auf OPNSense weiterleiten an VM-Nat mit iptables, da dann Port->IP:22 scripten.
Ich bin aber eigentlich gar nicht auf der Suche nach Alternativen, sondern nach einem Verfahren, das mir mit OPNSense erlaubt, was mit iptables eben auch ganz einfach funktioniert. Wäre ja zu schön, wenn man per API an die Portweiterleitung  rankäme, alles andere ist doch irgendwie Gebastel.

5

German - Deutsch / Re: Viele Ports <--DNAT--> Viele IPs scripten oder API möglich?

« on: September 02, 2022, 01:05:37 pm »

Scheint nicht so eine typische Fragestellung zu sein. Ich probiere es noch kurz, und falls es nicht funktioniert bleibt mir nur bei iptables zu bleiben, zumindest für diese Aufgabe.

6

German - Deutsch / Re: Fragen zu Letsencrypt, FQDNs, HA Proxy

« on: September 02, 2022, 12:58:07 pm »

Oh weh, nun hast du mich komplett abgehängt.   

Du hast ja auch mit einer ganzen Liste von Problemen mit vielen unbekannten Faktoren losgelegt.

Die OPNsense ist aber "leider" ebenfalls von außen erreichbar. Das möchte ich ganz sicher nicht!

Kann ich die OPNsense selbst auf einen anderen Port legen, und dann über den HA Proxy darauf zugreifen, so dass ich mir den Port nicht merken muss?  --- Oder klappt das nur mit Weiterleitungen an externe Services?

Schau doch als erstes mal unter System->Settings->Administration nach, ob Listen Interface auf LAN gesetzt ist.

Als nächstes entscheidest du dich, ob deine Clients aus dem LAN direkt auf die Server zugreifen sollen oder über HA Proxy.

7

German - Deutsch / Re: Fragen zu Letsencrypt, FQDNs, HA Proxy

« on: September 01, 2022, 04:35:19 pm »

Ok, das liegt an der Mehrfachbelegung des Begriffs "Hostname".
Irrelevant ist, was der Befehl hostname oder hostname -fqdn auf dem Host ausgibt (macht es aber übersichtlicher). Wichtig ist, dass der DNS-Eintrag für den Host mit dem FQDN im Zertifikat übereinstimmt. Sowohl intern als auch extern.
Zu dem weiteren Teil meiner Aussagen, muss ich einschränken, dass ich von einem Szenario ausgegangen bin, wo der Traffic aus dem LAN nicht über den HAProxy läuft. Folglich kann auch der HA-Proxy nicht auf magische Weise gültige Schlüssel an die Server verteilen.
Wer spricht mit wem:

Code: [Select]

        WAN
           |
         OPNSEnse und HAProxy
           |         |
      Clients----Server
Was micneu mit

wie du die zertifikate von LE auf deinen webserver bekommst: garnicht da kümmert sich der HAProxy drum, denn der macht das alles (selbst den redirect von 80 —> 443

glaube ich meinte würde eher so aussehen

Code: [Select]

        WAN
           |
         OPNSEnse und HAProxy
           |         |
      Clients    Server
Der Unterschied ist, ob dein lokales DNS die FQDN vom LAN aus auf den HAProxy auflöst oder auf deine Server.
Wenn auf HAProxy, pro: musst dir um anerkannte Schlüssel auf den Servern keine Gedanken machen, machst CA, signierst selbst Certs und importierst CA-Cert im Proxy. Con: gesamter HTTPS-Traffic aus LAN über Proxy.
Wenn du FQDN auf die Server auflöst, dann brauchen die alle ein gültiges Zertifikat, dafür LAN HTTPS Traffic direkt zwischen Client und Server.

8

German - Deutsch / Re: Fragen zu Letsencrypt, FQDNs, HA Proxy

« on: August 31, 2022, 07:56:53 pm »

Ich les mal gespannt mit, das Thema kommt auf mich auch noch zu. Ich hab leider noch keine großartige Erfahrung diesbezüglich, mit OPNSense, kann dir aber allgemein ein paar Fragen beantworten, wie das allgemein oder bei meinem jetzigen, strukturell ähnlichen System funktioniert.
Vorweg: Die LE Zertifikate sollen dem Client/Browser bestätigen, dass Domainname und Seitenbetreiber zusammengehören. Wenn sie das nicht mehr tun, wird dein Browser das für ungültig/Betrug halten. Du kannst z.B. nicht ein Zertifikat für hanswurst.de beantragen und dich dann als Sparkasse-Hamburg.de bezeichnen.
Insofern sollten die internen Maschinen unter den Domains, die in ihren Zertifikaten stehen, erreichbar sein.
Ausschlaggebend ist, was im DNS steht, nicht der Hostname der Maschine.
Zu Problem 1 und 2:
Es gibt (meiner Meinung nach mindestens) 2 Wege, um den Traffic bis zu den Internen zu verschlüsseln:
1. Alles mit FQDN (intern und extern gleich) und die Zertifikate vom Proxy aus bei LE anfordern und auf die Internen kopieren (Cron-Job). Pro: Alle Clients akzeptieren auch intern automatisch die Zertifikate. Con: Cron-Jobs nicht immer möglich, dann muss man Zertifikate kopieren und je nach Vertrauenswürdigkeit der internen Maschinen auch den Zugriff auf andere Zertifikate unterbinden usw.
2. eigene Domain intern lassen und selbst CA erstellen, selbst für die Internen Zertifikate erstellen und mit der CA signieren (z.B mit XCA). CA-Cert bei OPNSense hinterlegen. Von Proxy dann LE Certs für Verbindungen nach außen anfordern.
Pro: Keine Kopiererei, Zertifikate länger gültig (einstellbar). Zertifikate auch für nur interne Server erhältlich. Con: Alle Clients/Browser müssen erstmal einmalig das CA-Zertifikat importieren, bevor sie die damit signierten Zertifikate akzeptieren.
Zu 3: Das wäre jetzt raten. Hast du https:// genommen? Fehlt ein redirect 80->443? Hast du mod_ssl aktiviert? Was sagen die Logs, ist das hier überhaupt das richtige Forum?
Zu 4: Ohne das je mit OPNSense gemacht zu haben, würde ich behaupten: Ja das geht, sofern du darauf verzichten kannst, den Proxy am LAN Interface lauschen zu lassen. Deine OPNSense bekommt einen Namen und ein zugehöriges Zertifikat, einen internen DNS-Eintrag und eben keine Regel im Proxy. Wenn du die Admin-Seite aus dem LAN besuchen willst, antwortet OPNSense, von WAN kommt keiner dran, weil es keine Proxy Regel gibt. Du solltest beim Admin Interface einstellen, dass es nur aus dem LAN erreichbar ist. Sicherheitshalber von außen (Handy...) mit an- und abgeschaltetem Proxy prüfen.

9

German - Deutsch / Re: Probleme mit Unbound und DNS-Auflösung

« on: August 31, 2022, 06:59:02 pm »

Könnte gut am Client, bzw. dessen DNS-Config (primärer/sekundärer DNS Server extern?) oder DNS-Cache liegen. VPN ist auch super für sowas. Was sagt

Code: [Select]

dig <falsch_aufgelöste_domain> woher die externe IP kommt?

Das ist ein schwieriges Setup mit mehreren DNS-Servern (Extern/Intern), die für die gleiche Domain zuständig sind.

10

German - Deutsch / Viele Ports <--DNAT--> Viele IPs scripten oder API möglich?

« on: August 31, 2022, 05:45:39 pm »

Moin zusammen,

ich teste gerade OPNSense auf Tauglichkeit, mein etwas angestaubtes iptables-System zu ersetzen. Soweit ich das beurteilen kann, lässt sich nur eine Aufgabe noch nicht zufriedenstellen lösen:
Ich möchte eine Vielzahl von Servern in meinem LAN mit unterschiedlicher IP und gleichem Port per SSH von außen über eine gemeinsame WAN-IP, dafür mit unterschiedlichen Ports zugänglich machen. Anders gesagt: Jeder Nutzer kann seinen Server über die eine gemeinsame WAN-IP mit einem eigenen SSH-Port erreichen.
Ich muss also regelmäßig einen WAN-Port-Bereich auf einen LAN-IP-Adressbereich per DNAT weiterleiten., z.B
203.0.113.123:{1...255} <----->  172.16.31.{1...255}:22
Ich habe aber keine Zeit, regelmäßig 255 Portweiterleitungen per Weboberfläche anzulegen.
Mit iptables lässt sich so etwas in in bash scripten, z.B.

Code: [Select]

for(( i=1;i<256;i++))
do
let sshport=$i+31000;
iptables -t nat -A PREROUTING -p tcp -d 203.0.113.123 --dport $sshport -j DNAT --to 172.16.31.$i:22
done
Geht so etwas auch mit OPNSense?
Ich habe bisher folgendes herausgefunden:

• Die OPNSense API kennt, soweit ich das sehe,  von der Firewall leider nur Aliase und Kategorien, aber nicht NAT. s. https://docs.opnsense.org/development/api/core/firewall.html Steckt das evtl. irgendwo anders?
• Ein neuer NAT Eintrag wird in der Weboberfläche per PHP erzeugt, s. https://github.com/opnsense/core/blob/master/src/www/firewall_nat_edit.php - da könnte man zur Not was basteln, aber der Code muss dann regelmäßig mit OPNSense zusammengeführt werden und es erscheint mir auch recht umfangreich für das Problem.
• Händisch in der Weboberfläche angelgte DNAT Einträge landen als rule-Tag in /conf/config.xml. Wenn das alles ist, was man braucht, ließen sich die rule-Tags per Script erzeugen. Ich hätte allerdings Angst, die associated-rule-id-Tags außerhalb des Systems zu erzeugen. Nicht, dass man da Kollisionen erzeugt oder das irgendwie nicht passt. Ich weiß auch nicht, ob die associated-rules nicht irgendwo angelegt werden müssten.
• HAProxy ist glaube ich nicht das Mittel der Wahl, ich will ja nicht die Last verteilen, sondern eine persistente 1:1 Zuordnung von WAN-Port <----> LAN-IP bekommen.

Fällt euch noch etwas ein? Wie würdet ihr das angehen?
                                                             
Vielen Dank!