Server besser absichern

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema Server besser absichern gibt es 27 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Server besser absichern

    Hallo,

    ich betreibe einen Server im Rechenzentrum (Hetzner), auf dem openSUSE 42.3. Das YAST System Hardening habe ich schon ausgeführt, trotzdem steht mein Server regelmäßig unter SSH Brute-Force Beschuss. Ich habe habe schon viele asiatische IP Adressen via iptables ausgeschlossen. Das hat zumindest die Anzahl von mehreren Tausenden täglich auf den einstelligen Bereich verkleinert. Das ist für mich immer noch nicht zufrieden stellend, weil ich das im besten Fall komplett unterbinden möchte.
    Was ich bisher gemacht habe:
    • SSH Authentifizierung über Schlüssel (RSA 4096 Bits)
    • sichere Passwörter mittels des Generators Strong Random Password Generator und der Einsatz von KeePass auf dem Client System um die Passwörter merken zu können
    • Ich hatte versuch in der SSH Daemon Einstellung die Anmeldung via Passwort abzuschalten, hatte jedoch keinen Effekt.
    • Von der Polizei hatte ich mal gehört, dass es nichts bringt Fail2Ban einzusetzen, wenn der Angreifer wechselnde IP-Adressen verwendet.
    Was ich tun möchte:
    • root Login per Remote abschalten ist ja eine Empfehlung, die es schon länger gibt. Schön und gut, nur wie geht es dann weiter? Denn ich kann mir nicht vorstellen, dass es sicherer sein soll, sich mit einem unprivilegierten User am System anzumelden, um in dessen Home Verzeichnis den root SSH Key zu hinterlegen.
    • eine Intrusion-Detection / Intrusion Prevention Firewall einsetzen. Für mich kämen hier Snort oder ossec-hids infrage. Für andere Alternative bin ich natürlich offen. Leider steige ich bei beiden genannten nicht so wirklich durch, gerade was Konfiguration und Inbetriebnahme anbelangt
    • Applicaction-Level Firewall: Es gibt ja drei große im Linux Umfeld: selinux, Novell's AppArmor (mein Favorit) und noch eine, dessen Name ich vergessen habe. Von selinux ist soviel ich weis eher abzuraten, weil das die NSA mitentwickelt hat. Eine Hintertür ist also nicht unbedingt auszuschließen.
    • lohnt es sich SSH auf einen anderen Port als 22 zu legen? Das ist laut meines Wissens "Security by obscurity" aka "Kopf in den Sand stecken" und bringt nicht wirklich was. Das Netz wird ja laut Forschern regelmäßig ausgeforscht. Wer also meinen Server findet, sollte auch in der Lage sein einen Port Scanner zu bedienen. Es mag vielleicht sein, dass es den ein oder anderen "Skript-Kiddie" vom Brute Forcen abhält, weil das 0815 Skript dann nicht mehr funktioniert, aber die große Masse wird es denke ich nicht abhalten.
    • Lohnt sich der Einsatz eines SSH-Fakers? Man könnte zum Beispiel den Faker auf den SSH Port 22 lassen und fälscherlicher weise jeden ins System lassen und den richtigen SSH Zugang auf einen anderen Port legen.
    • zusätzlich zur Schlüssel Authentifikation möchte ich einen Hardware Wallet verwenden. Es ist schließlich schon länger bekannt, dass Quantencomputing theoretisch möglich ist. Damit ist laut diversen Security Beilagen der Fachzeitschrift iX aus dem letzten Jahr jede SSH Verbindung als unsicher zu betrachten, die nicht über ein zusätzliches Mittel abgesichert ist. Nur ist hier auch nicht alles Gold was glänzt, denn zum Beispiel der Yubikey hat eine zu lange Leiterbahn und man kann dadurch wenn man neben der Person steht den geheimen Schlüssel aus den elektromagnetischen Wellen empfangen und auslesen. Die Google Alternative möchte ich ebenfalls nicht verwenden, weil es Google ist (man kennt ja Google was die teilweise für Schweinereien betreiben, von gesetzlich vorgeschriebenen Hintertüren ganz zu schweigen...). Als letzte Alternative bleibt dann wohl nur noch der USB Stick aus dem Hause Ledger. Falls da jemand eine gute Alternative kennt, dann bin ich dafür gerne offen. Neben der SSH Authentifizierung möchte ich den Hardware Wallet mit folgenden Kryptowährungen benutzen: Bitcoin, Ethereum (mit Tokens) und Steem
    • Gegen DDoS Attacken kann man sich doch nicht schützen, außer die Power in ein Content Delivery Network abzuleiten, das hoffentlich mächtiger und größer ist als die Bandbreite des Angreifers, oder? Was man tun kann ist soviel ich weis Dienst-Abschottung. Das heißt, wenn ein Dienst befeuert wird, dass die anderen weiterhin störungsfrei laufen. Das erreicht man laut meines Wissen durch Virtualisierung und/ oder Cloud Computing. Für mein Low Budget also eher schlecht, oder?
    Wie man sehen kann, gibt es noch viel zu tun. Deswegen würde ich mich sehr über jeden Ratschlag aus der Community bezüglich meiner geschilderten Aufgabenstellungen freuen :smilie_hops_011:

    MFG

    derwunner
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 128623 haftet ausdrücklich der jeweilige Autor: derwunner

  • Die Anmeldung von root per ssh sollte unterbunden werden, siehe dazu /etc/ssh/sshd_config
    Besser ist es sich als User anmelden und dann auf dem Server mittels su zum root.

    Hier mal ein Ausschnit von meiner:

    Quellcode

    1. grep -Ei 'password|permit' /etc/ssh/sshd_config
    2. #PermitRootLogin yes
    3. # To disable tunneled clear text passwords, change to no here!
    4. PasswordAuthentication no
    5. PermitEmptyPasswords no
    6. # Change to no to disable s/key passwords
    7. # PasswordAuthentication. Depending on your PAM configuration,
    8. # the setting of "PermitRootLogin without-password".
    9. # PAM authentication, then enable this but set PasswordAuthentication
    10. #PermitUserEnvironment no
    11. #PermitTunnel no
    Alles anzeigen
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 128626 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Quellcode

    1. grep -Ei 'password|permit' /etc/ssh/sshd_config
    2. PermitRootLogin yes
    3. # To disable tunneled clear text passwords, change to no here!
    4. PasswordAuthentication no
    5. #PermitEmptyPasswords no
    6. # Change to no to disable s/key passwords
    7. # PasswordAuthentication. Depending on your PAM configuration,
    8. # the setting of "PermitRootLogin without-password".
    9. # PAM authentication, then enable this but set PasswordAuthentication
    10. #PermitTTY yes
    11. #PermitUserEnvironment no
    12. #PermitTunnel no
    13. # PermitTTY no
    Alles anzeigen

    hatte ich schon vor geraumer Zeit mal so eingestellt. Ein

    Quellcode

    1. systemctl restart sshd
    brachte keinerlei Veränderungen. Denn ein Blackbox Test mit putty ergab, dass ich mich als root user immer noch mit Benutzername/Paswort anmelden kann (gerade eben getestet).

    Quellcode

    1. # systemctl status -l sshd
    2. ● sshd.service - OpenSSH Daemon
    3. Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
    4. Active: active (running) since Tue 2019-01-22 21:02:49 CET; 38s ago
    5. Process: 13662 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
    6. Main PID: 13667 (sshd)
    7. Tasks: 1
    8. Memory: 848.0K
    9. CPU: 69ms
    10. CGroup: /system.slice/sshd.service
    11. └─13667 /usr/sbin/sshd -D
    12. Jan 22 21:02:49 server systemd[1]: Starting OpenSSH Daemon...
    13. Jan 22 21:02:49 server sshd-gen-keys-start[13662]: Checking for missing server keys in /etc/ssh
    14. Jan 22 21:02:49 server systemd[1]: Started OpenSSH Daemon.
    15. Jan 22 21:02:49 server sshd[13667]: Server listening on 0.0.0.0 port 22.
    16. Jan 22 21:02:49 server sshd[13667]: Server listening on :: port 22.
    Alles anzeigen
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 128631 haftet ausdrücklich der jeweilige Autor: derwunner

  • ok, vielen Dank für die Info @ThomasS. Manchmal sind die Konfigurationswerte irreführend. Ich dachte nämlich yes heißt das, wenn man es nicht haben möchte. Was heißt überhaupt

    Quellcode

    1. #PermitEmptyPasswords no
    ? Anonyme Anmeldung per SSH oder wie?
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 128641 haftet ausdrücklich der jeweilige Autor: derwunner

  • Eine anonyme Anmeldung eher nicht. Ein User-Name wäre ja noch immer notwendig.
    Es steht ja auch "no" dort und nicht "yes"
    Wozu diese Option genau gut ist, kann ich jetzt so kurz vor dem zu Bett gehen auch nicht sagen....

    Für den Inhalt des Beitrages 128643 haftet ausdrücklich der jeweilige Autor: ThomasS

  • PermitRootLogin=no ist der Standard, siehe meine Ausgabe, dort ist PermitRootLogin auskommentiert, also greift Standard.....
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 128649 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Deine Punkte sind eine Melange von Hören-Sagen, Halbwahrheiten und nacktem Nichtwissen.
    Sicher wäre der Server, wenn du ihn abmelden würdest.
    Und ich meine das ernsthaft als guten Ratschlag.


    derwunner schrieb:

    Hallo,

    ich betreibe einen Server im Rechenzentrum (Hetzner), auf dem openSUSE 42.3. Das YAST System Hardening habe ich schon ausgeführt, trotzdem steht mein Server regelmäßig unter SSH Brute-Force Beschuss.
    Das ist business as usual. Wir loggen auf unserem Server täglich ca. 5000 Versuche. Mal mehr, mal sehr viel mehr, mal weniger.


    derwunner schrieb:

    Ich habe habe schon viele asiatische IP Adressen via iptables ausgeschlossen. Das hat zumindest die Anzahl von mehreren Tausenden täglich auf den einstelligen Bereich verkleinert. Das ist für mich immer noch nicht zufrieden stellend, weil ich das im besten Fall komplett unterbinden möchte.
    Das schlichte Aussperren ist keine Lösung. Denn damit triffst du auch User, die damit gar nichts zu tun haben. Erwischt du ein IP von einem bösen Buben, und sperrst die dann, sind damit auch alle die User ausgesperrt, die später mit dieser IP im Netz unterwegs sind. Das ist der Normalfall für alle normalen Einwählmechanismen. Egal ob Router zu Hause mit DSL oder Smartphone. Ein böser Bube trifft also x^2 Unschuldige.
    Theoretisch wirst du irgendwann das gesamte Netz ausgesperrt haben (Was nur nicht eintritt, weil du und dein Server vorher längst gestorben sind)

    derwunner schrieb:

    Was ich bisher gemacht habe:
    • SSH Authentifizierung über Schlüssel (RSA 4096 Bits)
    • sichere Passwörter mittels des Generators Strong Random Password Generator und der Einsatz von KeePass auf dem Client System um die Passwörter merken zu können
    • Ich hatte versuch in der SSH Daemon Einstellung die Anmeldung via Passwort abzuschalten, hatte jedoch keinen Effekt.
    • Von der Polizei hatte ich mal gehört, dass es nichts bringt Fail2Ban einzusetzen, wenn der Angreifer wechselnde IP-Adressen verwendet.

    Auf einem Server schaltet man zu allererst bei SSHd die Möglichkeit, sich mit einem Spasswort anzumelden, komplett ab. Nur mit Schlüssel. Sonst nada, nothing niente.

    Der Polizei für das Netz sicherheitstechnische Kompetenz zu unterstellen, ist ein Fail, denn man sofort bannen sollte.
    Selbstverständlich gehört fail2ban zur Grundausstattung jeden Servers (sofern man nicht richtig große IDS einsetzt. ).
    Aber, wie jedes Serverprogramm unter Linux, muss man es erst verstehen und dann sauber konfigurieren. Danach muss man TÄGLICH dessen Logs prüfen.
    Mit fail2ban werden Loginversuche auf einzelne Dienste überwacht.

    Es geht also um jeden 'Port, auf dem ein Service lauscht, und eben NICHT um irgendwelche IP-Adressen, von denen die Anfrage kommt.
    Die Aussage der mal "irgendwo gehörten Polizei" ist technisch schlicht falsch. Kompletter Schwachfug.

    Und du MUSST für jeden deiner Serverdienstge, egal, ob Web, Mail, NFS, CIFS um nur die bekanntesten zu nennen, JEDEN davon sauber innerhalb von fail2ban konfigurieren.

    Samt korrekter Einschätzung des "Treatlevels" und entsprechender Echtzeitbenachrichtigung.

    derwunner schrieb:

    Was ich tun möchte:
    • root Login per Remote abschalten ist ja eine Empfehlung, die es schon länger gibt. Schön und gut, nur wie geht es dann weiter? Denn ich kann mir nicht vorstellen, dass es sicherer sein soll, sich mit einem unprivilegierten User am System anzumelden, um in dessen Home Verzeichnis den root SSH Key zu hinterlegen.

    Es ist Sinn und Zweck von SSH, dass man sich remote einloggen kann, oder selektiv irgendwelche Kommandos ausgeführt werden können. Und das macht man eben von remote. Diese Empfehlung meint nichts anderes, als SSH abschalten. Schwachfug.

    Die Empfehlung root diese Möglichkeit zu nehmen, gilt für das Spasswort Szenario. Denn wenn man sich als root via SSH nicht anmelden kann, so muss der Hacker erst einen normalen Account knacken UND dann root werden. Es dauert also länger, bis ein Hacker root- Rechte erreicht.
    Das kommt aber auf einem echten Server ja gar nicht vor, weil dort sowieso sich absolut gar niemand mit einem Spasswort einloggen kann.

    Sobald nur das Einloggen mittels Schlüssel möglich ist, existiert dieses Thema nicht mehr. Und das ist heute (leider) der einzig sinnvolle Einsatz von SSH. Alles andere ist eine Einladung zum gehackt werden, mit Anlauf, Vorsatz und Absicht.

    derwunner schrieb:


    • eine Intrusion-Detection / Intrusion Prevention Firewall einsetzen. Für mich kämen hier Snort oder ossec-hids infrage. Für andere Alternative bin ich natürlich offen. Leider steige ich bei beiden genannten nicht so wirklich durch, gerade was Konfiguration und Inbetriebnahme anbelangt
    • Applicaction-Level Firewall: Es gibt ja drei große im Linux Umfeld: selinux, Novell's AppArmor (mein Favorit) und noch eine, dessen Name ich vergessen habe. Von selinux ist soviel ich weis eher abzuraten, weil das die NSA mitentwickelt hat. Eine Hintertür ist also nicht unbedingt auszuschließen.

    Davon rate ich ab. Um auch nur eine davon zu betreiben, sind ein paar tiefergehende Kentnisse nötig. Wenn du die üblichen Paketsniffer ( die ganze tcpdump Familie) aus dem Effeff beherrscht UND komplexe RegExe betrunken, rückwärts unter Wasser fehlerfrei auf Anhieb schreiben kannst UND die ganze TCP/IP Protokollfamilie mit Vornamen kennst, DANN und ERST DANN kannst du dich an ein echtes IDS/IPS wagen.
    Ist das nicht der Fall, wird der Server i.d.R. nach der Installation unsicherer sein, die Dienste enorme bis nicht hinnehmbare Verzögerungen haben und deine User richtig sauer sein.
    Wenn dich das dennoch nicht abschreckt, würde ich zu Suricata raten. Ein geiles IDS/IPS

    derwunner schrieb:


    • lohnt es sich SSH auf einen anderen Port als 22 zu legen? Das ist laut meines Wissens "Security by obscurity" aka "Kopf in den Sand stecken" und bringt nicht wirklich was. Das Netz wird ja laut Forschern regelmäßig ausgeforscht. Wer also meinen Server findet, sollte auch in der Lage sein einen Port Scanner zu bedienen. Es mag vielleicht sein, dass es den ein oder anderen "Skript-Kiddie" vom Brute Forcen abhält, weil das 0815 Skript dann nicht mehr funktioniert, aber die große Masse wird es denke ich nicht abhalten.

    Das bringt selbstverständlich was. Man nehme einen Port, der nicht in den 10000 meist verwendeten Ports, die von nmap gescannt werden, und schon geht die Last merklich nach untern.
    Das macht das Lesen der Logs leichter, die Kiste hat weniger zu tun, womit andere Dienste etwas mehr Leistung zeigen können.
    Natürlich bringt das nur was für den täglichen Kleinkram uns spart ein wenig Ressourcen, für die Sicherheit bringt es nur minimal marginal ein klitzeklein wenig.

    derwunner schrieb:


    • Lohnt sich der Einsatz eines SSH-Fakers? Man könnte zum Beispiel den Faker auf den SSH Port 22 lassen und fälscherlicher weise jeden ins System lassen und den richtigen SSH Zugang auf einen anderen Port legen.


    Du willst also jemanden reinlassen, den du nicht reinlassen willst.
    Kommt dir das nicht selber dämlich vor?
    Der "Faker" fakt dann was genau? Eine FakeShell? Eine FakeBratwurstbude?

    Wenn du Honeypots einsetzen willst, solltest du dafür einen extra Server einsetzen, der NUR VMs für solche "Faker" einsetzt, laufen lassen.
    Auf dem eigenen Server sowas zu machen, ist wieder Katastrophe mit Ansage, Anlauf und purem Vorsatz.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 128652 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • derwunner schrieb:


    • zusätzlich zur Schlüssel Authentifikation möchte ich einen Hardware Wallet verwenden. Es ist schließlich schon länger bekannt, dass Quantencomputing theoretisch möglich ist. Damit ist laut diversen Security Beilagen der Fachzeitschrift iX aus dem letzten Jahr jede SSH Verbindung als unsicher zu betrachten, die nicht über ein zusätzliches Mittel abgesichert ist. Nur ist hier auch nicht alles Gold was glänzt, denn zum Beispiel der Yubikey hat eine zu lange Leiterbahn und man kann dadurch wenn man neben der Person steht den geheimen Schlüssel aus den elektromagnetischen Wellen empfangen und auslesen. Die Google Alternative möchte ich ebenfalls nicht verwenden, weil es Google ist (man kennt ja Google was die teilweise für Schweinereien betreiben, von gesetzlich vorgeschriebenen Hintertüren ganz zu schweigen...). Als letzte Alternative bleibt dann wohl nur noch der USB Stick aus dem Hause Ledger. Falls da jemand eine gute Alternative kennt, dann bin ich dafür gerne offen. Neben der SSH Authentifizierung möchte ich den Hardware Wallet mit folgenden Kryptowährungen benutzen: Bitcoin, Ethereum (mit Tokens) und Steem

    Was auch immer du unter "Hardware Wallet" verstehst:
    Auch für die gelten die elektromagetischen Gesetze.
    Hochpotente Dienste können aus einer Entfernung von mehreren Kilometern deinen Bildschirm durch Wände hindurch lesen, und deine Tastatureingabe in Echtzeit mitschneiden.

    Willst du wirklich sicher sein, wirf ne Granate in den Server rein.
    Aus. Omega. Ende. Punkt. Für jeden deutschen Forstadjunkt

    Es gibt derzeit zwei (in Zahlen: 2) Quantenrechner weltweit, die Hinz&Kunz das Programmieren von Quantensoftware und das Testen dieser Programme frei ermöglichen.
    Melde dich dort an und schreibe ein paar Quantenrechnerprogramme.
    Du wirst, wenn du das schaffst, sehr schnell feststellen, dass es noch nicht einmal halbwegs einsetzbare Peripherie dafür gibt.
    Die Bedrohung durch Quantenrechner ist derzeit ähnlich hoch, wie die Gefahr, dass eine Radlwerkstatt ohne Internet und Wissenszufluss von außen in einem halben Jahr eine Rakete entwickelt, die die Bewegunsrichtung der Andromedagalaxie so ändert, dass der Zusammenprall mit unserer Galaxie in 15Millarden Jahren ausgeschlossen und beim Start noch der ganzen Weltraumschrott in unserem Orbit aufgekehrt wird.
    Und selbst wenn die Entwicklung schneller voranschreiten würde, würde es am Müll im Orbit scheitern.

    Wenn sich dann Quantenrechner endlich soweit entwickelt haben werden, dann wird noch immer nichts passieren, denn unsere heilig- demokratischen Dienste werden das unter Verschluss halten. Warum auch sollte Otto-Normal-Demokrat auf einmal das Können, was nur sie selbst schon immer praktizieren?

    Deine ganzen Key- Überlegungen sind fragwürdig.
    Warum nicht schlicht ein anständiges VPN mit eigener CA aufsetzen, alle Kommunikation darüber laufen lassen, und alle Keys auf einem Stick speichern der korrekt mit cryfs oder ähnlichem verschlüselt ist, und der danach bei Oma im fernen Hintertupfingen unter dem Kopfkissen liegt? (Dort sucht garantiert niemand)
    Das ist praktikabel, kostet nichts und man lernt dabei ein paar Basics.

    derwunner schrieb:


    • Gegen DDoS Attacken kann man sich doch nicht schützen, außer die Power in ein Content Delivery Network abzuleiten, das hoffentlich mächtiger und größer ist als die Bandbreite des Angreifers, oder? Was man tun kann ist soviel ich weis Dienst-Abschottung. Das heißt, wenn ein Dienst befeuert wird, dass die anderen weiterhin störungsfrei laufen. Das erreicht man laut meines Wissen durch Virtualisierung und/ oder Cloud Computing. Für mein Low Budget also eher schlecht, oder?

    Das ist Quark.
    DDOS ist eine Attacke von zig-Millionen Rechnern, die einen Rechner mit Dienst(e)anfragen bombadieren.
    Der angegriffene Server MUSS auf jede Verbindung reagieren. Irgendwann ist der Netzwerkstack so überlastet, dass KEIN Dienst mehr korrekt funktioniert,
    womit sich die Last nochmal erhöht, weil jetzt auch alle legitimen Verbindungen wegen der nun auftretenden Fehler eine erneute Übertragung zur Fehlerkorrektur verlangen.
    Und kurz darauf ist der Netzwerkstack dieses Rechners in einem aussichtslosen Kampf von sich potenzierender Korrektur und Abwehr gefangen, was von außen so aussieht, als sei er schon komplett gestorben.

    Gegen DDOS machst du gar nichts.
    Ende Gelände.

    Das machen andere. Nämlich die Provider im Backbone untereinander.
    Entgegen der landläufigen Meinung, dass ein Rechner eine Verbindung zu einem Server aufbauen würde, ist das per definitionem falsch. Das tun nur "virtuelle Verbindungen" auf einer hohen Protokollebene, die eben als Grundlage NUR auf diese tatsächliche Verbindung zur Verfügung haben.
    Physikalisch wird IMMER NUR EINE Verbindung zum nächsten "Hop" aufgebaut, der dann seinerseits wieder eine Verbindng zum nächsten "Hop" aufbaut. (und das ganze natürlich wieder auf die gleiche Weise zurück für die Antwort, die auch auf einer höheren logischen Ebene wohnt.)

    Wenn du eine Website aufrufst, ist der erste Hop dein WLAN-Router, der zweite der Einwahlknoten deines DSL-Providers, dann mögen sich die Pakete ein paar Hops lang im Netz deines Providers tummeln, bis sie den Übergang zum nächstbesten Provider gefunden haben. Jetzt läuft die Kommunikation eine Ebene höher. Rein zwischen zwei Providern auf deren Backbone.
    Es mag nun sein, dass deine Pakete noch immer nicht im korrekten Subnetz aufschlagen. Also geht das Spiel noch eine Ebene höher. Wieder ein Hop.
    Die Provider betreiben untereinander ebenfalls ein hierarchisch gegliedertes Netz. Auf dieser Ebene sprechen wir von SecondTier, ThirdTier usw. von sogenannten AS Diese AutonomenSysteme sind letztlich ein unabhängier Zweig dieses riesigen hierarchischen Baumes, also ein Provider mit all seinen in eigenen Netz angeschlossenen Rechnern UND ALLEN dort angeschlossenen Subnetzen)

    Deren Aufgabe ist die möglichst schnelle und möglichst kürzeste Route zum tatsächlichen logischen Zielrechners zu finden und alle Pakete über diese Strecke zu übermitteln, und, sollte diese Strecke langsamer werden, Ausweichrouten bereitzustellen und einzusetzen.

    Auf dieser Ebene stellen dann Jungs mit ganz anderen Werkzeugen und ganz anderem Netzwerk Know- How fest, dass Böses im Gange ist, und reagieren entsprechend. Das tun die notwendigerweise aus reinem Eigennutz. Ein DDOS belastet ihre Backbones, treibt damit die Peeringkosten und verschlechtert für ALLE den Durchsatz.
    Wir spielen da garantiert NICHT mit.

    Alles, was du tun kannst, ist abschalten.
    Gegen DDOS machst du gar nichts.
    Ende Gelände.

    Und legst du dein Zeuchs in die Cloud, tust du genau das, was du als Obscurity bezeichnet hast.
    Nur weil du die Löcher und Gefahren der Cloud nicht siehst, gibt es sie nicht.
    Du verlagerst lediglich dein Risiko auf die Cloudbetreiber, die das zwar i.d.R. besser können, als man selbst, aber eben auch alle deine Daten in IHREN Netzwerken haben.
    Du selbst hast nicht einmal ansatzweise die Chance zu erfahren, wie sicher oder nicht, deren Netz intern ist und wer da alles mitliest.

    derwunner schrieb:

    Wie man sehen kann, gibt es noch viel zu tun. Deswegen würde ich mich sehr über jeden Ratschlag aus der Community bezüglich meiner geschilderten Aufgabenstellungen freuen :smilie_hops_011:

    MFG

    derwunner
    Was mich wundert, dass nichts von psad geschrieben hast.
    Den PortScanAttackDetektor halte ich bei einem Server für ebenso grundlegend, wie einen Kernel.
    Den solltest du -natürlich ebenso sorgfältig konfiguriert, wie SSH und Fail2ban- unbedingt einsetzen.

    fail2ban, psad und ufw sollten immer am Start sein. Sie bieten die grundlegenden Einblicke und Abwehrmechansimen, die unverzichtbar sind.
    ufw, die UncomplicatedFireWall, ermöglicht dir das sichere Einstellen deiner Firewall. Dieses Frontend zur eigentlichen Firewall erlaubt es dir Regeln zu erstellen, die funktionieren und einfach handhabbar machen. Machst du deine Regeln selbst, oder kopierst einfach irgendwelche aus dem Netz, wird das Ergebnis i.d.R. eine vorsätzlich selbst durchlöcherte Firewall sein.
    Leute, die das können, würden einen solchen Post nicht erstellen. Daher mein guter Rat: Finger weg von iptables!
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 128653 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Berichtigung schrieb:

    Hallo,
    Das ist business as usual. Wir loggen auf unserem Server täglich ca. 5000 Versuche. Mal mehr, mal sehr viel mehr, mal weniger.
    Moin zusammen,

    welch himmlische Ruhe auf einem server auf einmal herrscht, wenn man den sshd schlichtweg auf einem anderen unüblichen Port lauschen lässt ..... haut 95% der dämlichen Angriffe ins Nirvana.

    Ich habe meine Server allesamt mit der Kombi anderer Port, Passwort Login komplett verbieten - auch und insbesondere für Root sofern der nicht auf login No steht und fail2ban allesamt sehr beruhigt .... so ein paar Unentwegte kommen mal ab und an vorbei, aber die werden gleich mit dem iptables Hammer gehauen und das wars dann in aller Regel auch schon. :saint:
    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 128656 haftet ausdrücklich der jeweilige Autor: Tamerlain