Vorratsdatenspeicherung in den USA

[Lord_Vader]

Deine Meinung Teile ich nun nicht. Gute Verschlüsselung kann auch ein NSA nicht knacken, ebensowenig unbemerkt in den Verkehr einbrechen, sofern die Zielrechner nicht kompromittiert sind. Gegen mitm und mitschneiden des Datenverkehrs gibt es auch Mittel. Stichwort Forward Secrecy.
Für ein ausführliches Gespräch im Bereich Kryptographie und OS kann ich dir da meinen Dozenten Michael Gisbers empfehlen wenn du da tiefer einsteigen willst. Was die "Freaks" da an Wissen haben ist mir eindeutig zu hoch und das kann ich selbst nicht wiedergeben.
Nur soviel, das es gute Kryptographie gibt die derzeit nicht zu knacken ist. Man macht sich allenfalls verdächtig wenn man diese nutzt. Ansonsten liegt es eben häufig an der eigenen Bequemlichkeit das man unsicher kommuniziert.
Wie gesagt, nutze ich auf dem Smartphone Threema. Da kann ich sicher sein das die NSA so nicht mitlesen kann. Die Kryptographischen Methoden sind bekannt. Natürlich kann es auch hier Bugs geben die Einbrüche gestatten.
Die Alternative wie WhatsApp kann die gesamte Kommunikation von Server ausleiten und weitergeben. Nur, wenn man die Leute fragt warum sie lieber WA einsetzen ist die Antwort meist - Hat jeder, Smilies (im Ernst, das wichtigste! "Argument" überhaupt), Gruppenchat und kostenlos...
Würde jeder Verschlüsselung einsetzen, hätte die NSA ernsthafte Probleme.


Und ja, Linux ist per se nicht sicher, aber eben überprüfbar. Bei CS hat man ja erst garkeine Wahl. Es ist sicher zuviel verlangt das jeder gleich mit Archlinux anfängt und sich selbst alles zusammenbastelt. Auch proprietäre Treiber muss man nicht nehmen. Grundsätzlich aber erschwert es Angriffe und je mehr man selbst davon versteht, desto sicherer wirds.
Besser als Windows auf Geschäftsrechner ist es allemal.
Aber aus deinen genannten Gründen werde ich wohl demnächst auch mein Ubuntu gegen OpenSuse tauschen.

[[FtN|GT] Bob Sacamano]

Selbst Windows-Abstinenz macht dich nicht weniger angreifbar oder schwerer auszuspionieren. Open Source erlaubt dir zwar theoretisch jede Zeile Quelltext einzusehen und auf Hintertüren und Schwachstellen abzuklopfen. Aber wer macht das schon? Selbst eine Linux-Minimalinstallation hat abermillionen Zeilen Quelltext und selbst dann müsstest du noch dem Bau-OS und deinem Compiler voll vertrauen, oder diese ebenfalls evaluieren.

Ja, möglich ist es, dass jemand Abhörprogramme in beispielsweise eine Ubuntu-Minimalinstallation einfügt.
Ich halte es aber für höchst unwahrscheinlich:

• Natürlich kann man alle Quelltexte nicht selbst durchlesen und verstehen. Aber es reicht ja, wenn es die Öffentlichkeit tut: Gerade die Basis-Programme werden von Entwicklern gerne als Referenz genommen. Und bei größeren Projekten sehen sich viele der Mitwirkende bereits die Commits/Diffs an.
• Der Spionage-Code darf keine kritischen Bugs haben! Rock solid C-Code bekommt man nicht an jeder Ecke.
• Ob kommerziell oder privat, gerade mit Linux wird oft jedes Byte geprüft, was über die Leitung geht. Mit den eingebauten Mitteln, tcpdump oder pcap hat man sie schnell in der Hand.

[Toska]

Ich halte es auch für unwahrscheinlich, dass in Mainstream Linux-Distributionen von Hause aus Hintertüren sind. Denkbar wäre es, aber ich stimme euch beiden zu, dass sowas früher oder später auffällt. Da schauen da dann doch zu viele Leute hin.

Aber wie gesagt: Durch eine "man-in-the-middle"-Attacke könnte ein Geheimdienst an den angezapften Backbones dafür sorgen, dass im Rahmen eines stinknormalen online Updates von einem sauberen Mirror statt des sauberen Pakets ein trojanisiertes Updates installiert wird. Signierung und Checksummen nützen da wenig. Kryptographie erledigt sich dann von selbst, wenn einer der beiden Endpunkte einer verschlüsselten Kommunikation kompromittiert worden ist. Da nützt einem auch der beste Algorithmus und die besten Chiffren nichts. Der Hack an sich mag kaum auffallen. Die Kommunikation des Trojaners "nach Hause" ist 'ne andere Geschichte.

Ob kommerziell oder privat, gerade mit Linux wird oft jedes Byte geprüft, was über die Leitung geht. Mit den eingebauten Mitteln, tcpdump oder pcap hat man sie schnell in der Hand.

An sich richtig. Aber Tools auf einem ggf. kompromittierten System ist nicht zu trauen. Die meisten Hacks von Linux-Servern im Rechenzentrum-Umfeld sind halt oft zum Spamversand. Da macht sich keiner die Mühe, Spuren zu verwischen. Durch hohe Server-Last, SPAM-Rückläufer und volles MailQueue fällt das Ganze sowieso eher früher als später auf. Bei Industrie-Spionage dagegen sieht das anders aus und da sieht man in der Forensik dann ggf. schon mal Dinge, die nicht so alltäglich sind und bei denen sich recht clevere Leute richtig viel Mühe gegeben haben.

Anfang letzten Jahres hatte ich 'nen Fall, da hat ein Kunde "Unregelmäßigkeiten" seines wichtigsten Systems nur dadurch bemerkt, dass im Log der vorgeschalteten Firewall eine (kleine) Anzahl von SSH-Verbindungen aus unbekannter Quelle war. Obwohl das Zielsystem nur key-basiertes SSH von einem einzigen externen Host erlaubt. Mit Bordmitteln konntest du dich auf dem Server austoben wie du wolltest. Die Büchse hat dir nach Strich und Faden die Hucke vollgelogen und sich dabei nur in winzigsten Details verraten. "rpm", RPM-Datenbank, "lsof", "procps", Prozessliste unter /proc, tcpdump ... alles größtenteils stimmig und nicht sonderlich auffällig. Dank trojanisierten Binaries (inklusive "rpm") und einem hübsch maskierten Kernel-Modul konnte man dem nur auf die Schliche kommen, wenn man das OS von einem sauberen Medium bootete und mit garantiert sauberen Tools die Analyse machte. Selbst beim Ausführen der sauberen Tools von einem read-only Medium wurde man verarscht, solange das System mit dem eigenen Kernel lief. Unterm Strich war das noch einer der eher "invasiven" Hacks des letztes Jahres, da man dem Ganzen durch extern gelagerte Checksummen leicht auf die Schliche hätte kommen können. Um es bildlich auszudrücken: Vor einigen Jahren reichte die Lupe für die IT-Forensik. Heute brauchst du teilweise das Elektronen-Raster-Mikroskop. Forensik an laufenden Systemen mit deren Bordmitteln (sofern es keine Dilettanten-Hacker waren) sollte an sich nur dazu dienen, sich einen generellen Überblick zu verschaffen.

Wenn man sich anschaut, dass STUXNET in nur zweieinhalb Jahren entstanden ist und welches interdisziplinäres Wissen für diesen speziellen Anwendungsfall (Sabotage von Uran-Anreicherungs-Zentrifugen, die mit Siemens SPS'en gesteuert wurden) nötig war (und welche Ressourcen!), dann sollte man an sich schon damit rechnen können, dass die betreffenden Geheimdienste zum Hacken von Betriebssystemen von der Stange deutlich mehr investieren. Und Ubuntu, Fedora, RHEL und dessen Clone zähle ich da mal ganz frech mit zu den OS'en von der Stange. Denn sowohl von der Verbreitung her als auch mit Rücksicht auf ihre speziellen Anwendungsfälle sind sie sicherlich von Interesse. Server-OS'e dabei eher mehr, als reine Desktop-Distributionen. Es mag zwar was bringen, einzelne wichtigen Desktops in einer Firma zu verwanzen. Wenn du jedoch Zugriff auf die Kern-Elemente der Firmen-IT bekommst (Mailserver, Groupware, die MySQL-Datenbank und das interne Dokumenten-System), dann ist das der wahre Jackpot.

[[FtN|GT] Bob Sacamano]

Jupp, dem eigenen Sytem sollte man nicht trauen.
Aber es ist zB keine Seltenheit, dass Protokolle implementiert werden, wobei man sich Sender und Empfänger genau ansieht. Vielleicht ist eines der beiden Systeme eine Distro von der Stange - das andere ein selbstgebautes Embedded-Linux... Spätestens dann mach die Ubuntu-Spionagesoftware Schlagzeilen

Die Anekdote mit den trojanisierten Binaries ist mal wirklich interessant! Von solchen Fällen hab ich bislang nicht gehört.

[Toska]

Jupp, dem eigenen Sytem sollte man nicht trauen.
Aber es ist zB keine Seltenheit, dass Protokolle implementiert werden, wobei man sich Sender und Empfänger genau ansieht. Vielleicht ist eines der beiden Systeme eine Distro von der Stange - das andere ein selbstgebautes Embedded-Linux... Spätestens dann mach die Ubuntu-Spionagesoftware Schlagzeilen

Oh ja. :-)

Als ich noch in Deutschland war, hatte ich lange Jahre zwei Büchsen vor der Firewall: Das eine war ein Honeypot-System, an dem sich möchtegern-Hacker austoben konnten. Das Ding hat alle möglichen Dienste mit jede Menge Lücken vorgegaukelt. Wenn die jemand ausnutzen wollte, wurde die IP des Angreifers an die Firewall weitergegeben, die dann den Rest des Netzes für ihn geblockt hat. Das andere System war ein Cobalt RaQ2, auf dem eine Uralt-Version eines Cobalt Linux lief (seit ca. 1998 ungepatched). Wegen MIPS Architektur und händisch deinstalliertem Compiler konnte man damit auch Angreifer zur Verzweiflung bringen. Vorkompiliertes Zeugs lief dort nicht (sofern es nicht auf einem kompatiblen MIPS Linux vor-kompiliert worden war. Das Ding ist in 10 Jahren "nur" viermal gehackt worden und keiner hat was damit anfangen können oder wollen.

Die Anekdote mit den trojanisierten Binaries ist mal wirklich interessant! Von solchen Fällen hab ich bislang nicht gehört.

Trojanisierte Binaries, (die andere Dinge machen, als man eigentlich von ihnen erwartet) sind an sich bei Hacks nicht so selten. Nur macht sich in der Regel keiner die Mühe, die per RPM's abzuliefern und macht dann noch so einen Mordsaufwand, intakte RPM Checksummen vorzugaukeln. Diesen Februar hatte jemand die Support-Datenbank von Plesk gehackt und Zugangsdaten von Kunden-Server abgegriffen, die diese für Plesk-Support dort hinterlegt hatten. Im Zuge dessen kam es dann (auch auf nicht-Plesk-Systemen) dieser Kunden zu Einbrüchen, sofern dort dooferweise die gleichen Passwörter verwendet wurden. Und ja, manche Kunden sind halt so <seuftz>.

Dabei wurde dann eine trojanisierte Version von libkeyutils.so.1.9 installiert (jeweils die für X86 und X86_64 passende Version. Das Ding war schon geil gemacht. Normalerweise ist libkeyutils nicht installiert (zumindest in userer Distri nicht). Aber es ist im RHEL, CentOS oder Scientific Linux Repository vorhanden und kann bei Bedarf nachinstalliert werden. Die trojanisierte Version hat sich in OpenSSH einklinkt und erlaubte dem Angreifer Logins, die nicht protokolliert wurden. Fast alle dann vom Angreifer ausgeführten Aktionen wurden nicht protokolliert. Weder syslog, __syslog_chk, audit_log_user_message, audit_log_acct_message funktionierten dann für die Prozesse, die der Hacker auslöste. Auch der write() hook nach STDERR war abgedreht. Unterm Strich ist dieser Angriff auch nur wieder zum SPAM-Versand im großen Stil genutzt worden. Die Sendmail-Transkationen wurden ebenfalls nicht mitprotokolliert und man konnte die SPAM's bestenfalls kurz im mailqueue sehen, bevor sie rausgejagt wurden.

Das auf den ersten Blick gemeine war halt: OpenSSH selbst war komplett in Ordnung. Durch die zusätzlich installierte trojanisierte Library stand dem Angreifer dann jedoch per SSH Tür und Tor weit offen - mit eingebauter Tarnkappe. Über "lsof", Auswertung von /proc, "netstat" und natürlich RPM-Datenbank (Vorwärts- und Rückwärtsabgleich aller Files) konnte man dem aber relativ schnell auf die Schliche kommen.

[Herr Rossi]

Welch ein Aufwand für ein wenig SPAM-Versand oder ist das der Level an Hacks, den man mittlerweile ganz nebenbei beim Einkauf eines Kits erhält?
Zumal der ganze Aufwand der Verhüllung ja nicht vermeiden kann, dass man doch recht schnell mitbekommt, wenn der eigene Server / IP in den diversen SPAM-Blacklists landet.

[Waterhouse]

Toska, Du bist ein cleverer Hund!!!

[Toska]

Welch ein Aufwand für ein wenig SPAM-Versand oder ist das der Level an Hacks, den man mittlerweile ganz nebenbei beim Einkauf eines Kits erhält?
Zumal der ganze Aufwand der Verhüllung ja nicht vermeiden kann, dass man doch recht schnell mitbekommt, wenn der eigene Server / IP in den diversen SPAM-Blacklists landet.

Das ist 'ne gute Frage. Entsprechende Kits oder Exploit-Sätze zirkulieren angeblich in gewissen Kreisen und sind entweder gegen Tausch oder Kohle zu haben. Gesehen hab ich das noch nicht, aber ich halte das durchaus für glaubwürdig. Penetrations-Tools und Tools für Brute-Force Passwort-Attacken gibts dagegen wie Sand am Meer - in entsprechend guter oder schlechter Qualität. Die steht und fällt meistens mit der Art der Authentifizierung und der Qualität der Benutzername/Passwort-Liste. Schau dir den Hack gegen Ubi-Soft an. Oder den gegen SOE vor längerem. Auch da wurden in großem Umfang Kundendaten abgegriffen. Name, Anschrift, Email, Benutzername und Passwort. Da ist sicherlich der eine oder andere Nutzer dabei, der für alles (private Email, Paypal, Ebay, diverse Online-Dienste oder Spiele) die gleichen Zugangsdaten verwendet. Solche Listen sind dann (besonders, wenn sie frisch sind) in gewissen Kreisen möglicherweise was wert. Auf jeden Fall sind sie für den, der sie hat, sicherlich nützlich.

SPAM-Versand war schon immer lukrativ und lässt sich an der einfachen Milchmädchen-Rechnung verdeutlichen: 50 Millionen SPAM's verschickt. Am beworbenen Produkt pro Klick oder pro Verkauf (je nach Deal) 10 Cent verdient. 0.5% der Empfänger haben zugeschlagen. Das sind dann 25.000 EUR, die hängen bleiben. Selbst wenn du die 10 Cent Erfolgsprämie reduzierst oder die Erfolgsquote noch niedriger ansetzt: Es ist noch immer 'ne Menge Schotter für relativ wenig Aufwand und ein lächerlich geringes Risiko. Sofern der Angreifer keine IP aus dem Inland verwendete, wird da kein Strafverfolger wirklich tätig und dementsprechend kommen auch nur die allerwenigsten Fälle überhaupt zur Anzeige. Das Problem ist halt eher, 50 Millionen mehr oder minder aktuelle Email-Adressen zu sammeln. Das ist der Teil, der nicht von heute auf morgen geht, sofern man nicht etwas Geld in die Hand nimmt.

Die meisten "Hacks" die ich im RZ-Umfeld so sehe, sind unterm Strich auf Brute-Force Login-Attacken zu reduzieren. Da hat keiner "root"-Zugang bekommen und der "gehackte" normale Benutzer-Account wurde/wird zum SPAM-Versand benutzt, bis es einem auffällt. Die meisten Hobby-Admins sind dann schon überfordert, wenn es nur darum geht, aus den Logs auf den verursachenden Account zu schließen. Traurig aber wahr.

Die etwas intelligenteren Programme benutzen SMTP zum Check ob der Benutzername existiert. Per "RCPT to" geht das einfach am schnellsten, da man nicht für jeden Benutzernamen die Verbindung zu und wieder aufmachen muss. Email wird dabei keine verschickt, aber Sendmail/Postfix (oder was sonst so läuft) meldet fix, ob der Benutzer existiert oder nicht. Erst wenn die eine Liste von "guten" Benutzernamen haben, läuft der Passwort-Check drüber. So'n Verhalten sieht man recht gut in den Logfiles und ordentliche Brute-Force Detektoren setzen da an und sperren die verursachende IP einfach.

Da gibt es reihenweise Lösungen von der Stange, oder man schustert sich selbst was zusammen. Egal ob Dfix, BFD, IPTables-Recent ... alles ist besser als nichts. Und SSH am besten ohne Passwort-Auth sondern nur mit Key-basiertem Auth betreiben. Oder gleich per Firewall den Zugriff auf den SSH-Port nur von gewissen IPs erlauben. Problematisch wird es, wenn Botnetze im Spiel sind und diese für die Brute-Force Attacken gegen die Login-Dienste genutzt werden. Sieht man leider mit zunehmender Häufigkeit im RZ-Umfeld. Dein Tool blockt eine IP nach X Fehlversuchen und der kommt sofort von 'ner anderen IP wieder und macht an der Stelle im Alphabet weiter, wo der letzte geblockte Besucher aufgehört hat.

[Toska]

Toska, Du bist ein cleverer Hund!!!

Nicht clever genug. Hab leider seit 15 Jahren ständig mit dem Scheiß zu tun. Dabei würd' ich mich lieber aufs Programmieren beschränken, aber das wird zu schlecht bezahlt.

[Herr Rossi]

SPAM-Versand war schon immer lukrativ und lässt sich an der einfachen Milchmädchen-Rechnung verdeutlichen: 50 Millionen SPAM's verschickt. Am beworbenen Produkt pro Klick oder pro Verkauf (je nach Deal) 10 Cent verdient. 0.5% der Empfänger haben zugeschlagen. Das sind dann 25.000 EUR, die hängen bleiben. Selbst wenn du die 10 Cent Erfolgsprämie reduzierst oder die Erfolgsquote noch niedriger ansetzt: Es ist noch immer 'ne Menge Schotter für relativ wenig Aufwand und ein lächerlich geringes Risiko. Sofern der Angreifer keine IP aus dem Inland verwendete, wird da kein Strafverfolger wirklich tätig und dementsprechend kommen auch nur die allerwenigsten Fälle überhaupt zur Anzeige. Das Problem ist halt eher, 50 Millionen mehr oder minder aktuelle Email-Adressen zu sammeln. Das ist der Teil, der nicht von heute auf morgen geht, sofern man nicht etwas Geld in die Hand nimmt.

Ist das jetzt einfach mal ins Blaue hinnein geschätzt oder gibt es dazu Erhebungen? Wenn ja, dann würden mich weitergehende Infos interessieren.
Ich weiss durchaus aus meinem beruflichen Alltag, dass du die Leute so ziemlich mit allem kriegen kannst. Irgendwo ist immer einer, der auf die ein oder andere Masche reinfällt. Wir hatten z.B. mal einen Wirtschaftsberater, der tätsächlich 100 EUR mit seiner Kreditkarte aufgrund eines GVU-Trojaners bezahlt hat. Dabei predigen wir seit ewig, dass die uns bei sowas anrufen sollen. Zu dieser Art von Trojanern gab es übrigens auch mal eine Untersuchung von Kaspersky, die zum Ergebnis hatte, dass die mit den Dingern Millionen machen müssen.

Die meisten "Hacks" die ich im RZ-Umfeld so sehe, sind unterm Strich auf Brute-Force Login-Attacken zu reduzieren. Da hat keiner "root"-Zugang bekommen und der "gehackte" normale Benutzer-Account wurde/wird zum SPAM-Versand benutzt, bis es einem auffällt. Die meisten Hobby-Admins sind dann schon überfordert, wenn es nur darum geht, aus den Logs auf den verursachenden Account zu schließen. Traurig aber wahr.

Jo, das kann ich wohl bestätigen. Meine Logs sind auch ordentlich gefüllt mit Login-Versuchen. In der Vergangenheit habe ich zwar auch immer fleißig den root Account gesperrt, zeitweise auch mal Keys verwendet (wurde mir aber zu umständlich) und ebenfalls diverse iptables Sets gebastelt. Mittlerweile lasse ich das aber. Ein dickes Passwort, hin und wieder geändert und natürlich von Zeit zu Zeit mal in die Logs geschaut... die meisten Brute-Force Attacken sind einfach nur stupide simpel und keine echte Gefahr. Wahrscheinlich reicht es aber dennoch, um den ein oder anderen schlecht eingerichteten Server mitzunehmen.

Die etwas intelligenteren Programme benutzen SMTP zum Check ob der Benutzername existiert. Per "RCPT to" geht das einfach am schnellsten, da man nicht für jeden Benutzernamen die Verbindung zu und wieder aufmachen muss. Email wird dabei keine verschickt, aber Sendmail/Postfix (oder was sonst so läuft) meldet fix, ob der Benutzer existiert oder nicht. Erst wenn die eine Liste von "guten" Benutzernamen haben, läuft der Passwort-Check drüber. So'n Verhalten sieht man recht gut in den Logfiles und ordentliche Brute-Force Detektoren setzen da an und sperren die verursachende IP einfach.

Das ist übrigens einer der Gründe, weshalb ich meinen Mail-Server alles annehmen lasse und die Filterung per Spam-Aussortierung erledige. Hat mich zwar ein paar Tage Arbeit gekostet aber ergänzt um eine bald 10 Jahre alte Bayes Datenbank kommt da praktisch nix mehr durch und keiner kann aufgrund reiner Rumprobiererei erkennen, welche Adressen existieren und welche nicht.

Da gibt es reihenweise Lösungen von der Stange, oder man schustert sich selbst was zusammen. Egal ob Dfix, BFD, IPTables-Recent ... alles ist besser als nichts. Und SSH am besten ohne Passwort-Auth sondern nur mit Key-basiertem Auth betreiben. Oder gleich per Firewall den Zugriff auf den SSH-Port nur von gewissen IPs erlauben. Problematisch wird es, wenn Botnetze im Spiel sind und diese für die Brute-Force Attacken gegen die Login-Dienste genutzt werden. Sieht man leider mit zunehmender Häufigkeit im RZ-Umfeld. Dein Tool blockt eine IP nach X Fehlversuchen und der kommt sofort von 'ner anderen IP wieder und macht an der Stelle im Alphabet weiter, wo der letzte geblockte Besucher aufgehört hat.

Sind alles Ansätze, die man umsetzen kann. Ich lasse es aber mittlerweile. Alles was ich bisher an Befall hatte kam eh von innen, meistens über den Webserver. Key-basierte Authentifizierung ist ein Ansatz, aber ein komplexes Passwort reicht imo auch. Ab einem bestimmten Level kommt man da mittels Bruteforce nicht wirklich weit. Zumal der Key dir auch geklaut werden kann und meine Praxiserfahrung war halt nicht selten, dass ich irgendwo anders unterwegs war, Zugriff brauchte, aber den Key nicht dabei hatte....

[Toska]

Hi Rossi,

Ist das jetzt einfach mal ins Blaue hinnein geschätzt oder gibt es dazu Erhebungen? Wenn ja, dann würden mich weitergehende Infos interessieren.

Gibt es sicherlich, aber ich hab da nichts greifbar. Da ich für Kundenserver seit vielen Jahren eine angepasste SpamAssassin und Clam AV Lösung baue, bin ich natürlich an dem Thema interessiert und lese alles mögliche, was es dazu gibt. Auf theregister.co.uk war vor einigen Jahren mal ein Interview mit einem der großen Spammer und der hat ein bischen aus dem Nähkästchen geplaudert. War interessant.

Ich weiss durchaus aus meinem beruflichen Alltag, dass du die Leute so ziemlich mit allem kriegen kannst. Irgendwo ist immer einer, der auf die ein oder andere Masche reinfällt. Wir hatten z.B. mal einen Wirtschaftsberater, der tätsächlich 100 EUR mit seiner Kreditkarte aufgrund eines GVU-Trojaners bezahlt hat. Dabei predigen wir seit ewig, dass die uns bei sowas anrufen sollen. Zu dieser Art von Trojanern gab es übrigens auch mal eine Untersuchung von Kaspersky, die zum Ergebnis hatte, dass die mit den Dingern Millionen machen müssen.

Ja, das ist nicht ohne. Vor etwa zwei Monaten erhielt ich eine Email, die auf den ersten Blick von meinem Vater war. Absender-Adresse stimmte fast. Nur war halt statt einem "O" eine Null am Ende des Account-Namens des AOL Accounts (ja, ich weiß). Hatte ihm ein Postfach bei mir eingerichtet, aber dafür ist er zu bequem. Die Mail war recht weinerlich verfasst. Er sei auf den Philippinen ausgeraubt worden und bräuchte Geld, um das Hotel und das Rückflugticket zu bezahlen. Alles soweit recht schick gemacht. Nur schreibt mein Dad mir halt nicht in Englisch und ich wusste: An dem Wochenende ist er an der Mosel und nicht auf den Philippinen.

Später stellte sich heraus: Sein Laptop war gehackt worden. Die Mail ging an alle Kontakte in seinem Thunderbird-Adressbuch und an alle, von denen er Mail in der AOL-Inbox und der Inbox auf meinem Server hatte. Der Angreifer hat extra ein AOL-Konto mit ähnlich klingendem Namen aufgemacht. Ein spanischer Geschäftspartner von meinem Vater hat tatsächlich 2500 EUR per Western Union losgeschickt, die natürlich futsch sind.

Leute sind halt so. Der Spanier hat alle Nummern - auch die Privatnummer der Familienwohnung und Handy. Das ganze vielleicht mal telefonisch abklären? Wäre ja zu einfach.

Jo, das kann ich wohl bestätigen. Meine Logs sind auch ordentlich gefüllt mit Login-Versuchen. In der Vergangenheit habe ich zwar auch immer fleißig den root Account gesperrt, zeitweise auch mal Keys verwendet (wurde mir aber zu umständlich) und ebenfalls diverse iptables Sets gebastelt. Mittlerweile lasse ich das aber. Ein dickes Passwort, hin und wieder geändert und natürlich von Zeit zu Zeit mal in die Logs geschaut... die meisten Brute-Force Attacken sind einfach nur stupide simpel und keine echte Gefahr. Wahrscheinlich reicht es aber dennoch, um den ein oder anderen schlecht eingerichteten Server mitzunehmen.

Klar, für den eigenen Server, auf dem man jeden Nutzer persönlich kennt kann man natürlich ganz anders agieren, als auf Büchsen die von Hinz und Kunz genutzt werden. "Seine" Nutzer kann man ggf. noch erziehen. Wenn ich Support auf Kundenservern mache, muss ich halt technische Maßnahmen vorschieben um zu verhindern, dass ein Hobby-Site-Admin den Benutzer "test" mit Passwort "test" anlegt. Alles schon dagewesen. Und manche technische Sicherheitsmaßnahme, die man gerne vorschieben würde, muss aus "Kundenfreundlichkeit" den Kunden meines Kunden gegenüber wegfallen. Das sind dann Sachen, die unterm Strich den Sicherheitsstandard senken und mehr Überwachung und Vorsicht erfordern.

Das ist übrigens einer der Gründe, weshalb ich meinen Mail-Server alles annehmen lasse und die Filterung per Spam-Aussortierung erledige. Hat mich zwar ein paar Tage Arbeit gekostet aber ergänzt um eine bald 10 Jahre alte Bayes Datenbank kommt da praktisch nix mehr durch und keiner kann aufgrund reiner Rumprobiererei erkennen, welche Adressen existieren und welche nicht.

Interessanter Ansatz. Mein Bayes lasse ich generell nur auf auto-learn laufen und muss es daher ab und an mal wegen "Bayes-poisoning" ausmisten. Halt wenn zu viele kurze Mails mit Müll durchgegangen sind, die bei zukünftigen SPAM-Mails die Erkennungsschwelle senken. Ich gehe eher den anderen Ansatz: Blacklisten noch und nöcher. Alle "unallocated" Adressbereiche, bekannte SPAM-Netze, diverse Spamhaus und DynaRats Blacklisten werden in SpamAssassin eingebunden und vergeben Punkte. URLs im Nachrichtenbody werden ebenfalls geprüft. Dann gibts da noch RBL-Country. Je nach Land der Absende-IP oder der Relays vergebe ich ebenfalls Punkte. Mails aus Asien (Minus Japan, AU & NZ) bekommen extra-Punkte. Alle ex-UdSSR Staaten und Balkan sowieso. Alles mit mehr als 10 Punkten wird direkt an der MTA rejected. Alles mit mehr als fünf Punkten landet im SPAM-Ordner. Dazu noch Greylisting und 1.00 Extra-Punkte für alle Emails von unbekannten Absendern und auf einmal wird es erstaunlich ruhig im Postfach. :-)

Sind alles Ansätze, die man umsetzen kann. Ich lasse es aber mittlerweile. Alles was ich bisher an Befall hatte kam eh von innen, meistens über den Webserver. Key-basierte Authentifizierung ist ein Ansatz, aber ein komplexes Passwort reicht imo auch. Ab einem bestimmten Level kommt man da mittels Bruteforce nicht wirklich weit. Zumal der Key dir auch geklaut werden kann und meine Praxiserfahrung war halt nicht selten, dass ich irgendwo anders unterwegs war, Zugriff brauchte, aber den Key nicht dabei hatte....

Oh? Das ist interessant. Ich mach' an sich alles nur noch per SSH-keys. Auf Linux Laptop und Linux Workstation hab' ich die selben SSH-Keys. Per Klick auf ein oder mehrere Icons baut mir meine Büchse diverse Shell-Fenster mit getabbten SSH-Verbindungen auf. Ein Icon für alle eigenen Server und dann halt weitere für diverse Kunden-Systeme. Falls ich wirklich mal mobil auf irgendwas drauf muss, hab ich ein Minimal-VPS, von dem aus ich mich von überall her per Benutzername und ziemlich gutem Passwort auf der Workstation daheim oder auf einem Virtual Desktop in einer VM auf einem meiner Server einloggen kann. Das geht aber nur, wenn vorher in der richtigen Sequenz an gewisse Ports der Firewall angeklopft wurde. SSH ist halt überall per Firewall geblockt und nur für ganz bestimmte IP's offen, oder erfordert vorheriges "anklopfen". Mit der Sicherheit muss ich es leider recht ernst nehmen und bei gewissen Büchsen auch schon mal bis ins Exzessive. Meine Linux-Distri läuft auf knapp 20.000 Servern. Wenn jemand meine Toplevel YUM Repositories oder die Bau-Büchsen hackt, auf denen ich die RPMs und ISO's baue, dann wäre das mehr als peinlich. Aber mit guten Passwörtern alleine ist man auch schon recht gut geschützt. Und ja, recht viel Mist kommt halt durch die Hintertür über die Webserver und diverse Apps. 2008 hatte ich (aus Resourcenmangel) noch YUM-Repository (2nd Level) und Webserver auf einer Büchse. Hab das ganz fix gelassen und schön sauber getrennt.

Aber ich hab (fast) den ganzen Kram halt in einem RZ in den USA und da mache ich mir halt schon Gedanken, ob das weiterhin sinnvoll ist.

[Lord_Vader]

Das die NSA da einfach drauf zugreifen kann, ist ja nun bekannt. Wäre nur die Frage wohin du gehen könntest. Es gibt ja nu kaum ein Land das nicht das Recht herausnimmt auf alles Zugreifen zu dürfen. Abgesehen davon das die Infrastruktur nicht in jedem Land gut ausgebaut ist.
Wenn man mal so nachdenkt, ist das schon unheimlich das die "Dienste" einfach so auf deinen Servern herumspazieren dürfen. Ausser der Kiste im eigenen Haus ist ja irgendwie nichts sicher.
Nur was tun. Insofern hast du schon recht das da Verschlüsselung nur bedingt was nutzt, wenn der 3Mann direkten Zugriff hat und dir alles mögliche unterschieben kann.
Und alles im Namen der Terrorbekämpfung/Wirtschaftsspionage.

[cubi]

Apropos Kiste im eigenen Haus: Warum wohl die Breitbandanbindungen hier so lausig sind und in Zukunft noch lausiger werden?

[Toska]

Das die NSA da einfach drauf zugreifen kann, ist ja nun bekannt. Wäre nur die Frage wohin du gehen könntest. Es gibt ja nu kaum ein Land das nicht das Recht herausnimmt auf alles Zugreifen zu dürfen.

Genau, das ist die gute Frage. USA, UK und Deutschland fallen flach. In anderen Ländern wird es vermutlich aber auch nicht besser aussehen.

Wenn man mal so nachdenkt, ist das schon unheimlich das die "Dienste" einfach so auf deinen Servern herumspazieren dürfen. Ausser der Kiste im eigenen Haus ist ja irgendwie nichts sicher.
Nur was tun. Insofern hast du schon recht das da Verschlüsselung nur bedingt was nutzt, wenn der 3Mann direkten Zugriff hat und dir alles mögliche unterschieben kann.
Und alles im Namen der Terrorbekämpfung/Wirtschaftsspionage.

Ist leider wahr. Der Faschismus ist wieder da. Nur trägt er heute Bibel, Unabhängigkeitserklärung und Anti-Terror-Gesetze unterm Arm. In seinen KZ's fehlt zwar die Gaskammer, aber dafür gibts ja die Drohnen.

Selbst wenn du die Kisten im eigenen Haus hast, über die weiter oben beschriebenen Methoden käme man auch noch ran. Nur ist es halt die Frage, ob die sich die Mühe machen, oder in wieweit sowas automatisiert ist.

Kisten im eigenen Haus ist leider auch nicht so ganz das wahre. Ich hatte von 2001 bis 2011 'ne Abstellkammer im Haus zum Server-Raum umfunktioniert. Inklusive Klima-Anlage. Zu Spitzenzeiten (also Anfangs) hatte ich bis zu 27 Server laufen. Durch Virtualisierung und Auslagerung in RZ's dann immer weniger. Zum Schluss waren es noch 5 Büchsen. Drei davon mit Entwickler-VPS'en, der Rest halt Firewall und Fileserver. Das geht dank der Strompreise zuletzt richtig ins Geld. Selbst in den Monaten, wo man keine Klimaanlage braucht. Auf dem Land war zudem nur 2.5Mbit SDSL mit festen IP's zu bekommen. Für 'n bissel Hobbykram ins Netz zu stellen reicht das.

Für das Projekt? Kann man knicken. Meine Büchsen in den USA schieben im Tages-Peak 60Mbit/sec an Daten raus (wenn die Slave-Mirror replizieren). Im Durchschnitt liegt die Netzauslastung meist so um die 8-10Mbit/sec. Das bekommt man aus 'ner Besenkammer in Deutschland nicht gestemmt. Sofern man keinen Anbieter hat, der einem 'ne Glasfaser in den Keller legt. Und dafür zahlt man halt noch Mondscheinpreise.

Hier in Kolumbien könnte ich 30, 50 oder 100Mbit Glasfaser-Anschluss fürs Home-Office bekommen. In der Stadt kein Problem. 30Mbit + Flat sollen umgerechnet ca. 330 EUR im Monat kosten, was knapp über dem Preis von meinem 2.5Mbit SDSL von damals liegt. Ich hatte das anfangs ernsthaft ins Auge gefasst. Aber bei den Preisen für die Installation waren die mir zu "unscharf". 500m Verlegung von Glasfaser im Installationspreis (eine Monatsmiete) inbegriffen. Ob die 500m reichen und was es ab Meter 501 kostet, konnte oder wollte man nicht sagen. Das fand ich dann weniger professionell und habs nach einigem nachbohren gelassen. Ohne Server in Haus reichen 8Mbit Downlink auch.

Apropos Kiste im eigenen Haus: Warum wohl die Breitbandanbindungen hier so lausig sind und in Zukunft noch lausiger werden?

Weil der NSA-Shunt im Glasfaser 30-50% der Photonen abfängt?

Kann mich noch dumpf an Merkel's Wahlverspechen erinnern: Breitband-Ausbau in D-Land um die "Zukunftssicherheit des Standorts D-Land zu gewährleisten". Aber jetzt ist das auf einmal alles "Neuland". Ja, nee. Ist klar.

[Herr Rossi]

Ach ja, das Elend mit den synchronen Leitungen. Das ist teilweise schon ziemlich absurd. Da kriegt man ein VDSL 50/10 Mbit/s für luschige 50 EUR im Monat, soll dann aber für 4Mbit/s synchron direkt mal locker das vierfache abdrücken, weil in dem Fall dann ja angeblich der Traffic direkt über den Backbone läuft... sowas erzählen die einem wirklich. Dabei liefert in allen Fällen, die ich kenne, der VDSL Anschluss konstant seine 10Mbit/s im Upload. Bei den üblichen Businessanwendungen ist es zudem völlig latte, ob das evtl. dann mal 10ms mehr oder weniger sind.

Weiterhin kann man die Performance des tollen Backbones der Telekom eh immer wieder am Austauschpunkt FFM "bewundern", wenn sich mal wieder Level3 bzw "x beliebiger anderer Anbieter" und die Telekom gegenseitig die Schuld zuweisen, warum das Peering kurz vor tot ist... imo sind die ganzen synchronen business Lösungen einfach nur abzocke. Die spekulieren halt darauf, dass Admins bzw. Firmen gerne auf dem Weg Verantwortung loswerden wollen und dafür dann locker mal ein paar hundert bis tausend EUR locker machen.