Ich bevorzuge Syncthing, weil dann so eine nicht ganz unkritische Datei gar nicht auf einem öffentlich erreichbaren Rechner liegen muss.
Beiträge von mropen
-
-
Such bei Ali nach "dust plugs USB HDMI RJ45".
-
Kann ich deinem Profilbild entnehmen, dass das Teil mit OpenBSD kompatibel ist?
Ja, kannst du. Sorry für die späte Antwort, bin in zu vielen Foren unterwegs...
Die Intel NICs waren damals das Hauptentscheidungskriterium für mich, weil OpenBSD die gut unterstützt. Sonst gibt's nicht viel dazu zu sagen, läuft einfach. Inzwischen habe ich mir noch ein 10 m langes serielles Kabel zugelegt, damit klappen auch Updates auf die nächste OpenBSD Version problemlos und sozusagen remote.
Übrigens steht bei mir ein Q355G4, ist aber schon fast fünf Jahre alt. (Hatte jedenfalls null Probleme mit dem Gerät in den fünf Jahren.)
-
Zu Hause verwende ich einen passiv gekühlten Mini PC von Qotom, direkt aus China bestellt. Die gibt's in Ausführungen bis 8 Ethernetports und stecken auch in diversen OEM Produkten, die hierzulande angeboten werden. Die Hardware ist ordentlich und jedenfalls meine Ausführung hat Intel NICs.
-
Naja, ich persönlich würde gerne von meinem VPS 200 auf 500 hochgehen, aber der Preissprung ist einfach zu groß. Kann ich auch verstehen angesichts stetig steigender Hardware- und Energiekosten und der schlechten Verfügbarkeit neuer Hardware.
-
Copy & Paste im VNC ist ein MUSS! Wie soll man vernünftig lange Passwörter mit Sonderzeichen sonst eingeben.
Mit KeePass und Auto-Type. Ist jedenfalls sicherer als Copy & Paste. Mal abgesehen davon hätte ich auch gerne Copy & Paste.
-
Generell mache ich solche Dinge nur von Hand, um zu verstehen, was da genau passiert und dann weiß man in der Regel auch, was man gerade falsch gemacht hat.
Du könntest in die iptables Befehle des Skripts LOG Anweisungen einbauen, damit du dann auf der Konsole beobachten kannst, an welcher Stelle die Verbindung blockiert wird.
Außerdem achte darauf, dass du auch die Blockliste löscht und nicht nur die Regeln.
-
Sehe ich irgendwo, wen -als welche IPs - das Skript gerade auf Blocked gesehen hat?
Das sollte mit sudo ipset list funktionieren.
Und muss ich bei der 2. Quelle erst die Schritte des User Ibrahim ausführen, oder reicht das Script von User Feriman?
Das Skript reicht. Du musst aber evtl. noch die Parameter der Regeln im Skript auf deine Bedürfnisse abstimmen.
-
Guckst du hier:
https://superuser.com/question…port-scanner-via-iptables
Oder das hier ist noch ausgefeilter:
-
RFC 6532 / SMTPUTF8 erlaubt auch Nicht-ASCII Buchstaben in Emailheadern. Allerdings dürfte der Sender solche Header nicht schicken, wenn der Empfänger nicht verlautbart, dass SMTPUTF8 verarbeitet werden kann. In der Praxis ist SMTPUTF8 also nicht sehr nützlich.
Jedenfalls kannst du dir sicher sein, dass du nicht der einzige bist, der die o2 Emails nicht empfangen kann.
-
Wenn du schon dabei bist, richtest du am besten auch gleich DKIM und DMARC ein, um die Chancen weiter zu erhöhen, dass Emails von deinen Servern/Domänen angenommen werden.
-
Ist mir nicht klar, was das Protokoll der Firewall mit diesem Thema zu tun hat? Und einen Scanner zu blockieren, bevor er einen offenen Port erreicht, ist eine gute Idee.
-
Ja, das mache ich auch so, aber hier ging es darum, dass die Firewall "mitzählt", wenn ein Scanner Ports abgrast, und die Adresse dann automatisch in die interne Blockliste aufnimmt.
-
Wäre schon aber nett, wenn man diesen Scannern nochmal einen extra Maulkorb verpasst, also zusätzlich zu den Ports auch die IP Adressen der Scanner sperrt, weil die auf den offenen Ports sicher auch nichts Gutes vorhaben. Mit pf wüsste ich wie das geht. Mit netfilter, also dem Linuxkernelmodul, das die eigentliche Firewall von Linux ist, ginge das sehr wahrscheinlich auch, habe da aber auch keine vernünftige Anleitung zur Hand.
-
Ja, das verlinkte Blog macht das nur für Port 22, aber das könnte man natürlich auch auf beliebige andere Ports anwenden. Man muss nur aufpassen, dass z.B. bei einem Webserver der HTTP Port sehr viel Verkehr haben wird. Wenn man da wie bei SSH jeden fünften Verbindungsversuch innerhalb einer Minute permanent blockt, hat man bald keine Leser mehr.
-
Mal abgesehen davon, dass Fail2Ban funktionieren sollte und das nur eine Konfigurationsfrage ist, würde ich auf jeden Fall zunächst mal solche Anfragen automatisch in der Firewall abfackeln. Das geht schneller, effizienter und sicherer als erst darauf zu warten, dass die Anfrage von SSH behandelt wird, dann abgelehnt und geloggt wird und dann Fail2Ban das Log auswertet und die Firewall scharf schaltet.
Die Firewall lässt sich mit iptables, ipset und dem recent Modul schön einrichten: https://www.falk-online.eu/201…icherung-des-ssh-zugangs/ (siehe Abschnitt "Rate Limiting"). Idealerweise nimmt man heutzutage nftables statt iptables, aber dafür sind die Anleitungen noch etwas spärlich. Fail2Ban deckt dann noch weitere Fälle ab, die die Firewall selbst nicht erkennen kann.
-
Pullen halt ich afaik für eine schlechte Idee, weil du ja wenn den ganzen Server sichern möchtest. Und dann braucht das NAS einen Root-Zugang zum Server. Und dann... neeee, lass mal. Bin da nicht so für. Wir sind nicht so.
Prinzipbedingt sind Pull Backups sicherer als Push. Die Wahrscheinlichkeit, dass jemand in das NAS im internen Netzwerk eindringt ist sehr viel geringer als ein Eindringling im öffentlich erreichbaren VPS.
Borg & Co (also Push) kann man natürlich so einrichten, dass der VPS auf dem NAS nur zusätzliche Backups anlegen kann und ein Eindringling die vorhandenen Backups nicht löschen kann. Aber auf jeden Fall hat der Eindringling so schon mal einen Zugang ins interne Netz, den es bei Pull einfach nicht gibt.
-
Ubuntu kommt mit Snap, Netplan und systemd-resolved(?), Debian ist etwas schlanker und nutzt die /etc/network/interfaces Syntax, sowie resolv.conf
Bei Debian kann man auch systemd-resolved nehmen, wenn man das mag.
-
Wie sieht's denn bei den Vorgängern mit der Unterstützung durch den Linuxkernel aus? Bei den meisten SBCs wird eine Kernelversion so hingefrickelt, dass sie einigermaßen läuft und bei der hängt man dann für immer fest.
-
mit Key (inkl. Passphrase) und anderem Port sollte ich doch einigermassen geschützt sein
Nur um da mit einem Missverständnis aufzuräumen - der geänderte Port dient nicht der Sicherheit sondern nur dem Komfort. Vor einem gezielten Angriff auf sshd kann ein geänderter Port nicht schützen. Der geänderte Port sorgt aber dafür, dass die Systemlogs nicht von Scannern zugemüllt werden.