Guter Mann, reagiert schnell, höflich und zuvorkommend.
Guter Mann, reagiert schnell, höflich und zuvorkommend.
Du sagst es doch selber das es nahezu unmöglich ist damit etwas zu finden. In einer Stunde schafft man realistisch etwa 7.200 Wallets zu prüfen (bei 0,5 Sekunden pro Überprüfung), nicht 100.000. Die Chance, eine Wallet mit Guthaben zufällig zu finden, ist extrem gering: etwa 1 zu 10^33 wenn ich nicht komplett Dumm bin. Das bedeutet, bei 100.000 Versuchen liegt die erwartete Trefferzahl bei 10^-28, also praktisch null. Wie kommst du da auf einen Preis von 5k? Wenn du selber weißt das dein Tool nutzlos ist und niemals etwas finden wird. Die Chance solo einen Bitcoin zu minen ist höher. Nimm es mir nicht übel, aber dieses Tool ist MAXIMAL 5 Euro wert.
1. Einleitung Grüße, der Post geht mal wieder in Richtung Infrastruktur statt „Crime“ und knüpft direkt an mein letztes Thema an. Dort ging es um WAFs mit ModSecurity. Problem: Wenn der Server selbst Müll ist, hilft die beste WAF nicht viel. Sobald jemand Initial Access hat, sind SQLi egal. Dann geht es um Privilege Escalations und Persistence, um den Server komplett zu übernehmen. Wichtig: Dieser Artikel ist vor allem für Leute relevant, die langfristig Infrastruktur betreuen – Marktplätze, Shops, SaaS (Suites, Mailer, weiß der Geier was). Wer nur ein paar Wochen ein Panel bei einem shady Russenhost laufen lässt, kann das hier ignorieren. Viele bauen fancy Shops, Bots oder self-hosten Projekte, denken aber, Security heißt nur: Cloudflare davor + Reverse Proxy, Auto-Updates, Firewall irgendwie aktiv. Ganz vergessen werden Filesystem-Rechte, SUID+GUID Bits, Logging, unnötige Services oder saubere Systemkonfiguration. 2. Warum System-Hardening wichtig ist Default-Linux ist nicht unsicher, aber generisch. Die meisten Images sind auf „läuft überall“ ausgelegt, nicht darauf, es Angreifern möglichst schwer zu machen. Genau hier setzen die CIS-Benchmarks vom Center for Internet Security an. Angriffe hören selten bei der ersten Lücke auf. Wer einmal drin ist, versucht, Rechte zu erhöhen, Persistenz aufzubauen und Daten auszuleiten. Default-Systeme sind dafür oft zu großzügig: unnötige Dienste laufen, Rechte sind zu weit, bekannte PrivEsc-Tricks funktionieren sofort. System-Hardening macht das Angreiferleben deutlich anstrengender: Es reduziert die Angriffsfläche, erschwert Privilege Escalations und macht Post-Exploitation auffälliger und aufwändiger. ^^ 3. Was sind die CIS Benchmarks? Die Benchmarks vom Center for Internet Security sind im Grunde eine Sammlung von konkreten Empfehlungen, wie ein System sicherer laufen sollte – basierend auf echten Angriffen und entwickelt mithilfe der Auswertung von Incident-Response-Berichten aus echten Breaches. Deshalb setzen Unternehmen, Behörden und Cloud-Provider sie weltweit ein und sie sind der De-facto-Industrie-Standard in Europa, wenn es um Infrastruktur-Hardening geht. Sie decken Dinge ab wie: SSH-Settings, Passwort- und Authentifizierungsrichtlinien, Logging, Netzwerk-, Rechte- und Filesystem-Hardening. Es gibt zwei für uns relevante Level: Level 1: solide Baseline, ohne viel kaputt zu machen (kann relativ gut auf bestehende Systeme angewendet werden, trotzdem vorher in der Testumgebung bitte testen) Level 2: restriktiver, eher für sensible Umgebungen Wer sich in das Thema mehr einlesen will, kann das hier machen : https://www.cisecurity.org/cis-benchmarks 4. System-Hardening Als erstes installieren wir uns alle Pakete, die wir benötigen. Ich mache das jetzt auf einem Debian 12. Solltet ihr ein anderes Linux verwenden, prüft bitte vorher hier, ob es bereits ein fertiges Ansible-Playbook für euer OS gibt. Aktuell unterstützt werden in der Free-Version: RHEL 7-9 Ubuntu 18-24 Debian 11-12 Windows 10-11 Windows Server 2016-2025 (wobei euch auch nicht mehr zu helfen ist, wenn ihr da auf ernst irgendwas Kritisches laufen habt ^^) RHEL 10 und Debian 13 werden mittelfristig ebenfalls kostenlos zur Verfügung gestellt werden. Bis es soweit ist, empfehle ich entweder Debian 12 zu nutzen oder Ubuntu 24 ohne SNAP. 4.2 Vorbereitung Nun zurück zu den Paketen, die ihr installieren müsst: Bash: apt install ansible git sshpass -y # Installiert das Konfigurationstool Ansible sowie die Abhängigkeit sshpass und einen Git-Client. Anschließend klonen wir das Debian-12-Ansible-Lockdown-Playbook, welches die Benchmarks auf unseren Server anwenden wird: Bash: git clone https://github.com/ansible-lockdown/DEBIAN12-CIS.git # Klont das Repository auf euren Server.
cd DEBIAN12-CIS # Gehe in das eben geklonte Repository 4.3 Das Playbook anwenden Um den Benchmark nun anzuwenden, erstellen wir in dem Verzeichnis DEBIAN12-CIS einfach eine hosts.ini mit dem folgenden Inhalt: Bash: [hardening] # Statt Hardening könnt ihr hier alles reinschreiben, das ist nur der Name der Hostgruppe, die gehärtet werden soll.
localhost ansible_connection=local Wenn ihr mehrere Server auf einmal härten wollt, klont ihr das DEBIAN12-CIS-Repo nicht auf euren Server, sondern auf euren Computer und legt eine hosts.ini an, die ungefähr so aussieht: Bash: [hardening]
169.40.CENSORED.CENSORED ansible_user=root
28.15.CENSORED.CENSORED ansible_user=root Jetzt setzen wir im DEBIAN12-CIS-Ordner den folgenden Befehl ab: Bash: ansible-playbook -i hosts.ini site.yml --tags level2-server
# > -i sagt Ansible, es soll unser Hardening-Playbook auf die Hosts anwenden, die wir in der hosts.ini angegeben haben.
# > site.yml initialisiert einfach das Playbook
# > --tags level2-server sagt, dass auf den Server Hardening Level 2 angewendet werden soll
# > --ask-pass (optional, wenn ihr Remote-Server konfiguriert und keine SSH-Schlüssel verwendet) 4.3 Probleme debuggen Wir werden beim Ausführen fast immer auf Probleme stoßen, wie auf diesem Screenshot ganz unten in Rot gut zu sehen ist. Der Fehler sagt uns, dass eine SSH-Hardening-Regel 5.1.8 nicht angewendet werden konnte, weil kein SSH-Server auf meinem Testserver installiert ist. Jetzt haben wir zwei Optionen, dieses Problem zu beheben: Wir installieren einen SSH-Server und die Benchmarks härten den für uns. Wir deaktivieren alle Regeln, welche versuchen, auf die Datei /etc/ssh/sshd_confi aus dem Bild zuzugreifen. Um alle Tasks zu identifizieren, welche versuchen werden, auf diese File zuzugreifen, öffnen wir die folgende File: Bash: nano tasks/section_5/cis_5.1.x.yml Auf welche File ihr jeweils zugreifen müsst, könnt ihr euch recht leicht erschließen. Der Task 5.1.8 wirft einen Fehler, also müsst ihr in den Ordner tasks/ gehen, dort section_5 und so weiter. Nun müsst ihr euch nur noch alle Tasks merken, die auf die besagte File versuchen zuzugreifen. Diese Tasks könnt ihr dann in dieser File deaktivieren: Bash: nano defaults/main.yml Wenn ihr dann alle Fehler behoben habt und das Playbook einmal durchgelaufen ist, habt ihr dasselbe Sicherheitsniveau auf diesem Server wie so gut wie alles, was in Deutschland unter KRITIS fällt (Banken, Strom, Bahn, ...). Wenn ihr ganz hart seid, richtet ihr noch einen Log-Server ein, der eure Audit-Logs entgegennimmt und euch auf Matrix oder TG live über komische Vorkommnisse auf eurem Server informiert. ^^ WICHTIG: Wendet so ein Hardening niemals auf eine Produktivumgebung an, ohne vorher ausführliche Tests in einer Testumgebung durchzuführen – die Gefahr, dass ihr etwas kaputt macht, ist real. Ihr werdet wahrscheinlich auf andere Fehler als ich stoßen, deaktiviert die Regel, die den Fehler wirft, einfach oder implementiert den Fix. Meistens geht aus dem Error oder der Tasks-File recht gut hervor, was das Problem ist. 5. Nachwort Ihr solltet natürlich nicht nur euer Linux härten, auf dem bspw. euer Shop läuft, sondern auch alle Software, die ihr nachträglich dazu installiert, wie z.B. Apache, Postgres etc. Glücklicherweise gibt es dafür auch fertige Benchmarks. ^^ Hoffe, der ein oder andere nimmt hier etwas mit und es ist halbwegs informativ. Der Text wurde mit der folgenden Prompt überarbeitet, da ich zu dumm zum Schreiben bin: „Entferne Rechtschreibfehler und formuliere so, dass es runder klingt“, das Fachliche stammt zu 100% aus meiner Feder. Falls jemand Fragen zu dem Thema hat, kann ich diese gerne im Detail beantworten. Freue mich auch über weitere Themenvorschläge. Habe bereits ein Paar Themen in der Pipeline wie: "FastFlux DIY", "Halbwegs Takedown sicher hosten", jetzt nichts super komplexes und NP ist es erst recht nicht aber vielleicht für den einen oder anderen Anfänger ganz hilfreich. ^^
Also, ich frage immer Leute vor der Packstation nach einem Hotspot oder nutze das WLAN des Supermarkts, an den die Packstation angeschlossen ist. Klappt recht gut, ist aber nichts für irgendwelche 3-Uhr-morgens-Drop-Aktionen.
Die Infrastruktur von PiaProxy wurde zumindest in Teilen zerschlagen wann die wieder kommen steht noch in den Sternen. Kann dir nsocks.net sehr ans Herz legen für alles was nicht Kleinanzeigen ist. https://cloud.google.com/blog/topic.../disrupting-largest-residential-proxy-network
Hi, vielleicht ist es dem einen oder anderen auch aufgefallen: In den letzten Monaten tauchen immer wieder Mail-Spam-Vendoren mit offensichtlichen Scam-Angeboten auf. Das Muster ist immer dasselbe: offensichtliche Scam-Angebote, ein „aged“ New-Member-Account startet einen Verkaufsthread, sobald sein letzter Account gebannt wurde. Eine kurze Historie: @HackerBaby @SpamChef @SpamGott @H1tler > Future Iterations incoming Woran man erkennt, dass es Scam ist? Dass dort komplett widersprüchliche Angebote gemacht werden. HackerBaby zum Beispiel hat Vic-Sets für 10–15 Euro verkauft – welcher Spammer verkauft Vic-Sets, das lohnt schlicht und ergreifend nicht?! Teilweise wird sogar mit Spoofed-Spam und 95 % Inbox-Quote geworben… Viel Spaß beim Inboxen bei outlook.com mit Spoof. Ja Spoofing ist vielleicht punktuell in kleinen Maßstab bei ausgewählten deutschen Providern unter bestimmten Bedingungen noch möglich aber so eine Inbox zu versprechen ist absurd. Deshalb halte ich es für sinnvoll, den Preis für den Spam-Vendor von 200 auf 450 Euro zu erhöhen um diese Masche auszutrocknen, die 200 Euro waren 2018 oder so Zeitgemäß aber nicht mehr 2026. Die Leute die davon Betroffen sind, sind sind eh keine Armen. Jemand, der halbwegs kompetent ist, verdient an einer Kampagne mehrere tausend Euro. Jemand, der „nur“ als Dienstleister spammt, müsste damit maximal eine Kampagne im Monat fahren, um seine Vendor-Lizenz wieder drin zu haben.
Das OPSEC des Shops, nicht des Shopbetreibers … Aber genau das war deine Anleitung im anderen Thread: irgendein Server und dann CF. Hier ist jemand, der offensichtlich keine Ahnung hat und nach Hilfe fragt, und du gibst Tipps, die seine Operation gefährden. Natürlich verlässt du dich nicht auf einen "Bulletproof"-Hoster, dafür gibt es ja Reverse Proxies. Wo sind denn die weiteren Sicherheitsmaßnahmen die den Server Standort verschleiern sollen wenn er mit CF Hosted und man Hostern nicht trauen kann? Da gibt es nur die beiden möglichkeiten CF Tunnel in Whonix rein oder Reverse Proxy, nichts von beidem hast du erwähnt.
Wtf… bei den Domains stimme ich dir zu, aber das mit dem Hosting ist halt einfach Unsinn. Du lieferst dich damit der Barmherzigkeit eines US-Konzerns aus, und davon sollte man sein OPSEC beim besten Willen nicht abhängig machen und schon garnicht die Sicherheit seiner Kunden. Das kannste vielleicht bei einem Panel machen das eh nur 1-2 Wochen online ist aber nicht bei nem Drugstore.
Amtshilfeersuchen wegen schweren Verstößen gegen das BtMG sind SEEEEHR schnell gestellt. Ich denke, man sollte nicht mit der Sicherheit seiner Kunden spielen, nur weil man 5 $ für einen VPS sparen will. Habe mal in einer Akte gelesen das die Dreieckskommunikation Deutsche Bullen > Ami Bullen > CF und zurück etwa 3-6 Monate dauert.
Kann dir Virtualine empfehlen. Die werben auf Exploit auch aktiv damit, dass bei ihnen einige größere DN-Vendor-Shops gehostet werden. Du solltest trotzdem immer mindestens einen Reverse Proxy zwischen den Servern, Cloudflare und dem Internet hängen haben, wie ich hier beschrieben habe. https://c-network.to/threads/hilfe-bei-online-drugshop-gegen-bezahlung.11792/#post-91061 https://virtualine.net/ Ansonsten kann ich noch dedbro.pro empfehlen. Da sind zwar, wie bei jedem Hoster, Drogen verboten, aber das LKA kann ja mal ein Amtshilfeersuchen nach Russland stellen, bei der aktuellen politischen Situation wird es da niemals eine Antwort geben.
Es wäre zu ergänzen, dass zwischen Cloudflare und dem Shop am besten noch ein Reverse Proxy geschaltet werden sollte. So kann verhindert werden, dass die Behörden bei der ersten Anfrage bei Cloudflare die IP des Shops erhalten und der Shop down genommen oder beschlagnahmt wird. Diesen Reverse Proxy sollte man alle ein bis zwei Monate rotieren, damit die nicht einfach bei ner Anfrage an den Rev-Proxy-Hoster, sich die IP deines Backends direkt von der Disk holen. Wichtig wäre außerdem, dass der Shop auf den Ports 443 und 80 nur Verbindungen vom Reverse Proxy zulässt damit deine Backend IP nicht ausversehen geleaked wird.
Hi, das sollte bei Open-Source-Tools eigentlich nicht vorkommen, bei Crypto Wallets kann das aber gelegentlich vorkommen, da sie vom AV gerne mal mit Hidden-Minern verwechselt werden, hatte ich auch schon mit der offiziellen XMR-Wallet. Mach dir keine Sorgen, solange du sie von featherwallet.org heruntergeladen hast.
xss.pro ist die neue Domain, vielleicht kann @exo das ja in seinem Post aktualisieren?
Zufrieden | Neutral | Unzufrieden
Du musst deine Payload bei 5k Infects erstmal undetected bekommen – das ist ein Fulltime-Job und wird normalerweise im Team gemacht. Es hängt davon ab, ob du eine RAT nutzt oder ein HTTP-Botnet, und welche Last du deinen Bots zumutest bzw. wie oft sie nach Hause telefonieren. Für eine RAT würde ich 16 GB RAM und 6–8 vCPU empfehlen, bei einem HTTP-Bot reicht die Hälfte – tendenziell sogar weniger. Problem wird bei dir eher sein bei der Größe das dir ständig die Domains weg geballert werden. Habe in kleinerem Maßstab mit immer Domain Name Generator Algorithmen gearbeitet und bin damit sehr gut gefahren, da hast du dann auch keine Probleme falls dir mal ne Domain oder alle weggemeddelt wird.
Stemmeisen ansetzen und ein wenig hebeln. ^^ Meme: Der Staatsschutz ermittelt.