Iptables Regel

[LessSecurity]

Hallo.
Jeder mit einem Server kennt ja das Problem mit Spam, ssh-bruteforcing etc.

Natürlich benutze ich uA. fail2ban um dem Einhalt zu gebieten. Zusätzlich dazu nutze ich iptables mit reject-regel, gefüttert von öffentlichen und eigenen Blacklists.

Allerdings gibts zB. auch Referrerspam in meinen Statistiken. Könnte ich zwar mit webalizereigenen Mitteln abwehren, oder htaccess (mit htaccess in dem Punkt noch nicht auseinandergesetzt), aber ich hab mir was ausgedacht.

Nachdem ich einen Server angepingt habe bemerkte ich dass die Antwort von 127.0.0.1 kommt.

So kam ich auf die Idee, dass jemandem der zuviele Fehlversuche bei ssh hat, quasi sich selber brutet, indem ich eine forwardingregel oÄ. anwende die auf 127.0.0.1 verweist.

Allerdings tun sich da möglicherweise Probleme mit auf.

Würde so ein forward den Angreifer überhaupt erreichen, oder würde die 127... auf meinen servereigenen localhost verweisen?

Ein Angreifer könnte seine IP ja manipulieren. Angenommen er hat 1.2.3.4 aber manipuliert seine IP so dass es für meinen Server aussieht als kämen die Anfragen von 2.4.6.8 . Wie könnte ich verhindern dass mein Server dann an 2.4.6.8 weiterleitet, und würde er das überhaupt tun?

Mir würde es nämlich nicht gefallen, wenn es auf einmal so aussieht als würde mein Server zB. einen komplett unbeteiligten Server bruten würde. Ich will Unbeteiligte ja komplett aus dem Spiel lassen.

Und ganz wichtig wäre für mich erst mal zu wissen, was war überhaupt passiert als ich den Server angepingt habe, und der reply augenscheinlich vom localhost kam?

 

[elias5000]

Wie passen bitte Refererspam, SSH bruteforce und Ping zusammen?
Dein Posting ist sehr wirr.

 

[LessSecurity]

Es geht doch nicht darum in welcher Beziehung ping und ssh-bruteforce zusammenpassen.

Es geht darum bei jenen ssh-brutern quasi den gleichen Effekt auszulösen wie den, den ich bei der pingabfrage an den server erfahren habe.

Mit fail2ban kann ich mir eigene Regeln erstellen, zB. wer den Referrer xy hat, wird auf sich selbst umgeleitet. Gut, den Referrer werde ich in der webalizer.conf excluden. Meine Annahme war hier aber, der Spammer würde theoretisch dann bei sich selber anfragen wenn er die Antworten von "localhost" erhält.

Vielleicht täusche ich mich wirklich damit. Deswegen auch die Frage, was ist überhaupt wirlich passiert als ich 1.2.3.4 gepingt habe und die Antwort von 127.0.0.1 kam

 

[d4f]

was ist überhaupt wirlich passiert als ich 1.2.3.4 gepingt habe und die Antwort von 127.0.0.1 kam

Hast du die IP oder eine Domain angepingt?
Domains können auf 127.0.0.1 verweisen oder aber dein Server hat schlicht ein NXDOMAIN um seinen eigenen Hostname ergänzt (abstellbares Verhalten)

Mit fail2ban kann ich mir eigene Regeln erstellen, zB. wer den Referrer xy hat, wird auf sich selbst umgeleitet.

Hier gehst du davon aus dass das Spam-Tool mehr kann als POST-Abfragen ab zu senden. Schliesslich schickst du dem Client nur den Befehl "bitte leite auf dich selber um". Falls er diesen ignoriert oder überhaupt nicht bemekrt wird daraus nix.

quasi sich selber brutet, indem ich eine forwardingregel oÄ. anwende die auf 127.0.0.1 verweist.

Klar ist das möglich. Beachte aber dass du dann ein Proxy für ihn auf sich selber bist; falls also ein Kunde von Webhoster X dich angreift und die die Angriffe umleitest passiert unter dem Strich dass Webhoster X deinem Anbieter eine Abuse-Meldung schreibt weil du SIE angegriffen hast.
Erkläre dann mal deine Logik deinem RZ und dem Webhoster

Ein Angreifer könnte seine IP ja manipulieren. Angenommen er hat 1.2.3.4 aber manipuliert seine IP so dass es für meinen Server aussieht als kämen die Anfragen von 2.4.6.8 .

Spoofing ist bei TCP in gerouteten Netzwerken ehrheblich schwerer. UDP hingegen stellt kein Problem dar. SSH und HTTP laufen beide über TCP, du kannst also im Regelfall davon ausgehen dass Absender auch Empfänger ist.

Ich will Unbeteiligte ja komplett aus dem Spiel lassen.

Dann lass doch auch das Netz deines Providers und dessen Carriers aus dem Spiel und mach nur ein -j DROP? Kostengünstiger in Punkto Leistung und Geld ist es allemal.

 

[LessSecurity]

Hey d4f,

danke für deine Antworten die meine Annahmen und Bedenken einwandfrei bestätigt haben.

Hast du die IP oder eine Domain angepingt?

Ich habe beides angepingt.
Was genau meinst du aber mit "nxdomain um eigenen Hostname ergänzt", und wie wird es abgestellt?

Hier gehst du davon aus dass das Spam-Tool mehr kann als POST-Abfragen ab zu senden.

So sieht es in meinem access.log aus:

77.10.XX - - [XX +0200] "GET / HTTP/1.1" 200 566 "http://www.tunXX/chiptuning-forum/ftopic12.html" "Internet Explorer 8.0; WinXP"
77.10.XX - - [XX +0200] "GET / HTTP/1.1" 200 566 "http://www.tunXX/chiptuning-forum/ftopic12.html" "Netscape 6.0; WinNT6.1"

Beachte aber dass du dann ein Proxy für ihn auf sich selber bist; falls also ein Kunde von Webhoster X dich angreift

Damit habe ich gerechnet, aber die Hoffnung gehabt dass es etwas anders laufen könnte.

Dann lass doch auch das Netz deines Providers und dessen Carriers aus dem Spiel und mach nur ein -j DROP? Kostengünstiger in Punkto Leistung und Geld ist es allemal.

Das ist die nächste "Sorge" gewesen die ich hatte, zumal bei einer gespooften IP uU. ein komplett anderer Rechner angegriffen worden wäre.

Am Punkt DROP scheiden sich ja die Geister. Was da wirklich besser ist kann ich (noch) nicht beurteilen. Für beides gibt es gute und schlüssige Argumente, und ich denke dass noch der Faktor Programmierung des Bots hizukommt.

 

[d4f]

Was genau meinst du aber mit "nxdomain um eigenen Hostname ergänzt", und wie wird es abgestellt?

In /etc/resolv.conf search abschalten und evtl zusätzlich ndots-Funktionalität ebenfalls abschalten.

options ndots:0
search ""

Die Idee ist zB falls dein Server hostname server1.domain.de hat und du 'server2' (ohne was dahinter) anpingst dies magisch in server2.domain.de umgewandelt wird. Das kann aber nach hinten losgehen dass eine nicht existierende existiert-nicht.de in existiert-nicht.de.domain.de umgewandelt wird, was dann auf 127.0.0.1 zeigt.

So sieht es in meinem access.log aus:

Was genau soll mir das jetzt sagen?

Am Punkt DROP scheiden sich ja die Geister. Was da wirklich besser ist kann ich (noch) nicht beurteilen.

Du kannst allerhöchstens manuell oder automatisiert ein Abuse schicken. Aber den Traffic willst du weder zurückschicken (sinnfreie Kosten) noch durchlassen. Also bleibt so oder so nur drop oder direktes Schliessen der TCP-Verbindung.

 

[Joe User]

Am Punkt DROP scheiden sich ja die Geister. Was da wirklich besser ist kann ich (noch) nicht beurteilen.

Dann solltest Du die Beurteilung Profis überlassen: http://altlasten.lutz.donnerhacke.de/mitarb/lutz/usenet/Firewall.html#Deny

 

[d4f]

Die Vergleice im verlinkten Blog hinkeo so stark dass sie ne Gehhilfe brauchen.
Man kann in aller Regel davon ausgehen dass der Sysadmin des sendenden Servers
a) es durch Verbindungslogs selber merkt
b) nicht interessiert oder eh nicht bemerkt
c) gar nicht existiert

Ein reject kostet also nur unnötige Ressourcen und hilft dem Angreifer sogar
Wenn er keine Antwort kriegt weiss er nicht was Sache ist und muss bis zum Timeout die Verbindung verhalten


Zum Vergleich mit der Einkaufsstrasse und dem Bettler:
der Angreifer bettelt nicht manuell sondern automatisiert. Es entspricht also einem Cd-spieler welche dauernd Betteleien ausschickt.
Es ist also besser ihn zu ignorieren also ebenfalls mit einem cd-spieler "nein" zu antworten

 

[Joe User]

Die Vergleice im verlinkten Blog hinkeo so stark dass sie ne Gehhilfe brauchen.

Zunächst ist es kein Blog, sondern die de.comp.security.firewall FAQ, erstellt von den fähigsten Firewall-Admins Deutschlands. Diese Leute wissen sehr genau, was sie tun und was sie anderen raten. Ich bin mir relativ sicher, dass diese Leute geringfügig mehr von der Materie verstehen, als wir alle hier.

Ein reject kostet also nur unnötige Ressourcen und hilft dem Angreifer sogar

Nichts Anderes steht in der FAQ, nur dass es dort besser erklärt ist.

 

[d4f]

Nichts Anderes steht in der FAQ, nur dass es dort besser erklärt ist.

Doch. In der FAQ steht deutlich dass man REJECT statt DROP nehmen soll; " Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst, nimm DENY."

Ich bin mir relativ sicher, dass diese Leute geringfügig mehr von der Materie verstehen, als wir alle hier.

Mag gut sein. Aber dann übersimplifizieren diese Leute den Inhalt so weit dass ihr ganzes Fachwissen schlicht nicht mit einfliesst und das Resultat genau wie die Informationen der meisten FAQ's/Blogs/Foren schlicht wertlos ist.
Die ständigen Vergleiche mit Fussgängerzonen u.a. sind bei den Haaren herbei gezogen.

Ein Beispiel aus dem gleichen Eintrag:

Es ist problemlos möglich, viele tausend Scans gleichzeitig zu starten und so auf alle Timeout gleichzeitig zu warten.

Nein ist es nicht _problemlos_. Aus mehreren Gründen
- Die Blockiersysteme des eigenen Hosters/RZ/Carrier springen sehr schnell an
- Die Blockiersysteme des Ziel-Hosters/RZ springen sehr schnell an
- Es gibt nur eine begrenzte Anzahl an möglichen gleichzeitigen Verbindungen
- Conntrack-Tabellen sind nur begrenz lange und das Ziel wirft alte Verbindungen aus der Tabelle wenn diese aufgeschöpft ist.

Aus diesen Gründen ist das Ergebnis des Scans dann zweifelhaft da man nicht weiss ob ein Paket vom Ziel willkürtlich gedroppt wurde oder durch die massive Anzahl einkommenden Daten. Hier würde ein REJECT (bezogen auf das eigentliche Thema) dann sogar dem Angreifer helfen da er dann weiss was ankam und was nicht.

 

[Mr.Check]

So ganz nachvollziehen kann ich die Argumentation für REJECT auch nicht. Die Beispiele auf der Webseite spotten jeder Beschreibung. Genau so gut könnte man auch sagen dass man den Bettlern lieber aus dem weg gehen sollte (DENY bzw. DROP) statt sich auf eine Diskussion einzulassen (REJECT).

Technisch gesehen hat m.E. der REJECT den Vorteil, dass man beim Debugging sieht, an welcher Stelle Pakete verworfen werden. Das ist mir bei einem öffentlichen Server aber egal. Mit gespooften IP-Adressen würde aus einem eingehenden Flood bei REJECT sogar noch ein ausgehender werden.. Oder sehe ich da was falsch?

 

[Joe User]

Doch. In der FAQ steht deutlich dass man REJECT statt DROP nehmen soll;

Richtig und dort steht auch genau warum:

Als REJECT bezeichnet man die aktive Ablehnung einer Verbindungsanfrage mit einem ICMP Paket vom Inhalt "Der Admin hat's verboten" oder "Dienst nicht verfügbar".
...
Sieh das Ganze doch so, wie in einer offenen Beziehung:
Es ist besser seinem Partner direkt zu sagen, daß man über ein bestimmtes Thema nicht sprechen möchte (REJECT): Der Partner weiß sofort, was Sache ist und und kann dann ohne Zeitverzögerung seine Entscheidung darüber treffen, ob er die Beziehung fortsetzen möchte oder nicht.

Was macht noch gleich der Kernel OOTB?

 

[d4f]

Was macht noch gleich der Kernel OOTB?

Standardmässig macht Software vieles was in verschiedenen Nutzungsszenarien Sinn ergibt oder mal ergab.
Das bedeutet aber nicht dass es immer Sinn ergeben muss oder gewünscht ist.

EXT4 aktualisiert auch noch immer brav standardmässig die access-time aller Dateien. Sinnvoll und performant ist das aber nicht, gewünscht und gebraucht wird es auch nur in sehr wenigen Szenarien.

 

[Deleted member 14254]

Also auf die Frage: 'REJECT' vs. 'DROP' - würde ich persönlich auf 'DROP' setzen.

Im Beispiel ServerSecurity: Durch rejecten dem Angreifer zusätzliche Informationen zukommen zu lassen, (was wurde rejected, was aber kam durch) - halte ich prinzipiell nicht für sehr sinnvoll. Ein 'DROP' lässt den Angreifer nur sehen, das nichts mehr durchgeht, aber nicht, welches Paket genau dies verursacht hat. Die gesamte IP hat nach dem Erstellen einer IP-Tables-DROP-Regel keinen Zugang mehr zum System auf Basis, des genutzten Ports.

Im Beispiel 'Beziehung': Hier ist - natürlich - besser, auf 'REJECT' zu setzen, da ja, auch wenn eine Meinungsverschiedenheit mit dem Beziehungspartner besteht, man dennoch weiteres Interesse an einer Kommunikation mit ihm verfolgt. Zumindest temporär. HIER 'DROP' zu setzen käme ja einem sofortigen Verbindungsabbruch mit dem Partner gleich - Etwas, was sicherlich hier nicht Wunsch sein kann.

DENY: Man kann herausfinden, WAS wird denn alles verneint... -Einladung- Zum Trotz noch mehr Anfragen gestartet.

f2b mit IPTABLES:

Natürlich benutze ich uA. fail2ban um dem Einhalt zu gebieten. Zusätzlich dazu nutze ich iptables mit reject-regel, gefüttert von öffentlichen und eigenen Blacklists.

Normalerweise brauchst Du, wenn Du mit f2b arbeitest keine eigenen IP-Tables-Regeln zu erstellen, weil es dadurch Probleme geben kann, wenn f2b sich einmischt, und nach einer gewissen Zeit die DROP-Regeln wieder entfernt. Davon hatte ich gelesen. Wenn man eigene Regeln erstellen möchte, sollte man nur mit IP-Tables als 'Firewall'-Lösung arbeiten, nicht aber zusätzlich als 'Wirkstoff' für Log-Analyzer.

Bruteforce auf SSH:
Hier würde ich empfehlen, Password-login komplett zu disablen und auf das PublicKey-Verfahren zu setzen: Hierbei ist PAM (Password-Access-Module) für den Daemon SSH disabled und es wird der login NUR dann zugelassen, wenn sich der private Schlüssel (das Gegenstück zum Öffentlichen, das auf dem Server platziert werden muss) auf dem zugreifenden System - dem Client-System befindet - und - Sicherheitshalber über eine Passphrase verfügt. Somit würde der private Key, selbst wenn er gestohlen würde, für den Dieb wertlos sein, da er ihn ohne die Passphrase nicht nutzen kann. Hier lassen sich bis zu 16kbit (16384 bit)-Verschlüsselungen festlegen. Zum Stand der technik: Ziemlich unmöglich, eine SOLCH starke Verschlüsselung zu bruteforcen.

Kleiner Nachteil: Die Mühe, den privaten Schlüssel portieren zu müssen, und zwar auf ALLE Clients, die Zugriff zum Server haben sollen.

Großer Vorteil dagegen: Man kann gar als Anmeldung root-login zulassen, muss nicht jedesmal erst root 'werden'. UND: Es ist wesentlich sicherer, als für SSH Passwörter zu verwenden!!!

http://wiki.ubuntuusers.de/SSH

Das in Verbindung mit IP-Tables und f2b und 'DROP'...

Und: SSH-Port weg von '22'.

.htaccess:
Ich kenne es nur als Schutz für Webordner: Sollen Intranets vor Zugriff von "Außen" geschützt werden, kann man die .htaccess so einstellen, das der Ordner nur vom IP-Address-Pool des Intranets aus erreicht werden kann. Damit kann man gut Webpanels oder Admin-Zugänge zu CMS schützen. Ich habe bei mir auf eine einzige IP beschränkt um z.B. postfixadmin/phpmyadmin zu schützen. Sicherheitshalber heißen die bei mir auch nicht so... Der Name taucht in der url nirgends auf.

http://de.selfhtml.org/servercgi/server/htaccess.htm

 

[d4f]

Es ist wesentlich sicherer, als für SSH Passwörter zu verwenden!!!

Sicherheit bedeutet dass der Aufwand höher dem Risiko ist.
Entsprechend ist nicht die Frage ob etwas _sicherer_ ist sondern ob etwas _sicher_ ist.
Bei einem 24stelligen Passwort mit Gross-Kleinschreibung (52 Zeichen), den üblichen Sonderzeichen (15 Stück) und Zahlen (10 Zeichen) ist die Zahl möglicher Angriffe eine 1 mit 45 Nullen dahinter, im Worst-Case bei 100 Anfragen/Sekunde (hoch geschätzt bei fail2ban und einem durchschnittlichen Botnet) braucht der Angreifer also eine 6 mit 35 Nullen an Jahren... ein Stück länger als unsere Sonne lebt.

Der Mehraufwand von Zertifikaten ist also in vielen Nutzungsszenarien nicht notwendig, es kann aber auf den üblichen "Arbeitsrechner" oft praktisch sein mit einem (eigenen) Passwort dank Zertifikat-Login in alle Server rein zu kommen.

Hauptrisiko ist so oder so ein Trojaner auf dem eigenen Rechner welcher auch aus Keyfiles kurzen Prozess macht und diese einfach brav mit hochlädt sobald er den Decryption key kennt.

 

[Deleted member 14254]

Dem Rechenbeispiel in Bezug auf 'Sichere Passwörter' will ich nicht widersprechen, d4f. Doch eine Frage stelle ich mir doch: Selbst WENN der Trojaner, der auf das System gelangt ist, die Keyfiles hochlädt, gelangt der Angreifer immer nur an den Public-Key im "authorized_keys"-File unter "/benutzername/.ssh"
Also würden ihm die keyfiles nur dann etwas bringen, wenn der Serveradmin Password-Auth verwendet. Der private Key auf dem Client wird auf die Art nie in die Hände des Eindringlings geraten. Oder aber der Serveradmin hat ihn gleich mithochkopiert :/ Würd dem Angreifer aber auch nichts bringen, weil er mit dem privaten Key nichts anfangen kann, wenn er eine ebenso, um beim Beispiel zu bleiben, eine Passphrase mit 24 Ziffern plus der möglichen Sonderzeichen enthält. Mit den asymmetrischen Verschlüsselungen schliesse ich ja eben explizit aus, das es niemand anderen geben KANN, der in der Lage sein würde per Passwort einen Login zu erhalten... Die Schwierigkeit, das 24-Ziffern + AllIncl. zu bruten jetzt mal unbetrachtet. Mich persönlich interessiert die Frage: "KANN jemand, ausser mir per SSH Zugriff zum Server erhalten...?!" - Kann ich mir die mit 'Nein' beantworten, eben weil eine asymmetrische Verschlüsselung

[B][U]Verschlüsselung:[/U][/B]
$zu-verschlüsselnde-Zahl ^ öffentlicher Exponent modulo N (Multiplikat der beiden Primzahlen, auf der die RSA-Verschlüsselung beruht)

[B][U]Entschlüsselung:[/U][/B]
$zu-entschlüsselnde-Zahl ^ privater Exponent modulo N

zugrundeliegt und es physikalisch nicht möglich ist, das jemand den Schlüssel lesen kann, mathematisch nicht möglich, das er dann, hätte er ihn doch, etwas damit anfangen kann, weil dieser ja nur mit Passphrase lesbar wird... DANN habe ich zumindest ein deutlich bessereres Gefühl in der Magengegend.

In Anbetracht, das es viel leichter ist, Sicherheitslücken in PHP auszunutzen, stellt sich - einverstanden - dann wieder die Frage: "Wofür steht der Aufwand bei SSH, wenn per Exploiting von PHP-Lücken sehr schnell ein Zugriff möglich werden kann, den SSH-Mechanismus vollständig umgehen...

Allein vom SSH - her... Da hab ich mir wirklich von ganz zu Anfang angewöhnt, generell auf PubKey-Verfahren zu setzen.

OT
Hab mich vor einigen Jahren mal - in einem Schulprojekt in der Technikerschule speziell mit RSA auseinandergesetzt. Bei Interesse kann ich mal ein HowTo nachliefern: Angefangen von der Bildung der Schlüssel - deren Kriterien bis hin zu Funktionsfähigen Ver- und Entschlüsselungen. Möglicherweise bin ich daher so "vernarrt" speziell in RSA
/OT

 

[d4f]

Selbst WENN der Trojaner, der auf das System gelangt ist, die Keyfiles hochlädt, gelangt der Angreifer immer nur an den Public-Key im "authorized_keys"-File unter "/benutzername/.ssh"

Ich habe vom Client geredet, nicht vom Server.
Wenn jemand deine Serverseitige Keyfile lesen kann ist er ja eh schon drin.

KANN jemand, ausser mir per SSH Zugriff zum Server erhalten...?!

Siehe oben. Ein Keyfile ist äquivalent zu einem verdammt langen Passwort, die theoretische Möglichkeit ist also nie ausgeschlossen.
Ich denke sobald Quantencomputer entsprechend hohe qubits verarbeiten können sollte dein Server das kleinste Problem sein aber:
Sollte es dem Angreifer (zB durch Re-Use) möglich sein dein Public-Cert zu erlangen und den Private-Key zu berechnen ist ein Bruteforce ohne Anfragen an deinen Server möglich =)

In Anbetracht, das es viel leichter ist, Sicherheitslücken in PHP auszunutzen

PHP hat nicht so viele für Eindringlinge relevante Sicherheitslücken in letzter Zeit gehabt. (Oder meinst du PHP-basierte Skripte? Diese lassen sich ja schön einschränken)
Und selbst wenn; der Angreifer landet auf einem unpriviligierten Account mit sehr wenigen Berechtigungen.

 

[Deleted member 14254]

Ich habe vom Client geredet, nicht vom Server.
Wenn jemand deine Serverseitige Keyfile lesen kann ist er ja eh schon drin.

Da liegt ein Missverständnis vor, ja. Ich hatte es anders gemeint, als es rübergekommen war: Ich ging von einem böswilligen PHP-Script aus, das an einen Interpreter geschickt wird der dies ausführt, und dann Zugriff zum Server ermöglicht: Worüber ich, - hier war das meine ich mich zu erinnern - mal gelesen habe, das beim Aufruf der Admin-Seite eines $CMS eine "888.php" erschien, die sämtliche Informationen über das infiltrierte Server-System in das Internet publizierte.
An die Beschaffung des PublicKey über ein solches hatte ich gedacht.

Ich denke sobald Quantencomputer entsprechend hohe qubits verarbeiten können sollte dein Server das kleinste Problem sein...

Gut, der 'Quantencomputer'. Aber wer wird ihn haben? Sicher kein Privatmann. Oder auch niemand, der gar eine gesamte Serverplantage unterhält...
Wenn ich mir jetzt einen Angreifer vorstelle, dann als "Gruppe von Crackern" oder auch nur einen Menschen, ein Botnet von ihm aus gelenkt...

Die Quantencomputersache ist mir aus verschiedenen Schriftstücken bekannt, doch nunja, wie wird er beschaffen sein, vor allem, was wird er kosten? Ihn sehe ich als ein riesiges Projekt, wie beispielsweise der CERN - Teilchenbeschleuniger.

...Sollte es dem Angreifer (zB durch Re-Use) möglich sein dein Public-Cert zu erlangen und den Private-Key zu berechnen ist ein Bruteforce ohne Anfragen an deinen Server möglich =)

Obs jetzt mein, oder welcher Server auch immer ist...
Sollte ein Angreifer den Public-Key erlangen, bringt ihm das nichts. Nur halt mit einem entsprechend entwickelten Quantencomputer. Er müsste den entschlüsselnden Teil berechnen (auch ohne Anfrage an den Server, was ihm ohnehin nichts bringen wird, da es um reine Mathematik geht hierbei) ,das Multiplikat der beiden Primzahlen = 'N' - den einzig gemeinsamen Teil von Ver- und Ent- Schlüsselung, faktorisieren um an die Primzahlen zu kommen, damit dann das multiplikative Inverse vom öffentlichen Exponenten bestimmen zu können. Ohne Quantencomputer, auf den er sicherlich nur als eng vertrauter Mitarbeiter in einer Forschungseinrichtung haben kann... dasselbe Unterfangen wie, als gebe es keinen QuComputer. Interessieren würd mich soein ReChiffriervorgang mit Hilfe eines solchen auch mal, und zwar brennend...

 

[Marentis]

Ihm ging es auch um den Quantencomputer, damit könnte man tatsächlich den ursprünglichen Schlüssel "erraten".
Mit heutigem Equipment natürlich sehr unwahrscheinlich (Wahrscheinlichkeit konvergiert gegen 0) in realistischer Zeit machbar, außer man hat "Glück".

Ob und wie weit Quantencomputer in 20-30 Jahren verbreitet sind ist natürlich eine hoch interessante Frage, besonders welche Algorithmen dann zur Verfügung stehen.

 

[d4f]

. Aber wer wird ihn haben?

Den D-Wave One (128Qbit) kannst du, entsprechendes Kleingeld vorausgesetzt, bereits kaufen. Allerdings kann er nur eine einzige Arbeit ausführen; Optimisation (Quantum annealing)
Für Crypto ist er aktuell also ungeeignet.

das beim Aufruf der Admin-Seite eines $CMS eine "888.php" erschien, die sämtliche Informationen über das infiltrierte Server-System in das Internet publizierte

Nur das was PHP eh auslesen und bearbeiten kann. Auf einem üblich abgesicherten System ist das nicht sehr viel was interessant wäre; ausser Versionsinformationen welches Exploits von ungepatchen Lücken ermöglichen könnte.

besonders welche Algorithmen dann zur Verfügung stehen.

Thereotische Versionen der Primzahl-Faktoralgorithmen gibt es bereits.

Ihn sehe ich als ein riesiges Projekt, wie beispielsweise der CERN - Teilchenbeschleuniger.

LHC ist gross weil er viel Energie in die Beschleunigung pumpen muss. Bei Quantencomputer willst du aber möglichst wenig Energie da das Auslesen und Manpulieren sonst viel zu komplex wird.



Aber ich denke wir können als Konklusion behaupten dass zumindest theoretisch auf einem perfekten System weder ein sicheres Passwort noch ein Keyfile ein Sicherheitsloch darstlellt.
Wobei bei Passwörter die Länge des Passworts bei manueller Eingabe natürlich absniffbar ist (bursts) - deswegen hatte ich ja nur die Passwortlänge und nicht Passwortlänge! als Grundbasis zur Berechnung genommen.