Beiträge von Plavix98

Zitat von Mixus

Okay also im Grunde nur ne Point to Point Verbindung. Dann musst du in deiner Wireguard Config auf dem VPS nur die Direktive "AllowedIPs = 0.0.0.0/0" ändern.

Von jetzt 0.0.0.0/0 auf das innerhalb von Wireguard benutzte Netz. In deinem oben geschilderten Fall also 10.66.66.X/YY.

Damit routest du dann nicht mehr den gesamten Traffic des VPS zu deinem Heimserver, sondern nur noch das Netz innerhalb von Wireguard.

Da wie du schreibst noch weitere Clients darauf zugreifen sollen, musst du diese entsprechend auch in die AllowedIPs aufnehmen, entweder als Netz, oder als /32 EinzelIPs.

Beispiel

AllowedIPs = 10.66.66.0/30, 10.77.77.0/24, 10.88.88.8/32

Sofern noch nicht geschehen, muss außerdem das IPv4 Forwarding auf deinem Heimserver aktiv sein, damit mehr als nur der Traffic Heimserver <=> VPS geroutet wird.

Alles anzeigen

Klasse, so funktioniert es. Tunnel steht und die Docker-Dienste sind weiter über die URL erreichbar. VPS kann auf eine zum Test erstellte NFS Freigabe zugreifen und auch eine Linux VM kann auf den VPS bzw. die dort erstellte NFS Freigabe zugreifen. Darauf kann ich nun aufbauen - gleich mal testen wie schnell eine 5GB Datei hochgeladen wird .

Das Backup der Docker-Umgebung bzw. die Daten von Nextcloud wird dann die nächste Aufgabe.

Danke für die tolle Unterstützung!

VG Mario

Zitat von Mixus

Was genau ist denn dein Vorhaben? Einfach nur ein Point to Point Tunnel zwischen Heimserver und VPS, oder wirklich den VPS über deinen Heimanschluss erreichbar zu machen?

Hallo!

meine Vorstellung war eigentlich diese: Auf dem VPS laufen div. Dienste unter Docker - diese sind über einen Reverse Proxy zu erreichen (Meine Familie und 7 Feunde) vor allem Bitwarden und Nextcloud. Die auf dem VPS anfallenden Daten sollten dann mittels sicherer Verbindung (erster Gedanke VPN) auf meinen Homeserver gesichert werden. Bzw. hatte ich die Idee (was für mich aktuell noch sehr viel Stoff zum lernen ist) das Datenverzeichnis von Nextcloud (VPS 1000) auf meinen Server "umzubiegen" um den Storage beim VPS1000 nicht vollaufen zu lassen. Mein Server hier hat 8TB Plattenplatz mit kleimem Backupserver so das hier auch der Datenverlusst eher gering sein sollte.

Natürlich könnte ich die Dienste auch hier zu Hause für die Familie freigeben, da bin ich mir dann aber wegen der Sicherheit nicht mehr ganz so "sicher" .

Dann doch lieber über einen Tunnel eine art Backup auf meinen Server hier zu Hause, als evtl. ungebetene Gäste direkt hier zu Hause .

Warscheinlich wird es dann eher über einen SSH-Tunnel gehen oder sowas, aber hier betrete ich dann auch für mich wieder Neuland.

Wenn ich das Thema IT nicht so faszinierent finden würde, dann würde ich mir viel arbeit sparen und Angeln gehen oder sowas .

Ist aber ein tolles Forum wie ich finde, gibt dann doch immer wieder tolle Unterstützung.

Danke!

VG Mario

Zitat von frank_m

wg0 findet ja eth0, sonst würde ja der Tunnel (mit 10.66.66.6) auch nicht mehr funktionieren. Dafür sorgt wg beim Verbindungsaufbau durch eine dedizierte Host Route.

Aber natürlich ist 0.0.0.0/0 das Problem. Damit schaltest du das Internet im VPS quasi ab. Mach es dir klar: Ein Paket kommt von außen auf deinem Server auf eth0 an. Der will darauf antworten, guckt in seine Routen und schickt die Antwort zum VPN Interface raus, über deinen Heimrouter ins Internet. Es kommt vielleicht am Ende wieder beim Absender an, aber von einer komplett anderen IP Adresse. Der Sender weiß gar nicht, dass die Antwort mal zu seiner Frage gehörte und wird sie verwerfen.

Hallo!

uih, dann lag ich ja mal ziemlich richtig mit meiner Vermutung. Danke die Erklärung - die ist genau so wie ich es brauche - klar und gut verständlich .

Jetzt habe ich das auch für mich klar bekommen, ist ja dann auch logisch und kann so einfach nicht funktionieren.

Zitat von frank_m

Wenn der Internetzugang über eth0 erhalten bleiben soll, dann darfst du nicht 0.0.0.0/0 über VPN routen. Alternativ musst du über Portweiterleitungen dafür sorgen, dass die Dienste des Servers auf deinem FTTH Zugang erreichbar werden. Aber aus Sicht der Latenzen ist das natürlich eine Katastrophe. Und ich würde auch nicht Server Traffic durch mein Heimnetz routen wollen.

Ok das möchte ich natürlich auch nicht machen. Aber nun müsste man (ich) mich besser mit Wireshark auskennen und mal hier intern mit lauschen - aber das erstmal nicht so wichtig (ich träume ).

Zitat von frank_m

Was natürlich geht, ist ein policy based Routing für spezifische Randbedingungen. Da müsstest du dir halt überlegen, unter welchen Randbedingungen der VPN Tunnel genutzt werden soll, dann kann man ggf. eine Regel dafür bauen.

Ok dann geht es schon einige Etagen höher vom Niveau - ich lese mich da mal etwas ein und entscheide dann, ob das was wäre oder ob es schon zu weit geht.

Vielen Dank für die tolle Hilfe! - Hat mich wieder etwas weiter gebracht!

VG Mario

Zitat von michaeleifel

Baust du die SSH Verbindung von dem Home-Server zu dem Netcup-Server auf?

Hallo! Nein ich gehe von einem Windows PC - welcher im selben Netz wie der Server ist - über Bitvise auf den NetCup.

Was mich eigentlich am meisten stört ist die Tatsache, dass ich die Docker Container bzw. die dort laufenden Dienste nicht mehr erreichen kann, also es wird keine URL mehr zum NetCup Server durchgereicht. Auch ein Ping auf die öffentliche IP des NetCup Servers ist nicht mehr möglich, als ob eth0 abgeschaltet ist - ist es natürlich nicht aber eben nicht mehr direkt erreichbar. Der V1000 kann sich nur noch selbst anpingen - also seine öffentliche IP, alle über den Wireguard Tunnel, also mein Heimnetz kann auch erreicht werden. DNS wird über meinen AdGuard (VM auf meinem Homeserver) aufgelöst - auch das funktioniert.

Beende ich dann den Tunnel, ist wieder alle über die öffentliche IP erreichbar, also auch die Dienste im Docker.

Muss ich noch manuell was Routen damit wg0 quasi eth0 findet? Oder denke ich da mittlerweile komplett falsch.

Ich muss mir das ganze mal skizzieren und mit den ensprechenden Nummern versehen.

Vielleicht finde ich selbst den fehler - oder hier kann man sich das ganze besser veranschaulichen

VG Mario

Hallo!

Ich habe mal wieder eine Verständnisfrage zu meinem Testserver welchen ich für mein Hobby zum lernen verwende.

Es laufen auf diesem im Docker Containern - Traefik als reverse Proxy (SSL) - Nextcloud - Bitvarden. Nicht wirklich produktiv, also nur so um mich ein wenig mit der IT

zu beschäftigen.

Nun wollte ich den V1000 (Ubuntu) als "Client" oder besser Peer über Wireguard mit meinem Homeserver verbinden.

Ich habe hier FTTH mit 1Gbit in beide Richtungen und eine feste öffentliche IPV4. Handy und Co. geht auch ohne Probleme mit dem VPN.

Die Verbindung konnte ich erfolgreich herstellen. Ein Traceroute zu 1.1.1.1 zeigt mir ein erfolgreiches Routing über meinen Server hier zu Hause.

Ping geht in beide Richtungen - also die jeweilige TUN Adresse (10.66.66.6 NetCup) bzw (10.66.66.2 Homeserver).

Was ich nun gern verstehen würde, wenn ich den Tunnel von Client (NetCup) öffne mit "wg-quick up wg0" wird der Tunnel gestartet, im selben Moment

aber hängt sich die SSH-Shell weg bzw. wird unterbrochen. Auch die Dienste im Docker sind nicht mehr zu erreichen. Auch die öffentliche IP des Servers

bei NetCup ist "tot". Ich kann dann die SSH wieder neu aufbauen - aber nur über die TUN Adresse 10.66.66.6 aber so laufen die Docker Dienste nicht mehr

bzw. sind eben nicht erreichbar.

Wo liegt mein Denkfehler? Es wird sämtlicher Verkehr mit "Allowed IP = 0.0.0.0/0" über TUN geroutet. Kann es das schon sein und wenn ja, wie kann ich das ändern?

Vielen Dank!

VG Mario

Zitat

Nur um sicherzugehen, dass wir nicht wieder in denselben Fehler laufen: eingetragen im CCP hast du folglich nur sub   A   94.x.x.x, also links nicht den gesamten FQDN, sondern nur den Hostteil? Wie sieht denn ein Check bei https://dnschecker.org/ aus? Liefern alle DNS-Server die gewünschte IP? Gut möglich dass dir zuhause irgendein Gerät (Client, Router, etc) noch aus dem Cache noch falsche Werte liefert.

Hehe ja das hat diesmal geklappt - bin noch lernfähig

Der Tip mit dem dnschecker hat mich aber weiter gebracht, ich bin wohl zu ungeduldig. Es waren gestern nur 3 DNS Resolver die meine richtige IP zurückgemeldet haben. Heute Morgen melden sich alle aufgeführten mit der richtigen IP.

Zitat

Rufst du die Seite explizit mit https davor auf? Ansonsten muss im Webserver noch eine 301-Weiterleitung eingetragen werden, damit automatisch von http auf https weitergeleitet wird. (auch gut möglich, dass dein Bitwarden-Docker-Dings das bereits implementiert hat, keine Ahnung, ich installier sowas immer händisch - dann weiß ich auch welche Config da wirklich aktiv ist). Lauscht der Webserver auf dem Port 443? ss -tlpen Welches Zertifikat wird ausgegeben - das von Letsencrypt? Lässt sich auch über die CLI auslesen: openssl s_client <HOST>:443

Und auch da hast Du den richtigen "Richer" gehabt, eben mal nachgesehen, die 301-Weiterleitung macht das Docker-Image nicht automatisch

Wenn ich exakt mit https://s3.dddddd.de aufrufe, komme ich auch auf die Seite - oh man es könnte so einfach sein

Zitat

Die Frage ist aber, ob du wirklich auf deinem Server landest.

Ja hier frage ich mich, was bei mir im Netz die DNS so lange im Cache hält. Gestern Nacht wollte ich noch mal mit meinem IPhone die Nextcloud auf meinem "Kellerserver" ansprechen, also die App aufgerufen und die war der Meinung - Server gefunden, aber Zertifikat ungültig. Hier war das Handy im WLan. Ok also mal WLan aus - und siehe da, der Server ist erreichbar und auch das Zertifikat wurde "anerkannt". Ja wie gehts sowas? - Dann wieder WLan an und das Zertifikat wurde als nicht vertrauenswürdig gemeldet. - Und durch dieses Thema hier im Forum - gleich nochmal die Zerts angesehen, wenn das Handy im WLan war, wurde das "Plesk" Zert. ausgeliefert - also stimmte im WLan was mit dem DNS noch nicht. Über Nacht wurde dann wohl der DNS Cache geleert und siehe da - alles so wie es sein soll. -> Bin mal gespannt wie lange

Also Router habe ich hier eine FritzBox - keine Ahnung wie lange die DNS Anfragen im Cache hält.

Aber erstmal herzlichen Dank an Deine und KB19´s Hilfe!

Ich bin nicht aus der IT - mein ergeiziges Hobby eben, leider der einzige in meinem Bekantenkreis mit diesem Hobby.

Gibt es NetCup bei Discord? - Oder einen Chat oder sowas da könnte ich dann auch "nerven"

VG Mario

Zitat von DerRené

Ja leider bist du bei Letsencrypt mit deiner Domain durch die vermutlich vielen Versuche nun in ein Rate Limit gerannt:

Es bietet sich daher immer an zuerst mit den Staging-/Testserver von LE den Zertifikatsantrag durchzuspielen bis alles klappt. Bei acme.sh geht dies mit dem Schalter --test, certbot nutze ich nicht, gibt es dort aber sicherlich auch.

Ist natürlich jetzt im Nachhinein etwas doof... ich weiß auch nicht ob es Möglichkeiten gibt dieses Limit zu umgehen, vermutlich aber nicht.

DIe im WCP erstellten LE-Zertifikate bringen dir zuhause nichts, richtig. Die werden im WCP am Webserver für dich hinterlegt. Davon hast du ja leider zuhause dann recht wenig. Also: richtig verstanden.

OK dann ist bei mir noch nicht alles verloren

Aber ich stehe mit dem DNS Einträgen echt auf dem Kriegsfuß. Da ich mit meinem Homeserver nicht weiter komme, ich aber unbedingt Bitwarden_RS am laufen haben will, dachte ich mir eben - hey der VPS 1000 9G ist zwar nur zum testen gemietet aber Bitwarden kann der eben auch. Gesagt getan, ich habe unter der zweiten Domain einen DNS Eintrag eingetragen "s3.meinserver.de" und zeige auf die IP bei Netcup 94.16.xxx.xxx

So und nun dreht sich mein kopf - auf dem VPS alles mit Docker und Bitwarden eingerichtet. Gewartet bis ich den VPS mit der Sub-Domain anpingen kann (45 Minuten). Dann Bitwarden script gestartet, hier Domain eingetragen, das Zert erstellen lassen und nun... ich gebe die Sub-Domain in meinen Browser und was kommt... ??? "Die Aufgerufende Seite ist nicht sicher" - ich dreh durch. Das Zert ist erstell und liegt auch auf dem Server im entsprechenden Order. Was auch lustig ist, wenn ich jetzt die SUB anpinge, bin ich wieder auf dem Netcup Domain Bereich. Warum geht kurz der DNS und dann ist er wieder weg? Auf dem Hosting läuft eine Webseite von mir, ich kann also nicht alle Einträge im DNS löschen. Hier sind noch die Wildcard-Einträge vorhanden, damit ich auf die Webseite komme.

Ich glaub ich mach Feierabend... aua.

VG Mario

Hallo, ich nochmal. Also der DNS war total falsch. Nun komme ich auch mit PING auf die richtige IP zu Hause.

Leider laufe ich jetzt durch meine Versuche in ein Limit von Lets Encrypt. Zumindest interpretiere ich das aus dieser Meldung:

Error: Command failed: certbot certonly --non-interactive --config "/etc/letsencrypt.ini" --cert-name "npm-7" --agree-tos --authenticator webroot --email "npm@dddddd.de" --preferred-challenges "dns,http" --domains "dd.dddddd.de" Saving debug log to /var/log/letsencrypt/letsencrypt.log

An unexpected error occurred:
There were too many requests of a given type :: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: dd.dddddd.de: see https://letsencrypt.org/docs/rate-limits/
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
at ChildProcess.exithandler (node:child_process:397:12)    at ChildProcess.emit (node:events:394:28)    at maybeClose (node:internal/child_process:1064:16)    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)

Ich kann die Seiten ohne HTTPS erreichen. Da diese aber unbedingt HTTPS brauchen, funktioniert das erstmal nicht.

Der "internal Error" ist wohl das Limit von Let´s Encrypt.

Nur noch für mich zum Verständnis, die Zertifikate usw. welche ich für die Domain im CCP erstellen kann, haben doch keine Bewandnis, da ich ja durch die DNS auf meinen Server verweise oder?

Das macht ja echt Arbeit - never change a running system, das passt mal wieder.

Wenn ich meinen Server nicht mehr zu HTTPS bewegen kann, dann melde ich mich nochmal

VG Mario

Zitat von DerRené

Dann landest du doch beim Aufruf im Browser vermutlich eher irgendwo auf deinem Webhosting von Netcup (dort ist das fehlerhafte Plesk-Zertifikat leider üblich) und nicht bei dir zuhause - oder?! Und wenn bis eben auch ein DNS-Wildcard-Record hinterlegt war, ist das gar nicht so unwahrscheinlich.

Hast du schon sichergestellt, dass die entsprechenden (Sub)Domains wirklich die korrekte IP von zuhause liefern? Klingt als wäre irgendwo noch ein alter/falscher Wert in einem Cache und zeigt noch auf dein Webhosting. Fakt ist zumindest, ein Plesk-Zertifikat sollte dir nicht ausgeliefert werden, wenn auch kein Plesk im Einsatz ist.

Ansonsten habe ich sehr gute Erfahrungen mit dem acme.sh Cient gesammelt - unterstützt von Hause auch die Netcup-API - dann müssen auch keine Ports in der Firewall aufgerissen werden. Damit einfach WIldcard-Zertifikate (*.deinedomain.de) oder eben Multisite-Zertifikate (bla1.deinedomain.de, bla2.deinedomain.de, usw) anfordern und fertig.

Hallo DerRené,

ich hoffe Du hast recht, ich habe einen Ping auf die Sub-Domains gestartet und lande damit immer auf dem Hosting von Netcup

Nun habe ich die DNS EInstellungen noch einmal angesehen.... ich denke man sollte den DNS Eintrag nicht so machen wie ich.... ich habe

die gesamte Sub-Domain eingetragen also s9.testdomain.de - A - Destination

Habe das nun geändert, mal schaun wenn die Aktuallisierung durch ist, was dann passiert. Dann kann mein nginx aber auch eigentlich kein

Zert. empfangen haben.

Ich gebe dann mal Rückmeldung wenn DNS passt - oh man...

Zitat von KB19

Gibt es vielleicht in irgendwelchen Logs eine genauere Fehlermeldung? "Internal Error" ist halt leider relativ nichtssagend

Prinzipiell gibt es bei Let's Encrypt mehrere Challenge-Typen: https://letsencrypt.org/de/docs/challenge-types/

• Ich gehe mal davon aus, dass Du aktuell HTTP-01 verwendest? Ist Port 80 von überall aus erreichbar?
• Lösen die A/AAAA Records der betroffenen Subdomains wirklich korrekt auf, auch mit DNSSEC? (Dafür gibt es einige Test-Tools im Internet.)
• Verwendest Du bei den DNS-Records Wildcard-Einträge mit einem *?

Ok ich merke schon, langsam komme ich als "Hobby Admin" nicht mehr weiter. Die Ports für den nginx reverse Proxy sind frei - also 80 und 443 sind erreichbar.

Und ja somit nutze ich HTTP-01.

Ich habe nun nginx neu gestartet - jetzt wurden für die Dienste auch neue Zertifikate erstellt - liegen auf dem Server.

Die A/AAAA Records scheinen zu passen, wie ich die DNSSEC teste - da bin ich noch nicht weiter.

Ich hatte noch Wildcard-Einträge zur Domain. Was ich nun aber gelöscht habe. Ich zeige direkt mit den Sub-Domanins auf meine fest IPv4.

Im Browser werden die Seiten als "nicht Sicher" angezeigt, was mich wundert, wenn ich mir das Zertifikat ansehe, steht da was von Plesk und

eine Gültigkeit bis 2019 - also ob die Zertifikate nicht gelesen werden und etwas von Netcup verwendet wird.

Der "Internal Error" ist weg, ich kann also Zertifikate erstellen und diese sind auch der Sub-Domain zugeordnet werden aber nicht nach außen genutzt, wenn ich das so beschreiben kann.

Oh man, muss ich im ccp noch die Sub-Domains erstellen und dort dann ein Zertifikat erstellen lassen? Eigentlich sollte das ja mein proxy bereitstellen.

Nachtrag: EIn PING auf die URL gibt die Adresse des Hostingspackets aus... hmm warum nur?

Vielen Dank für Deine Mühen!

VG Mario

Hallo in die Runde,

ich bin von Host**rope mit meinen drei Domains und einer Webseite zu Netcup umgezogen. Das Webhosting 2000SE reicht mit den drei inkl. Domains.

EMail und Webseite laufen soweit. Nun komme ich mit meinem Wissen aber nicht mehr wirklich voran.

Ich habe eine feste IPv4 hier zu Hause, im Keller läuft ein Server welcher div. Dienste (Nextcloud, Bitwarden usw.) für meine Familie zur verfügung stellt - bzw. stellte.

Der Zugriff auf diese Dienste läuft über nginx als reverse Proxy, dieser kümmerte sich auch um die Let´s Encryp Zertifikate für die jeweiligen Dienste (jeder Dienst eine Sub-Domain).

Nun werden die Zertifikate aber nicht mehr erstellt, bzw. enden mit einem "internal Error" und die Dienste sind nicht erreichbar.

Bei meinem "alten Hoster" habe ich einfach nur die A und AAAA Records auf meine IP umgebogen und es ging ohne Probleme. Ports sind in der Fritte offen, da wurde nichts geändert.

Die Sub-Domains sind auch erreichbar, nur eben ohne HTTPS und versagen so die Arbeit. Ich nutze eine eigene Domain dafür - ich bräuchte also kein Hosting sondern nur die DNS weiterleitung, kann es daran schon liegen? Oder muss ich meine nginx Manager Config aus DNS Challange umstellen? Wenn ja wie geht das? Steht was von API und sowas - da bin ich aber raus

Boah, ich sitze nun schon seit 12 Stunden davor und komme nicht weiter. Wenn es jemanden gibt, welcher mir helfen mag und noch Infos benötigt, dann bitte bescheid geben.

Danke schonmal!

VG Mario

Zitat von mropen

Das ist keine Glaubensfrage. Das ist alleine schon aus Gründen des Auditings bei professionellen Installationen ein Tabu. Privat und als einziger Nutzer auf dem Rechner ist Auditing zwar nicht unbedingt relevant, aber da greift dann das Prinzip der Verteidigung in der Tiefe.

Anstatt Fail2ban könntest du auch OSSEC nehmen. Das beinhaltet Fail2ban und kann noch einiges mehr.

Hallo mropen,

OSSEC kenne ich garnicht. Schau ich mir gern mal an. Aber wie schon geschrieben, der Server ist mehr zum spielen (lernen) wenn da mal was "passiert" hoffe ich, dass ich es merke und setzte zur Not das Ding neu auf. Aber toller Tip - mal sehen wie OSSEC funktioniert.

VG

Danke Super!

jetzt habe ich das verstanden.

Den Beitrag bei Wikipedia werde ich mir auch durchlesen.

tab > Die Erklärung ist klasse!

KB19 > Den Port 22 werde ich dann mal umlegen. Hoffentlich sperre ich mich nicht aus

VG Mario

Zitat von Paul

Hallo Mario,

das was du in den Logs siehst, ist der Client Port (+ Client IP), nicht der Server Port. Das darfst du nicht verwechseln. Daher brauchst du dir diesbezüglich keine Gedanken machen.

Hallo Paul,

danke für Deine beruhigende Antwort!

Ok nun fängt das lernen schon an - "ist der Client Port (+ Client IP), nicht der Server Port" - kann ich das irgentwo

nachlesen damit ich das einordnen kann?

So verstehe ich das leider nicht ganz

Hallo!

Ich bin neu hier und habe einen VPS 1000 G9 12M gemietet.

Der Server ist meine "Lernplattform" - zu Hause habe ich einen Server mit FreeBSD laufen welcher

div. Daten im Heimnetz zur Verfügung stellt. Es laufen einige VMs (WireGuard, Ubuntu für Docker, Bitvarden)

Diesen Server hier möchte ich nutzen um mein Wissen zu erweitern. Es werden auch keine wichtigen Daten oder Anwendungen

hier laufen.

Meine Frage bestifft nun aber die Absicherung meines Servers. Diese Punkte habe ich bereits durchgeführt:

- SSH auf Key only umgestellt

- ROOT darf nicht SSH

- User für Sudo eingerichtet

- Mittels UFW den eingehenden und ausgehenden Verkehr unterbunden (Port 22, 80, 443 sind offen in beide Richtungen)

- fail2ban läuft und sperrt nach 3 Versuchen die entsprechende IP für 24h.

Nun aber meine Frage, im Netz habe ich noch nichts passendes gefunden, wenn ich mir das Log /var/log/auth.log ansehe,

dann kommt doch noch die eine oder andere IP mit einem hohen Port bis zu fail2ban durch. Sollte das nicht

schon durch die Firewall-Regel unmöglich sein?

Auszug aus auth.log:

Sep 11 13:48:02 "mein Server" sshd[1419]: Invalid user user from 24.147.90.130 port 10945

Sep 11 13:48:04 "mein Server" sshd[1419]: Received disconnect from 24.147.90.130 port 10945:11: Bye Bye [preauth]

Sep 11 13:48:04 "mein Server" sshd[1419]: Disconnected from invalid user user 24.147.90.130 port 10945 [preauth]

Sep 11 13:50:33 "mein Server" sshd[1422]: Invalid user kristen from 68.183.88.186 port 43870

Sep 11 13:50:33 "mein Server" sshd[1422]: Received disconnect from 68.183.88.186 port 43870:11: Bye Bye [preauth]

Sep 11 13:50:33 "mein Server" sshd[1422]: Disconnected from invalid user kristen 68.183.88.186 port 43870 [preauth]

sudo ufw status verbose

Status: active

Logging: on (low)

Default: deny (incoming), allow (outgoing), deny (routed)

New profiles: skip

To Action From

-- ------ ----

22/tcp ALLOW IN Anywhere

22 ALLOW IN Anywhere

80 ALLOW IN Anywhere

443 ALLOW IN Anywhere

22/tcp (v6) ALLOW IN Anywhere (v6)

22 (v6) ALLOW IN Anywhere (v6)

80 (v6) ALLOW IN Anywhere (v6)

443 (v6) ALLOW IN Anywhere (v6)

Hier ist der Port 22 doppelt in der Config, sollte aber nicht stören oder?

Verwendet wird ein Ubuntu 20.04

Hat jemand einen Tip wie das funktionieren könnte? Ich möchte natürlich die Ports nicht offen haben bzw. sind sie zu aber es kommt doch

noch wer durch... oder verstehe ich das Log auch falsch?

Danke Viele Grüße

Mario