Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
inn2 "selfhosten" hinter pfsense mit SSL....
7 views
Skip to first unread message
Christian Peters
Oct 29, 2023, 5:43:30 AM10/29/23
to
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
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
Oct 30, 2023, 7:46:21 AM10/30/23
to
Am 29.10.23 um 22:09 schrieb Peter Heirich:
> 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..
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:
>
>> 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
>
>> 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).
>
> 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?
>> 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.
>
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
Oct 30, 2023, 8:09:43 AM10/30/23
to
Am 29.10.23 um 22:09 schrieb Peter Heirich:
> Christian Peters wrote:
>
> 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).
>
>> 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..
>
> 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.
>
>> 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.
>
Christian Peters
Nov 1, 2023, 7:14:18 AM11/1/23
to
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
> 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 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
Christian Peters
Nov 1, 2023, 10:34:06 AM11/1/23
to
> 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.
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...?
Friedemann Stoyan
Nov 1, 2023, 10:40:08 AM11/1/23
to
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:
> Da werde ich wohl doch irgendwie versuchen müssen, SSL am Inn2 direkt
> einzurichten...?
"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
Christian Peters
Nov 1, 2023, 8:44:37 PM11/1/23
to
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
> 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:
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
Nov 2, 2023, 4:50:43 PM11/2/23
to
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:
> 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
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
Nov 6, 2023, 3:18:27 AM11/6/23
to
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
>>
>> 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
Christian Garbs
Nov 15, 2023, 6:55:16 PM11/15/23
to
Mahlzeit!
Christian Peters <hcpe...@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 Peters <hcpe...@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.
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
Nov 18, 2023, 5:02:35 PM11/18/23
to
Mahlzeit!
Peter Heirich <talk....@info21.heirich.name> wrote:
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 ;)
Why use Windows when there is a door?
Peter Heirich <talk....@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.
>
>>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)
>
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 ;)
Why use Windows when there is a door?
0 new messages