Hallo zusammen,

ich habe mich ein bisschen mit INN2 beschäftigt, bin da aber noch
blutiger Anfänger.
Ich habe einen INN2 auf meinem Homeserver auf Port 119 nun aufsetzen
können und kann mich auch ohne SSl von aussen über meine pfsense
verbinden (Port 119 einfach weitergeleitet auf die entsprechen VM auf
der INN2 läuft).
Da ich einen HAPROXY laufen habe auf der pfsense die mir das Lets's
Encrypt Wildcard Zertifikat entsprechend holt und die Adressen
entsprechend auf die VMs verteilt, wäre es super, wenn ich das auch mit
INN2 machen könnte. Leider bekomme ich es nicht hin.
Falls jemand so eine Konfiguration laufen hat und mir die entsprechenden
Einstellung zukommen lassen könnte für die HAPROXY Konfiguration wäre
das super.
Mir ist bewusst das ich auch einfach Port 563 durchleiten könnte, aber
dann müsste ich irgendwie das Zertifikat von der pfsense in die VM
kopieren und da entsprechend aufarbeiten das es akzepiert wird.
Mir schwebte eher vor das man irgendwie im HAPROXY Port 563 mit dem Lets
Encrypt Wildcard Zertificat verknüpft und dann auf das Backend (VM mit
INN2) auf Port 119 weiterleitet. Das habe ich aber nicht hinbekommen
bzw. hat so leider nicht geklappt, das wäre schön einfach gewesen (quasi
SSL bis zur Firewall, bei mir intern dann ohne SSL).
Falls jemand noch einen Tipp hat wie ich das auf meinem Homeserver
hinbekomme bzgl. INN2 mit SSL und Lets's Encrypt Zertifikat wäre ich
sehr dankbar. Ansonsten muss ich ihn ohne SSL und im Heimnetz belasssen
und eventuell nur über VPN zugreifen.

Vielen Dank schon mal im voraus.

Gruss

Christian

Christian Peters wrote:

>ich habe mich ein bisschen mit INN2 beschäftigt, bin da aber noch
>blutiger Anfänger.
>Ich habe einen INN2 auf meinem Homeserver auf Port 119 nun aufsetzen
>können und kann mich auch ohne SSl von aussen über meine pfsense
>verbinden (Port 119 einfach weitergeleitet auf die entsprechen VM auf der
>INN2 läuft).

Eigentlich nur sicherheitskritisch bezüglich der Passworte, um schreibend
posten zu können.

Wenn Du dem INN2 eine eigene Nutzerdatenbank mit eigenständigen
Passwörtern spendierst, m.E. kein Problem.

Das Passwort schützt dann keinen Shell-Zugang o.ä. Um es zu erhalten,
müßte man an der Verbindung mitlauschen.

Die geposteten Artikel sind ohnehin öffentlich, es sei denn du betreibst
eigene Newsgruppen mit eigener Disribution, was aber weit weg vom Standard
ist.

Kostenfreie Newsaccounts mit Schreibrechten gibt es Einige. Selbst
bezahlte Accounts sind so etwa 10 € im Monat.

Um dein Passwort, selbst ohne SSL, abzuhören, müsste ein Angreifer weit
mehr als diese 10 € aufwenden.

>Da ich einen HAPROXY laufen habe auf der pfsense die mir das Lets's
>Encrypt Wildcard Zertifikat entsprechend holt und die Adressen
>entsprechend auf die VMs verteilt, wäre es super, wenn ich das auch mit
>INN2 machen könnte. Leider bekomme ich es nicht hin.

Hast du jetzt echt Bedarf an Lastverteilung?

Ansonsten kennt die pfsense ein stunnel Paket. SSL bis zur pfsense und von
dort ungesichert zum Newsserver.

>Falls jemand so eine Konfiguration laufen hat und mir die entsprechenden
>Einstellung zukommen lassen könnte für die HAPROXY Konfiguration wäre
>das super.
>Mir ist bewusst das ich auch einfach Port 563 durchleiten könnte, aber
>dann müsste ich irgendwie das Zertifikat von der pfsense in die VM
>kopieren und da entsprechend aufarbeiten das es akzepiert wird.
>Mir schwebte eher vor das man irgendwie im HAPROXY Port 563 mit dem Lets
>Encrypt Wildcard Zertificat verknüpft und dann auf das Backend (VM mit
>INN2) auf Port 119 weiterleitet. Das habe ich aber nicht hinbekommen bzw.
>hat so leider nicht geklappt, das wäre schön einfach gewesen (quasi SSL
>bis zur Firewall, bei mir intern dann ohne SSL).

Ich würde es, wie gesagt, mit stunnel versuchen, nicht mit HAPROXY. Ohne
Notwendigkeit der Lastverteilung und Ausfallredundanz, kein Bedarf.
HAPROXY liest vom Design her, http: mit und verteilt entsprechend.

Mit Notwendigkeit von Lastverteilung und Ausfallredundanz ist es mit einer
pfsense ohnehin nicht erledigt.

>Falls jemand noch einen Tipp hat wie ich das auf meinem Homeserver
>hinbekomme bzgl. INN2 mit SSL und Lets's Encrypt Zertifikat wäre ich sehr
>dankbar. Ansonsten muss ich ihn ohne SSL und im Heimnetz belasssen und
>eventuell nur über VPN zugreifen.

Bei mir hat sich die Nutzung von zunächst Port 433 für den inn bewährt.
Port 119 und 563 werden vom xinetd abgehört, die direkt den nnrpd starten.

Der Vorteil für mich ist, dass ich über die ssh zu einem Newsserver
tunneln kann der hinter Carrier-Grade-NAT mit dynamischer Adresse
"versteckt" ist.

Zusätzlich gibt es Vorteile bei der Unterscheidung des "Anrufwunsches".
Normalerweise unterscheidet der inn über die "anklopfende" IP-Adresse, ob
das Newsserver <--> Newsserver oder Newsserver <--> Newsreader ist.

Dumm, wenn das zwar im Heimnetz unterschiedliche Adressen sind, aber schon
ein einfaches NAT durch eine z.B. Fritzbox diese Adressen zusammenführt,
geschweige denn mit doppeltem CG-NAT und NAT im Heimnetz.

Peter

Am 29.10.23 um 22:09 schrieb Peter Heirich:
> Christian Peters wrote:
>
>> ich habe mich ein bisschen mit INN2 beschäftigt, bin da aber noch
>> blutiger Anfänger.
>> Ich habe einen INN2 auf meinem Homeserver auf Port 119 nun aufsetzen
>> können und kann mich auch ohne SSl von aussen über meine pfsense
>> verbinden (Port 119 einfach weitergeleitet auf die entsprechen VM auf
>> der INN2 läuft).
>
> Eigentlich nur sicherheitskritisch bezüglich der Passworte, um
> schreibend posten zu können.
>
> Wenn Du dem INN2 eine eigene Nutzerdatenbank mit eigenständigen
> Passwörtern spendierst, m.E. kein Problem.
>
> Das Passwort schützt dann keinen Shell-Zugang o.ä. Um es zu erhalten,
> müßte man an der Verbindung mitlauschen.
>

Ja, das stimmt. Es sind ja eigene Passwörter, das hatte ich gar nicht
mehr auf dem Schirm.

> Die geposteten Artikel sind ohnehin öffentlich, es sei denn du betreibst
> eigene Newsgruppen mit eigener Disribution, was aber weit weg vom
> Standard ist.

Das war eventuell die Idee, den Server als privaten "Safe" für
Anleitungen oder auch pdf zu nutzen die ich aufheben und einfach im
Zugriff haben möchte. Aber nach lesen deiner Antwort denke ich auch das
es an der Sache eine Newsservers vorbei geht. Der Ringbuffer und die
Idee das es ja eigentlich öffentlich sein sollte schlägt sich im Konzept
nieder und so sollte der Newsserver doch auch genutzt werden bzw. ist
dafür konzipiert..
>
>> Da ich einen HAPROXY laufen habe auf der pfsense die mir das Lets's
>> Encrypt Wildcard Zertifikat entsprechend holt und die Adressen
>> entsprechend auf die VMs verteilt, wäre es super, wenn ich das auch
>> mit INN2 machen könnte. Leider bekomme ich es nicht hin.
>
> Hast du jetzt echt Bedarf an Lastverteilung?

Nein, Lastverteilung brauche ich nicht, der HA Proxy ist aber in der
Firewall drin und verteilt mir schön die Seiten auf die VMs.
>
> Ansonsten kennt die pfsense ein stunnel Paket. SSL bis zur pfsense und
> von dort ungesichert zum Newsserver.
Ja, so mache ich es dann im Zweifel wenn ich den INN rein geschlossen
für mich betrieben sollte.

>
> Bei mir hat sich die Nutzung von zunächst Port 433 für den inn bewährt.
> Port 119 und 563 werden vom xinetd abgehört, die direkt den nnrpd starten.
>
> Der Vorteil für mich ist, dass ich über die ssh zu einem Newsserver
> tunneln kann der hinter Carrier-Grade-NAT mit dynamischer Adresse
> "versteckt" ist.

Carrier-Grade-NAT: das Elend steht hier auch noch vor der Tür mit dem
demnächst kommenden Deutsche Giganetz Anschluss. Das wird dann noch mal
90% der letzten Recken vergraulen, eigene Dienste auf einem Homeserver
zu betreiben. Mir graut es schon davor wenn ich das einrichten muss da
ich einige Dienste (Matrix Server, Webseiten etc.) hier betreibe. Ich
überlege ernsthaft ob ich meinen Telekom Anschluss behalte, die
wechselnde IP4 Adresse ist gegen Carrier-Grade-NAT mit evtl. zu
betreibendem externen VPS und entsprechendem komplizierten Setup ja ein
Kinderspiel.
>
> Zusätzlich gibt es Vorteile bei der Unterscheidung des "Anrufwunsches".
> Normalerweise unterscheidet der inn über die "anklopfende" IP-Adresse,
> ob das Newsserver <--> Newsserver oder Newsserver <--> Newsreader ist.
>
> Dumm, wenn das zwar im Heimnetz unterschiedliche Adressen sind, aber
> schon ein einfaches NAT durch eine z.B. Fritzbox diese Adressen
> zusammenführt, geschweige denn mit doppeltem CG-NAT und NAT im Heimnetz.
>

Ja, das übersteigt jetzt schon fast meine Kenntnisse, es wird leider
komplizierter werden. Alles auf einen Mitserver auszulagern geht mir
aber gegen den Strich.

Ich denke ich werde dann doch mal schauen, ob ich den INN2 doch
klassisch als öffentlichen Newsserver aufsetze, aber es wird immer
schwieriger Leute zu begeistern für solche Technik: Matrix, Slack o.ä.
ist einfach beliebter....leider.

Noch mal vielen Dank für die Tipps und Anregungen.

Christian

Am 29.10.23 um 22:09 schrieb Peter Heirich:
> Christian Peters wrote:
>
>> ich habe mich ein bisschen mit INN2 beschäftigt, bin da aber noch
>> blutiger Anfänger.
>> Ich habe einen INN2 auf meinem Homeserver auf Port 119 nun aufsetzen
>> können und kann mich auch ohne SSl von aussen über meine pfsense
>> verbinden (Port 119 einfach weitergeleitet auf die entsprechen VM auf
>> der INN2 läuft).
>
> Eigentlich nur sicherheitskritisch bezüglich der Passworte, um
> schreibend posten zu können.
>
> Wenn Du dem INN2 eine eigene Nutzerdatenbank mit eigenständigen
> Passwörtern spendierst, m.E. kein Problem.
>
> Das Passwort schützt dann keinen Shell-Zugang o.ä. Um es zu erhalten,
> müßte man an der Verbindung mitlauschen.
>

Ja, das stimmt. Es sind ja eigene Passwörter, das hatte ich gar nicht
mehr auf dem Schirm.

> Die geposteten Artikel sind ohnehin öffentlich, es sei denn du betreibst
> eigene Newsgruppen mit eigener Disribution, was aber weit weg vom
> Standard ist.

Das war eventuell die Idee, den Server als privaten "Safe" für
Anleitungen oder auch pdf zu nutzen die ich aufheben und einfach im
Zugriff haben möchte. Aber nach lesen deiner Antwort denke ich auch das
es an der Sache eine Newsservers vorbei geht. Der Ringbuffer und die
Idee das es ja eigentlich öffentlich sein sollte schlägt sich im Konzept
nieder und so sollte der Newsserver doch auch genutzt werden bzw. ist
dafür konzipiert..
>
>> Da ich einen HAPROXY laufen habe auf der pfsense die mir das Lets's
>> Encrypt Wildcard Zertifikat entsprechend holt und die Adressen
>> entsprechend auf die VMs verteilt, wäre es super, wenn ich das auch
>> mit INN2 machen könnte. Leider bekomme ich es nicht hin.
>
> Hast du jetzt echt Bedarf an Lastverteilung?

Nein, Lastverteilung brauche ich nicht, der HA Proxy ist aber in der
Firewall drin und verteilt mir schön die Seiten auf die VMs.
>
> Ansonsten kennt die pfsense ein stunnel Paket. SSL bis zur pfsense und
> von dort ungesichert zum Newsserver.
Ja, so mache ich es dann im Zweifel wenn ich den INN rein geschlossen
für mich betrieben sollte.

>
> Bei mir hat sich die Nutzung von zunächst Port 433 für den inn bewährt.
> Port 119 und 563 werden vom xinetd abgehört, die direkt den nnrpd starten.
>
> Der Vorteil für mich ist, dass ich über die ssh zu einem Newsserver
> tunneln kann der hinter Carrier-Grade-NAT mit dynamischer Adresse
> "versteckt" ist.

Carrier-Grade-NAT: das Elend steht hier auch noch vor der Tür mit dem
demnächst kommenden Deutsche Giganetz Anschluss. Das wird dann noch mal
90% der letzten Recken vergraulen, eigene Dienste auf einem Homeserver
zu betreiben. Mir graut es schon davor wenn ich das einrichten muss da
ich einige Dienste (Matrix Server, Webseiten etc.) hier betreibe. Ich
überlege ernsthaft ob ich meinen Telekom Anschluss behalte, die
wechselnde IP4 Adresse ist gegen Carrier-Grade-NAT mit evtl. zu
betreibendem externen VPS und entsprechendem komplizierten Setup ja ein
Kinderspiel.
>
> Zusätzlich gibt es Vorteile bei der Unterscheidung des "Anrufwunsches".
> Normalerweise unterscheidet der inn über die "anklopfende" IP-Adresse,
> ob das Newsserver <--> Newsserver oder Newsserver <--> Newsreader ist.
>
> Dumm, wenn das zwar im Heimnetz unterschiedliche Adressen sind, aber
> schon ein einfaches NAT durch eine z.B. Fritzbox diese Adressen
> zusammenführt, geschweige denn mit doppeltem CG-NAT und NAT im Heimnetz.
>

Ja, das übersteigt jetzt schon fast meine Kenntnisse, es wird leider
komplizierter werden. Alles auf einen Mitserver auszulagern geht mir
aber gegen den Strich.

Ich denke ich werde dann doch mal schauen, ob ich den INN2 doch
klassisch als öffentlichen Newsserver aufsetze, aber es wird immer
schwieriger Leute zu begeistern für solche Technik: Matrix, Slack o.ä.
ist einfach beliebter....leider.

Noch mal vielen Dank für die Tipps und Anregungen.

Christian

Christian Peters wrote:

>Das war eventuell die Idee, den Server als privaten "Safe" für
>Anleitungen oder auch pdf zu nutzen die ich aufheben und einfach im
>Zugriff haben möchte. Aber nach lesen deiner Antwort denke ich auch das
>es an der Sache eine Newsservers vorbei geht. Der Ringbuffer und die Idee
>das es ja eigentlich öffentlich sein sollte schlägt sich im Konzept
>nieder und so sollte der Newsserver doch auch genutzt werden bzw. ist
>dafür konzipiert..

Da würde mir eher Dovecot einfallen. Der kann auch etwas anbieten was man
in Exchange "öffentliche Ordner" nennt.

Peter

Am 30.10.23 um 16:01 schrieb Peter Heirich:

> Da würde mir eher Dovecot einfallen. Der kann auch etwas anbieten was
> man in Exchange "öffentliche Ordner" nennt.
>
Ja, das wäre eine Alternative, allerdings ist das auch recht komplex
aufzusetzen.

> Bei mir hat sich die Nutzung von zunächst Port 433 für den inn bewährt.
> Port 119 und 563 werden vom xinetd abgehört, die direkt den nnrpd
> starten.

Ich habe noch mal die Idee von dir mit stunnel versucht nachzuvollziehen.
Ich habe diese Anleitung gefunden (leider von 2015):

https://wiki.freifunk.net/Newsserver_einrichten

Leider scheint das nicht mehr aktuell zu sein. stunnel scheint einen
config File inzwischen zu brauchen?

"
.....in /etc/inetd.conf eintragen

nntps stream tcp nowait root /usr/bin/stunnel stunnel -p
/usr/lib/news/cert.pem -s news -g news -r nntp

....."

Muss ich dann für /usr/lib/news/cert.pem das Cert von meinem aktuellen
Lets' Encrypt Zertifikat dann reinkopieren?
Wie müsste ein config File für Inn für stunnel aussehen?

Kannst du mir da vielleicht weiterhelfen bzw. deine config mal zukommen
lassen?
Es wäre toll wenn es man eine aktualisierte Installationsanleitung für
Inn2 mit stunnel mal wieder ins Netz bringen könnte.

Schon mal Danke im voraus.

Christian

> Kannst du mir da vielleicht weiterhelfen bzw. deine config mal zukommen
> lassen?
> Es wäre toll wenn es man eine aktualisierte Installationsanleitung für
> Inn2 mit stunnel mal wieder ins Netz bringen könnte.

Ok, ich glaube ich habe das mit stunnel falsch verstanden. Das geht wohl
nur zwischen 2 Servern/Mascheinen (Client und Server) und ich muss es
auf beiden Maschinen einrichten um zu tunneln? Das ist aber nicht das
ich will, ich will ja mit Thunderbird oder slrn von verschiedenen
Client-Masxhinen (und verschiedenen OS) zugreifen.
Da werde ich wohl doch irgendwie versuchen müssen, SSL am Inn2 direkt
einzurichten...?

Christian Peters wrote:

> Da werde ich wohl doch irgendwie versuchen müssen, SSL am Inn2 direkt
> einzurichten...?

Ist doch total einfach. Einfach das Zertifikat bzw. den Key in die Sektion:
"Reading and Posting -- TLS/SSL Support" eintragen. Und dann nur einen
nnrpd.service entsprechend starten:

# /etc/systemd/system/nnrpd.service
[Unit]
Description=NNRPD Newsreader
BindsTo=inn2.service
After=inn2.service

[Service]
Restart=on-failure
ProtectSystem=full
ProtectControlGroups=yes
ProtectHome=yes
User=news
Group=news
ExecStart=/usr/lib/news/bin/nnrpd -f -D -4 192.168.17.119 -p 563 -S
LogNamespace=news
IPAddressDeny=any
IPAddressAllow=localhost
IPAddressAllow=192.168.16.0/20
IPAddressAllow=fda6:51a:e5b5::/48

[Install]
WantedBy=multi-user.target

mfg Friedemann

Am 01.11.23 um 15:40 schrieb Friedemann Stoyan:

> Ist doch total einfach. Einfach das Zertifikat bzw. den Key in die Sektion:
> "Reading and Posting -- TLS/SSL Support" eintragen. Und dann nur einen
> nnrpd.service entsprechend starten:

Danke Friedemann,

mit dem etc/systemd/system/nnrpd.service aufsetzen hat geklappt,
aber das eintragen der Zertifikate ist leider nicht ganz so einfach.

Die pfsense holt mit dem acme Skript ein wildcard Zertificat und erzeugt
die folgenden Files:

lets_encrypt_prod.all.pem
lets_encrypt_prod.ca
lets_encrypt_prod.crt
lets_encrypt_prod.fullchain
lets_encrypt_prod.key

Mein Abschnitt der inn.conf:

# Reading and Posting -- TLS/SSL Support

tlscafile: /etc/news/cert/lets_encrypt_prod.ca
tlscapath: /etc/news/cert
tlscertfile: /etc/news/cert/lets_encrypt_prod.crt
tlskeyfile: /etc/news/cert/lets_encrypt_prod.key
#tlsciphers:
#tlsciphers13:
#tlscompression: false
#tlseccurve:
#tlspreferserverciphers: true
tlsprotocols: [ TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 ]

sslscan --show-ciphers IP:563

TLS Fallback SCSV:
Connection failed - unable to determine TLS Fallback SCSV support

TLS renegotiation:
Session renegotiation not supported

TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

Heartbleed:

Supported Server Cipher(s):
Certificate information cannot be retrieved.

Log von nnrpd:

Nov 01 23:34:26 news nnrpd[1150]: error initializing TLS: [CA_file:
/etc/news/lets_encrypt_prod.ca] [CA_path: /etc/news/cert] [cert_file:
/etc/news/cert/lets_encrypt_prod.>
Nov 01 23:34:26 news nnrpd[1150]: times user 0.003 system 0.000 idle
0.000 elapsed 0.003
Nov 01 23:34:26 news nnrpd[1150]: time 3 nntpwrite 0(1)

Das Zertifikat wird irgendwie nicht genommen. Müssen die umbenannt
werden, funktionieren die in der Form nicht mit INN...?

Mit einem selfsigned Zertifikat komme ich ein Stück weiter:

openssl req -new -x509 -nodes -out -nodes -out /etc/news/cert/cert.pem
-days 366 -keyout /etc/news/cert/key.pem

sslscan --show-ciphers IP:563

alles ok!

Log von nnrpd:

Nov 02 00:34:02 news nnrpd[1220]: ? reverse lookup for 10.0.1.2 failed:
Name or service not known -- using IP address for access
Nov 02 00:34:02 news nnrpd[1220]: 10.0.1.2 (10.0.1.2) connect - port 563
Nov 02 00:34:02 news nnrpd[1220]: 10.0.1.2 failure to negotiate TLS session
Nov 02 00:34:02 news nnrpd[1220]: 10.0.1.2 times user 0.022 system 0.006
idle 0.000 elapsed 0.058

Ich hoste den Server zuhause, hier Access via VPN. Reverse lookup wird
nicht gehen, ist das das Problem...?
Ich fürchte das ganze ist zu komplex und übersteigt meinen Horizont. :-D

Gruss

Christian

Christian Peters wrote:

>
>Ok, ich glaube ich habe das mit stunnel falsch verstanden. Das geht wohl
>nur zwischen 2 Servern/Mascheinen (Client und Server) und ich muss es auf
>beiden Maschinen einrichten um zu tunneln? Das ist aber nicht das ich
>will, ich will ja mit Thunderbird oder slrn von verschiedenen
>Client-Masxhinen (und verschiedenen OS) zugreifen.
>Da werde ich wohl doch irgendwie versuchen müssen, SSL am Inn2 direkt
>einzurichten...?

Ja, in deinem Fall die pfsense durch den auf ihr installierten
stunnel-modul von pfsense

https://docs.netgate.com/pfsense/en/latest/packages/stunnel.html

Die andere Seite ist dann der Außen-Newsclient.

Mit den Text-Newsreadern, wie slrn etc. auf Linux läuft dort auch stunnel.

Der newsreader unterhält sich mit localhost z.B. port 119. stunnel
verpackt das in ssl und schiebt das über das offene Netz, jetzt
verschlüsselt, zur pfsense port 563. Der stunnel modul packt das aus. Die
pfsense nutzt unverschlüsselt zB. port 2119 und schiebt nach NAT alles,
dann unverschlüsselt weiter, auf die IP des docker-hosts zielport z.B.
1119.

Auf dem docker-host gibst du port 119 des containers als 1119 nach außen
frei.

Statt stunnel get nach internet wohl auch haproxy im tcp-mode.

Ich unterstelle jetzt mal, pfsense und der host mit dem docker-container
sind getrennte Maschinen.

Dann wäre die erste Aufgabe, den dockercontainer auf dem docker host zum
laufen zu bringen.

Vorab wäre zu entscheiden, ob du im Innennetz einen getrennten Newsserver
nutzen willst.

Hängt vom Geheimhaltungsgrad deiner internen Newsgruppen ab.

Wenn streng geheim, würde ich Newsserver allgemein ind Newsserver intern
geheim in getrennte vm stecken und über einen nntp-cache-server
zusammenführen.

Der cache würde dann auf port 119 des hosts laufen, der Newssercer
allgemein dann z.B. auf port 1119 der Newsserver intern-geheim auf
getrennter Maschine zB. port 2199

Der Cache-Server holt sich dann je nach Gruppen-Name das Zeugs von dem
einen oder anderen Server.

Alternativ, wenn die Zugriffssteuerung des INN als Schutz genügt, gibt es
nur den Newsserver im Dockercontainer. Dieser wird dann 1:1 auf den port
des Dockerhosts, also mit -p 119:119 durchgeschleift.

Als Aufgabe 1 benötigst du also einen Newsserver, der im Innennetz per
nntp unverschüsselt erreichbar ist.

Peter

Christian Peters wrote:

>Die pfsense holt mit dem acme Skript ein wildcard Zertificat und erzeugt
>die folgenden Files:

Hier würde ich über 2 Zertifikate nachdenken.

*.example.com und *.intern.example.com

Weil die Wildcard-Zerifikate ohnehin die dns-challenge zur Folge haben,
macht das keinen wesentlichen Unterschied.

Peter

Christian Peters wrote:

>Die pfsense holt mit dem acme Skript ein wildcard Zertificat und erzeugt
>die folgenden Files:

Ich hatte Rechteprobleme.

Viele server erzwingen für den .key bestimmte Rechte und verweigern
symlinks

IIRC erwartet inn 600 oder 640 und liest mit dem user unter dem er läuft.

In meinem Fall nutze ich Owner root:news und 640

d.h. root darf lesen und Schreiben, die Gruppe news (zu der der user news
gehört) den key lesen. Und der Rest der welt hat keinen Zugriff.

Man muss also verschiedentlich für Zertifikate Kopien erzeugen und die
Rechte und den Eigentümer setzen. Ein symlink hilft manchmal eben nicht.

Peter

Am 02.11.23 um 14:16 schrieb Peter Heirich:
> Christian Peters wrote:

> In meinem Fall nutze ich Owner root:news und 640
>
> d.h. root darf lesen und Schreiben, die Gruppe news (zu der der user
> news gehört) den key lesen. Und der Rest der welt hat keinen Zugriff.

Es klappt jetzt alles, dank aller Tipps hier, noch mal vielen Dank!
Wie in der manpage von inn.conf beschrieben habe ich jetzt die
LetsEncrypt Files *.fullchain und *.key Files verwendet und unter das
Verzeichnis des Domainnamens gelegt, dann ging es. Rechte gesetzt auf
640, news:news

tlscapath: /etc/news/news.test.de
tlscertfile: /etc/news/news.test.de/lets_encrypt.fullchain
tlskeyfile: /etc/news/news.test.de/lets_encrypt.key

und das Skript von Fridemann für nnrpd mit SSL:

# /etc/systemd/system/nnrpd.service
[Unit]
Description=NNRPD Newsreader
BindsTo=inn2.service
After=inn2.service

[Service]
Restart=on-failure
ProtectSystem=full
ProtectControlGroups=yes
ProtectHome=yes
User=news
Group=news
ExecStart=/usr/lib/news/bin/nnrpd -f -D -4 192.168.17.119 -p 563 -S
LogNamespace=news
IPAddressDeny=any
IPAddressAllow=localhost
IPAddressAllow=192.168.16.0/20
IPAddressAllow=fda6:51a:e5b5::/48

[Install]
WantedBy=multi-user.target

....mit angepasster IP und IPAddress... Anpassungen.

Ich kann jetzt von extern über SSL Port 563 und mit Passwort auf meinen
INN2 von extern zugreifen. Alle 90 Tage muss ich das neue Zertifikat
halt rüber schieben von der pfsense in das Verzeichnis des INN und
entsprechend die Rechte inkl. user:group setzen. Aber das ist zu
verschmerzen da ich eh Hand anlegen muss auf der pfsense um das
Zertifikat zu erneuern.

Noch mal Dank an alle.

Christian

Christian Peters wrote:

>
>tlscapath: /etc/news/news.test.de

Das würde mir auffallen!

>tlscertfile: /etc/news/news.test.de/lets_encrypt.fullchain
>tlskeyfile: /etc/news/news.test.de/lets_encrypt.key
>

Diese beiden genügen eigentlich, um SSL nach außen anzubieten.

>
>tlscapath: /etc/news/news.test.de

Sieht für mich nach debian oder ubuntu aus.

von meiner debian 12

#tlscafile:
#tlscapath: /etc/news
#tlscertfile: /etc/news/cert.pem
#tlskeyfile: /etc/news/key.pem
tlscapath: /etc/ssl/certs
tlscertfile: /etc/news/fullchain.pem
tlskeyfile: /etc/news/privkey.pem

tlscapath ODER tlscafile haben eine andere Aufgabe.

Wenn der inn oder irgendwas von ihm selbst über SSL zugreift, bekommt er
ein Zertifikat bzw. eine Zertifikatskette geliefert.

Von dem Zertifikat ( aus tlscertfile des Gegenübers ) mit
cn=<fdqn_des_ziel_hosts> (oder Alternativname) wird der öffentliche
Schlüssel gezogen.

Meine Seite liefert eine (im Prinzip) Zufallszahl an den Gegenüber, die
dieser mit seinem privaten Sclüssel verschlüsselt und das Ergebnis
zurückliefert.

Da meine Seite den öffentlichen Schlüssel vom Zertifikat her kennt,
enschlüssele ich mit diesem öffentlichen Schlüssel und dann muss die
ursprüngliche Zusatzzahl wieder herauskommen.

Das beweist, dass der Gegenüber den korrekten privaten Key zum Zertifikat
besitzt, also auch berechtigter Besitzer des Zertifikats ist.

Nur nützt das noch wenig, denn Zertifikate kann jeder mit z.B. openssl
und tinyCA erstellen.

Hier wird jetzt eine weitere Prüfung vorgenommen.

Wurde das Zertifikat mit dem eigenen Key unterschrieben? Dafür wird der
Begriff "selfsigned certificate" benutzt.

Wurde das Zertifikat NICHT selbst unterschrieben, wird über den cn= der
Herausgeber bzw. das Zertifikat dessen ermittelt.

Praktischerweise ist das das nächste Zertifikat in der fullchain.pem.

Die Unterschrift wird selbstverständlich geprüft, ob diese mit dem
privaten Schlüssel des Herausgebers erfolgt ist.

Das geht so weiter, bis mal ein selbstunterschriebenes Zertifikat
auftaucht. Das ist das Root- oder Wurzelzertifikat. Im Fall von Letsencryt
ist dieses Wurzelzertifikat auch in der fullchain.pem enthalten.

Damit ist alles hübsch, bis auf das Problem, dass jeder auch ein
selbstunterschriebenes Wurzelzertifikat erzeugen kann.

Wichtig dabei ist, dass diese Fragestellung ein Problem des Gegenübers,
nicht von uns, ist.

Wir haben über die fullchain.pem das Wurzelzertifikat geliefert, ob der
Gegenüber dieses als zulässig akzeptiert, entscheidet er.

Natürlich haben wir eine ähnliche Fragestellung wenn wir ausgehend eine
SSL Verbindung aufbauen. Der Gegenüber liefert uns letztlich auch ein
Wurzelzertifikat.

Unsere Entscheidung ist nun, ob wir der herausgebenden CA, zumeist also
letsencrypt, vetrauen. Neben letsencrypt gibt es noch weitere
Zertifikatsherausgeber.

Die Lösung: Wir führen ein Liste von den Herausgebern, die aus unserer
Sicht Vertrauen verdienen.

Redhat und Debian gehen hier unterschiedliche Wege.

Redhat und Verwandte packen alle vertrauenswürdigen Zertifkate
hintereinander in eine Datei.

Diese wird in tlscafile: configuriert.

Hier von meiner Centos 8 Stream Maschine:

tlscafile: /etc/pki/tls/certs/ca-bundle.crt
#tlscapath: /etc/news
#tlscertfile: /etc/pki/tls/certs/mail0.heirich.name-cert.pem
#tlskeyfile:
/etc/pki/tls/private/mail0.heirich.name-privkey.pem
tlscertfile: /etc/pki/tls/certs/innd.pem
tlskeyfile: /etc/pki/tls/private/innd.key

Debian und Abkömmlinge packen alle vertrauenswürdigen Zertifikate, jedes
in einer eigenen Datei, in ein Verzeichnis. Wie oben zu sehen
/etc/ssl/certs bei meiner debian 12.

Du solltest in das Problem laufen, dass ausgehende (!) SSL Verbindunen nur
funktonieren, wenn Gegenüber ein letsencrypt Zertifikat benutzt.

in /etc/news/news.test.de ist das ja als selbstsigniertes Zertifikat, also
Wurzelzertifikat, auffindbar.

Natürlich habe ich alles deutlich vereinfacht dargestellt.

Um in den vertauenswürdigen Wurzelzertifikaten Änderungen zu machen,
müssen spezielle Vorgehensweisen beachtet werden.

Redhat:

man 8 update-ca-trust

Debian:

man 8 update-ca-certificates

Oft stellen Linux-Distributionen beide Wege zur Verfügung.
Auf der Debian könnte ich statt

tlscapath: /etc/ssl/certs

auch

tlscafile: /etc/ssl/certs/ca-certificates.crt

konfigurieren.

Das macht keinen wirklichen Unterschied, weil update-ca-certificates immer
beides aktualisiert.

Peter

Am 03.11.23 um 06:11 schrieb Peter Heirich:

>>
>> tlscapath:      /etc/news/news.test.de
>
> Sieht für mich nach debian oder ubuntu aus.

Ja, Debian 12.

>
> von meiner debian 12
>
> #tlscafile:
> #tlscapath:                  /etc/news
> #tlscertfile:                /etc/news/cert.pem
> #tlskeyfile:                 /etc/news/key.pem
> tlscapath:                   /etc/ssl/certs
> tlscertfile:                 /etc/news/fullchain.pem
> tlskeyfile:                  /etc/news/privkey.pem
>
> tlscapath ODER tlscafile haben eine andere Aufgabe.
>
> Wenn der inn oder irgendwas von ihm selbst über SSL zugreift, bekommt er
> ein Zertifikat bzw. eine  Zertifikatskette geliefert.
>
> Von dem Zertifikat ( aus tlscertfile des Gegenübers ) mit
> cn=<fdqn_des_ziel_hosts> (oder Alternativname) wird der öffentliche
> Schlüssel gezogen.
>
> Meine Seite liefert eine (im Prinzip) Zufallszahl an den Gegenüber, die
> dieser mit seinem privaten Schlüssel verschlüsselt und das Ergebnis
> zurückliefert.
>
> Da meine Seite den öffentlichen Schlüssel vom Zertifikat her kennt,
> entschlüssele ich mit diesem öffentlichen Schlüssel und dann muss die
> ursprüngliche Zusatzzahl wieder herauskommen.

Ah, zum ersten mal verstehe ich was vorgeht.

>
> Die Lösung: Wir führen ein Liste von den Herausgebern, die aus unserer
> Sicht Vertrauen verdienen.
>
>
> Debian und Abkömmlinge packen alle vertrauenswürdigen Zertifikate, jedes
> in einer eigenen Datei, in ein Verzeichnis. Wie oben zu sehen
> /etc/ssl/certs bei meiner debian 12.

Ich hab das jetzt darauf geändert.
>
> Du solltest in das Problem laufen, dass ausgehende (!) SSL Verbindunen
> nur funktonieren, wenn Gegenüber ein letsencrypt Zertifikat benutzt.

Ja, im Moment bin ich aber erst einmal froh das der INN funktioniert mit
SSL und dem Lets Encrypt Zertifikat. Der Charme an dem Lets Encrypt
Zertifikat ist, das es out-of-the-box auf meinen MacOS X Clients mit
Thunderbird und auch slrn funktioniert (und nicht kostet), so bin ich da
erst mal glücklich mit.
Wenn ich natürlich vielleicht doch irgendwann darüber nachdenke, mich
mit andere Newsservern über SSL zu verbinden, dann muss man das
natürlich bedenken und abwägen welches Zertifikat man dann verwendet.
Selbst signierte Zertifikate hatte ich auch schon mal probiert in
Zusammenhang mit Mail (tinyCA, S/MIME), aber das Problem war dann eben
genau das man das Wurzelzertifikat erst allen bekannt machen muss. Das
ist für mich persönlich noch einigermassen (nach rumprobieren) machbar
gewesen das in Thunderbird einzupflegen, für Freunde mit wenigen
tieferen Kenntnissen ist das dann teilweise aber doch kaum lösbar gewesen.
>
>
> tlscapath:                 /etc/ssl/certs
>
> auch
>
> tlscafile:             /etc/ssl/certs/ca-certificates.crt

tlscapath: /etc/ssl/certs

ist jetzt erst einmal konfiguriert, auch wenn es eigentlich im Moment
nicht nötig wäre.

Nach mal vielen Dank für Deine ausführliche Erklärung.

Christian

Mahlzeit!

Christian Peters <hcpeters@gmx.de> wrote:

> Ja, im Moment bin ich aber erst einmal froh das der INN funktioniert
> mit SSL und dem Lets Encrypt Zertifikat. Der Charme an dem Lets
> Encrypt Zertifikat ist, das es out-of-the-box auf meinen MacOS X
> Clients mit Thunderbird und auch slrn funktioniert (und nicht
> kostet), so bin ich da erst mal glücklich mit.

> Wenn ich natürlich vielleicht doch irgendwann darüber nachdenke,
> mich mit andere Newsservern über SSL zu verbinden, dann muss man das
> natürlich bedenken und abwägen welches Zertifikat man dann
> verwendet.

In der Regel hast Du bei "echten" Newsfeeds (Server zu Server über
Port 119) gar keine Zertifikate im Spiel (kann das Protokoll sowas
überhaupt?), jedenfalls habe ich für keinen meiner Peers irgendwas mit
Zertifikaten konfiguriert. Du trägst einfach eine feste Gegenstelle
ein (Hostname oder gar feste IP).

Falls Du News per suck holst, könntest Du über SSL gehen, aber der
scheint dann auch einfach nur die systemweiten Zertifikate zu nutzen.

Beim Senden über nntpsend/innxmit habe ich spontan nichts mit SSL
gesehen.

Und über UUCP gibt's das sowieso nicht ;-)
(es sei denn, Du arbeitest explizit mit stunnel oder sowas, aber davon
kriegt das UUCP schon nichts mehr mit)

Gruß
Christian
--
.....Christian.Garbs....................................https://www.cgarbs.de
Wer sich nicht bewegt, spürt auch nicht seine Fesseln.

Christian Garbs wrote:

>Und über UUCP gibt's das sowieso nicht ;-)
>(es sei denn, Du arbeitest explizit mit stunnel oder sowas, aber davon
> kriegt das UUCP schon nichts mehr mit)

Statt stunnel ist bei UUCP eher ssh sinnvoll.

Man baut einen SSH-Tunnel auf und startet dann den uucico auf der
Gegenseite im Vordergrundmodus.

Peter

Mahlzeit!

Peter Heirich <talk.usenet@info21.heirich.name> wrote:
> Christian Garbs wrote:
>
>>Und über UUCP gibt's das sowieso nicht ;-)
>>(es sei denn, Du arbeitest explizit mit stunnel oder sowas, aber davon
>> kriegt das UUCP schon nichts mehr mit)
>
> Statt stunnel ist bei UUCP eher ssh sinnvoll.

Deshalb das "oder sowas".

Ist vermutlich sinnvoller, das mit SSH zu machen, aber ich hatte
die stunnel sowieso schon aktiv, das war da nur ein Dienst mehr.

Mit SSH muss man wohl auch nicht über 127.0.0.{2,3,4,5} gehen, um die
verschiedenen Gegenstellen in /etc/uucp/sys separiert zu kriegen ;)

Gruß
Christian
--
.....Christian.Garbs....................................https://www.cgarbs.de
Why use Windows when there is a door?